[Bug fortran/37523] data syncronisation error with openmp
--- Comment #2 from j at jasper dot es 2008-09-15 08:52 --- Whoops, sorry, this was an error on my side, as the test case was dumbed down too much. Will try to make a better and valid testcase, as I have something like this occurring to me. -- j at jasper dot es changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37523
[Bug target/37520] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
--- Comment #4 from ubizjak at gmail dot com 2008-09-15 09:01 --- IMO, you need to define NO_DOLLAR_IN_LABEL in your configuration files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug middle-end/37499] [4.4 Regression] Scheduling pass 2 time increases by order of magnitude
--- Comment #3 from abel at gcc dot gnu dot org 2008-09-15 09:02 --- I have checked that this is because of the selective scheduler merge. I will look at it. -- abel at gcc dot gnu dot org changed: What|Removed |Added CC||abel at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |abel at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-15 09:02:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37499
[Bug testsuite/36889] [4.4 regression] gfortran.fortran-torture/execute/execute.exp tries to run sse2 execute tests without checking for host support
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-15 09:11 --- Please try http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01076.html patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||09/msg01076.html Status|NEW |ASSIGNED Last reconfirmed|2008-08-22 14:46:17 |2008-09-15 09:11:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36889
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #7 from irar at il dot ibm dot com 2008-09-15 09:11 --- (In reply to comment #6) > > I see vect_create_data_ref_ptr is getting the type to use passed > in case of stores and this is TREE_TYPE (vec_oprnd) - is vec_oprnd > the lhs or the rhs? It looks like it is the rhs which may explain > the ICE for PR37385, It's the other way around in PR37385 - it ICEs if we use the type of lhs. > I can try to have a look here, but I'm not exactly familiar with > the code (thanks for the pointers ;)), so I'd appreciate if you > try to figure out what it takes to fix vect_create_data_ref_ptr or > its caller. Sure, I never meant to ask you to look into the vectorizer code. I only gave you the pointers because I thought you asked. Fixing the vectorizer code is not a problem. The problem is I don't really understand what we should generate. For scalar store *x = y we create vector store *vect_x = vect_y. The type of vect_x must be "vector type_of_x", right? This will cause the ICE in pr 37385, so we must check something to prevent it. AFAIU, the ICE is because the lhs and the element type of rhs do not alias. Testing "vector type_of_x" and "type_of_y" for alias does the job. But this prevents vectorization of vectorize2.c (vector int and long int do not alias)... Thanks a lot for your help, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-15 09:21 --- I'd prefer it just to call initializer_constant_valid_p (val, TREE_TYPE (val)) == null_pointer_node for flag_pic (and != NULL_TREE for !flag_pic). What is in #c4 would need at least some write after write barriers, would enlarge code too much and might be worthwhile just in very hot basic blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36881
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #8 from rguenther at suse dot de 2008-09-15 09:23 --- Subject: Re: [4.4 Regression] Revision 140257 causes vectorizer tests failures On Mon, 15 Sep 2008, irar at il dot ibm dot com wrote: > > > --- Comment #7 from irar at il dot ibm dot com 2008-09-15 09:11 --- > (In reply to comment #6) > > > > > I see vect_create_data_ref_ptr is getting the type to use passed > > in case of stores and this is TREE_TYPE (vec_oprnd) - is vec_oprnd > > the lhs or the rhs? It looks like it is the rhs which may explain > > the ICE for PR37385, > > It's the other way around in PR37385 - it ICEs if we use the type of lhs. > > > I can try to have a look here, but I'm not exactly familiar with > > the code (thanks for the pointers ;)), so I'd appreciate if you > > try to figure out what it takes to fix vect_create_data_ref_ptr or > > its caller. > > Sure, I never meant to ask you to look into the vectorizer code. I only gave > you the pointers because I thought you asked. Fixing the vectorizer code is > not > a problem. The problem is I don't really understand what we should generate. > > For scalar store *x = y we create vector store *vect_x = vect_y. The type of > vect_x must be "vector type_of_x", right? This will cause the ICE in pr 37385, > so we must check something to prevent it. AFAIU, the ICE is because the lhs > and > the element type of rhs do not alias. Testing "vector type_of_x" and > "type_of_y" for alias does the job. But this prevents vectorization of > vectorize2.c (vector int and long int do not alias)... Well, I think the ICE happens because for stores we call vect_create_data_ref_ptr with an explicit vector type which is based on the rhs, not the lhs. The ICE should never occur if we based the vector type on the lhs. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug testsuite/36440] [4.4 Regression] FAIL: g++.dg/cdce3.C on powerpc-apple-darwin8.5.0
--- Comment #8 from jakub at gcc dot gnu dot org 2008-09-15 09:42 --- Everything seems to be fixed as far as I can see. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36440
[Bug fortran/37523] New: data syncronisation error with openmp
When running the attached code (compiled with -fopenmp) I see intermittent 'WUH' in my output, which should not happen. Wasting some cycles between the initialization of the array and the start of the DO loop (by printing some data) works. jbook:optidus-tng spaans$ LANG=C gfortran -v Using built-in specs. Target: i386-apple-darwin9.4.0 Configured with: ../gcc/configure --prefix=/usr/local/gfortran/ --with-gmp=/opt/local --with-mpfr=/opt/local --enable-languages=c,fortran --no-create --no-recursion Thread model: posix gcc version 4.4.0 20080909 (experimental) (GCC) jbook:optidus-tng spaans$ gfortran -fopenmp gfortranbug-testcase.f90 -o gfortranbug-testcase jbook:optidus-tng spaans$ for a in `gseq 1 1000`; do ./gfortranbug-testcase ; done |grep WUH STOP WUH! ... -- Summary: data syncronisation error with openmp Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j at jasper dot es GCC build triplet: i386-apple-darwin9.4.0 GCC host triplet: i386-apple-darwin9.4.0 GCC target triplet: i386-apple-darwin9.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37523
[Bug middle-end/37456] [4.4 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-15 08:38 --- Mine then. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-09-10 08:14:32 |2008-09-15 08:38:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37456
[Bug fortran/37523] data syncronisation error with openmp
--- Comment #1 from j at jasper dot es 2008-09-15 08:45 --- Created an attachment (id=16321) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16321&action=view) source code for testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37523
[Bug middle-end/37456] [4.4 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-15 08:31 --- This is caused by PR15255 fix, undistribute_ops_list -> build_and_add_sum happily appends new statements after a throwing statement. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37456
[Bug testsuite/36889] [4.4 regression] gfortran.fortran-torture/execute/execute.exp tries to run sse2 execute tests without checking for host support
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-15 09:36 --- *** Bug 36458 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36889
