www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2434] New: Compiler generates code that does not pass with -w for some array operations

reply d-bugmail puremagic.com writes:
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[];


--
Oct 28 2008
next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jun 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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                       |



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: -------
Jul 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jul 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2434




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: -------
Jul 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2434




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: -------
Jul 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2434






 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: -------
Jul 13 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2434




13:27:56 PDT ---


 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: -------
Jul 13 2011