http://d.puremagic.com/issues/show_bug.cgi?id=2434

           Summary: Compiler generates code that does not pass with -w for
                    some array operations
           Product: D
           Version: 1.036
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: jarrett.billingsley@gmail.com


T[] a = [1, 2, 3, 4, 5];
a[] = 1 op a;

Replace T with byte, ubyte, short, or ushort.  Replace op with / or %.  For example:

byte[] a = [1, 2, 3, 4, 5];
a[] = 1 / a;

All possible combinations give errors like this when -w is enabled:

warning - Error: implicit conversion of expression (cast(int)c0 /
cast(int)(p1[p])) of type int to byte can cause loss of data

The c0, p1, and p variables are what the compiler uses for internal names when converting array operations into code, so this is an error in the generated code.

Similar things happen if you have something like:

T[] b = [1, 2, 3, 4, 5];
a[] = b[] op a[];


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2434


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |yebblies@gmail.com
         Resolution|                            |FIXED


--- Comment #1 from yebblies <yebblies@gmail.com> 2011-06-10 05:07:30 PDT ---
Currently dmd (1.068 and 2.052) fails to compile these with the following
message:

testx.d(4): Error: incompatible types for ((1) / (a)): 'int' and 'byte[]'

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2434


Jarrett Billingsley <jarrett.billingsley@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


--- Comment #2 from Jarrett Billingsley <jarrett.billingsley@gmail.com> 2011-07-13 11:50:47 PDT ---
So the compiler now requires that I put [] on operands in array operations, but the bug has NOT been fixed.

T[] a = [1, 2, 3, 4, 5];
a[] = 1 op a[];

Still fails with the same warning when -w is thrown, and the last example still fails as well.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2434


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com
            Version|1.036                       |D1 & D2
            Summary|Compiler generates code     |Need a way to add casts
                   |that does not pass with -w  |into array operations.
                   |for some array operations   |
         OS/Version|Windows                     |All
           Severity|normal                      |enhancement


--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-07-13 12:37:32 PDT ---
hm... shouldn't the calculation follow the same rules as an individual operation?

for example

byte b;
b = 1 / b;

This has the same error message, so I would assume that an array operation must obey the same rules.

The biggest issue here is, how does one create an expression which circumvents the requirement?

In my above example, you can do:

b = cast(byte)(1 / b);

but this doesn't work:

a[] = cast(byte)(1 / a[]);
or
a[] = cast(byte[])(1 / a[]);

So essentially there is no way to insert a cast into the array expression.  I
think we almost need a new syntax for this (maybe cast[](byte)? )

I'm going to rename the bug (and adjust properties accordingly) because the code you wrote is *supposed* to give an error.  The issue is that there's no way to cast out of it!

Note the reason D2 does not give an error (with or without -w) on your original code is because of range propagation.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2434



--- Comment #4 from Jarrett Billingsley <jarrett.billingsley@gmail.com> 2011-07-13 12:40:02 PDT ---
Range propagation "fixes" it, but the bug only manifests in D1 because of the ridiculous rules regarding integer math. (1 / a) where a is a ubyte is of type "int", not of type "ubyte". But the problem doesn't manifest with 32- or 64-bit integers.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2434



--- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-07-13 12:46:35 PDT ---
Hm, I take it back.  This doesn't compile on D2, so maybe range propagation isn't smart enough.

int x = 1;
byte b = 1 / x;

Same error reported

Now I really don't know why D2 passes the array operation...

I still think the right solution is allowing casting in an array expression.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2434



--- Comment #6 from kennytm@gmail.com 2011-07-13 13:09:26 PDT ---
(In reply to comment #5)
> Hm, I take it back.  This doesn't compile on D2, so maybe range propagation isn't smart enough.
> 

There is no way VRP will support this. After the statement 'int x = 1', the information that 'x == 1' is lost. We don't have data flow analysis. So in the expression '1 / x', x is treated as having the complete range of 'int'.

In the current implementation of VRP, since the divisor contains 0, the result will be the complete range, so '1 / x' still gives the complete range of 'int', not [-1, 1].

</off-topic>

> int x = 1;
> byte b = 1 / x;
> 
> Same error reported
> 
> Now I really don't know why D2 passes the array operation...
> 
> I still think the right solution is allowing casting in an array expression.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2434



--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-07-13 13:27:56 PDT ---
(In reply to comment #6)
> There is no way VRP will support this. After the statement 'int x = 1', the information that 'x == 1' is lost. We don't have data flow analysis. So in the expression '1 / x', x is treated as having the complete range of 'int'.

I was taking this into account.

if the divisor is zero, you get a floating point exception (i.e. SIGFPE), so VRP is able to safely use [-1, 1] as the range.

Technically, the set of possible values is [1, -1, undefined], and we can simply ignore the undefined part for VRP.

Indeed the example is quite questionable, but I suppose if you know none of the values are 0, it's valid code.

In any case, I don't think VRP is the answer to the problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------