[Bug target/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #8 from julian1844 at yahoo dot com 2009-04-30 06:38 --- (In reply to comment #7) ok, mingw should be linking against libpthreads with -fopenmp (it should also be linking against libgomp also) I don't think libgomp has been ported to mingw yet. I wonder if the source code for libgomp is available. I'm looking for it about 5 days and I cannot find it. Have you got any idea? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #8 from ruben at tapir dot caltech dot edu 2009-04-30 07:33 --- In my considered opinion, the need to support these functions has little to do with efficiency or with convenience. It has more to do with accuracy and symmetries; relations such as sind(30)=0.5, cosd(90)=0.0, and such must be fulfilled exactly, and that without damaging finite-differencing properties. Relations such as sind(x)=cosd(90-x) may also be fulfilled to sufficient accuracy - and maybe even exactly. These things are difficult or impossible to achieve using radian units, giving niche use to the degree-based functions for applications where high floating point accuracy of symmetries must be preserved. Angular grids in curvilinear CFD occassionally need that. There must be other examples. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #9 from ruben at tapir dot caltech dot edu 2009-04-30 07:38 --- Someone suggested multiplying or dividing the argument by a factor. That does not do - the floating point precision achieved would be insufficient. Someone complains about the names of these functions. I don't care one way or the other about that - I need the functions, I don't care about the spelling - they are not in the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #10 from steven at gcc dot gnu dot org 2009-04-30 07:51 --- These functions will *not* be implemented, period. And even if they would be implemented, they'd internally just return sin(arg*180/pi) co. The compiler and the runtime library don't actually calculate sin/cos themselves. They rely on libc and often on machine instructions, and they all work in radians too. End of discussion -- move along... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug debug/35462] anonymous struct in c++ has wrong name in -gdwarf-2
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-04-30 07:52 --- Please close it as DUPLICATE of PR debug/35463. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added CC||jan dot kratochvil at redhat ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35462
[Bug tree-optimization/39621] Delaying operation to end of function causes high stack usage
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-30 07:54:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39621
[Bug bootstrap/39968] [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used
--- Comment #4 from espindola at google dot com 2009-04-30 08:07 --- Probably fixed on 146998. Andrew Pinski, we cannot use a shared library for this. The idea is for the plugin to remember what gcc version it was compiled for. A shared library can change after the fact. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968
[Bug middle-end/39973] [4.5 Regression] 416.gamess in SPEC CPU 2006 is miscompiled
-- 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=39973
[Bug middle-end/39972] [4.5 Regression] 465.tonto in SPEC CPU 2006 is miscompiled
-- 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=39972
[Bug target/35586] seg fault when compiling liboil 0.3.13, file conv_c.c
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 09:02 --- Can you try with a later version of the compiler (in the set of released versions) 4.3.4 , 4.4.0 or trunk and report back ? Don't get this failure with arm-eabi configurations. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35586
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #16 from jakub at gcc dot gnu dot org 2009-04-30 09:07 --- Created an attachment (id=17783) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17783action=view) gcc45-pr39942.patch Patch that attempts to take into account .p2align directives that are emitted for (some) CODE_LABELs and also the gen_align insns that the pass itself inserts. For a CODE_LABEL, say .p2align 16,,10 means either that the .p2align directive starts a new 16 byte page (then insns before it are never interesting), or nothing was skipped because more than 10 bytes would need to be skipped. But that means the current group could contain only 5 or less bytes of instructions before the label, so again, we don't have to look at instructions not in the last 5 bytes. Another fix is that for MAX_SKIP 7, ASM_OUTPUT_MAX_SKIP_ALIGN shouldn't emit the second .p2align 3, which might (and often does) skip more than MAX_SKIP bytes (up to 7). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug libfortran/36689] PRINT and WRITE eat minus sign
--- Comment #10 from pault at gcc dot gnu dot org 2009-04-30 09:52 --- (In reply to comment #9) (In reply to comment #8) I have remote access to the machine now. Having trouble with gcc build. Not forgotton. I remember our admin talking about needing an updated ld to be able to compile gcc. Are you aware of anything in that direction? Where are we with this one, Dennis and Jerry? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36689
[Bug target/38571] [arm] -mthumb generates unnecessary padding between functions
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-30 10:05 --- Subject: Bug 38571 Author: ramana Date: Thu Apr 30 10:04:52 2009 New Revision: 147000 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147000 Log: Fix PR target/38571 Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
[Bug target/38571] [arm] -mthumb generates unnecessary padding between functions
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-30 10:05 --- This is now fixed with r147000 -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
[Bug target/38571] [arm] -mthumb generates unnecessary padding between functions
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
[Bug bootstrap/39968] [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used
--- Comment #5 from joseph at codesourcery dot com 2009-04-30 10:09 --- Subject: Re: [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used On Thu, 30 Apr 2009, pinskia at gcc dot gnu dot org wrote: Really I think plugin support is flawed. There should really be a shared library which the plugins link against and this library is what the main GCC links against too. This may be needed to support plugins on Windows hosts (and plugins do definitely need a common GCC-provided build infrastructure so that plugins people write will naturally build for other OSes as soon as support for them is added to that infrastructure), but we should not need to slow down GCC on Linux hosts by putting most of it in a shared library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968
[Bug bootstrap/22479] Use of --prefix and --exec-prefix breaks compiler build with --with-headers
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-30 10:10 --- Can you try with a compiler of more recent vintage and report back. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22479
[Bug bootstrap/29780] temporary file breaks cross-build
--- Comment #5 from ramana at gcc dot gnu dot org 2009-04-30 10:18 --- Can you try with a compiler of more recent vintage and report back ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29780
[Bug target/39975] New: Support big endian ARM by default.
Create a default configuration that honours big endian ARM by default. PR31938 refers to this. -- Summary: Support big endian ARM by default. Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana at gcc dot gnu dot org GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39975
[Bug target/39975] Support big endian ARM by default.
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-30 10:25:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39975
[Bug target/31938] Wrong code on int to short cast on armeb
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 10:25 --- If there is a request to support a big endian default configuration for ARM, there should be a separate enhancement request for that. Given this, I'd close this bug as being invalid. I've filed PR39975 for this particular request. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31938
[Bug middle-end/31241] Post Increment opportunity missed
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 10:30 --- Not sure if this is related to PR31849 as well. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-30 10:30:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31241
[Bug libfortran/36689] PRINT and WRITE eat minus sign
--- Comment #11 from dennis dot wassel at googlemail dot com 2009-04-30 10:31 --- It is working with 4.3.3, so it seems to have been silently fixed somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36689
[Bug middle-end/38696] gcc.dg/torture/pr37868.c wrong code at -O2 and above for 4.3 and trunk / bit packing
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-30 10:37 --- For 4.3 try if -fno-tree-sra fixes the failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38696
[Bug target/33519] Invalid code generated with a combination of thumb, AAPCS and -Os.
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-30 10:39 --- We need more information on what the exact problem is with the code generated. Could you try with a compiler of more recent vintage and report back ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33519
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-30 10:53:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug tree-optimization/39974] New: [4.5 regression] Bogus array subscript is below array bounds warning in compiler generated code
The following code snippet produces a bogus warning when compiled with
-O2 -Wall on trunk:
bug.cc: In function 'void
_Z41__static_initialization_and_destruction_0ii.clone.0()':
bug.cc:3: warning: array subscript is below array bounds
bug.cc:3: warning: array subscript is below array bounds
bug.cc:3: warning: array subscript is below array bounds
Maybe the warning indicates a code generation bug.
Interestingly, the second array must contain at least 42 elements ;-)
==
#includestring
std::string x[2][3] = { { , , }, { , , } };
struct A
{
A(int);
};
struct B
{
A a1, a2, a3, a4, a5, a6;
};
B b[42] =
{
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 }
};
==
--
Summary: [4.5 regression] Bogus array subscript is below array
bounds warning in compiler generated code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39974
[Bug middle-end/38696] gcc.dg/torture/pr37868.c wrong code at -O2 and above for 4.3 and trunk / bit packing
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-30 09:27 --- Seems to work today on gcc50 with gcc 4.4.0 and trunk on the simulator .I don't see these failures in recent testresults on gcc-testresults@ from the auto-tester at gcc50. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38696
[Bug rtl-optimization/29336] shorten_branches and machine-dependent constant pool placement should be integrated
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|sh-elf, arm-elf |sh-elf, arm-elf, arm-eabi Last reconfirmed|-00-00 00:00:00 |2009-04-30 10:26:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29336
[Bug target/35562] internal compiler error compiling qemu on arm
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-30 11:29 --- gcc 3.4 is no longer supported. Marking this as WONTFIX. -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||ramana at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35562
[Bug tree-optimization/39974] [4.5 regression] Bogus array subscript is below array bounds warning in compiler generated code
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39974
[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9
--- Comment #5 from dominiq at lps dot ens dot fr 2009-04-30 11:25 --- Does http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01619.html fix this? No! Still fails at revision 146999. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
[Bug rtl-optimization/29336] shorten_branches and machine-dependent constant pool placement should be integrated
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29336
[Bug libfortran/36689] PRINT and WRITE eat minus sign
--- Comment #12 from dennis dot wassel at googlemail dot com 2009-04-30 12:44 --- Closing, works with 4.3.3 -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36689
[Bug debug/35462] anonymous struct in c++ has wrong name in -gdwarf-2
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-30 12:46 --- *** This bug has been marked as a duplicate of 35463 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35462
[Bug debug/35463] typedef missing in debug information with -gdwarf-2 for c++
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-30 12:46 --- *** Bug 35462 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
[Bug middle-end/39973] [4.5 Regression] Revision 146817 miscompiled 416.gamess in SPEC CPU 2006
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-30 13:00 --- Revision 146817: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||matz at suse dot de Summary|[4.5 Regression] 416.gamess|[4.5 Regression] Revision |in SPEC CPU 2006 is |146817 miscompiled |miscompiled |416.gamess in SPEC CPU 2006 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
[Bug middle-end/39972] [4.5 Regression] 465.tonto in SPEC CPU 2006 is miscompiled
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-30 13:02 --- Revision 146817: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html may be the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
[Bug debug/35463] typedef missing in debug information with -gdwarf-2 for c++
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-30 13:05 --- I think this has been fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=146137 http://gcc.gnu.org/viewcvs?root=gccview=revrev=146290 http://gcc.gnu.org/viewcvs?root=gccview=revrev=146897 on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
[Bug rtl-optimization/34849] Missed autoincrement opportunities due to a different basic block structure.
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-30 13:18:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849
[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9
--- Comment #6 from bonzini at gnu dot org 2009-04-30 14:56 --- Fails after PRE. Reduced testcase requiring just a jc1 executable (assuming gcc is built in a subdirectory of the toplevel, i.e. ../configure): ./jc1 ../../libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -fPIC -feliminate-unused-debug-symbols -quiet -mmacosx-version-min=10.5.6 -m64 -mtune=generic -g -O2 -Wno-deprecated -ffloat-store -fomit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fjni -findirect-dispatch -fno-indirect-classes -fno-common -fbootclasspath=../../libjava/classpath/lib/ -o /dev/null -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-30 14:56:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9
--- Comment #7 from bonzini at gnu dot org 2009-04-30 14:56 --- Ah, I didn't bootstrap so jc1 cannot be miscompiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
[Bug fortran/39667] I/O possibly unneccesary truncations
--- Comment #2 from jb at gcc dot gnu dot org 2009-04-30 15:12 --- Subject: Bug 39667 Author: jb Date: Thu Apr 30 15:12:37 2009 New Revision: 147004 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147004 Log: Fix PR libfortran/39667 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/advance_1.f90 trunk/gcc/testsuite/gfortran.dg/advance_4.f90 trunk/gcc/testsuite/gfortran.dg/advance_5.f90 trunk/gcc/testsuite/gfortran.dg/append_1.f90 trunk/gcc/testsuite/gfortran.dg/backslash_1.f90 trunk/gcc/testsuite/gfortran.dg/backslash_2.f90 trunk/gcc/testsuite/gfortran.dg/backslash_3.f trunk/gcc/testsuite/gfortran.dg/backspace_10.f90 trunk/gcc/testsuite/gfortran.dg/backspace_3.f trunk/gcc/testsuite/gfortran.dg/backspace_4.f trunk/gcc/testsuite/gfortran.dg/backspace_5.f trunk/gcc/testsuite/gfortran.dg/backspace_8.f trunk/gcc/testsuite/gfortran.dg/backspace_9.f trunk/gcc/testsuite/gfortran.dg/complex_write.f90 trunk/gcc/testsuite/gfortran.dg/convert_implied_open.f90 trunk/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_1.f trunk/gcc/testsuite/gfortran.dg/dos_eol.f trunk/gcc/testsuite/gfortran.dg/empty_format_1.f90 trunk/gcc/testsuite/gfortran.dg/endfile.f trunk/gcc/testsuite/gfortran.dg/eof_1.f90 trunk/gcc/testsuite/gfortran.dg/eor_1.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_1.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_2.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_3.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_4.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_5.f90 trunk/gcc/testsuite/gfortran.dg/error_recovery_5.f90 trunk/gcc/testsuite/gfortran.dg/f2003_inquire_1.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_4.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_5.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_7.f03 trunk/gcc/testsuite/gfortran.dg/fgetc_1.f90 trunk/gcc/testsuite/gfortran.dg/fgetc_2.f90 trunk/gcc/testsuite/gfortran.dg/flush_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_exhaust.f90 trunk/gcc/testsuite/gfortran.dg/fmt_huge.f90 trunk/gcc/testsuite/gfortran.dg/fmt_read.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_2.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_3.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_4.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_5.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_7.f trunk/gcc/testsuite/gfortran.dg/fseek.f90 trunk/gcc/testsuite/gfortran.dg/ftell_1.f90 trunk/gcc/testsuite/gfortran.dg/ftell_2.f90 trunk/gcc/testsuite/gfortran.dg/func_derived_3.f90 trunk/gcc/testsuite/gfortran.dg/inquire_9.f90 trunk/gcc/testsuite/gfortran.dg/iostat_1.f90 trunk/gcc/testsuite/gfortran.dg/iostat_2.f90 trunk/gcc/testsuite/gfortran.dg/list_read_1.f90 trunk/gcc/testsuite/gfortran.dg/list_read_4.f90 trunk/gcc/testsuite/gfortran.dg/list_read_5.f90 trunk/gcc/testsuite/gfortran.dg/list_read_7.f90 trunk/gcc/testsuite/gfortran.dg/list_read_8.f90 trunk/gcc/testsuite/gfortran.dg/list_read_9.f90 trunk/gcc/testsuite/gfortran.dg/namelist_13.f90 trunk/gcc/testsuite/gfortran.dg/namelist_14.f90 trunk/gcc/testsuite/gfortran.dg/namelist_15.f90 trunk/gcc/testsuite/gfortran.dg/namelist_16.f90 trunk/gcc/testsuite/gfortran.dg/namelist_17.f90 trunk/gcc/testsuite/gfortran.dg/namelist_18.f90 trunk/gcc/testsuite/gfortran.dg/namelist_19.f90 trunk/gcc/testsuite/gfortran.dg/namelist_20.f90 trunk/gcc/testsuite/gfortran.dg/namelist_24.f90 trunk/gcc/testsuite/gfortran.dg/namelist_26.f90 trunk/gcc/testsuite/gfortran.dg/namelist_27.f90 trunk/gcc/testsuite/gfortran.dg/namelist_28.f90 trunk/gcc/testsuite/gfortran.dg/namelist_37.f90 trunk/gcc/testsuite/gfortran.dg/namelist_38.f90 trunk/gcc/testsuite/gfortran.dg/namelist_39.f90 trunk/gcc/testsuite/gfortran.dg/namelist_40.f90 trunk/gcc/testsuite/gfortran.dg/namelist_43.f90 trunk/gcc/testsuite/gfortran.dg/namelist_44.f90 trunk/gcc/testsuite/gfortran.dg/namelist_45.f90 trunk/gcc/testsuite/gfortran.dg/namelist_46.f90 trunk/gcc/testsuite/gfortran.dg/namelist_47.f90 trunk/gcc/testsuite/gfortran.dg/namelist_48.f90 trunk/gcc/testsuite/gfortran.dg/namelist_49.f90 trunk/gcc/testsuite/gfortran.dg/namelist_50.f90 trunk/gcc/testsuite/gfortran.dg/namelist_51.f90 trunk/gcc/testsuite/gfortran.dg/namelist_52.f90 trunk/gcc/testsuite/gfortran.dg/namelist_56.f90 trunk/gcc/testsuite/gfortran.dg/namelist_char_only.f90 trunk/gcc/testsuite/gfortran.dg/namelist_use.f90 trunk/gcc/testsuite/gfortran.dg/namelist_use_only.f90 trunk/gcc/testsuite/gfortran.dg/noadv_size.f90 trunk/gcc/testsuite/gfortran.dg/open_access_append_1.f90 trunk/gcc/testsuite/gfortran.dg/pad_no.f90 trunk/gcc/testsuite/gfortran.dg/pr12884.f trunk/gcc/testsuite/gfortran.dg/pr17090.f90
[Bug debug/35463] typedef missing in debug information with -gdwarf-2 for c++
--- Comment #5 from jan dot kratochvil at redhat dot com 2009-04-30 15:15 --- Just that I agree this Bug looks to me fixed in g++-4.5. The sample code like what is Comment 0 here from: http://gcc.gnu.org/ml/gcc-help/2009-04/msg00393.html gives DW_TAG_structure_type DW_AT_name anonymous struct on: g++ (GCC) 4.4.0 20090427 (Red Hat 4.4.0-3) and gives DW_TAG_structure_type DW_AT_name type27 on: g++ (GCC) 4.5.0 20090430 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2009-04-30 16:09 --- Subject: Re: gfortran support for non-standard sind,cosd and friends intrinsics On Thu, Apr 30, 2009 at 07:38:31AM -, ruben at tapir dot caltech dot edu wrote: --- Comment #9 from ruben at tapir dot caltech dot edu 2009-04-30 07:38 --- Someone suggested multiplying or dividing the argument by a factor. That does not do - the floating point precision achieved would be insufficient. Yep. I even wrote the necessary code. You're more than welcomed to improve it. http://gcc.gnu.org/ml/fortran/2006-12/msg00329.html You need to (1) Treat special cases. (2) Add argument reduction in degrees. (3) Treat special cases of the reduced argument. (4) Convert to radians and use the hardware FPU, or implement a Remes polynomial approximation to evaluation the function in degrees. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug fortran/39971] kinds.h fails at building libgfortran
--- Comment #2 from gustcr at yahoo dot com dot ar 2009-04-30 16:24 --- (In reply to comment #1) Change Severity to normal. Fortran bugs are never major. AFAIK, there will be no further releases from the gcc-4.1.x branch, so it is highly unlikely that this bug will be fixed. gcc-4.4.0 was released a week or so ago. Try using it. You'll find that gfortran in 4.4.0 is much, much, much, better than the compiler in 4.1.2 (a two year old piece of software). Thanks for the quick replay. Unfortunately, I have just tried with gcc-4.4.0 and it gives a similar error. Now I used: /home2/gdb/local/src/gcc-4.4.0/configure --prefix=/home2/gdb/local/gcc-4.4.0 --enable-languages=c,fortran --with-as=/home2/gdb/local/binutils-2.18/bin/as --with-ld=/home2/gdb/local/binutils-2.18/bin/ld I copied gmp-4.2.4 and and mpfr-2.4.1 within the source, so as to build everything together. Also tried with other versions of gmp, mpfr and binutils getting always the same error. -- gustcr at yahoo dot com dot ar changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39971
[Bug regression/39976] New: [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
We have a hot spot on sixtrack in a function called thin6d. Such loop is generated by the old (pre-146817) gcc as a single BB, thus the only way inside that loop is by executing instructions until we fall into that code. The post-146817 gcc breaks that loop in two BB's, such that we can actually branch to the middle of that loop in the first iteration, and then the loop runs just like in pre-146817. The degradation comes from the fact that the creation of two BB's breaks good scheduling of instructions inside that loop, like this: Good code: All the fp load instructions are grouped in the upper portion of the code. fmulf22,f11,f13 fmulf23,f11,f0 addis r12,r6,-27 lfd f3,0(r6) addir4,r6,8 lfd f1,9472(r12) addis r12,r4,-27 fmadd f8,f12,f0,f22 fmsub f4,f12,f13,f23 lfd f22,9472(r12) lfd f23,8(r6) addir6,r4,8 fmulf11,f8,f13 fmulf24,f8,f1 fmulf25,f8,f3 fmulf5,f8,f0 fmadd f11,f4,f0,f11 fmadd f21,f4,f3,f24 fmsub f2,f4,f1,f25 fmsub f12,f4,f13,f5 fmulf1,f11,f23 fmulf8,f11,f22 faddf9,f9,f21 faddf10,f10,f2 fmsub f24,f12,f22,f1 fmadd f25,f12,f23,f8 faddf10,f10,f24 faddf9,f9,f25 bdnz100ca878 thin6d_+0x1018 Bad code: The second pair of loads are pushed down the second BB, causing slowdowns. fmulf5,f8,f0 addis r3,r4,-27 lfd f22,8(r7) addir7,r4,8 lfd f6,9472(r3) fmadd f10,f9,f0,f10 fmsub f23,f9,f13,f5 fmulf2,f10,f22 fmulf9,f10,f6 fmr f7,f23 fmsub f25,f23,f6,f2 fmadd f26,f23,f22,f9 faddf12,f12,f25 faddf11,f11,f26 fmulf8,f10,f13 BB mark fmulf22,f10,f0 addis r3,r7,-27 lfd f21,0(r7) addir4,r7,8 lfd f25,9472(r3) fmadd f8,f7,f0,f8 fmsub f9,f7,f13,f22 fmulf23,f8,f21 fmulf26,f8,f25 fmsub f24,f9,f25,f23 fmadd f7,f9,f21,f26 faddf12,f12,f24 faddf11,f11,f7 bdnz100c9fe0 thin6d_+0xfd0 -- Summary: [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: luisgpm at linux dot vnet dot ibm dot com GCC build triplet: powerpc*-*-* GCC host triplet: powerpc*-*-* GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug tree-optimization/39955] [4.5 Regression] struct-layout-1 test failures passing struct containing _Decimal32
--- Comment #12 from janis at gcc dot gnu dot org 2009-04-30 16:30 --- In comment #10 I meant that the tests in gcc.c-torture/execute now pass for powerpc64-linux with -m32 and -m64, and that the 3 tests in gcc.target/powerpc listed in comment #7 still fail for powerpc64-linux with -m32; sorry for the confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39955
[Bug middle-end/39972] [4.5 Regression] Revision 146817 miscompiled 465.tonto in SPEC CPU 2006
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-30 16:32 --- Revision 146817 is the cause. It is reproducible with test data, -i test. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.5 Regression] 465.tonto |[4.5 Regression] Revision |in SPEC CPU 2006 is |146817 miscompiled 465.tonto |miscompiled |in SPEC CPU 2006 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
[Bug rtl-optimization/38373] 32-bit Vortex degradation on PPC due to bad RTL aliasing
--- Comment #3 from luisgpm at linux dot vnet dot ibm dot com 2009-04-30 16:33 --- This is already in 4.4, but we would like to add additional checks on 4.5 that would be risky to have on 4.4 (since it was almost being released). I have the additional patch and will attach it soon. Sorry it took so long to reply. Luis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38373
[Bug fortran/39971] kinds.h fails at building libgfortran
--- Comment #3 from kargl at gcc dot gnu dot org 2009-04-30 16:35 --- (In reply to comment #2) (In reply to comment #1) Change Severity to normal. Fortran bugs are never major. AFAIK, there will be no further releases from the gcc-4.1.x branch, so it is highly unlikely that this bug will be fixed. gcc-4.4.0 was released a week or so ago. Try using it. You'll find that gfortran in 4.4.0 is much, much, much, better than the compiler in 4.1.2 (a two year old piece of software). Thanks for the quick replay. Unfortunately, I have just tried with gcc-4.4.0 and it gives a similar error. Now I used: /home2/gdb/local/src/gcc-4.4.0/configure --prefix=/home2/gdb/local/gcc-4.4.0 --enable-languages=c,fortran --with-as=/home2/gdb/local/binutils-2.18/bin/as --with-ld=/home2/gdb/local/binutils-2.18/bin/ld I copied gmp-4.2.4 and and mpfr-2.4.1 within the source, so as to build everything together. Also tried with other versions of gmp, mpfr and binutils getting always the same error. If 4.4.0 doesn't build on your i686-pc-linux-gnu system, then something is definitely broken but it's not gfortran. Do you have an older version of MPFR or GMP installed in /usr/local? This can sometimes cause problems. What happens if you use the system's ld and as? -- kargl at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39971
[Bug bootstrap/39977] New: r1467817 broke bootstrap on PA
The 32 bit PA build broke with version 146817. The failure can be reproduced
by compiling the included test program. The failure is:
x.c: In function '__fixtfdi':
x.c:9: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6825
Please submit a full bug report,
with preprocessed source if appropriate.
The source code is:
typedef int DItype __attribute__ ((mode (DI)));
typedef float TFtype __attribute__ ((mode (TF)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));
extern UDItype __fixunstfdi (TFtype);
DItype
__fixtfdi (TFtype a)
{
if (a 0)
return - __fixunstfdi (-a);
return __fixunstfdi (a);
}
--
Summary: r1467817 broke bootstrap on PA
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|regression |middle-end Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #16 from pault at gcc dot gnu dot org 2009-04-30 17:03 --- module m type t integer :: i,j end type t interface assignment (=) module procedure i_to_t end interface contains elemental subroutine i_to_t (p, q) type(t), intent(out) :: p integer, intent(in) :: q p%i = q end subroutine end module use m type(t), target :: a(3) type(t), target :: b(3) type(t), dimension(:), pointer :: p a%i = 1 a%j = 2 b%i = 3 b%j = 4 p = b a = p%i print *, a%j end Also shows the fault, so it's not just restricted to WHERE assignments. It's interesting to note that in this case, the dependency is due to the possibility of aliasing and is, in fact, not present. I can see easily how to fix it for the case here but have not quite clocked how to do comment#1 yet. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug tree-optimization/39978] New: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
if [ x-fPIC != x ]; then \
/home/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.5.0/arm-none-linux-gnueabi/bin/ -c
-DHAVE_CONFIG_H -g -O2 -I/home/dave/opt/gnu/include -I.
-I../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic -fPIC ../../gcc/libiberty/regex.c -o
pic/regex.o; \
else true; fi
In file included from ../../gcc/libiberty/regex.c:638:
../../gcc/libiberty/regex.c: In function 'byte_re_compile_fastmap':
../../gcc/libiberty/regex.c:4541: internal compiler error: Segmentation fault
Performing interprocedural optimizations
visibility early_local_cleanups {GC 5739k - 2977k} summary generate
cp inline static-var pure-constAssembling functions:
byte_compile_range byte_common_op_match_null_string_p
byte_alt_match_null_string_p byte_group_match_null_string_p xre_set_syntax
xre_set_registers xregfree xregerror byte_regex_compile {GC 5405k - 3470k}
xre_comp xre_compile_pattern byte_re_compile_fastmap {GC 5325k -
Program received signal SIGSEGV, Segmentation fault.
0x002c5398 in lookup_page_table_entry (p=0xafafafaf)
at ../../gcc/gcc/ggc-page.c:588
588 return base[L1][L2];
(gdb) bt
#0 0x002c5398 in lookup_page_table_entry (p=0xafafafaf)
at ../../gcc/gcc/ggc-page.c:588
#1 0x002c6294 in ggc_set_mark (p=0xafafafaf) at ../../gcc/gcc/ggc-page.c:1318
#2 0x0092fe80 in gt_ggc_mx_basic_block_def (x_p=0x404c3a78)
at gtype-desc.c:859
#3 0x00930558 in gt_ggc_mx_gimple_statement_d (x_p=0x404c3a50)
at gtype-desc.c:990
#4 0x00930228 in gt_ggc_mx_gimple_seq_node_d (x_p=0x4069c6b0)
at gtype-desc.c:931
#5 0x00930310 in gt_ggc_mx_gimple_seq_d (x_p=0x40593770) at gtype-desc.c:947
#6 0x0092e094 in gt_ggc_mx_gimple_bb_info (x_p=0x40702ef8) at gtype-desc.c:269
#7 0x0092ffe0 in gt_ggc_mx_basic_block_def (x_p=0x40731740)
at gtype-desc.c:879
#8 0x0092e89c in gt_ggc_mx_control_flow_graph (x_p=0x406b03b8)
at gtype-desc.c:411
#9 0x0092f7b8 in gt_ggc_mx_function (x_p=0x4069ba50) at gtype-desc.c:732
#10 0x000dab18 in gt_ggc_mx_lang_tree_node (x_p=0x4021c2a0)
at ./gt-c-decl.h:349
#11 0x000dad44 in gt_ggc_mx_lang_tree_node (x_p=0x402163f0)
at ./gt-c-decl.h:376
#12 0x000dabbc in gt_ggc_mx_lang_tree_node (x_p=0x40216460)
at ./gt-c-decl.h:356
#13 0x000dabbc in gt_ggc_mx_lang_tree_node (x_p=0x406b1150)
---Type return to continue, or q return to quit---
at ./gt-c-decl.h:356
#14 0x000da918 in gt_ggc_mx_lang_tree_node (x_p=0x40772c80)
at ./gt-c-decl.h:333
#15 0x0092ddc4 in gt_ggc_mx_cgraph_node (x_p=0x405ad800) at gtype-desc.c:229
#16 0x00934c34 in gt_ggc_m_P11cgraph_node4htab (x_p=0x401fae80)
at gtype-desc.c:2147
#17 0x00827b88 in ggc_mark_roots () at ../../gcc/gcc/ggc-common.c:107
#18 0x002c7660 in ggc_collect () at ../../gcc/gcc/ggc-page.c:1941
#19 0x00b813ac in execute_todo (flags=2055) at ../../gcc/gcc/passes.c:1059
#20 0x00b81e74 in execute_one_pass (pass=0x2a6b690)
at ../../gcc/gcc/passes.c:1314
#21 0x00b81fdc in execute_pass_list (pass=0x2a6b690)
at ../../gcc/gcc/passes.c:1340
#22 0x00b82008 in execute_pass_list (pass=0x29b2db0)
at ../../gcc/gcc/passes.c:1341
#23 0x01212bc0 in tree_rest_of_compilation (fndecl=0x403be000)
at ../../gcc/gcc/tree-optimize.c:394
#24 0x01cdb6d0 in cgraph_expand_function (node=0x405ad400)
at ../../gcc/gcc/cgraphunit.c:1051
#25 0x01cdb920 in cgraph_expand_all_functions ()
at ../../gcc/gcc/cgraphunit.c:1110
#26 0x01cdc040 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1324
#27 0x000d896c in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8306
This is with
-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
Target: arm-none-linux-gnueabi
Configured with: ../gcc/configure --host=arm-none-linux-gnueabi
--target=arm-none-linux-gnueabi --build=arm-none-linux-gnueabi
--enable-languages=c,c++,fortran --enable-shared --enable-threads
--disable-multilib --disable-libmudflap --disable-libssp --enable-symvers=gnu
--enable-__cxa_atexit --disable-libstdcxx-pch
--prefix=/home/dave/opt/gnu/gcc/gcc-4.5.0 --with-gmp=/home/dave/opt/gnu
Thread model: posix
gcc version 4.5.0 20090429 (experimental) [trunk revision 146971] (GCC)
--
Summary: [4.5 Regression] SEGV compiling libiberty/regex.c in
stage2
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: arm-none-linux-gnueabi
GCC host triplet: arm-none-linux-gnueabi
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug bootstrap/39977] r1467817 broke bootstrap on PA
--- Comment #1 from danglin at gcc dot gnu dot org 2009-04-30 17:27 --- See the same error on hppa-unknown-linux-gnu: libtool: compile: /home/dave/gnu/gcc/objdir/./gcc/gfortran -B/home/dave/gnu/gcc /objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/ -B/home/dave/o pt/gnu/gcc/gcc-4.5.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.5.0/h ppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-inclu de -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I. -iquote../../../gcc/libgfo rtran/io -I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/con fig -I../.././gcc -D_GNU_SOURCE -I . -Wall -Werror -fimplicit-none -fno-repack-a rrays -fno-underscoring -fallow-leading-underscore -g -O2 -c ../../../gcc/libgfo rtran/generated/_abs_c8.F90 -fPIC -o .libs/_abs_c8.o ../../../gcc/libgfortran/generated/_abs_c8.F90: In function '_gfortran_specific_ _abs_c8': ../../../gcc/libgfortran/generated/_abs_c8.F90:42: internal compiler error: in e xpand_expr_addr_expr_1, at expr.c:6825 -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|hppa2.0w-hp-hpux11.11 |hppa*-*-* (32-bit) GCC target triplet|hppa2.0w-hp-hpux11.11 |hppa*-*-* (32-bit) Last reconfirmed|-00-00 00:00:00 |2009-04-30 17:27:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug other/39979] New: possible wrong code at -O0.
hi, i'm currently testing gcc-4.4.1-20090427 on my large c++ codebase. the application uses threads, contains over 100+ shared components and the tested debug build (-O0 -g2 -fpic) needs over 2GB of disk space, so creating reduced testcase at this point isn't trivial thing. i've observed that boost-1.38.0 and/or stlport-5.2.1 used in this project are broken by gcc-4.4.1 and trig abort() in glibc malloc checker. application linked with boost/stlport compiled with gcc-4.3 works fine. after few hours of valgrinding i've noticed following errors with gcc-4.4.1/boost/stlport which don't happen with gcc-4.3. % grep Invalid -A5 valgrind.log.24977 ==24977== Invalid write of size 8 ==24977==at 0x327AA0F6D2: _dl_allocate_tls_init (in /lib64/ld-2.5.so) ==24977==by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.5.so) ==24977==by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195) ==24977==by 0x54D2983: _ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperIN2au9Function0IvEEOT_ (thread.hpp:155) ==24977==by 0x54D2769: ts::MakeThread(au::Function0void const) (tsMain.cpp:333) -- ==24977== Invalid write of size 1 ==24977==at 0x327AA0F6E5: _dl_allocate_tls_init (in /lib64/ld-2.5.so) ==24977==by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.5.so) ==24977==by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195) ==24977==by 0x54D2983: _ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperIN2au9Function0IvEEOT_ (thread.hpp:155) ==24977==by 0x54D2769: ts::MakeThread(au::Function0void const) (tsMain.cpp:333) -- ==24977== Invalid write of size 8 ==24977==at 0x327AA0F6D2: _dl_allocate_tls_init (in /lib64/ld-2.5.so) ==24977==by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.5.so) ==24977==by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195) ==24977==by 0x54D2A33: _ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperINS_8functionIFvvEEEOT_ (thread.hpp:155) ==24977==by 0x54D27F4: _ZN2ts10MakeThreadERKN5boost8functionIFvvEEE (tsMain.cpp:339) -- ==24977== Invalid write of size 1 ==24977==at 0x327AA0F6E5: _dl_allocate_tls_init (in /lib64/ld-2.5.so) ==24977==by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.5.so) ==24977==by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195) ==24977==by 0x54D2A33: _ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperINS_8functionIFvvEEEOT_ (thread.hpp:155) ==24977==by 0x54D27F4: _ZN2ts10MakeThreadERKN5boost8functionIFvvEEE (tsMain.cpp:339) -- ==24977== Invalid read of size 8 ==24977==at 0x20F9E46E: void au::Delete::operator()es::Port(es::Port const*) const (auOpDelete.hpp:13) ==24977==by 0x20F9DBAF: au::Delete stlpd_std::for_eachstlpd_std::priv::_DBG_iterstlpd_std::priv::_NonDbg_vectores::Port*, stlpd_std::allocatores::Port* , stlpd_std::priv::_DbgTraitsstlpd_std::priv::_Vector_nonconst_traitses::Port*, es::Port** , au::Delete(stlpd_std::priv::_DBG_iterstlpd_std::priv::_NonDbg_vectores::Port*, stlpd_std::allocatores::Port* , stlpd_std::priv::_DbgTraitsstlpd_std::priv::_Vector_nonconst_traitses::Port*, es::Port** , stlpd_std::priv::_DBG_iterstlpd_std::priv::_NonDbg_vectores::Port*, stlpd_std::allocatores::Port* , stlpd_std::priv::_DbgTraitsstlpd_std::priv::_Vector_nonconst_traitses::Port*, es::Port** , au::Delete) (_algo.h:61) ==24977==by 0x20F99CB4: es::Instance::~Instance() (esInstance.cpp:104) ==24977==by 0x20F7EAF5: es::EdifInstance::~EdifInstance() (esEdifInstance.cpp:27) ==24977==by 0x20F7D61C: es::EdifBlackInstance::~EdifBlackInstance() (esEdifBlackInstance.cpp:21) -- ==24977== Invalid read of size 8 ==24977==at 0x327AA0F575:
[Bug testsuite/39776] FAIL: g++.dg/ext/altivec-15.C
--- Comment #4 from janis at gcc dot gnu dot org 2009-04-30 17:48 --- Subject: Bug 39776 Author: janis Date: Thu Apr 30 17:48:03 2009 New Revision: 147010 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147010 Log: PR testsuite/39776 * g++.dg/ext/altivec-15.C: Remove dg-error for messages that are no longer issued. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/altivec-15.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39776
[Bug testsuite/39776] FAIL: g++.dg/ext/altivec-15.C
--- Comment #5 from janis at gcc dot gnu dot org 2009-04-30 17:53 --- Subject: Bug 39776 Author: janis Date: Thu Apr 30 17:53:23 2009 New Revision: 147011 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147011 Log: PR testsuite/39776 * g++.dg/ext/altivec-15.C: Remove dg-error for messages that are no longer issued. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/altivec-15.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39776
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-30 17:55 --- Interesting. I Knew about a PIC failure on arm but I the backtrace was different, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12 . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|tree-optimization |middle-end Keywords||build, GC, ice-on-valid-code Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug bootstrap/39977] [4.5 Regression] r1467817 broke bootstrap on PA
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-30 17:59 --- Seems related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209 which seems like it was worked around in 4.3 and 4.4 but exposed again with the SSA expand patch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, ice-on-valid-code Summary|r1467817 broke bootstrap on |[4.5 Regression] r1467817 |PA |broke bootstrap on PA Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug c++/39980] New: C++ ICE in tsubst
I will attach the preprocessed source code. I think the code is valid but I am not sure of that after using delta to cut it down as far as I could. x.cc:40: internal compiler error: tree check: accessed elt 3 of tree_vec with 2 elts in tsubst, at cp/pt.c:9249 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: C++ ICE in tsubst Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39980
[Bug c++/39980] C++ ICE in tsubst
--- Comment #1 from sje at cup dot hp dot com 2009-04-30 18:41 --- Created an attachment (id=17784) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17784action=view) Preprocessed test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39980
[Bug middle-end/39964] compilation with -fprofile-generate causes code to segfault.
--- Comment #3 from jv244 at cam dot ac dot uk 2009-04-30 18:48 --- a bug in the code that is triggered by the option. closing as invalid. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39964
[Bug c++/39981] New: zero-size base class optimization fails in certain scenarios
Scenario1A: When class X inherits from A, B, and C; and A and C are empty classes, then gcc properly creates X such that: sizeof(X) == sizeof(B) Scenario1B: When class X inherits from A and B; and A is an empty class, then gcc properly creates X such that: sizeof(X) == sizeof(B) Scenario2A: When class X inherits from A, B, and C; and A and C are empty classes inheriting from another empty class, then gcc IMPROPERLY creates X such that: sizeof(X) sizeof(B) Scenario2B: When class X is a composite of A and B; and A is an empty class inheriting from another empty class, then gcc properly creates X such that: sizeof(X) == sizeof(B) -- Summary: zero-size base class optimization fails in certain scenarios Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: navinkumar+bugs at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #1 from navinkumar+bugs at gmail dot com 2009-04-30 18:54 --- Created an attachment (id=17785) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17785action=view) demonstrates scenarios when zero-size base class optimization fails compile with flag: -std=c++0x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #2 from navinkumar+bugs at gmail dot com 2009-04-30 18:57 --- Tested with 2 versions of GCC, same behavior; Version #1 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /1123/scratch/gcc4.4.0/src/configure --prefix=/1123/software/gcc4.4.0 --with-local-prefix=/1123/software/local --enable-languages=c,c++ --enable-checking=release --enable-tls --enable-threads --disable-multilib Thread model: posix gcc version 4.4.0 (GCC) Version #2 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix --mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.3.3 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-30 19:01 --- I think GCC is doing the correct thing here as there is no padding to put _2_emptyB in. And this is not a zero-size base class optimization but rather padding filling class optimization. Have you read the IA64 C++ ABI (or the ARM EABI C++ ABI) to see what it has to say about this case? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #4 from navinkumar+bugs at gmail dot com 2009-04-30 19:22 --- Since std::is_empty_2_emptyB::value std::is_empty_2_emptyA::value (as verified by the static assertions), GCC should not treat _2_emptyB differently from _2_emptyA when computing the structure's layout. The IA64 C++ ABI only talks about pod, data, and empty structures, so the ABI specification does not distinguish between _2_emptyB and _2_emptyA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39982] New: Fail to use constructor to initialize volatile declaration (no matching function for call)
This problem originates in peren_c++. The test (Sec13/3_1_3/P13290.C)
exercising the following clause: ISO/IEC 14882:1998, 13.3.1.3.
(When a user-defined conversion is invoked to convert an
assignment-expression to a type cv T, where T is a class type,
a constructor of T is considered a candidate function by
overload resolution.)
Simplified test case is:
#include stdio.h
int counter = 0;
struct S {
int m;
S(int i=0) : m(i) { counter++; }
};
main(){
counter = 0;
S s00 = 1;
fprintf(stderr,counter = (%d)\n,counter);
counter = 0;
volatile S s02 = 1;
fprintf(stderr,volatile counter = (%d)\n,counter);
}
to compile: g++ P13290_short.C
The error massage is:
P13290_short.C: In function ?int main()?:
P13290_short.C:23: error: no matching function for call to ?S::S(volatile S)?
P13290_short.C:9: note: candidates are: S::S(int)
P13290_short.C:6: note: S::S(const S)
It will also fail for const volatile S s02 = 1;
It is passing with 3.4.6 but fails on 4.3.2 and 4.4.0. The 4.4.0 platform is
plain vanilla x86 (x86_64-unknown-linux-gnu). I got it just to verify the issue
so you can refer to a supported platform. Thanks.
--
Summary: Fail to use constructor to initialize volatile
declaration (no matching function for call)
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergei_lus at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39982
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #1 from luisgpm at linux dot vnet dot ibm dot com 2009-04-30 19:29 --- ASM code for the bad loop .L145: fmul 10,8,13 fmul 5,8,0 addis 3,4,0xffe5 lfd 22,8(7) addi 7,4,8 lfd 6,9472(3) fmadd 10,9,0,10 fmsub 23,9,13,5 fmul 2,10,22 fmul 9,10,6 fmr 7,23 fmsub 25,23,6,2 fmadd 26,23,22,9 fadd 12,12,25 fadd 11,11,26 .L93: fmul 8,10,13 fmul 22,10,0 addis 3,7,0xffe5 lfd 21,0(7) addi 4,7,8 lfd 25,9472(3) fmadd 8,7,0,8 fmsub 9,7,13,22 fmul 23,8,21 fmul 26,8,25 fmsub 24,9,25,23 fmadd 7,9,21,26 fadd 12,12,24 fadd 11,11,7 bdnz .L145 stfd 9,472(1) mr 7,8 lwz 3,472(1) lwz 4,476(1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug c++/39967] Ignored static qualifier on a local variable
--- Comment #5 from sergei_lus at yahoo dot com 2009-04-30 19:32 --- Please close this issue. I think the real problem is in libc, not in the compiler. (test passes with -fno-threadsafe-statics). Thank you for support. -- sergei_lus at yahoo dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39967
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #2 from luisgpm at linux dot vnet dot ibm dot com 2009-04-30 19:38 --- Created an attachment (id=17786) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17786action=view) Last tree pass for the bad code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #1 from danglin at gcc dot gnu dot org 2009-04-30 19:47 --- Still present in 4.4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-30 19:51 --- bb 45: # crkveuk_lsm.686_3635 = PHI crkveuk_lsm.686_517(44) # cikve_lsm.685_3640 = PHI cikve_lsm.685_528(44) # crkveuk_lsm.686_3564 = PHI crkveuk_lsm.686_517(44) Interesting, I wonder if that causes expand SSA to go crazy or do we go into closed loop form on purpose now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-30 20:17 --- I am not sure if it is related. Revision 146817 miscompiled 465.tonto in SPEC CPU 2006 on Linux/ia32 with -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops -m32 The resulting tonto binary generated the wrong result and ran VERY VERY slow. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug target/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-04-30 20:57 --- (In reply to comment #6) (In reply to comment #4) Your libpthreads is doing something wrong. Re. comment 5 The command was actually gcc -fopemnp test.c -lgomp -o test.exe That command works for me with gcc 4.3.4, 4.4.0 and trunk In 4.4.0 and trunk, test.exe links against LIBGOMP-1.DLL which in turn resolves the pthread imports from PTHREADGCE2.DLL, which is distributed by the pthreads-win32 project http://sources.redhat.com/pthreads-win32/ My version of 4.3.4 has local mods. I'm not sure if the shared libgomp build was standard then. How did you build gcc-4.3.0? You need to add --enable-libgomp to configure and ensure that libpthread.a (note spelling) can be found. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug middle-end/39983] New: ICE: type mismatch in address expression
gcc-trunk rev.147009 with command-line
gcc -O -c tst7.c
fail to compile
typedef struct {
int *p;
} *A;
extern const int a[1];
extern const int b[1];
void foo()
{
A x;
A y;
static const int * const c[] = { b };
x-p = (int*)c[0];
y-p = (int*)a;
}
with message:
tst7.c: In function foo:
tst7.c:16: error: type mismatch in address expression
int *
const int[1] *
# .MEM_5 = VDEF .MEM_4(D)
x_2(D)-p = b;
tst7.c:16: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[r...@localhost gcc_err]# gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc_current/configure --prefix=/usr/local/gcc_current
--enable-bootstrap --enable-shared --enable-checking=yes --with-system-zlib
--enable-__cxa_atexit --enable-languages=c,c++
--enable-version-specific-runtime-libs : (reconfigured)
../gcc_current/configure --prefix=/usr/local/gcc_current --enable-bootstrap
--enable-shared --enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++ --enable-version-specific-runtime-libs :
(reconfigured) ../gcc_current/configure --prefix=/usr/local/gcc_current
--enable-bootstrap --enable-shared --enable-checking=yes --with-system-zlib
--enable-__cxa_atexit --enable-version-specific-runtime-libs
--enable-languages=c,c++ --no-create --no-recursion : (reconfigured)
../gcc_current/configure --prefix=/usr/local/gcc_current --enable-bootstrap
--enable-shared --enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-bootstrap --enable-shared
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-bootstrap --enable-shared
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-bootstrap --enable-shared
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-bootstrap --enable-shared
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-bootstrap --enable-shared
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-bootstrap --enable-shared
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ --no-create
--no-recursion
Thread model: posix
gcc version 4.5.0 20090430 (experimental) [trunk revision 147009] (GCC)
--
Summary: ICE: type mismatch in address expression
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dimhen at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39983
[Bug target/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #10 from dannysmith at users dot sourceforge dot net
2009-04-30 21:07 ---
(In reply to comment #9)
(In reply to comment #6)
(In reply to comment #4)
Your libpthreads is doing something wrong.
Re. comment 5
The command was actually
gcc -fopemnp test.c -lgomp -o test.exe
That command works for me with gcc 4.3.4, 4.4.0 and trunk
In 4.4.0 and trunk, test.exe links against LIBGOMP-1.DLL which in turn
resolves
the pthread imports from PTHREADGCE2.DLL, which is distributed by the
pthreads-win32 project
http://sources.redhat.com/pthreads-win32/
My version of 4.3.4 has local mods. I'm not sure if the shared libgomp build
was standard then.
No it wasn't. And so the problem is that libgomp.spec says:
# This spec file is read by gcc when linking. It is used to specify the
# standard libraries we need in order to link with -fopenmp.
*link_gomp: -lgomp %{static: -lpthread }
You have not specified '-static', so you must provide the '-lpthread' (again
note spelling) yourself.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9
--- Comment #8 from dominiq at lps dot ens dot fr 2009-04-30 21:07 --- I successfully bootstrapped libjava on powerpc-apple-darwin9 at revision 146999. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Component|target |libgomp Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9
--- Comment #9 from bonzini at gnu dot org 2009-04-30 21:10 --- Subject: Re: [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9 I successfully bootstrapped libjava on powerpc-apple-darwin9 at revision 146999. Interesting, can you try the command-line I posted on both ppc and i386, plus -fdump-tree-all-details, and see what the differences are in the tree dumps? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
[Bug tree-optimization/39984] New: ggc-pr37574.c gets ICE in tree_node_structure
Test gcc.dg/vect/ggc-pr37574.c started failing on powerpc64-linux with -m32 or -m64 with this patch: http://gcc.gnu.org/viewcvs?view=revrev=146888 r146888 | rguenth | 2009-04-28 12:16:22 + (Tue, 28 Apr 2009) with the following options to cc1, which are used in the testsuite: -D__linux__ -Dunix -D__unix -Dlinux -D__linux -O2 -maltivec -ftree-vectorize --param ggc-min-expand=0 --param ggc-min-heapsize=0 -- Summary: ggc-pr37574.c gets ICE in tree_node_structure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39984
[Bug middle-end/39579] [4.5 regression] revisions 145171/145172 caused 2 extra failures
--- Comment #4 from sje at gcc dot gnu dot org 2009-04-30 21:43 --- Subject: Bug 39579 Author: sje Date: Thu Apr 30 21:43:21 2009 New Revision: 147018 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147018 Log: PR middle-end/39579 * gcc.dg/vect/vect-35.c: XFAIL for IA64 and Sparc. * gfortran.dg/vect/fast-math-pr38968.f90: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-35.c trunk/gcc/testsuite/gfortran.dg/vect/fast-math-pr38968.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39579
[Bug tree-optimization/39955] [4.5 Regression] struct-layout-1 test failures passing struct containing _Decimal32
--- Comment #13 from meissner at gcc dot gnu dot org 2009-04-30 22:00 --- Subject: Bug 39955 Author: meissner Date: Thu Apr 30 21:59:49 2009 New Revision: 147021 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147021 Log: fix for PR 39955 Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39955
[Bug c/39985] New: Type qualifiers not actually ignored on function return type
The warning printed with -Wignored-qualifiers (warning: type qualifiers
ignored on function return type) seems to be lying. The const on a functions
return type is not actually ignored, as can be demonstrated using typeof(). I
think that the warning should be right and the typeof() behavior is wrong, but
Im not actually sure.
int f(void);
const int g(void); /* warning: type qualifiers ignored on function return type
*/
typeof(f()) a;
a = 5;
typeof(g()) b;
b = 5; /* error: assignment of read-only variable b */
Another thing that seems similarly strange is that a statement expression can
return a const type, even though it is not an lvalue:
const int x = 5;
typeof( ({ x; }) ) y;
y = 5; /* error: assignment of read-only variable y */
--
Summary: Type qualifiers not actually ignored on function return
type
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anders at kaseorg dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
[Bug fortran/39971] kinds.h fails at building libgfortran
--- Comment #4 from gustcr at yahoo dot com dot ar 2009-05-01 00:10 --- (In reply to comment #3) I couldn't find any other gmp or mpfr in the system. Also tried using the system's ld and as (both version 2.11.2) but the same error pops up (see below). Using ps ax I checked that the right versions of ld and as are used while compiling. Any other idea on what to try? Bootstraping only c works ok --- In file included from /home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:246, from /home2/gdb/local/src/gcc-4.4.0/libgfortran/fmain.c:1: ./kinds.h:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'float' ./kinds.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'double' ./kinds.h:46: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'long' In file included from /home2/gdb/local/src/gcc-4.4.0/libgfortran/fmain.c:1: /home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:332: error: expected specifier-qualifier-list before 'GFC_COMPLEX_4' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39971
[Bug fortran/39988] New: F2008: Default initialization, structure constructors, and allocatable components
Consider the following test case: program defallocatable implicit none ! Demonstrate structure constructors with default initialization ! and allocatable arrays. (Unspecified in F2003, initialized to ! unallocated in F2008.) type mytype_t integer, allocatable :: data(:) end type type(mytype_t) :: my_object my_object = mytype_t () print *, 'allocated =', allocated (my_object%data) end program When compiling with gfortran, we get: $ gfortran defallocatable.f90 defallocatable.f90:14.25: my_object = mytype_t () 1 Error: No initializer for component 'data' given in the structure constructor at (1)! $ This may be a valid error in F2003. In F2003 section 4.5.9 paragraph 3, it states that If a component with default initialization has no corresponding component-data-source, then the default initialization is applied to that component. But when a component is allocatable, it is not legal to specify a component-data-source. This creates a difference in how default initialization works with structure constructors, and other places where default initialization must take place. In F2008 the above paragraph, this time in section 4.5.10 paragraph 3, adds: If an allocatable component has no corresponding component-data-source, then that component has an allocation status of unallocated. This closes the hole and makes default initialization of allocatable components in structure constructors work like it does everywhere else. So this enhancement request is to consider gfortran allow the code to compile under the F2008 semantics (which are seemingly undefined in F2003.) FWIW, g95 and ifort have the same problem. -- Summary: F2008: Default initialization, structure constructors, and allocatable components Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39988
