[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-01 06:02 --- Remember to update the webpage: http://gcc.gnu.org/gcc-4.5/changes.html Add the MPC library dependency in the Caveats section, and add the benefits of using MPC in the General Optimizer Improvements section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug fortran/40318] New: Complex division by zero in gfortran returns wrong results
Complex division by zero in gfortran returns NaN. This is expected for 0/0, but other finite/zero should return Inf. This impacts the testcase gfortran.dg/real_const_3.f90 in two values incorrectly computed: complex :: z = (-0.1,-2.2)/(0.0,0.0) complex :: z2 = (0.1,1)/0 See: http://gcc.gnu.org/ml/fortran/2009-05/msg00423.html This should be fixed in gcc-4.5 by using MPC for division, but older versions of GCC should add special case handling in the fortran frontend simplification code. -- Summary: Complex division by zero in gfortran returns wrong results Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #1 from kargl at gcc dot gnu dot org 2009-06-01 06:54 --- (In reply to comment #0) Complex division by zero in gfortran returns NaN. This is expected for 0/0, but other finite/zero should return Inf. This impacts the testcase gfortran.dg/real_const_3.f90 in two values incorrectly computed: complex :: z = (-0.1,-2.2)/(0.0,0.0) complex :: z2 = (0.1,1)/0 See: http://gcc.gnu.org/ml/fortran/2009-05/msg00423.html This should be fixed in gcc-4.5 by using MPC for division, but older versions of GCC should add special case handling in the fortran frontend simplification code. Kaveh, After looking into the problem, I think (nan + i nan) is an acceptable result for z = (-0.1,-2.2)/(0.0,0.0) because of the standard definition of complex division. For z2 = (0.1,1)/0, I think that you are correct, and gfortran should give (inf + i inf). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-01 07:00 --- Subject: Bug 40309 Author: burnus Date: Mon Jun 1 07:00:35 2009 New Revision: 148035 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148035 Log: 2009-06-01 Tobias Burnus bur...@net-b.de PR fortran/40309 * trans-decl.c (gfc_sym_identifier): Use MAIN__ for PROGRAM main. (create_main_function): Set main_identifier_node. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-01 07:34 --- FIXED on the trunk (4.5). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-06-01 08:05 --- I checked the fix and it works. Verified. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug tree-optimization/39129] The meaning of 'BB' in too many BBs in loop
--- Comment #8 from irar at gcc dot gnu dot org 2009-06-01 08:15 --- Subject: Bug 39129 Author: irar Date: Mon Jun 1 08:15:01 2009 New Revision: 148036 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148036 Log: PR tree-optimization/39129 * tree-vect-loop-manip.c (conservative_cost_threshold): Change the printed message. (vect_do_peeling_for_loop_bound): Use LOOP_REQUIRES_VERSIONING_FOR_ALIGNMENT and LOOP_REQUIRES_VERSIONING_FOR_ALIAS macros. (vect_loop_versioning): Likewise. (vect_create_cond_for_alias_checks): Fix indentation. * tree-vectorizer.h (struct _loop_vec_info): Fix indentation of the macros. (LOOP_REQUIRES_VERSIONING_FOR_ALIGNMENT): Define. (LOOP_REQUIRES_VERSIONING_FOR_ALIAS): Likewise. * tree-vect-loop.c (vect_analyze_loop_form): Change too many BBs to control flow in loop. (vect_estimate_min_profitable_iters): Use LOOP_REQUIRES_VERSIONING_FOR_ALIGNMENT and LOOP_REQUIRES_VERSIONING_FOR_ALIAS macros. * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Likewise. (vect_create_data_ref_ptr): Don't mention array dimension in printing. * tree-vect-stmts.c (vectorizable_store): Replace the check that the statement belongs to a group of strided accesses with the exact code check. (vectorizable_load): Likewise. * tree-vect-slp.c (vect_analyze_slp_instance): Spell out basic block. (vect_slp_analyze_bb, vect_slp_transform_bb): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39129
[Bug tree-optimization/39129] The meaning of 'BB' in too many BBs in loop
--- Comment #9 from irar at il dot ibm dot com 2009-06-01 08:20 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39129
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-01 08:35 --- (In reply to comment #1) Kaveh, After looking into the problem, I think (nan + i nan) is an acceptable result for z = (-0.1,-2.2)/(0.0,0.0) because of the standard definition of complex division. For z2 = (0.1,1)/0, I think that you are correct, and gfortran should give (inf + i inf). Why is one different than the other? I don't know fortan promotion rules, but in C, the latter case promotes to (0.1,1.0)/(0.0,0.0) which looks very much like the first case. Does fortran handle type promotion differently? Regardless, I don't know that any standard definition of complex division applies here. The canonical algebraic formula is undefined mathematically in the presence of division by zero. So at least in C there are rules telling us what to do, and they say return Inf. Does fortran follow a standard here we can compare against or are we guessing? :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #3 from dominiq at lps dot ens dot fr 2009-06-01 10:19 --- In http://gcc.gnu.org/ml/fortran/2009-06/msg6.html, Dennis Wassel wrote: Complex numbers have a well-defined concept of infinity, which I like to visualise as the infinite-diameter ring around the finite complex numbers, so its argument is, of course, not well-defined. This is conceptually somewhat different from the two points +/-Inf on the real line, and it is not signed. My understanding of infinity in the complex plane is what is called (I call?) directed inifinity: if abs((a,b)) goes to +Inf and atan2(a,b) has a defined value in this limit, then (a,b) goes to infinity in the direction given by atan2(a,b). However (+/-Inf,+/-Inf) defines only four directions and is unable to represent general directed inifinity. So I think that from a mathematical point of view the problem is ill-posed, (+/-Inf,+/-Inf) is in the same class of undefined values as 0/0 or Inf/Inf, and should give NaNs. Now atan2(a,b) is DEFINED such that atan2(+0,+/-0)=+/-0, atan2(-0,+/-0)=+/-Pi, atan2(+Inf,+/-Inf)=+/-Pi/4, atan2(-Inf,+/-Inf)=+/-3*Pi/4 (it seems that it is even built in the Intel hardware). With this definition of atan2, it is possible to give a definition of (+/-Inf,+/-Inf) as the directions of the corners of the infinite square. I have nothing against this defintion, except it should be documented. Part of the problem originates from the optimization of (a,b)/(c,0.0) as (a/c,b/c), see pr30482, and it limit when c goes to 0 (the latter giving (+/-Inf,+/-Inf) if b/=0.0 or has a unknown value at compile time, (+/-Inf,+/-0) if b known to be zero at compile time, optimized as (a/c,+/-0.0), or (+/-Inf,-/+Nan) if b==0 at run time). Note that due to the definition of atan2(+/-0,+/-0), (+/-0,+/-0)=0*exp((+/-k*Pi,+/-0)) (k being 0 or 1), then to be consistent 1.0/(+/-0.0,+/-0.0) should give 1/0.0*exp((-/+k*Pi,-/+0))=(+/-Inf,-/+Nan). Last remark, if I remember correctly (I cannot find the right pointer) C99 defines precisely how complex multiplications should behave in the exception limits, with the drawback of a large increase of the computation cost avoided with the -fcx-fortran-rules option. As far as I can tell: (1) Without the IEEE module, using or producing Inf or NaN makes the code non (fortran) standard comforming, so the processor can give any answer. (2) With the IEEE module, Inf and NaN are part of the numerical model, however I did not find any definition of the values that intrinsincs should return in such cases. To conclude, I'll repeat that in my opinion the only relevant answer for overflow, divide by zero, or invalid argument exceptions is call abort(). Since I know that it is a lost battle, I think at least the behavior shall not increase the computation time with complex numbers (or provide a way to avoid the penalty). Now if the f standard does not define the expected result, but the C99 does, the best answer to this ill-posed problem is probably to follow the C99 standard if possible (I have no idea of what does mpc). In this case the results at compile and run times should be the same (least surprising approach). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #15 from Woebbeking at web dot de 2009-06-01 10:28 --- Ian, I know open source and I also know that some parts are more interesting than others :-) Most the time I'm a happy GCC user (sure, it could be faster but that's what compile farms are for). But this bug is assigned for nearly 6 years now that makes me a bit sad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-01 11:09 --- Regarding the run-time evaluation, note that Fortran sets (internally) the -fcx-fortran-rules flag, which modifies the complex evaluation. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #5 from dominiq at lps dot ens dot fr 2009-06-01 11:24 --- (In reply to comment #2) Does fortran follow a standard here we can compare against or are we guessing? :-) What the fortran standard says is you shall not divide by zero! anything else is just a matter of choice of the implementation, but it won't make the code valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #6 from dennis dot wassel at googlemail dot com 2009-06-01 12:14 --- (In reply to comment #3) My understanding of infinity in the complex plane is what is called (I call?) directed inifinity: if abs((a,b)) goes to +Inf and atan2(a,b) has a defined value in this limit, then (a,b) goes to infinity in the direction given by atan2(a,b). However (+/-Inf,+/-Inf) defines only four directions and is unable to represent general directed inifinity. So I think that from a mathematical point of view the problem is ill-posed, (+/-Inf,+/-Inf) is in the same class of undefined values as 0/0 or Inf/Inf, and should give NaNs. Then this is the gist of the matter - my FA textbook does not require the argument to converge, but just the modulus, so our understandings of infinity differ. I agree with Dominique in that mathematically (+/-Inf,+/-Inf) is not well-defined, because the limit of a/b is unknown. Now atan2(a,b) is DEFINED such that atan2(+0,+/-0)=+/-0, atan2(-0,+/-0)=+/-Pi, atan2(+Inf,+/-Inf)=+/-Pi/4, atan2(-Inf,+/-Inf)=+/-3*Pi/4 (it seems that it is even built in the Intel hardware). With this definition of atan2, it is possible to give a definition of (+/-Inf,+/-Inf) as the directions of the corners of the infinite square. I have nothing against this defintion, except it should be documented. The mathematicians among us will writhe in agony, but I think this serves the purpose best :) [...] In this case the results at compile and run times should be the same (least surprising approach). I strongly support that point, because everything else would be a very nasty gotcha for an average Fortran user like myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #7 from dominiq at lps dot ens dot fr 2009-06-01 12:25 --- Then this is the gist of the matter - my FA textbook does not require the argument to converge, but just the modulus, so our understandings of infinity differ. Think of something like \rho\exp(i\rho\sin(\pi\rho)): it is going to infinity when \rho goes to +infinity, but you cannot define a directed infinity since the argument keeps oscillating when \rho increases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug libfortran/40319] New: write (*,'(A1)') 65 should generate an error/warning
$ cat foo.f write (*,'(A1)') 65 end $ gfortran -std=f95 -pedantic -Wall foo.f $ ./a.out A $ We might want to permit this with -std=legacy, though. g77 also accepts it. -- Summary: write (*,'(A1)') 65 should generate an error/warning Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40319
[Bug bootstrap/40320] New: [4.5 Regression] broken bootstrap again: gcc/java/verify-impl.c:1280: ICE: in extract_insn, at recog.c:2078
Bootstrapping revision 148039 on i686-apple-darwin9 fails with: /opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.5w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.5w/i686-apple-darwin9/sys-include-c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Ijava -I../../gcc-4.5-work/gcc -I../../gcc-4.5-work/gcc/java -I../../gcc-4.5-work/gcc/../include -I./../intl -I../../gcc-4.5-work/gcc/../libcpp/include -I/opt/mpc/build/include -I/sw/include -I../../gcc-4.5-work/gcc/../libdecnumber -I../../gcc-4.5-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -I/sw/include -DCLOOG_PPL_BACKEND ../../gcc-4.5-work/gcc/java/win32-host.c -o java/win32-host.o /opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.5w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.5w/i686-apple-darwin9/sys-include-c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Ijava -I../../gcc-4.5-work/gcc -I../../gcc-4.5-work/gcc/java -I../../gcc-4.5-work/gcc/../include -I./../intl -I../../gcc-4.5-work/gcc/../libcpp/include -I/opt/mpc/build/include -I/sw/include -I../../gcc-4.5-work/gcc/../libdecnumber -I../../gcc-4.5-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -I/sw/include -DCLOOG_PPL_BACKEND ../../gcc-4.5-work/gcc/java/jcf-parse.c -o java/jcf-parse.o ../../gcc-4.5-work/gcc/java/verify-impl.c: In function 'get_variable_t': ../../gcc-4.5-work/gcc/java/verify-impl.c:1280: error: unrecognizable insn: (insn 81 80 82 13 ../../gcc-4.5-work/gcc/java/verify-impl.c:1279 (set (mem:SI (plus:SI (reg/f:SI 56 virtual-outgoing-args) (const_int 4 [0x4])) [0 S4 A32]) (plus:SI (reg/f:SI 113) (reg:SI 66 [ D.14606 ]))) -1 (nil)) ../../gcc-4.5-work/gcc/java/verify-impl.c:1280: internal compiler error: in extract_insn, at recog.c:2078 -- Summary: [4.5 Regression] broken bootstrap again: gcc/java/verify-impl.c:1280: ICE: in extract_insn, at recog.c:2078 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40320
[Bug c++/40321] New: internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
This is with GCC trunk, revision 148003: ... [ 69%] Building CXX object CMakeFiles/openlierox.dir/src/common/PhysicsLX56_Projectiles.o [ 70%] Building CXX object CMakeFiles/openlierox.dir/src/common/HTTP.o [ 70%] Building CXX object CMakeFiles/openlierox.dir/src/common/Networking.o /home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp: In function 'ProjCollisionType FinalWormCollisionCheck(CProjectile*, const LX56ProjAttribs, const CVec, const CVec, CWorm*, TimeDiff, ProjCollisionType)': /home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp:129: internal compiler error: in compute_antic, at tree-ssa-pre.c:2501 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [CMakeFiles/openlierox.dir/src/common/PhysicsLX56_Projectiles.o] Fehler 1 make[2]: *** Warte auf noch nicht beendete Prozesse... -- Summary: internal compiler error: in compute_antic, at tree-ssa- pre.c:2501 Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ich at az2000 dot de GCC host triplet: amd64 GCC target triplet: amd64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug bootstrap/40320] [4.5 Regression] broken bootstrap again: gcc/java/verify-impl.c:1280: ICE: in extract_insn, at recog.c:2078
--- Comment #1 from dominiq at lps dot ens dot fr 2009-06-01 14:16 --- See also Gcc [trunk revision 148039] failed to boostrap on i686! at http://gcc.gnu.org/ml/gcc-regression/2009-06/msg7.html and NEW GCC build failure, h...@148039 on native at http://gcc.gnu.org/ml/gcc-regression/2009-06/msg6.html -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40320
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #8 from jb at gcc dot gnu dot org 2009-06-01 14:21 --- Whatever you do, as long as the Fortran standard is silent on this matter, can you hide it behind some -fC99-wankery or such option and not enable it by default, so that those of us who care less about which of (NaN, NaN) and (Inf, Inf) is the better error indicator than the roughly factor of 4 in performance for complex arithmetic can get on with our lives? -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug bootstrap/40320] [4.5 Regression] Revision 148039 caused ICE: in extract_insn, at recog.c:2078
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-01 14:26 --- Revision 148039: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00016.html is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||mkuvyrkov at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-apple-darwin9 | GCC host triplet|i686-apple-darwin9 | GCC target triplet|i686-apple-darwin9 |x86 Last reconfirmed|-00-00 00:00:00 |2009-06-01 14:26:00 date|| Summary|[4.5 Regression] broken |[4.5 Regression] Revision |bootstrap again:|148039 caused ICE: in |gcc/java/verify-impl.c:1280:|extract_insn, at |ICE: in extract_insn, at|recog.c:2078 |recog.c:2078| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40320
[Bug bootstrap/40320] [4.5 Regression] Revision 148039 caused ICE: in extract_insn, at recog.c:2078
-- hjl dot tools at gmail dot com changed: What|Removed |Added Severity|normal |blocker Priority|P3 |P1 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40320
[Bug c++/40321] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #1 from ich at az2000 dot de 2009-06-01 14:40 --- Sorry, it was revision 148004. I also tried with rev 148039, same error: /home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp: In function 'ProjCollisionType FinalWormCollisionCheck(CProjectile*, const LX56ProjAttribs, const CVec, const CVec, CWorm*, TimeDiff, ProjCollisionType)': /home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp:129: internal compiler error: in compute_antic, at tree-ssa-pre.c:2501 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug bootstrap/40320] [4.5 Regression] Revision 148039 caused ICE: in extract_insn, at recog.c:2078
--- Comment #3 from hjl dot tools at gmail dot com 2009-06-01 14:43 --- On Linux/ia32, I got /export/gnu/import/svn/gcc-test/bld/./gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../src-trunk/libgcc -I../../../src-trunk/libgcc/. -I../../../src-trunk/libgcc/../gcc -I../../../src-trunk/libgcc/../include -I../../../src-trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep -DL_powitf2 -c ../../../src-trunk/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../src-trunk/libgcc/../gcc/libgcc2.c: In function '__powitf2': ../../../src-trunk/libgcc/../gcc/libgcc2.c:1739: error: unrecognizable insn: (insn 48 47 49 7 ../../../src-trunk/libgcc/../gcc/libgcc2.c:1734 (set (mem:SI (reg/f:SI 56 virtual-outgoing-args) [0 S4 A32]) (plus:SI (reg/f:SI 54 virtual-stack-vars) (const_int -16 [0xfff0]))) -1 (nil)) ../../../src-trunk/libgcc/../gcc/libgcc2.c:1739: internal compiler error: in extract_insn, at recog.c:2078 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40320
[Bug bootstrap/40320] [4.5 Regression] Revision 148039 caused ICE: in extract_insn, at recog.c:2078
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2009-06-01 14:50 --- I've reverted the patch that caused the bootstrap failure. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40320
[Bug c++/40321] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #2 from ich at az2000 dot de 2009-06-01 14:50 --- The specific file which fails has a lot of inline code, perhaps that is the reason for failing. There are certain reasons why we want to have that inline. This is the file if you want to take a look: http://openlierox.svn.sourceforge.net/viewvc/openlierox/src/common/PhysicsLX56_Projectiles.cpp?view=markup I guess it cannot really be reproduced with a simple example as the problem is probably the complexitiy here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu 2009-06-01 14:56 --- Subject: Re: Complex division by zero in gfortran returns wrong results On Mon, Jun 01, 2009 at 08:35:05AM -, ghazi at gcc dot gnu dot org wrote: --- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-01 08:35 --- (In reply to comment #1) Kaveh, After looking into the problem, I think (nan + i nan) is an acceptable result for z = (-0.1,-2.2)/(0.0,0.0) because of the standard definition of complex division. For z2 = (0.1,1)/0, I think that you are correct, and gfortran should give (inf + i inf). Why is one different than the other? I don't know fortan promotion rules, but in C, the latter case promotes to (0.1,1.0)/(0.0,0.0) which looks very much like the first case. Does fortran handle type promotion differently? Regardless, I don't know that any standard definition of complex division applies here. The canonical algebraic formula is undefined mathematically in the presence of division by zero. So at least in C there are rules telling us what to do, and they say return Inf. Does fortran follow a standard here we can compare against or are we guessing? :-) Let's deal with the z = (-0.1,-2.2)/(0.0,0.0) case. This program, IMHO, needs to give a consistent answer. subroutine sub(z1, z2) implicit none complex z1, z2 print *, z1 / z2 end subroutine sub program a implicit none complex :: z1 = (-0.1,-2.2), z2 = (0.0,0.0) complex :: z3 = (-0.1,-2.2) / (0.0,0.0) call sub(z1, z2) print *, z3 end program a If one wants z3 to be inf or (inf + i inf) or anything other than (nan + i nan), then the complex division in sub() will cause an unacceptably large drop in performance because GCC would need to generate code to check all the special cases i.e., subroutine sub(z1, z2) implicit none complex z1, z2 if (real(z2) == 0. .and. aimag(z2) == 0.) then if (real(z1) == 0. .and. aimag(z1) then nan + i nan else if (aimag(z1) == 0.) then inf + i nan else if (real(z1) == 0.) then nan + i inf end if else print *, z1 / z2 end if end subroutine sub As for the second case of z = (0.1, 1) / 0, Fortran indeed has promotion rules (see Sec. 7.1.2 in Fortran 2003). This is transformed to z = (0.1, 1) / (0., 0.), so once again my above argument for a consistent result applies. PS: Please do not consider -ffast-math as a method to disable all of the checking. -ffast-math has too much baggage to be used with impunity. If MPC returns inf or (inf + i inf) and the MPC developers do not consider this to be a bug in their library, then gfortran will need to handle the division by zero during constant folding as a special case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug c++/40321] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #3 from ich at az2000 dot de 2009-06-01 16:34 --- I have commented out the check in tree-ssa-pre.c:2501, and then, after eating up about 8GB memory (that was all available), I got this: c++: Internal error: Killed (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. Btw., I have some similar problem with GCC 4.4.0. It's also eating up all memory there and dies in the end, for the same source file. It doesn't occur with GCC 4.3 though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug other/40322] New: make clean fails (/bin/bash: -/: invalid option)
In revision 148041: ... make[2]: Verlasse Verzeichnis '/home/az/Programmierung/gcc-trunk/build/libiberty' rm -f *.a required-list tmpmulti.out rm -f libiberty.dvi libiberty.pdf libiberty.info* libiberty.html make[1]: Verlasse Verzeichnis '/home/az/Programmierung/gcc-trunk/build/libiberty' /bin/bash: -/: invalid option Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --protected --rcfile --restricted --verbose --version --wordexp Shell options: -irsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option /bin/bash: -/: invalid option Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --protected --rcfile --restricted --verbose --version --wordexp Shell options: -irsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option /bin/bash: -/: invalid option Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --protected --rcfile --restricted --verbose --version --wordexp Shell options: -irsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option /bin/bash: line 0: test: !=: unary operator expected make[1]: Betrete Verzeichnis '/home/az/Programmierung/gcc-trunk/build/x86_64-unknown-linux-gnu/libgcc' rm -f config.h stamp-h stmp-ldirs libgcc.map Makefile:147: *** Rekursive Variable »AR_FOR_TARGET« referenziert sich (schließlich) selbst. Schluss. make[1]: Verlasse Verzeichnis '/home/az/Programmierung/gcc-trunk/build/x86_64-unknown-linux-gnu/libgcc' make: *** [clean-stage3-target-libgcc] Fehler 2 -- Summary: make clean fails (/bin/bash: -/: invalid option) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ich at az2000 dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40322
[Bug tree-optimization/40321] [4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c++ |tree-optimization Keywords||ice-on-valid-code Summary|internal compiler error: in |[4.5 Regression] internal |compute_antic, at tree-ssa- |compiler error: in |pre.c:2501 |compute_antic, at tree-ssa- ||pre.c:2501 Target Milestone|--- |4.5.0 Version|tree-ssa|4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug tree-optimization/40321] [4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #4 from ich at az2000 dot de 2009-06-01 16:52 --- Created an attachment (id=17941) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17941action=view) source file after preprocessor I just created the temporary source file (via -save-temps) and attached it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug middle-end/40316] [4.5 Regression] Revision 147995 breaks gcc.target/i386/lea.c
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-01 17:13 --- Subject: Bug 40316 Author: jakub Date: Mon Jun 1 17:13:04 2009 New Revision: 148055 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148055 Log: PR middle-end/40316 * recog.c (peep2_reinit_state): New function. (peephole2_init_state): Use it at the end of a basic block and also when seeing a RTX_FRAME_RELATED_P insn. Modified: trunk/gcc/ChangeLog trunk/gcc/recog.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40316
[Bug middle-end/40316] [4.5 Regression] Revision 147995 breaks gcc.target/i386/lea.c
--- Comment #2 from jakub at gcc dot gnu dot org 2009-06-01 17:15 --- Fixed. -- 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=40316
[Bug libfortran/40319] write (*,'(A1)') 65 should generate an error/warning
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-01 17:41 --- If we can have a warning/error at compile time it would be great. However, I'm inclined to allow it for -std=gnu at run time. (I'm personally against too much standard diagnostics at run time. If such an error appears after a lengthy calculation or if the user does not have the source code, such diagnostics are rather unfriendly. While compile-time errors are OK - they can easily worked around using -std=legacy or by changing the source code.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40319
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-06-01 17:45 --- Remember to upload the MPC tarball (whatever version we settle on) to: ftp://gcc.gnu.org/pub/gcc/infrastructure/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #28 from pault at gcc dot gnu dot org 2009-06-01 18:00 --- Created an attachment (id=17942) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17942action=view) A progression of -fwhole-file This patch is as far as I have got. It incorporates module procedures and this is where I have run into problems. I have posted an appeal for help on the list. It should be noted that -fwhole-file is fixed to be on all the time in parse.c so that the regtesting goes correctly. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug tree-optimization/40321] [4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #5 from ich at az2000 dot de 2009-06-01 18:02 --- Perhaps that was anyway clear from the report, but I didn't noted the most important point directly: The problem occurs only with -O3. If I don't set a specific optimisation, it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-01 18:03 --- Subject: Bug 40024 Author: jakub Date: Mon Jun 1 18:03:26 2009 New Revision: 148061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148061 Log: PR other/40024 * emutls.c (__emutls_get_address): Change arr-size to mean number of allocated arr-data entries instead of # of slots + 1. Modified: trunk/gcc/ChangeLog trunk/gcc/emutls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #10 from ghazi at gcc dot gnu dot org 2009-06-01 18:14 --- (In reply to comment #9) If MPC returns inf or (inf + i inf) and the MPC developers do not consider this to be a bug in their library, then gfortran will need to handle the division by zero during constant folding as a special case. I believe the goals for MPC are to follow C99 rules for special cases. Thus the return value of (inf + i inf) is intentional for MPC and not a bug in their thinking. I entirely agree that the compile-time and runtime results should be identical. If it is your intention to preserve the existing runtime behavior, then we should do the same in the fortran folder and special case this if/when converting complex division to use MPC. Does this mean this PR should be closed as invalid ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug c++/40323] New: compiling just takes forever and doesn't really process
This is with GCC trunk, rev 148041:
I have a cpp file where g++ just takes forever with 100% CPU usage and constant
(low) memory usage. I am waiting now for 20 minutes without any visible
progress.
I attached with GDB to the process and this is some of the details I am seeing:
a...@gcomputer:~$ gdb
/opt/gcc4.4-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus 32654
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu...
Really redefine built-in command frame? (y or n) [answered Y; input not from
terminal]
Really redefine built-in command thread? (y or n) [answered Y; input not from
terminal]
Really redefine built-in command start? (y or n) [answered Y; input not from
terminal]
Attaching to program:
/opt/gcc4.4-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus, process
32654
Reading symbols from /usr/lib/libmpfr.so.1...done.
Loaded symbols for /usr/lib/libmpfr.so.1
Reading symbols from /usr/lib/libgmp.so.3...done.
Loaded symbols for /usr/lib/libgmp.so.3
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
___
Error while running hook_stop:
Value can't be converted to integer.
0x00a6ebd4 in ipa_compute_jump_functions (cs=value optimized out) at
../../gcc/ipa-prop.c:437
437 while (TREE_CODE (rhs) == SSA_NAME !SSA_NAME_IS_DEFAULT_DEF (rhs))
gdb bt ful
#0 0x00a6ebd4 in ipa_compute_jump_functions (cs=value optimized out)
at ../../gcc/ipa-prop.c:437
info = value optimized out
__FUNCTION__ = ipa_compute_jump_functions
call = value optimized out
#1 0x0002 in ?? ()
No symbol table info available.
#2 0x7f11dcc99480 in ?? ()
No symbol table info available.
#3 0x02394010 in ?? ()
No symbol table info available.
#4 0x0002 in ?? ()
No symbol table info available.
#5 0x7f11df850360 in ?? ()
No symbol table info available.
#6 0x7f11dd0b6c80 in ?? ()
No symbol table info available.
#7 0x7f11dd0b6d20 in ?? ()
No symbol table info available.
#8 0x02394040 in ?? ()
No symbol table info available.
#9 0x7f11dc83b160 in ?? ()
No symbol table info available.
#10 0x7f11ddb0f400 in ?? ()
No symbol table info available.
#11 0x7f11dc8865a0 in ?? ()
No symbol table info available.
#12 0x003b in ?? ()
No symbol table info available.
#13 0x7f11dd0b6d20 in ?? ()
No symbol table info available.
#14 0x7f11dd0b6c80 in ?? ()
No symbol table info available.
#15 0x00a6d0d0 in ?? ()
No locals.
#16 0x7f11dc898600 in ?? ()
No symbol table info available.
#17 0x7f11dc833600 in ?? ()
No symbol table info available.
#18 0x in ?? ()
No symbol table info available.
gdb c
^C
Program received signal SIGINT, Interrupt.
___
Error while running hook_stop:
Value can't be converted to integer.
gimple_assign_single_p (gs=0x7f11dc839be0) at ../../gcc/gimple.c:1831
1831}
gdb bt
#0 gimple_assign_single_p (gs=0x7f11dc839be0) at ../../gcc/gimple.c:1831
#1 0x00a6ebee in ipa_compute_jump_functions (cs=value optimized out)
at ../../gcc/ipa-prop.c:441
#2 0x0002 in ?? ()
#3 0x7f11dcc99480 in ?? ()
#4 0x02394010 in ?? ()
#5 0x0002 in ?? ()
#6 0x7f11df850360 in ?? ()
#7 0x7f11dd0b6c80 in ?? ()
#8 0x7f11dd0b6d20 in ?? ()
#9 0x02394040 in ?? ()
#10 0x7f11dc83b160 in ?? ()
#11 0x7f11ddb0f400 in ?? ()
#12 0x7f11dc8865a0 in ?? ()
#13 0x003b in ?? ()
#14 0x7f11dd0b6d20 in ?? ()
#15 0x7f11dd0b6c80 in ?? ()
#16 0x00a6d0d0 in ?? ()
#17 0x7f11dc898600 in ?? ()
#18 0x7f11dc833600 in ?? ()
#19 0x in ?? ()
gdb c
^C
Program received signal SIGINT, Interrupt.
___
Error while running hook_stop:
Value can't be converted to integer.
0x00a6ebdf in ipa_compute_jump_functions (cs=value optimized out) at
../../gcc/ipa-prop.c:437
437 while (TREE_CODE (rhs) == SSA_NAME !SSA_NAME_IS_DEFAULT_DEF (rhs))
gdb list
432return the rhs of its defining statement. */
433
434 static inline tree
435 get_ssa_def_if_simple_copy (tree rhs)
436 {
437 while (TREE_CODE (rhs) == SSA_NAME !SSA_NAME_IS_DEFAULT_DEF (rhs))
438 {
439 gimple def_stmt = SSA_NAME_DEF_STMT (rhs);
440
441
[Bug c++/40323] compiling just takes forever and doesn't really process
--- Comment #1 from ich at az2000 dot de 2009-06-01 18:32 ---
gdb c
q
^C
Program received signal SIGINT, Interrupt.
___
Error while running hook_stop:
Value can't be converted to integer.
0x00780a0f in gimple_assign_single_p (gs=0x7f11dc839be0) at
../../gcc/gimple.c:1831
1831}
gdb list
1826gimple_assign_single_p (gimple gs)
1827{
1828 return (gimple_code (gs) == GIMPLE_ASSIGN
1829 get_gimple_rhs_class (gimple_assign_rhs_code (gs))
1830 == GIMPLE_SINGLE_RHS);
1831}
1832
1833/* Return true if GS is an assignment with a unary RHS, but the
1834 operator has no effect on the assigned value. The logic is adapted
1835 from STRIP_NOPS. This predicate is intended to be used in
tuplifying
gdb print gs
$4 = (gimple) 0x7f11dc839be0
gdb print *gs
$5 = {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, gsops = {opbase = {gsbase = {code =
GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, def_ops = 0x7f11db7df1d0, use_ops = 0x0}, op = {0x0}}, gsmem =
{membase = {opbase = {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited
= 0x0, nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops =
0x0, pad = 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2,
bb = 0x7f11dc8865a0, block = 0x7f11dc83a120}, def_ops = 0x7f11db7df1d0, use_ops
= 0x0}, vdef = 0x0, vuse = 0x0}, op = {0x7f11db7dccc0}}, omp = {gsbase = {code
= GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, body = 0x7f11db7df1d0}, gimple_bind = {gsbase = {code =
GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, vars = 0x7f11db7df1d0, block = 0x0, body = 0x0}, gimple_catch
= {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, types = 0x7f11db7df1d0, handler =
0x0}, gimple_eh_filter = {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0,
visited = 0x0, nontemporal_move = 0x0, plf = 0x0, modified = 0x0,
has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid = 0x0, location =
0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block = 0x7f11dc83a120}, types =
0x7f11db7df1d0, failure = 0x0}, gimple_phi = {gsbase = {code = GIMPLE_ASSIGN,
no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf = 0x0, modified =
0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid = 0x0, location =
0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block = 0x7f11dc83a120}, capacity
= 0xdb7df1d0, nargs = 0x7f11, result = 0x0, args = {{imm_use = {prev = 0x0,
next = 0x0, loc = {stmt = 0x7f11db7dccc0, ssa_name = 0x7f11db7dccc0}, use =
0x7f11dcb59a80}, def = 0x202205}}}, gimple_resx = {gsbase = {code =
GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, region = 0xdb7df1d0}, gimple_try = {gsbase = {code =
GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, eval = 0x7f11db7df1d0, cleanup = 0x0}, gimple_wce = {gsbase =
{code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0,
plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74,
uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, cleanup = 0x7f11db7df1d0}, gimple_asm = {membase = {opbase =
{gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, def_ops = 0x7f11db7df1d0, use_ops =
0x0}, vdef = 0x0, vuse = 0x0}, string = 0x7f11db7dccc0 \216, ni = 0x80, no =
0x9a, nc = 0xdcb5, op = {0x202205}}, gimple_omp_critical = {omp
[Bug c++/40323] compiling just takes forever and doesn't really process
--- Comment #2 from ich at az2000 dot de 2009-06-01 18:35 --- This only happens with -O3. Without specific optimisation, it compiles just fine. With all other GCC versions I have tried so far (GCC 4.4, GCC 4.3, GCC 4.0 and a lot others) it works fine (with any possible optimisation). -- ich at az2000 dot de changed: What|Removed |Added Component|tree-optimization |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
[Bug c++/40323] compiling just takes forever and doesn't really process
--- Comment #3 from ich at az2000 dot de 2009-06-01 18:36 --- Created an attachment (id=17943) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17943action=view) source file after preprocessor This is the specific source after the preprocessor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
[Bug c++/38089] [4.3/4.4/4.5 Regression] g++ crash on invalid code
--- Comment #4 from simartin at gcc dot gnu dot org 2009-06-01 19:02 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00102.html -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org Last reconfirmed|2008-12-24 04:35:02 |2009-06-01 19:02:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38089
[Bug libstdc++/40299] Rope + C++0x mode = build error
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-01 19:09:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40299
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2009-06-01 19:16 --- Subject: Re: Complex division by zero in gfortran returns wrong results On Mon, Jun 01, 2009 at 06:14:52PM -, ghazi at gcc dot gnu dot org wrote: - Comment #10 from ghazi at gcc dot gnu dot org 2009-06-01 18:14 --- (In reply to comment #9) If MPC returns inf or (inf + i inf) and the MPC developers do not consider this to be a bug in their library, then gfortran will need to handle the division by zero during constant folding as a special case. I believe the goals for MPC are to follow C99 rules for special cases. Thus the return value of (inf + i inf) is intentional for MPC and not a bug in their thinking. I entirely agree that the compile-time and runtime results should be identical. If it is your intention to preserve the existing runtime behavior, then we should do the same in the fortran folder and special case this if/when converting complex division to use MPC. Oh yuck. I just checked n1124.pdf In Annex G.5.1, it explicitly defines this behavior: if the first operand is a nonzero finite number or an infinity and the second operand is a zero, then the result of the / operator is an infinity. Combining this with G.3: A complex or imaginary value is a zero if each of its parts is a zero. What is disturbing is Example 2 in G.5.1 on page 470! Does gcc's runtime implementation of complex division mirror Example 2? I can understand the need to avoid under/overflow, but _Cdivd() seems overly complicated. Does this mean this PR should be closed as invalid ? I think we should leave it open, perhaps in a suspended state, as a reminder (to me) that soemthing needs to be done with gfortran an z/(0,0). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #29 from jv244 at cam dot ac dot uk 2009-06-01 19:34 --- (In reply to comment #28) Created an attachment (id=17942) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17942action=view) [edit] A progression of -fwhole-file This patch is as far as I have got. this seems to have some memory problem somewhere, compiling the normal version of cp2k (i.e. one module per file), at least 10Gb of memory is needed in several cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #30 from jv244 at cam dot ac dot uk 2009-06-01 19:43 --- Created an attachment (id=17944) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17944action=view) testcase attached is a testcase, this actually causes a segfault outside of the build infrastructure, but consumes XGb within: gfortran -v -ffree-form btree_i8_k_i4_v.F (gdb) bt #0 0x7ffe74a0efb0 in strcmp () from /lib64/libc.so.6 #1 0x0051bcbd in gfc_find_symtree (st=0x13f4460, name=0x7ffe741dba90 btree_node_p) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:2306 #2 0x0051bedb in gfc_find_sym_tree (name=0x7ffe741dba90 btree_node_p, ns=0x132b490, parent_flag=0, result=0x7fff7d54e068) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:2466 #3 0x0051bf82 in gfc_find_symbol (name=0x7ffe741dba90 btree_node_p, ns=0x7ffe741dbbd0, parent_flag=0, result=0x7fff7d54e098) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:2502 #4 0x005724dd in gfc_get_derived_type (derived=0x13309f0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1945 #5 0x00572861 in copy_dt_decls_ifequal (from=value optimized out, to=value optimized out, from_gsym=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1864 #6 0x00572506 in gfc_get_derived_type (derived=0x132fc30) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1948 #7 0x00572861 in copy_dt_decls_ifequal (from=value optimized out, to=value optimized out, from_gsym=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1864 #8 0x00572506 in gfc_get_derived_type (derived=0x13309f0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1948 #9 0x00572861 in copy_dt_decls_ifequal (from=value optimized out, to=value optimized out, from_gsym=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1864 #10 0x00572506 in gfc_get_derived_type (derived=0x132fc30) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1948 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives
--- Comment #8 from eduardo dot m dot costa at gmail dot com 2009-06-01
19:48 ---
(In reply to comment #7)
Subject: Re: [arm] libjava build failure due to missing
thread synchronization primitives
I'm not quite sure what you're trying to do.
What did you change to support arm-eabi* ?
I changed libjava/configure.host to also support arm-eabi
(arm*-elf|arm*-eabi)but that probably wasn't enough. Given that arm-elf
appears
to be supported for this as per the last comment in the bug report, I
thought
it would make sense to have it working for arm-eabi.
I decided to go back and try an arm-elf build as well just now. I get a
failure
with jni-libjvm.cc with an error about ParkHelper not naming a type. Hence
this
appears to be broken on trunk as revision 146222 for arm-elf as well as
arm-eabi.
Probably. The java.lang.concurrent library requires thread support,
so the only way you're going to get it to run with no threads is to
create dummy definitions for ParkHelper. That should be easy, since
null definitions for park() and unpark() will be fine.
Just add these to libjava/no-threads.cc and libjava/include/no-threads.h.
Andrew.
I tryed this:
libjava/include/no-threads.h
struct ParkHelper
{
void init ();
void deactivate ();
void destroy ();
void park (jboolean isAbsolute, jlong time);
void unpark ();
};
libjava/no-threads.cc
void ParkHelper::init () {}
void ParkHelper::deactivate () {}
void ParkHelper::destroy () {}
void ParkHelper::park (jboolean isAbsolute, jlong time) {}
void ParkHelper::unpark () {}
But I got more errors on libjava/sysdep/arm/locks.h (thumb mode does not
recognize swp and swpne).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340
[Bug libmudflap/18244] libmudflap installs include/mf-runtime.h in version-independent path
--- Comment #3 from gerald at pfeifer dot com 2009-06-01 20:32 --- This has been fixed for GCC 4.2.0, I believe by the following patch: 2006-06-21 Frank Ch. Eigler f...@redhat.com PR 21274 mf-runtime.h installation based on ssp patch for PR 26473 from Mark Mitchell m...@codesourcery.com. * configure.ac (ACX_NONCANONICAL_TARGET): Use it. * Makefile.am (target_noncanonical): Define. (libsubincludedir): New variable. (nobase_libsubinclude_HEADERS): Add mf-runtime.h. (include_HEADERS): Remove. * configure, aclocal.m4, config.h.in: Regenerated. * Makefile.in, testsuite/Makefile.in: Likewise. * mf-runtime.h: Add #ifndef protection for conflicting _REENTRANT and _THREAD_SAFE redefinition values. Thus marking as fixed, after all those years. -- gerald at pfeifer dot com changed: What|Removed |Added Known to work||4.2.0 Target Milestone|--- |3.1.x/3.2.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18244
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #12 from burnus at gcc dot gnu dot org 2009-06-01 20:33 --- Oh yuck. I just checked n1124.pdf In Annex G.5.1, it explicitly defines this behavior: Note: Annex G is only informative and not normative; still it makes probably sense to follow the informative parts of a standard unless they clash with a normative part - or are intolerably expensive in implementation, compile, or run time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug c/40325] New: C frontend permits setting a function pointer to a function with different parameter type
This C program is compiled with no warning or error by mainline.
enum E { A };
void foo(unsigned int);
void (*pfn)(enum E) = foo;
My reading of ISO C says that these function pointers are not compatible types.
I think the compiler should report something like
warning: initialization from incompatible pointer type
--
Summary: C frontend permits setting a function pointer to a
function with different parameter type
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40325
[Bug libmudflap/18244] libmudflap installs include/mf-runtime.h in version-independent path
-- gerald at pfeifer dot com changed: What|Removed |Added Target Milestone|3.1.x/3.2.x |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18244
[Bug c/40325] C frontend permits setting a function pointer to a function with different parameter type
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-01 20:40 --- Actually I think they are compatible. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6024#c3 explains why they are. The reason why they are compatible is explicitly explained in 6.7.2.2#4 (which specifies that enumerated types are compatible with char or a signed or unsigned integer type). Since enum E is compatible with unsigned int, the function pointer is compatible as the functions arguments are compatible. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40325
[Bug tree-optimization/40323] compiling just takes forever and doesn't really process
--- Comment #4 from ich at az2000 dot de 2009-06-01 21:36 --- It runs now for 200 minutes, so I really think this is not normal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #4 from dje at gcc dot gnu dot org 2009-06-01 21:49 --- Local variable debugging is broken for AIX stabs as well. On AIX, the DECL and the insn contain different offsets from virtual-stack-vars for the same variable: (mem/c/i:SI (plus:SI (reg/f:SI 115 virtual-stack-vars) (const_int 8 [0x8])) [0 a+0 S4 A128]) versus (insn 11 10 12 3 ad.c:11 (set (reg:SI 123) (mem/c/i:SI (reg/f:SI 115 virtual-stack-vars) [0 a+0 S4 A32])) -1 (nil)) -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug c++/38089] [4.3/4.4/4.5 Regression] g++ crash on invalid code
--- Comment #5 from simartin at gcc dot gnu dot org 2009-06-02 05:37 --- Subject: Bug 38089 Author: simartin Date: Tue Jun 2 05:37:17 2009 New Revision: 148069 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148069 Log: gcc/cp/ 2009-06-02 Simon Martin simar...@users.sourceforge.net PR c++/38089 * pt.c (register_specialization): Properly setup DECL_CONTEXT for specializations in an invalid namespace. gcc/testsuite/ 2009-06-02 Simon Martin simar...@users.sourceforge.net PR c++/38089 * g++.dg/template/spec36.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/spec36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38089
