PASS: gcc.c-torture/execute/arith-rand-ll.c execution, -O1 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/arith-rand-ll.c -w -O2 - lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/arith-rand-ll.x2 (timeout = 30 0) PASS: gcc.c-torture/execute/arith-rand-ll.c compilation, -O2 Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc::/test/gnu/gcc/objdir/gcc FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O2
The abort occurs in this block: { signed char xx = x, yy = y, r1, r2; r1 = xx / yy; r2 = xx % yy; if (ABS (r2) >= (unsigned char) ABS (yy) || (signed char) (r1 * yy + r2) != xx) abort (); } for i = 2. The test doesn't fail if I simply reduce the testcase to the above and add a check for yy = 0. My impression is the above fails because the it is using r1 and r2 values from this block: { signed short xx = x, yy = y, r1, r2; r1 = xx / yy; r2 = xx % yy; if (ABS (r2) >= (unsigned short) ABS (yy) || (signed short) (r1 * yy + r 2) != xx) abort (); } These are the values that cause the abort: (gdb) p/x x $79 = 0x1f801ff80ffff (gdb) p/x y $80 = 0x7f8007ffff8007ff (gdb) p/x xx $81 = 0xff (gdb) p/x yy $82 = 0xff (gdb) p/x r2 $83 = 0xff (gdb) p/x r1 $84 = 0x0 The r2 value is wrong.
Introduced by the following change: 2011-10-17 Richard Guenther <rguenther@suse.de> PR tree-optimization/50729 * tree-vrp.c (extract_range_from_unary_expr_1): Remove redundant test. (simplify_conversion_using_ranges): Properly test the intermediate result.
Is (sizeof (int) == sizeof (long long))? What else could be target specific here? VRP is target agnostic ... can you post detail VRP dumps from before and after the patch?
On 27-Oct-11, at 7:21 AM, rguenth at gcc dot gnu.org wrote: > Is (sizeof (int) == sizeof (long long))? What else could be target > specific here? VRP is target agnostic ... can you post detail VRP > dumps > from before and after the patch? No. My debugging indicated that the problem was signed char and short. Maybe the issue is LOAD_EXTEND_OP which is ZERO_EXTEND on pa. I'll work on getting the dumps but it won't be before this evening, maybe weekend. Dave -- John David Anglin dave.anglin@bell.net
Created attachment 25668 [details] vrp dumps
Hm, with a cross I cannot reproduce the IL you posted (on trunk head, that is). Is hppa2.0w-hp-hpux11.11 a host-wide-int 32bit host? (no idea how I can force HWI 32bit here :/) Can you attach -fdump-tree-vrp-details dumps for trunk head?
Created attachment 25737 [details] arith-rand-ll.c.067t.vrp1 On 7-Nov-11, at 6:07 AM, rguenth at gcc dot gnu.org wrote: > Is hppa2.0w-hp-hpux11.11 a host-wide-int 32bit host? (no idea how I > can > force HWI 32bit here :/) No, it's 64 bits. -- John David Anglin dave.anglin@bell.net
On 11/7/2011 6:07 AM, rguenth at gcc dot gnu.org wrote: > Can you attach -fdump-tree-vrp-details dumps for trunk head? Attached.
Created attachment 25738 [details] arith-rand-ll.c.124t.vrp2
Created attachment 25739 [details] xxx.c.067t.vrp1 Weird. My cross configured with /space/rguenther/src/svn/trunk/configure --enable-languages=c,c++,fortran --disable-nls --target=hppa2.0w-hp-hpux11.11 does not reproduce this. I'm using ./cc1 -O2 on arith-rand-ll.c, and I'm getting arith-rand-ll.c: In function 'main': arith-rand-ll.c:59:4: warning: incompatible implicit declaration of built-in function 'abort' [enabled by default] ... not sure if that's related. From your dump file: x_118: [0, +INF] EQUIVALENCES: { x_5 D.2243_12 } (2 elements) xx_56: VARYING D.2297_58: [-32768, 32767] xx_56 = (short int) x_118; Folding statement: D.2297_58 = (int) xx_56; Folded into: D.2297_58 = (int) x_118; should be reproducible with extern void abort (void); long long unsigned int x = 1 << (sizeof (short int) * 8); int main() { if (x >= 0) { short int xx = (short int)x; if (xx != 0) abort (); } return 0; } but that works for me ... does this fail for you? Looking at the above it _appears_ that x is signed!? The reported value-range should be x_5: VARYING which it is indeed when compiling with my cross ... Is, by any chance, the middle-end sizetype == long long unsigned int? And for some weird reason those are mapped together?
On 11/7/2011 10:09 AM, rguenth at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 > > --- Comment #10 from Richard Guenther<rguenth at gcc dot gnu.org> 2011-11-07 15:09:54 UTC --- > Weird. My cross configured with > > /space/rguenther/src/svn/trunk/configure --enable-languages=c,c++,fortran > --disable-nls --target=hppa2.0w-hp-hpux11.11 > > does not reproduce this. I'm using ./cc1 -O2 on arith-rand-ll.c, and I'm > getting > > arith-rand-ll.c: In function 'main': > arith-rand-ll.c:59:4: warning: incompatible implicit declaration of built-in > function 'abort' [enabled by default] > ... I see the same if I remove the "-w" option from the test. > not sure if that's related. > > > From your dump file: > > x_118: [0, +INF] EQUIVALENCES: { x_5 D.2243_12 } (2 elements) > xx_56: VARYING > D.2297_58: [-32768, 32767] > > xx_56 = (short int) x_118; > Folding statement: D.2297_58 = (int) xx_56; > Folded into: D.2297_58 = (int) x_118; > > should be reproducible with > > extern void abort (void); > > long long unsigned int x = 1<< (sizeof (short int) * 8); > > int main() > { > if (x>= 0) > { > short int xx = (short int)x; > if (xx != 0) > abort (); > } > return 0; > } > > but that works for me ... does this fail for you? Looking at the above The above test doesn't fail. I've attached the detail vrp dumps as they don't seem to match what you described below. > it _appears_ that x is signed!? The reported value-range should be > > x_5: VARYING > > which it is indeed when compiling with my cross ... > > Is, by any chance, the middle-end sizetype == long long unsigned int? > And for some weird reason those are mapped together? > Looking at the hwi issue, I see that need_64bit_hwint is not defined for this target, or for the 32-bit hppa-linux target. Test fails on both. However, it doesn't fail on hppa64-hp-hpux11.11 where need_64bit_hwint is defined (long is 64 bits). Suspect a cross from hppa64-hp-hpux11.11 would work.
Created attachment 25740 [details] xxx.c.124t.vrp2
(In reply to comment #1) > The r2 value is wrong. I see the same problem on Epiphany. The result of the modulo operation for short int is recycled for signed char. arith-rand-ll.c.079t.copyrename3 looks OK, but in arith-rand-ll.c.080t.dom1 I see that ill-advised recycling of the modulo result, D.2263_64 in the below dump snippets: <bb 27>: xx_56 = (short int) x_5; # DEBUG xx => xx_56 yy_57 = (short int) y_6; # DEBUG yy => yy_57 D.2260_58 = (int) x_5; D.2261_59 = (int) y_6; D.2262_60 = D.2260_58 / D.2261_59; # DEBUG r1 => (short int) D.2262_60 D.2263_64 = D.2260_58 % D.2261_59; r2_65 = (short int) D.2263_64; # DEBUG r2 => r2_65 D.2266_66 = (int) r2_65; D.2267_67 = ABS_EXPR <D.2266_66>; if (yy_57 >= 0) goto <bb 28>; else goto <bb 29>; ... <bb 31>: r1.4_73 = (short unsigned int) D.2262_60; yy.3_74 = (short unsigned int) y_6; D.2276_75 = r1.4_73 * yy.3_74; r2.5_76 = (short unsigned int) D.2263_64; D.2278_77 = D.2276_75 + r2.5_76; D.2279_78 = (short int) D.2278_77; if (D.2279_78 != xx_56) goto <bb 32>; else goto <bb 33>; ... <bb 37>: xx_89 = (signed char) x_5; # DEBUG xx => xx_89 yy_90 = (signed char) y_6; # DEBUG yy => yy_90 D.2291_91 = D.2260_58; D.2292_92 = D.2261_59; D.2293_93 = D.2262_60; # DEBUG r1 => (signed char) D.2262_60 D.2294_97 = D.2263_64; r2_98 = (signed char) D.2263_64; # DEBUG r2 => r2_98 D.2297_99 = (int) r2_98; D.2298_100 = ABS_EXPR <D.2297_99>; if (yy_90 >= 0) goto <bb 38>; else goto <bb 39>; ... <bb 41>: r1.8_106 = (unsigned char) D.2262_60; yy.7_107 = (unsigned char) y_6; D.2307_108 = r1.8_106 * yy.7_107; r2.9_109 = (unsigned char) D.2263_64; D.2309_110 = D.2307_108 + r2.9_109; D.2310_111 = (signed char) D.2309_110; if (D.2310_111 != xx_89) goto <bb 42>; else goto <bb 43>;
(In reply to comment #2) > Introduced by the following change: > > 2011-10-17 Richard Guenther <rguenther@suse.de> > > PR tree-optimization/50729 > * tree-vrp.c (extract_range_from_unary_expr_1): Remove > redundant test. > (simplify_conversion_using_ranges): Properly test the > intermediate result. I can confirm that backing out this patch makes the arith-rand-ll.c failure go away on Epiphany. Backing out only the first hunk doesn't help. Backing out only the send hunk does. And, FWIW, LOAD_EXTEND_OP is also ZERO_EXTEND on the Epiphany.
Created attachment 25855 [details] Preprocessed testcase for epiphany I can't reproduce the test on gcc20, I think this is a 32 vs. 64 bit build and/or host machine issue. I can reproduce the problem on a 32 bit system: Linux purzah 3.1.1-1.fc16.i686.PAE #1 SMP Fri Nov 11 22:04:40 UTC 2011 i686 i686 i386 GNU/Linux I have used trunk revision 181442 . configured for --target=epiphany-elf . You don't need Epiphany for this, you can just make "all-gcc", and when it has configured the gcc build directory, you can stop the build, cd to the gcc build directory, and build just cc1. compile the preprocessed sources with: ./cc1 -O2 -dumpbase arith-rand-ll.c arith-rand-ll.i -o arith-rand-ll.s -fdump-tree-all in arith-rand-ll.c.080t.dom1, you can see in line 543 r2_98 = (signed char) D.2263_64 earlier, the same ssa variable has been used in r2_65 = (short int) D.2263_64; both uses are, in fact, incorrect, because D.2263_64 is calculated as 32 bit signed modulo of 32 bit x and y.
(In reply to comment #15) I can also replicate this on gcc45 using trunk revision 181496.
Created attachment 25857 [details] Proposed patch Could you test if this also fixes your regressions?
On 11/18/2011 9:05 PM, amylaar at gcc dot gnu.org wrote: > Could you test if this also fixes your regressions? It does. Thanks, Dave
Author: amylaar Date: Thu Dec 1 14:25:24 2011 New Revision: 181880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181880 Log: PR tree-optimization/50802 * tree-vrp.c (simplify_conversion_using_ranges): Rewrite test considering what happens to ranges during sign changes and/or intermediate narrowing conversions. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c
Fixed.