[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #16 from jakub at gcc dot gnu dot org 2008-04-22 10:01 --- Downgrading to P2, the patches so far all seem to be quite risky for the branches, the wrong-code is on a corner case and isn't a recent regression. Regarding the comment #14 patch, I'd say the complete_type should be different from argtype only when !TYPE_UNSIGNED (argtype), for unsigned char or unsigned short the overflow behavior is well defined. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-04-18 12:24 --- With the patch in comment #14 we have === g++ tests === Running target unix FAIL: g++.dg/init/bitfield1.C (test for excess errors) FAIL: g++.dg/gomp/atomic-1.C (test for excess errors) FAIL: g++.dg/torture/pr33887-1.C -O0 execution test FAIL: g++.dg/torture/pr33887-1.C -O1 execution test FAIL: g++.dg/torture/pr33887-1.C -O2 execution test FAIL: g++.dg/torture/pr33887-1.C -O3 -fomit-frame-pointer execution test FAIL: g++.dg/torture/pr33887-1.C -O3 -g execution test FAIL: g++.dg/torture/pr33887-1.C -Os execution test === gcc tests === FAIL: gcc.dg/gomp/atomic-1.c (test for excess errors) FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect vectorized 1 l oops 2 FAIL: gcc.dg/vect/vect-reduc-dot-u16a.c scan-tree-dump-times vect vectorized 1 loops 2 FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/no-scevccp-outer-13.c scan-tree-dump-times vect OUTER LOOP VE CTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-14.c scan-tree-dump-times vect OUTER LOOP VE CTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-16.c scan-tree-dump-times vect OUTER LOOP VE CTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-17.c scan-tree-dump-times vect OUTER LOOP VE CTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-19.c scan-tree-dump-times vect OUTER LOOP VE CTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-21.c scan-tree-dump-times vect OUTER LOOP VE CTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-7.c scan-tree-dump-times vect OUTER LOOP VEC TORIZED. 1 === libgomp tests === Running target unix FAIL: libgomp.c/atomic-10.c (test for excess errors) WARNING: libgomp.c/atomic-10.c compilation failed to produce executable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-04-17 15:09 --- Created an attachment (id=15491) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15491action=view) gimple semantics change patch This is the variant I thought about with changing the way types are interpreted for the *CREMENT_EXPRs. The usual problem with vectorizer tests appear as SCEV doesn't handle for example bb 3: # i_14 = PHI i_7(5), 0(2) D.1560_4 = (int) i_14; a[D.1560_4] = D.1560_4; D.1561_6 = D.1560_4 + 1; i_7 = (short int) D.1561_6; if (i_7 = 63) goto bb 5; else goto bb 4; but for correctness reasons we cannot do the increment in signed short int due to the undefined overflow issue. We can avoid the promotion if the result is truncated to an unsigned type (but this is an optimization that I didn't want to put into this patch addressing correctness only). I will re-test this patch, a slightly oder version tested ok apart from the vectorizer fallout. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #12 from jakub at gcc dot gnu dot org 2008-04-09 14:32 ---
Created an attachment (id=15455)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455action=view)
gcc43-pr35634.patch
Here is the updated FE only patch. One change is that it avoids
P{RE,OST}{IN,DE}CREMENT_EXPR only for the promoting types, and has some
(admittedly very ugly) OpenMP parsing changes to counter that. Unfortunately
unlike #pragma omp for increment, #pragma omp atomic can have some_lvalue++
, not necessarily a variable_name++, so I have no idea how to handle that.
On x86_64 with this patch I get 3 omp failures (2 in libgomp atomic-10.c, one
in gcc/testsuite atomic-1.c) and:
FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect vectorized 1
loops 2
so (depending on where the other patch was tested) doing this in the FE doesn't
help much or at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #13 from rguenther at suse dot de 2008-04-09 15:26 ---
Subject: Re: [4.1/4.2/4.3/4.4 Regression] operand of
pre-/postin-/decrement not promoted
On Wed, 9 Apr 2008, jakub at gcc dot gnu dot org wrote:
--- Comment #12 from jakub at gcc dot gnu dot org 2008-04-09 14:32
---
Created an attachment (id=15455)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455action=view)
gcc43-pr35634.patch
Here is the updated FE only patch. One change is that it avoids
P{RE,OST}{IN,DE}CREMENT_EXPR only for the promoting types, and has some
(admittedly very ugly) OpenMP parsing changes to counter that. Unfortunately
unlike #pragma omp for increment, #pragma omp atomic can have some_lvalue++
, not necessarily a variable_name++, so I have no idea how to handle that.
On x86_64 with this patch I get 3 omp failures (2 in libgomp atomic-10.c, one
in gcc/testsuite atomic-1.c) and:
FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect vectorized 1 loops
1
FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect vectorized 1
loops 2
so (depending on where the other patch was tested) doing this in the FE
doesn't
help much or at all.
Thanks!
I will try doing the P{RE,OST}{IN,DE}CREMENT_EXPR semantic change and
handling it in the gimplifier. Just because I am curious how much
I break the frontends...
After the summit paper deadline is over ;)
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #10 from jakub at gcc dot gnu dot org 2008-03-26 13:15 --- Joseph, do you have that build_unary_op patch still around? If that patch didn't cause any regressions but OpenMP, I could look at tweaking OpenMP... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #11 from jsm28 at gcc dot gnu dot org 2008-03-26 15:11 --- Created an attachment (id=15382) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15382action=view) build_unary_op patch There may well be other regressions with this patch (in particular the vector ones may appear with this patch as well); I stopped testing when the OpenMP failures appeared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-03-20 13:29 --- Created an attachment (id=15349) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15349action=view) Gimplification-time patch Changing at build_unary_op time runs into OpenMP problems - the OpenMP code needs the trees to correspond more directly to the increments and decrements in the source code. Changing at gimplification time, as in the attached patch, avoids that problem, but a number of gcc.dg/vect tests regress because of the changes to the code for increment/decrement of types that get promoted. FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect vectorized 1 loops 2 FAIL: gcc.dg/vect/vect-reduc-dot-u16a.c scan-tree-dump-times vect vectorized 1 loops 2 FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/no-scevccp-outer-13.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-14.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-16.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-17.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-19.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-21.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-7.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-03-20 13:39 ---
Thanks. I guess the vect fallout needs to be dealt with separately. Now, I
think gimplification time is not the best here, can we maybe move this to
general gimplification code if we change the {PRE,POST}{IN,DE}CREMENT_EXPR
to have the type the increment is done in (and the expression result) be
TREE_TYPE of that expression? This way the generic gimplification code
would need to make sure to lower it properly.
Diego, I suppose this lowering is before tuples come into play and we loose
this extra type, right?
Of course this may need auditing of the FEs wrt correctness of the type
in this expression but feels like a more general fix?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dnovillo at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-03-20 13:41 --- Now, I think gimplification time is not the best here Now, if we think ... is the best here obviously ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-20 17:56 --- I did a quick scan and Ada, C++ and C ever build these operations. Also a few backends do (mips, rs6000 and s390). So IMHO changing the semantics of these to /* Nodes for ++ and -- in C. The second arg is how much to increment or decrement by. For a pointer, it would be the size of the object pointed to. The type of the expression specifies the type the increment is performed on and the type of the result. This type does not need to match the type of the first argument, instead that is properly size-/zero-extended before the arithmetic operation. */ DEFTREECODE (PREDECREMENT_EXPR, predecrement_expr, tcc_expression, 2) DEFTREECODE (PREINCREMENT_EXPR, preincrement_expr, tcc_expression, 2) DEFTREECODE (POSTDECREMENT_EXPR, postdecrement_expr, tcc_expression, 2) DEFTREECODE (POSTINCREMENT_EXPR, postincrement_expr, tcc_expression, 2) is reasonable. Note that expansion no longer handles these tree codes, they are expected to only survive until gimplification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
