[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=gcc&view=rev&rev=148069 Log: gcc/cp/ 2009-06-02 Simon Martin PR c++/38089

[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)

[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 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 enumerat

[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] 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 incomp

[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

[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 PR 21274 mf-runtime.h installation based on ssp patch for PR 26473 from Mark Mitchell .

[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 t

[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=17944&action=view) testcase attached is a testcase, this actually causes a segfault outside of the build infrastructure, but consumes

[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=17942&action=view) [edit] > A progression of -fwhole-file > This patch is as far as I have got. this se

[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

[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

[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 -

[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=17943&action=view) source file after preprocessor This is the specific source after the preprocessor. -- http://gcc.gnu.org/bugzilla/sh

[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). -

[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 g

[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:~$

[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 foldi

[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=gcc&view=rev&rev=148061 Log: PR other/40024 * emutls.c (__emutls_get_address):

[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 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=17942&action=view) A progression of -fwhole-file This patch is as far as I have got. It incorporates module procedures and this is

[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 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 appear

[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

[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=gcc&view=rev&rev=148055 Log: PR middle-end/40316 * recog.c (peep2_reinit_state

[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=17941&action=view) source file after preprocessor I just created the temporary source file (via -save-temps) and attached it. -- http:/

[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 |

[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/bas

[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

[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 d

[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.sou

[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 -

[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-li

[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 L

[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

[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

[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)

[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-regressi

[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/Progra

[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-ap

[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 Ve

[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\rh

[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 lim

[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 cho

[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

[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

[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 co

[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

[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

[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=gcc&view=rev&rev=148036 Log: PR tree-optimization/39129 * tree-vect-loop-manip.

[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 --

[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

[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=gcc&view=rev&rev=148035 Log: 2009-06-01 Tobias Burnus PR fortran/40309 * t