------- 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=15455&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455&action=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
