[Bug bootstrap/39940] New: [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

-- Summary: [4.5 Regression] Bootstrap failure in libjava on i686- apple-darwin9 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: u

[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.

--- Comment #2 from julian1844 at yahoo dot com 2009-04-28 07:16 --- libpthread is needed to link libgomp, otherwise you get unresolved references like c:/mingw/bin/../lib/gcc/mingw32/4.3.0/libgomp.a(parallel.o):(.text+0xe): undefin ed reference to `_imp__pthread_getspecific'. Symbol pt

[Bug bootstrap/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

--- Comment #1 from dominiq at lps dot ens dot fr 2009-04-28 07:17 --- Hit the return key too soon!-( On i686-apple-darwin9 bootstrapping revision 146855 fails when building libjava with -m64: ... libtool: compile: /opt/gcc/i686-darwin/gcc/gcj -B/opt/gcc/i686-darwin/i686-apple-darwin

[Bug middle-end/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenther at suse dot de Component|bootstrap

[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.

--- Comment #3 from julian1844 at yahoo dot com 2009-04-28 07:23 --- (In reply to comment #1) > Well libpthreads is not part of the GCC project. > I posted my reply as comment #2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939

[Bug java/38374] constant pool references have wrong types in ADDR_EXPR

--- Comment #6 from rguenther at suse dot de 2009-04-28 08:19 --- Subject: Re: constant pool references have wrong types in ADDR_EXPR On Tue, 28 Apr 2009, dave dot korn dot cygwin at gmail dot com wrote: > --- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-04-28

[Bug middle-end/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-28 08:28 --- Looks like a duplicate of pr38374. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940

[Bug c/39941] New: ice in passes.c:execute_todo()

I just tried to compile the Suse Linux package trustedgrub-1.1.3-8.27 with the GNU gcc version 4.5 snapshot 20090423. The compiler said boot.c:1350: internal compiler error: in execute_todo, at passes.c:1030 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug fortran/39931] ICE on invalid Fortran 95 code (bad pointer assignment), gimplify_expr at gimplify.c:6315

--- Comment #5 from janus at gcc dot gnu dot org 2009-04-28 09:44 --- Subject: Bug 39931 Author: janus Date: Tue Apr 28 09:44:36 2009 New Revision: 146880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146880 Log: 2009-04-28 Janus Weil PR fortran/39930 PR for

[Bug fortran/39930] Bogus error: ambiguous reference

--- Comment #2 from janus at gcc dot gnu dot org 2009-04-28 09:44 --- Subject: Bug 39930 Author: janus Date: Tue Apr 28 09:44:36 2009 New Revision: 146880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146880 Log: 2009-04-28 Janus Weil PR fortran/39930 PR for

[Bug fortran/39930] Bogus error: ambiguous reference

-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org

[Bug target/39323] MAX_OFILE_ALIGNMENT in elfos.h is too big

--- Comment #7 from uros at gcc dot gnu dot org 2009-04-28 09:48 --- Subject: Bug 39323 Author: uros Date: Tue Apr 28 09:48:04 2009 New Revision: 146881 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146881 Log: PR c/39323 * config/alpha/elf.h (MAX_OFILE_ALIGNMEN

[Bug target/39323] MAX_OFILE_ALIGNMENT in elfos.h is too big

--- Comment #8 from ubizjak at gmail dot com 2009-04-28 09:49 --- (In reply to comment #5) > The alignment checks in tests pr39323-2.c and pr39323-3.c fail on > powerpc*-linux, where the value in .align is log2 of the alignment, not the > alignment itself.For an alignment of (1<<28)

[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install

--- Comment #7 from dennis dot wassel at googlemail dot com 2009-04-28 09:53 --- Neither `make bootstrap' nor `make all' produce different results. Btw: isn't `make' (which I tried earlier) equivalent to `make bootstrap'? Back to square 1. -- dennis dot wassel at googlemail dot com

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

--- Comment #8 from paolo dot carlini at oracle dot com 2009-04-28 10:34 --- Fixed for 4.4.1. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug fortran/39930] Bogus error: ambiguous reference

--- Comment #3 from janus at gcc dot gnu dot org 2009-04-28 10:50 --- Fixed with r146880. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/39931] ICE on invalid Fortran 95 code (bad pointer assignment), gimplify_expr at gimplify.c:6315

--- Comment #6 from janus at gcc dot gnu dot org 2009-04-28 10:52 --- Fixed with r146880. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/39941] ice in passes.c:execute_todo()

--- Comment #1 from dcb314 at hotmail dot com 2009-04-28 08:55 --- Created an attachment (id=17773) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17773&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39941

[Bug libstdc++/39881] error_condition constructor and assignment postconditions not met

--- Comment #5 from paolo dot carlini at oracle dot com 2009-04-28 10:35 --- Fixed for 4.4.1. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug libstdc++/39882] error_code constructor and assignment postconditions not met

--- Comment #4 from paolo at gcc dot gnu dot org 2009-04-28 10:32 --- Subject: Bug 39882 Author: paolo Date: Tue Apr 28 10:32:22 2009 New Revision: 146886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146886 Log: 2009-04-28 Paolo Carlini PR libstdc++/39880 P

[Bug middle-end/39927] [4.5 Regression]: build breakage for cris-elf building libstdc++-v3

--- Comment #10 from matz at gcc dot gnu dot org 2009-04-28 11:41 --- I see. These are different base variables (a and b here), where my patch doesn't help. Andreas Krebbels patch should fix that, except there's still some confusion in there, see http://gcc.gnu.org/ml/gcc-patches/2009-

[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-28 11:55 --- SUBROUTINE DTREVC( SIDE, HOWMNY, SELECT, N, T, LDT, VL, LDVL, VR, $ LDVR, MM, M, WORK, INFO ) DOUBLE PRECISION T( LDT, * ), VL( LDVL, * ), VR( LDVR, * ), $

[Bug c/39942] New: Nonoptimal code - leaveq; xchg %ax,%ax; retq

Sometimes we can see 2 bytes nop (xchg %ax,%ax) between leaveq and retq. IMHO, better to remove xchg %ax,%ax Examples from Kernel 2.6.29.1: > gcc --version gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291] > objdump vmlinux ... 804262e0 : 804262e0: 55

[Bug middle-end/39922] [4.5 regression] Revision 146817 caused many regressions on trunk

--- Comment #4 from matz at gcc dot gnu dot org 2009-04-28 12:23 --- Subject: Bug 39922 Author: matz Date: Tue Apr 28 12:22:47 2009 New Revision: 146889 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146889 Log: PR middle-end/39922 * tree-outof-ssa.c (insert_valu

[Bug libstdc++/39881] error_condition constructor and assignment postconditions not met

--- Comment #4 from paolo at gcc dot gnu dot org 2009-04-28 10:32 --- Subject: Bug 39881 Author: paolo Date: Tue Apr 28 10:32:22 2009 New Revision: 146886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146886 Log: 2009-04-28 Paolo Carlini PR libstdc++/39880 P

[Bug fortran/39489] [4.3 regression] write_atom(): Writing negative integer

--- Comment #11 from burnus at gcc dot gnu dot org 2009-04-28 11:46 --- I cannot reproduce this with 4.3.4 20090428 [gcc-4_3-branch revision 138185], however, valgrind shows Conditional jump or move depends on uninitialised value(s) at 0x446764: (within /gcc-4.3/libexec/gcc/x86_64

[Bug libstdc++/39882] error_code constructor and assignment postconditions not met

--- Comment #5 from paolo dot carlini at oracle dot com 2009-04-28 10:35 --- Fixed for 4.4.1. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug libgcj/39899] gjdoc in 4.4.0 fails to build the libgcj documentation

--- Comment #1 from aph at gcc dot gnu dot org 2009-04-28 09:35 --- Subject: Bug 39899 Author: aph Date: Tue Apr 28 09:35:22 2009 New Revision: 146878 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146878 Log: 2009-04-28 Andrew Haley PR libgcj/39899 * Makefil

[Bug middle-end/39922] [4.5 regression] Revision 146817 caused many regressions on trunk

--- Comment #5 from matz at gcc dot gnu dot org 2009-04-28 12:38 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006

--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-28 12:45 --- I have a patch for the gamess failure. What was the gromacs failure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39937

[Bug fortran/35732] -fbounds-check: LHS/RHS size mismatch: Misleading error message

--- Comment #7 from dominiq at lps dot ens dot fr 2009-04-28 12:48 --- Posted a full patch at http://gcc.gnu.org/ml/fortran/2009-04/msg00283.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35732

[Bug libgcj/39899] gjdoc in 4.4.0 fails to build the libgcj documentation

--- Comment #2 from aph at gcc dot gnu dot org 2009-04-28 12:51 --- Subject: Bug 39899 Author: aph Date: Tue Apr 28 12:51:10 2009 New Revision: 146890 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146890 Log: 2009-04-28 Andrew Haley PR libgcj/39899 * Makefil

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

--- Comment #7 from paolo at gcc dot gnu dot org 2009-04-28 10:32 --- Subject: Bug 39880 Author: paolo Date: Tue Apr 28 10:32:22 2009 New Revision: 146886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146886 Log: 2009-04-28 Paolo Carlini PR libstdc++/39880 P

[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006

--- Comment #5 from hjl dot tools at gmail dot com 2009-04-28 13:36 --- (In reply to comment #4) > I have a patch for the gamess failure. What was the gromacs failure? > cc -c -o pdbio.o -DSPEC_CPU -DNDEBUG -I. -DHAVE_CONFIG_H -O2 -ffast-math -DSPEC_CPU_LP64 pdbio.c pd

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-28 13:42 --- Can you provide the preprocessed source which contains set_blitting_type? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug middle-end/39943] New: [4.5 Regression] Failed SPEC CPU 2000

On Linux/Intel64, revision 146870 failed SPEC CPU 2000 at -O3 -ffast-math: Error: 1x176.gcc 1x177.mesa 1x253.perlbmk -- Summary: [4.5 Regression] Failed SPEC CPU 2000 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal

[Bug middle-end/39943] [4.5 Regression] Failed SPEC CPU 2000

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-28 13:56 --- Please paste in the errors/commandlines for the individual fails. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39943

[Bug middle-end/39943] [4.5 Regression] Failed SPEC CPU 2000

--- Comment #2 from hjl dot tools at gmail dot com 2009-04-28 14:03 --- For gcc, I got /export/gnu/import/svn/gcc-test/usr/bin/gcc -DSPEC_CPU2000_LP64 -Dalloca=_alloca -ffast-math -O3 -ffast-math -funroll-loops -Dalloca=_alloca toplev.c -S ... toplev.c: In function ‘main’:

[Bug ada/39944] New: Incorrect expected file name encoding

Although GNAT supports UTF-8 characters in identifiers, it looks for the wrong file name by default. For example, the following code procedure Désolé is begin null; end Désolé; stored in désolé.adb (with a filesystem storing file names in UTF-8) gives, when compiled with a recent development

[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006

--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-28 14:11 --- int foo (__const char *__restrict __s); static void read_anisou(char line[]) { foo (line+1); } void read_pdbfile(void) { char line[4096]; read_anisou (line); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?

[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39937

[Bug bootstrap/39925] classpath build fails with "find: bad option -path"

--- Comment #1 from erwinrm at gmail dot com 2009-04-28 14:14 --- Same issue on Solaris 9. SunOS xxx 5.9 Generic_122300-28 sun4u sparc SUNW,Sun-Fire find ../../../../.././libjava/classpath/tools/gnu/classpath/tools \ ../../../../.././libjava/classpath/tools/com/sun/java

[Bug bootstrap/39925] classpath build fails with "find: bad option -path"

--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-28 14:16 --- *** This bug has been marked as a duplicate of 38715 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-apple-darwin9 and powerpc-ibm-aix

--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-28 14:19 --- Subject: Bug 39929 Author: pinskia Date: Tue Apr 28 14:19:00 2009 New Revision: 146894 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146894 Log: 2009-04-28 Andrew Pinski PR target/39929

[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-apple-darwin9 and powerpc-ibm-aix

--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-28 14:21 --- The darwin part of this bug report should have been fixed. The AIX bug was unrelated to the darwin bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929

[Bug middle-end/39941] [4.5 Regression] ice in passes.c:execute_todo()

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ice in |[4.

[Bug middle-end/39943] [4.5 Regression] Failed SPEC CPU 2000

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-28 14:27 --- 176.gcc and 253.perlbmk are fixed by patches I already posted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/39945] New: -fopenmp causes runtime crash on assigning reasonably large array

The attached very simple program crashes at runtime if compiled with -fopenmp if the variable m is sufficiently large. -- Summary: -fopenmp causes runtime crash on assigning reasonably large array Product: gcc Version: 4.4.0 Status

[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array

--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-28 14:30 --- Created an attachment (id=17774) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17774&action=view) sample source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945

[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array

--- Comment #2 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-28 14:32 --- $ gfortran -v Using built-in specs. Target: i386-apple-darwin9.2.2 Configured with: ../configure --prefix=/opt/gcc --with-languages=c,fortran Thread model: posix gcc version 4.4.0 20080424 (experimental) (GCC)

[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array

--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-28 14:34 --- This is by design, large arrays usually have an implict SAVE on them, though with -fopenmp, they don't. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c/39903] [4.4 Regression] ICE on flexible member

--- Comment #13 from hjl at gcc dot gnu dot org 2009-04-28 14:35 --- Subject: Bug 39903 Author: hjl Date: Tue Apr 28 14:35:12 2009 New Revision: 146895 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146895 Log: gcc/ 2009-04-28 H.J. Lu Backport from mainline:

[Bug c/39903] [4.4 Regression] ICE on flexible member

--- Comment #14 from hjl dot tools at gmail dot com 2009-04-28 14:36 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|---

[Bug fortran/39946] New: PROCEDURE statements: interface with RESULT variable

The following program procedure(prc_is_allowed), pointer :: fptr interface function prc_is_allowed (flv, hel, col) result (is_allowed) logical :: is_allowed integer, intent(in) :: flv, hel, col end function prc_is_allowed end interface fptr => prc_is_allowed end

[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array

--- Comment #4 from dominiq at lps dot ens dot fr 2009-04-28 14:39 --- Works for me on powerpc-apple-darwin9 (OSX 10.5.6). What 'ulimit -a' reports for "stack size"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945

[Bug middle-end/39943] [4.5 Regression] Failed SPEC CPU 2000

--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-28 14:40 --- Testcase for 177.mesa: void gl_fog_index_pixels(float f, unsigned int n, unsigned int index[]) { unsigned int i; for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=39943

[Bug fortran/39946] PROCEDURE statements: interface with RESULT variable

--- Comment #1 from janus at gcc dot gnu dot org 2009-04-28 14:52 --- Here's a patch: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (Revision 146879) +++ gcc/fortran/resolve.c (Arbeitskopie) @@ -924

[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array

--- Comment #5 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-28 14:53 --- O, now I see my stupidity, as for some reason ulimit -s is set to a pathetic 8192k. I am sorry to have troubled you folks with this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945

[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array

--- Comment #6 from dominiq at lps dot ens dot fr 2009-04-28 15:19 --- On darwin I never found a way to increase the stack size above 65532kbytes, you may be interested to RTFM and specially: -fno-automatic Treat each program unit (except those marked as RECURSIVE) as if the SAVE statem

[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006

--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-28 15:27 --- Subject: Bug 39937 Author: rguenth Date: Tue Apr 28 15:27:09 2009 New Revision: 146901 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146901 Log: 2009-04-28 Richard Guenther PR middle-end/39937

[Bug target/39947] New: Shared libgcc getting clobbered for multilib builds

Hello, Recently multilib capability was added to w64 mingw32 targets in gcc trunk. I noticed that both 64bit and 32bit libgcc dlls install to /bin. This would be ok, for non-multilib native builds, but obviously not for multilib cross compilers. For me, they are both named "libgcc_s_sjlj-1.dll".

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

-sysroot=/mingw/w64_64 --enable-version-specific-runtime-libs --enable-shared --disable-nls --with-dwarf --enable-fully-dynamic-string --enable-languages=c gcc version 4.5.0 20090428 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947

[Bug c++/39948] New: Cannot set default arguments in methods when methods contain multiple templates...

I found that the compiler was unable to compile the code when a method had default values for its arguments. This only seems to happen when the argument had multiple templates and when in a method. The same code compiles when inside a function outside of a class. Also, the code compiles if a type

[Bug c++/39948] Cannot set default arguments in methods when methods contain multiple templates...

--- Comment #1 from Lee at Gregory dot uk dot net 2009-04-28 16:14 --- Created an attachment (id=17775) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17775&action=view) Very simple code, testFunc function compiles, but testFunc method does not. It is very strange that testFunc (fu

[Bug regression/39914] [4.4/4.5 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13

--- Comment #13 from uros at gcc dot gnu dot org 2009-04-28 16:18 --- Subject: Bug 39914 Author: uros Date: Tue Apr 28 16:18:17 2009 New Revision: 146904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146904 Log: PR rtl-optimization/39914 * ira-conflicts.c (ira_b

[Bug rtl-optimization/39914] [4.4 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13

--- Comment #14 from ubizjak at gmail dot com 2009-04-28 16:19 --- Fixed on the trunk so far. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|

[Bug fortran/39946] PROCEDURE statements: interface with RESULT variable

--- Comment #2 from janus at gcc dot gnu dot org 2009-04-28 16:27 --- Subject: Bug 39946 Author: janus Date: Tue Apr 28 16:27:27 2009 New Revision: 146905 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146905 Log: 2009-04-28 Janus Weil PR fortran/39946 * reso

[Bug fortran/39946] PROCEDURE statements: interface with RESULT variable

--- Comment #3 from janus at gcc dot gnu dot org 2009-04-28 16:31 --- Fixed with r146905. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/39949] New: [4.5 regression] Revision 146874 breaks %z on x87 insns

Revision 146874: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01518.html breaks %z on x87 insns: [...@gnu-16 float-1]$ cat foo.c #define fp_to_int(func,ftype,itype) \ itype \ __attribute__((noinline)) \ func (ftype value) \ { \ itype res; \ __asm__ __volatile__ ("fistp%z0 %0" : "=m" (res) : "t"

[Bug target/39949] [4.5 regression] Revision 146874 breaks %z on x87 insns

--- Comment #1 from ubizjak at gmail dot com 2009-04-28 16:39 --- Wontfix, the code uses undocumented operand modifier. -- ubizjak at gmail dot com changed: What|Removed |Added ---

[Bug target/39949] [4.5 regression] Revision 146874 breaks %z on x87 insns

--- Comment #2 from hjl dot tools at gmail dot com 2009-04-28 16:45 --- None of x86 insn modifiers are documented and %z comments in gcc source codes on 4.3/4.4 branches are simply incorrect. %z has been working on x87 insns since day 1 on gcc.gnu.org back to 1992. Why do we have to brea

[Bug c++/39948] Cannot set default arguments in methods when methods contain multiple templates...

--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-28 16:51 --- *** This bug has been marked as a duplicate of 57 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument

--- Comment #43 from pinskia at gcc dot gnu dot org 2009-04-28 16:51 --- *** Bug 39948 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

--- Comment #2 from vvv at ru dot ru 2009-04-28 17:04 --- Created an attachment (id=17776) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17776&action=view) Source file from Linx Kernel 2.6.29.1 See static void set_blitting_type -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

--- Comment #3 from vvv at ru dot ru 2009-04-28 17:10 --- Additional examples from Linux Kernel 2.6.29.1: (Note: conditional statement at the end of all fuctions!) = linux/drivers/video/console/bitblit.c void fbcon_set_bitops(struct fbcon_ops *ops) { ops->bmove

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

--- Comment #4 from vvv at ru dot ru 2009-04-28 17:15 --- Created an attachment (id=1) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=1&action=view) Simple example from Linux See two functons: static void pre_schedule_rt static void switched_from_rt -- http://gcc.gnu.o

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

--- Comment #5 from ubizjak at gmail dot com 2009-04-28 17:37 --- Unfortunately, all code snippets and dumps are of no use. Please see http://gcc.gnu.org/bugs.html for the reason why. As an exercise, please compile *standalone* _preprocessed_ source you will create with -S added to your

[Bug target/39949] [4.5 regression] Revision 146874 breaks %z on x87 insns

--- Comment #3 from bonzini at gnu dot org 2009-04-28 18:12 --- H.J., please do not make up testcases and tell us who was actually using %z for x87 as of March 31st, 2009. Otherwise, this bug has the same level of seriousness as the one I'm closing it as duplicate of. *** This bug has

[Bug c++/5] [1.36.3/1.37/.../3.2/3.3/3.4 regression] C++ sucks, can't you make it better?

--- Comment #13 from bonzini at gnu dot org 2009-04-28 18:12 --- *** Bug 39949 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added --

[Bug c++/39950] New: __unix__ macro is not predefined on AIX platform (C and C++)

__unix__ macro is not predefined with gcc/g++ on AIX platform. Should it be predefined on this platform for portability? -- Summary: __unix__ macro is not predefined on AIX platform (C and C++) Product: gcc Version: 3.3.4 Status:

[Bug target/39949] [4.5 regression] Revision 146874 breaks %z on x87 insns

--- Comment #4 from bonzini at gnu dot org 2009-04-28 18:13 --- reopening... -- bonzini at gnu dot org changed: What|Removed |Added Status|RESOLVED

[Bug target/39949] [4.5 regression] Revision 146874 breaks %z on x87 insns

--- Comment #5 from bonzini at gnu dot org 2009-04-28 18:14 --- ... to mark as waiting. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIR

[Bug target/39949] [4.5 regression] Revision 146874 breaks %z on x87 insns

--- Comment #6 from hjl dot tools at gmail dot com 2009-04-28 18:22 --- (In reply to comment #3) > H.J., please do not make up testcases and tell us who was actually using %z > for > x87 as of March 31st, 2009. > If I had told you that we had had several internal applications which us

[Bug target/39949] [4.5 regression] Revision 146874 breaks %z on x87 insns

--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-28 18:23 --- Considering this is all undocumened no. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug debug/39703] GCC produces single locations instead of location lists for some formal parameters

--- Comment #2 from jdraper at super dot org 2009-04-28 18:24 --- (In reply to comment #1) > IIRC at -O0, variable tracking is not enabled so it only produces single > locations. > This makes sense to me as a possible explanation, but my response would be to turn variable tracking on e

[Bug other/39951] New: Dangling symlink ".../include-fixed/mach" created on install

After installing GCC: $ ls -l $PREFIX/lib/gcc/alphaev56-dec-osf4.0g/4.4.0/include-fixed/mach lrwxr-xr-x 1 locallocal 25 Apr 28 14:22 $PREFIX/lib/gcc/alphaev56-dec-osf4.0g/4.4.0/include-fixed/mach -> root/usr/sys/include/mach $ ls -l $PREFIX/lib/gcc/alphaev56-dec-osf4.0g/4.4.0/inclu

[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array

--- Comment #7 from burnus at gcc dot gnu dot org 2009-04-28 19:25 --- (In reply to comment #6) > may be interested to RTFM and specially: > > -fno-automatic > -fmax-stack-var-size=n Well, -fopenmp implies -frecursive and thus the use of the stack. If a function can never be called in s

[Bug target/39949] [4.5 regression] Revision 146874 breaks %z on x87 insns

--- Comment #8 from bonzini at gnu dot org 2009-04-28 19:33 --- Subject: Re: [4.5 regression] Revision 146874 breaks %z on x87 insns > If I had told you that we had had several internal applications > which use %z on x87 since 1998, would it make a difference? Maybe no, but i

[Bug debug/39703] GCC produces single locations instead of location lists for some formal parameters

--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-04-28 19:44 --- > This makes sense to me as a possible explanation, but my response would be > to turn variable tracking on even at -O0. This was experimented, but this generates bloated and inferior debugging infor mation for t

[Bug c++/35669] NULL (__null) not considered different from 0 with C++

--- Comment #9 from mdorey at bluearc dot com 2009-04-28 20:00 --- (In reply to comment #1) > Because a null pointer constant is an integral constant expression, thus the > warning is wrong. Are all integral constant expressions necessarily implicitly convertible to all integer types?

[Bug testsuite/39952] New: Inadequate gcc.dg/compat/struct-layout-1_generate.c

gcc.dg/compat/struct-layout-1_generate.c generates some tests randomly. Not all possible combinations are tested. The test T(2456,double a;struct{int * c;}b[];,F(2456,a,-85022.609375,131929.593750)) from PR 39903 was never generated on Linux/x86-64. As the result, PR 39903 regression wasn't detec

[Bug fortran/39953] New: Error: Expected VARIABLE at (1)

This compilation problem prevents SPECmpi benchmark 115.fds4 (file read.f) from compiling with gfortran. Here is an example of the problem: % cat read.f MODULE READ CONTAINS SUBROUTINE READ_SPRK OPEN(95,FILE='dat',FORM='FORMATTED',STATUS='OL

[Bug c/39903] [4.4 Regression] ICE on flexible member

--- Comment #15 from hjl dot tools at gmail dot com 2009-04-28 20:04 --- (In reply to comment #10) > (In reply to comment #9) > > Is this one of those bugs that only trigger on -fPIC? > > I opened PR 39952 for this. -- hjl dot tools at gmail dot com changed: What|R

[Bug fortran/39953] Error: Expected VARIABLE at (1)

--- Comment #1 from dominiq at lps dot ens dot fr 2009-04-28 20:38 --- Works for me on (powerpc|i686)-apple-darwin9 gfortran 4.2.3, 4.3.3, 4.4.0, and trunk. You should update your gfortran to at least 4.3.3 (4.2 is no longer supported). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug testsuite/39790] gcc.dg/tls/alias-1.c,opt-2.c fail if TLS is not supported by C library

--- Comment #3 from jingyu at gcc dot gnu dot org 2009-04-28 20:39 --- Subject: Bug 39790 Author: jingyu Date: Tue Apr 28 20:39:11 2009 New Revision: 146913 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146913 Log: PR testsuite/39790 * lib/target-supports.exp (c

[Bug target/39949] [4.5 regression] Revision 146874 breaks %z on x87 insns

--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-28 20:47 --- FWIW I agree. Relying on undocumented behavior is as invalid as any other invalid asm that happened to work in the past. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39949

[Bug libstdc++/39491] [4.2/4.3 regression] symbol __signb...@glibcxx_3.4 in libstdc++ exported

--- Comment #28 from carlos at codesourcery dot com 2009-04-28 20:57 --- Exporting a non-default versioned symbol is useless since new programs won't be able to link against that definition. Did 4.2/4.3 export a global default symbol for __signbitl? If we did export a global default s

[Bug testsuite/39790] gcc.dg/tls/alias-1.c,opt-2.c fail if TLS is not supported by C library

--- Comment #4 from jingyu at gcc dot gnu dot org 2009-04-28 20:57 --- Subject: Bug 39790 Author: jingyu Date: Tue Apr 28 20:57:42 2009 New Revision: 146914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146914 Log: Backport from mainline. PR testsuite/39790

[Bug testsuite/39790] gcc.dg/tls/alias-1.c,opt-2.c fail if TLS is not supported by C library

--- Comment #5 from jingyu at gcc dot gnu dot org 2009-04-28 20:58 --- Patch was committed to trunk and branch 4.4. -- jingyu at gcc dot gnu dot org changed: What|Removed |Added --

[Bug middle-end/39941] [4.5 Regression] ice in passes.c:execute_todo()

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-28 21:09 --- Confirmed. #1 0x084a7d71 in execute_todo (flags=7) at /home/richard/src/trunk/gcc/passes.c:1031 1031gcc_assert (flags & TODO_update_ssa_any); (gdb) #2 0x084a8772 in execute_one_pass (pass=0x8d26100)

  1   2   >