[Bug c++/41776] Segmentation fault printf(NULL\n)
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-21 07:12 --- The testcase is invalid, you can't pass NULL to %s. The fact that glibc printf doesn't crash on it is just an extension. In your case gcc optimizes the printf into puts and that one crashes even with glibc. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41776
[Bug c++/41774] ice: vector VEC(visibility,base) pop domain error, in pop_visibility at c-pragma.c:757
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-21 08:01 --- Created an attachment (id=18849) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18849&action=view) gcc45-pr41775.patch Fix I'm going to bootstrap/regtest. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41774
[Bug fortran/41777] New: wrong-code shown with EXCITING
Non-reduced test case.
This is with http://static.exciting-code.org/exciting.hydrogen.9.10.tar.gz
Untar, cp build/platform/make.inc.g95 build/platform/make.inc.gfortran and
adapt that file; run 'make'.
Note: Due to PR 41772, one needs to use the PGI loop in
src/FoX/fsys/fox_m_fsys_array_str.F90's "str_vs"
rather than TRANSFER.
cd examples/Al; ../../build/serial/exciting
Expected: Runs through successfully (as with g95, xlf90, ifort),
Actual result: Fails when FoX tries to remove a node ("NOT_FOUND_ERR").
As in PR 41772, I will try to get a small testcase. This time, valgrind is
silent which does not help :-(
--
Summary: wrong-code shown with EXCITING
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
BugsThisDependsOn: 41772
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41777
[Bug tree-optimization/41778] New: missed dead store elimination
Compile the attached source code with options -Os -march=armv5te -mthumb, gcc
generates:
push{lr}
ldr r3, [r1, #4] // redundant
ldrbr3, [r3] // redundant
@ sp needed for prologue
pop {pc}
There are two redundant instructions.
Compile it with options -O2 -march=armv5te -mthumb, gcc generates following
expected results.
foo:
@ sp needed for prologue
bx lr
The optimization done in -O2 is from this patch
http://gcc.gnu.org/viewcvs?view=revision&revision=145172. But this piece of
code was in pre pass, it is disabled when -Os is specified, so the unoptimized
code was passed to rtl passes. In rtl passes, the dead store is caught and
removed with some related code, but not all of them were removed, so we can
still see the two redundant instruction.
We should also add this optimization to dead store elimination pass to benefit
-Os cases.
--
Summary: missed dead store elimination
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41778
[Bug tree-optimization/41778] missed dead store elimination
--- Comment #1 from carrot at google dot com 2009-10-21 08:50 --- Created an attachment (id=18850) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18850&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41778
[Bug fortran/41706] [OOP] Calling one TBP as an actual argument of another TBP
--- Comment #6 from janus at gcc dot gnu dot org 2009-10-21 08:57 --- Subject: Bug 41706 Author: janus Date: Wed Oct 21 08:56:56 2009 New Revision: 153049 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153049 Log: 2009-10-21 Janus Weil PR fortran/41706 PR fortran/41766 * match.c (select_type_set_tmp): Set flavor for temporary. * resolve.c (resolve_class_typebound_call): Correctly resolve actual arguments. 2009-10-21 Janus Weil PR fortran/41706 PR fortran/41766 * gfortran.dg/class_9.f03: Extended test case. * gfortran.dg/select_type_7.f03: New test case. Added: trunk/gcc/testsuite/gfortran.dg/select_type_7.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_9.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706
[Bug fortran/41766] [OOP] SELECT TYPE selector as actual argument with INTENT(INOUT)
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-21 08:57 --- Subject: Bug 41766 Author: janus Date: Wed Oct 21 08:56:56 2009 New Revision: 153049 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153049 Log: 2009-10-21 Janus Weil PR fortran/41706 PR fortran/41766 * match.c (select_type_set_tmp): Set flavor for temporary. * resolve.c (resolve_class_typebound_call): Correctly resolve actual arguments. 2009-10-21 Janus Weil PR fortran/41706 PR fortran/41766 * gfortran.dg/class_9.f03: Extended test case. * gfortran.dg/select_type_7.f03: New test case. Added: trunk/gcc/testsuite/gfortran.dg/select_type_7.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_9.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41766
[Bug fortran/41706] [OOP] Calling one TBP as an actual argument of another TBP
--- Comment #7 from janus at gcc dot gnu dot org 2009-10-21 09:01 --- Fixed with r153049. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706
[Bug fortran/41766] [OOP] SELECT TYPE selector as actual argument with INTENT(INOUT)
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-21 09:02 --- Fixed with r153049. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41766
[Bug fortran/41777] wrong-code shown with EXCITING
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-21 09:10 ---
Created an attachment (id=18851)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18851&action=view)
Slightly reduced test case - needs now only FoX
Reduced test case -- still pretty large, but now only depends on FoX. Use
similarly to PR 41772:
wget http://www.uszla.me.uk/FoX/source/FoX-4.0.4.tar.gz
tar xfz FoX-4.0.4.tar.gz
cd FoX-4.0.4 && ./configure FC=gfortran && make -j4
gfortran -Iobjs/finclude fox.f90 objs/lib/libFoX_{dom,utils,sax,common,fsys}.a
./a.out
In order to see better what goes wrong, patch dom/m_dom_dom.F90's removeChild
by adding the PRINT statements:
do i = 1, size(arg%childNodes%nodes)
print *, 'removeChild: Walking list, i = ', i
if (associated(arg%childNodes%nodes(i)%this, oldChild)) then
print *, 'removeChild: Walking list, fount it, i_t = ', i_t
The gfortran output is then:
removeChild: Walking list, i =1
[...]
removeChild: Walking list, i =9
NOT_FOUND_ERR
While g95/NAG f95 have:
removeChild: Walking list, i = 1
[...]
removeChild: Walking list, fount it, i_t = 4
[...]
removeChild: Walking list, i = 9
FoX_NODE_IS_NULL
(Afterwards, all core dump. The result that it = 4 is found, can also be seen
with the full program, where no segfault occurs.)
The needed input.xml can be found in attachment 18846 of PR 41772
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41777
[Bug fortran/41777] wrong-code shown with EXCITING
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-21 09:12 --- (In reply to comment #1) > wget http://www.uszla.me.uk/FoX/source/FoX-4.0.4.tar.gz > cd FoX-4.0.4 && ./configure FC=gfortran && make -j4 I forgot to re-mention that one needs to patch fsys/fox_m_fsys_array_str.F90's "str_vs" -> comment 0 (or PR 41772 needs to be fixed). Otherwise, it crashes before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41777
[Bug c++/41779] New: Spurious integral promotion
The following code produces a warning about precision loss in an int-to-float
conversion:
$cat warn.cpp
float f(float x, unsigned short y)
{
return x * y;
}
$g++ -Wconversion -c -o warn.o warn.cpp
warn.cpp: In function float f(float, short unsigned int):
warn.cpp:3: warning: conversion to float from int may alter its value
$
The code snippet does not have an int-to-float conversion.
It does have an unsigned short-to-float conversion according to the C++
standard, chapter 5 [expr] para 9: "[inapplicable note on long double and
double...] Otherwise, if either operand is float, the other shall be converted
to float [...]". Only after this rule, integral promotions are performed, which
could promote the unsigned short to an int.
Moreover, he conversion does not lose information since the 16 bits of the
unsigned short fit amply in the float's mantissa.
Not tested with other shorter-than-int types. This problem might apply there as
well...
--
Summary: Spurious integral promotion
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zweije at xs4all dot nl
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41779
[Bug fortran/41777] wrong-code with FoX, related to ASSOCIATE( Ptr1, Ptr2)
--- Comment #3 from burnus at gcc dot gnu dot org 2009-10-21 09:22 --- No regression, segfaults immediately with 4.2; shows the same behaviour for 4.3, 4.4 and 4.5. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.1 4.3.3 4.4.2 4.5.0 Summary|wrong-code shown with |wrong-code with FoX, related |EXCITING|to ASSOCIATE( Ptr1, Ptr2) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41777
[Bug target/41780] New: File "gcc/config/arm/lib1funcs.asm" broken for THUMB version 1 since r150545
I suppose the file "gcc/config/arm/lib1funcs.asm" does not work when compiled for THUMB version 1 with an architecture other than __ARM_ARCH_6M__ since r150545. I got a link error: /opt/rtems-4.10-gcc/bin/../lib/gcc/arm-rtems4.10/4.5.0/../../../../arm-rtems4.10/bin/ld: /opt/rtems-4.10-gcc/bin/../lib/gcc/arm-rtems4.10/4.5.0/thumb/soft/libgcc.a(_dvmd_tls.o)(__div0): warning: interworking not enabled. first occurrence: /opt/rtems-4.10-gcc/bin/../lib/gcc/arm-rtems4.10/4.5.0/thumb/soft/libgcc.a(_udivsi3.o): arm call to thumb -- Summary: File "gcc/config/arm/lib1funcs.asm" broken for THUMB version 1 since r150545 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sebastian dot huber at embedded-brains dot de GCC target triplet: arm-rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
[Bug target/41780] File "gcc/config/arm/lib1funcs.asm" broken for THUMB version 1 since r150545
--- Comment #1 from sebastian dot huber at embedded-brains dot de 2009-10-21 09:30 --- Created an attachment (id=18852) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18852&action=view) Fix proposal This works at least for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
[Bug fortran/41781] New: [OOP] bogus undefined label error with SELECT TYPE.
With trunk at revision 153049 I get the following Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 20091021 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' /usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 gotobug.f03 -quiet -dumpbase gotobug.f03 -mtune=generic -auxbase gotobug -version -fintrinsic-modules-path /usr/local/gnu45/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/ccidWMNg.s GNU Fortran (GCC) version 4.5.0 20091021 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20091021 (experimental), GMP version 4.2.4, MPFR version 2.4.1 warning: MPFR header version 2.4.1 differs from library version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.5.0 20091021 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20091021 (experimental), GMP version 4.2.4, MPFR version 2.4.1 warning: MPFR header version 2.4.1 differs from library version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 gotobug.f03:17.15: goto 1 Error: Label referenced at (1) is never defined on the attached code, which is obiviously a bogus claim. If I change the source code as follows: - select type() .. class default info = -1 end select if (info /= 0) goto -- then it works, so it's definitely an interaction with SELECT TYPE. -- Summary: [OOP] bogus undefined label error with SELECT TYPE. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41781
[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.
--- Comment #1 from sfilippone at uniroma2 dot it 2009-10-21 09:34 --- Created an attachment (id=18853) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18853&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41781
[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application
--- Comment #6 from maurice35 dot david at laposte dot net 2009-10-21 09:36 --- Created an attachment (id=18854) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18854&action=view) Screen shoot form lauterbach -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application
--- Comment #7 from maurice35 dot david at laposte dot net 2009-10-21
09:37 ---
It seems that I have a similar issue with ccmips compilator :
typedef struct
{
char A;
char B;
char C;
/*char padding;*/
} tStructABC;
typedef struct
{
tStructABC ABC1;
tStructABC ABC2;
} tStruct2ABC;
tStruct2ABC Struct2ABC;
int Compute(tStructABC ArgA,tStructABC ArgB)
{
return(ArgA.A+ArgA.B);
}
int main(int argc, char *argv[])
{
tStructABC * pABC1;
tStructABC * pABC2;
pABC1 = &(Struct2ABC.ABC1);
pABC2 = &(Struct2ABC.ABC2);
printf("Compute=%d\n",Compute(*pABC1,*pABC2));
}
This code crash with the printout:
Address load Exception
Exception Program Counter: 0x803f56f8
Status Register: 0x3000ff01
Cause Register: 0x0010
Access Address : 0x80b8da83
Task: 0x80ffa440 "PGL_Main"
0x80ffa440 (PGL_Main): task 0x80ffa440 has had a failure and has been stopped.
0x80ffa440 (PGL_Main): fatal kernel task-level exception!
So The crash is due to an alignment issue on the address &(Struct2ABC.ABC2);.
To avoid this issue we need to add a padding byte in tStructABC because it
seems that there is no way to force a padding through a compilation option or
through a #pragma (as example #pragma pack(4)).
Please could you confirm this issue in compilation sw (ccmips) or not.
see: Created an attachment (id=18854)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18854&action=view) [edit]
Screen shoot form lauterbach
Best regard,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-21 09:38 --- Similar / same problem: block goto 99 end block 99 continue end -- burnus at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41781
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #23 from mikpe at it dot uu dot se 2009-10-21 10:48 --- (In reply to comment #8) > (In reply to comment #7) > > With binutils from the 2.20 branch, and gcc from the 4.4 branch, including > > Jakub's patch, and excluding the current workaround from Ramana, I get: > > > > IIUC and to make things explicit, the work-around is needed for any binutils > prior to the 2.20 branch until the backport is done. If the backport is > committed we should pull out my work around as well. The backport has been committed now, so your PR41533 workaround should not be needed any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above
--- Comment #11 from mikpe at it dot uu dot se 2009-10-21 10:51 --- *** Bug 40547 has been marked as a duplicate of this bug. *** -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
[Bug middle-end/40547] comparison in lhs of ?: incorrectly converted to unsigned min
--- Comment #3 from mikpe at it dot uu dot se 2009-10-21 10:51 --- *** This bug has been marked as a duplicate of 40747 *** -- mikpe at it dot uu dot se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40547
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-10-21 10:54 --- Subject: Re: Bootstrap with Sun Studio 12.1 fails > --- Comment #2 from ghazi at gcc dot gnu dot org 2009-10-21 01:48 --- > I would prefer a solution that does not involve linking xgcc and cpp with > libgmp since that links in unecessary code and/or yields a runtime penalty for > loading the shared library. Indeed, even if I've been building gmp and mpfr with --disable-shared to avoid RPATH problems. One option might be to avoid including gmp.h in gcc.c in the first place, as I've already mentioned. I'm not sure how easy that would be, though. > It's unusual that we've only just now received this report since gmp has been > used since gcc-4.3 (released 1.5 years ago). So I'm curious if something more > recently changed to trigger this issue. I.e. did it used to work, and some > newer version of either gmp, sun cc, or solaris exposed the problem? Or did > it > always fail? I've never tried this before (I regularly build with GCC 3.4 as a bootstrap compiler since I want to include Ada support and that requires an Ada compiler), but only just received a report from a colleague who tried to build GCC 4.4 within pkgsrc, but failed in unexpected ways. > (Also, you don't mention what version of gmp you were using.) Right, sorry: I've tried this with the latest version, gmp 4.3.1. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug lto/41782] New: lto/gold: -flto -user-linker-plugin dies with internal error in gold
When trying to compile and link the attached not.i with lto the linker dies with this error: /usr/bin/ld: internal error in set_linkonce_size, at ../../gold/layout.h:250 This only occurs if I use -use-linker-plugin, so I think this may be a bug in gcc's gold plugin, so I'm filing this as a gcc bug (but it may also be a bug in gold triggered by lto). To reproduce: $ /home/edwin/inst/bin/g++ -flto -c not.i -o not.o $ /home/edwin/inst/bin/g++ -shared -flto -use-linker-pluginnot.o /usr/bin/ld: internal error in set_linkonce_size, at ../../gold/layout.h:250 collect2: ld returned 1 exit status $ /home/edwin/inst/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/edwin/inst/bin/g++ COLLECT_LTO_WRAPPER=/home/edwin/inst/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold : (reconfigured) ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold Thread model: posix gcc version 4.5.0 20091020 (experimental) (GCC) $ ld -v GNU gold (GNU Binutils for Debian 2.20) 1.9 -- Summary: lto/gold: -flto -user-linker-plugin dies with internal error in gold Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41782
[Bug lto/41782] lto/gold: -flto -user-linker-plugin dies with internal error in gold
--- Comment #1 from edwintorok at gmail dot com 2009-10-21 11:22 --- Created an attachment (id=18855) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18855&action=view) testcase (reduced not.i) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41782
[Bug libgcj/41768] [regression] build failue in java component.
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-21 11:22 --- gjar is broken. *** This bug has been marked as a duplicate of 39177 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41768
[Bug bootstrap/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386
--- Comment #8 from doko at ubuntu dot com 2009-10-21 11:23 --- Created an attachment (id=18856) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18856&action=view) preprocessed source attached the preprocessed source (from an 20091018 build). the compiler used to build is a native compiler built from the same source, configured with: --enable-shared --enable-linker-build-id --with-system-zlib --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-plugin --enable-objc-gc --disable-softfloat --enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --with-long-double-128 --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu the cross compiler is configured with: -enable-languages=c,c++,fortran --prefix=/usr/lib/gcc-snapshot --libexecdir=/usr/lib/gcc-snapshot/libexec --disable-shared --disable-nls --disable-threads --enable-checking=release --disable-libssp --with-system-zlib --with-newlib --program-prefix=spu- --with-as=/usr/bin/spu-as --with-ar=/usr/bin/spu-ar --with-ld=/usr/bin/spu-ld --includedir=/usr/spu/include --libdir=/usr/spu/lib --host=powerpc-linux-gnu --build=powerpc-linux-gnu --target=spu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
[Bug bootstrap/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386
-- doko at ubuntu dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
[Bug tree-optimization/41778] missed dead store elimination
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-21 11:30 --- PRE should be turned into FRE at -Os. I have a patch for that somewhere, let me re-surrect it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-21 11:30:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41778
[Bug fortran/41777] Wrong-code with POINTER-returning GENERIC function
--- Comment #4 from burnus at gcc dot gnu dot org 2009-10-21 12:08 --- Reduced test case. The problem is the GENERIC INTERFACE. For some reason, the result attribute is not properly propagated. This leads to the bogus error: print *, associated(a,f(a)) ! Valid, but error 1 Error: 'target' argument of 'associated' intrinsic at (1) must be a POINTER or a TARGET and to the wrong code by printing "T F" instead of "T T". module m type t2 integer :: i end type t2 interface f module procedure f2 end interface f contains function f2(a) type(t2), pointer :: f2,a f2 => a end function f2 end module m use m implicit none type(t2), pointer :: a allocate(a) !print *, associated(a,f(a)) ! Valid, but error call cmpPtr(a,f2(a)) ! "T" which is OK call cmpPtr(a,f(a)) ! "F" which is wrong contains subroutine cmpPtr(a,b) type(t2), pointer :: a,b print *, associated(a,b) end subroutine cmpPtr end -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid Summary|wrong-code with FoX, related|Wrong-code with POINTER- |to ASSOCIATE( Ptr1, Ptr2) |returning GENERIC function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41777
[Bug lto/41767] assertion in tree-sra.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-21 12:18 ---
Confirmed. But the reduced testcase has
typedef struct VEC_constructor_elt_gc {
VEC_constructor_elt_base base;
} VEC_constructor_elt_gc;
vs.
typedef struct VEC_constructor_elt_gc {
} VEC_constructor_elt_gc;
which results in incompatible struct tree_constructor and thus union tree_node.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-10-21 12:18:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application
--- Comment #8 from mikpe at it dot uu dot se 2009-10-21 12:19 --- I can reproduce the misalignment exceptions on armv5tel-linux-gnueabi with gcc-4.3.4 at -O0 but not with gcc-4.4.2. The loop in main() which iterates over the packed array creates a misaligned pointer from which it performs word-sized loads, which causes misalignment exceptions. gcc-4.4.2 generates very different code which doesn't make assumptions about alignment. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
[Bug tree-optimization/41775] [4.5 Regression] IPA-SRA: ice in rewrite_stmt, at tree-into-ssa.c:1302
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-21 12:31 --- Confirmed. Looks like invalid tree-sharing. On (gdb) call debug_gimple_stmt (stmt) # .MEM = VDEF <.MEM> llvm::LiveInterval::removeRange (PI_10, D.2378_13->start, D.2378_13->end, 1); we have replaced the first use but on replacing the 2nd one the INDIRECT_REF was shared. Both built from #1 0x0888e476 in build_ref_for_offset_1 (res=0xb068, type=0xb7d72a8c, offset=0, exp_type=0xb7d728fc) at /home/richard/src/trunk/gcc/tree-sra.c:1255 1255 expr = build3 (COMPONENT_REF, TREE_TYPE (fld), *res, fld, without unsharing *res. Thus, this is IPA-SRA. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to work||4.4.2 Last reconfirmed|-00-00 00:00:00 |2009-10-21 12:31:40 date|| Summary|ice in rewrite_stmt, at |[4.5 Regression] IPA-SRA: |tree-into-ssa.c:1302|ice in rewrite_stmt, at ||tree-into-ssa.c:1302 Target Milestone|--- |4.5.0 Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41775
[Bug debug/41736] missing DW_TAG_template_*_ in some cases
--- Comment #2 from dodji at gcc dot gnu dot org 2009-10-21 13:10 --- Created an attachment (id=18857) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18857&action=view) Enhanced patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41736
[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-21 13:17 --- Created an attachment (id=18858) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18858&action=view) patch Mine. Preliminary patch attached. -- 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 | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41781
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-10-21 13:37 --- Subject: Re: Bootstrap with Sun Studio 12.1 fails Just for reference: here's the corresponding pkgsrc problem report by my colleague: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=42109 So at least bootstrapping with Studio 12 exhibits the same problem. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.
--- Comment #4 from burnus at gcc dot gnu dot org 2009-10-21 14:07 --- While for goto 99 if(.true.) then 99 continue end if end one gets (for if, do, select case) the nice warning (!) message: Warning: Label at (1) is not in the same block as the GOTO statement at (2) One gets for goto 99 block 99 continue end block end only: Error: Label 99 referenced at (1) is never defined I think something nicer than "never defined" would be useful. One has also to think about which of those should give a warning (like now) and which should give a hard error. I believe jumping *into* a (DO/IF/SELECT (TYPE/CASE)/BLOCK/ ...) block is invalid, but they are all in the same scoping unit. However, I failed to find this restriction. The standard has: R851 goto-stmt is GO TO label C846 (R851) The label shall be the statement label of a branch target statement that appears in the same scoping unit as the goto-stmt. 1.3.115 scoping unit either - a program unit or subprogram, excluding any scoping units in it, - a derived-type de nition (4.5.2), or - an interface body, excluding any scoping units in it Further restrictions (and some more related to branching to an END only from inside of the ): C734 (R744) A statement that is part of a where-body-construct shall not be a branch target statement. C743 (R756) A forall-body-construct shall not be a branch target. It is permissible to branch to an end-associate-stmt only from within its ASSOCIATE construct. C811 A statement that branches from the block of a critical-construct to outside the critical-construct is not permitted. A CYCLE or EXIT statement in a critical-construct that transfers control outside the critical-construct is not permitted. It is permitted to branch to the end-do of a block DO construct only from within the range of that DO construct. C824 A branch (8.2) within a DO CONCURRENT construct shall not have a branch target that is outside the construct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41781
[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.
--- Comment #5 from sfilippone at uniroma2 dot it 2009-10-21 14:23 --- > > I believe jumping *into* a (DO/IF/SELECT (TYPE/CASE)/BLOCK/ ...) block is > invalid, but they are all in the same scoping unit. However, I failed to find > this restriction. > That is what is spelled out clearly in the two translation from standardese into English that I have, Metcalf Reid and Cohen page 54: "a goto statement must never specify a branch into a block" and Fortran 2003 handbook page 280ff "the statements that may be branch targets are those classified as action statements plus the initial statements for ASSOCIATE, CASE, DO, FORALL, IF, SELECT TYPE and WHERE, however it is not permitted to branch to a statement within a block from outside the block. " plus some other things about the END [something] often being a legitimate target. Thus I think both your examples should be rejected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41781
[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.
--- Comment #6 from burnus at gcc dot gnu dot org 2009-10-21 14:25 --- Found it: "8.1.2.1 Control flow in blocks Transfer of control to the interior of a block from outside the block is prohibited, except for the return from a procedure invoked within the block. Transfers within a block and transfers from the interior of a block to outside the block may occur." > One has also to think about which of those should give a warning (like now) > and which should give a hard error. NAG f95 always rejects it. ifort/gfortran/g95 allow it for IF, SELECT TYPE, DO, ASSOCIATE (only supported by ifort). ifort/gfortran reject it for SELECT TYPE (though gfortran only indirectly). I think it should definitely remain like this! Other blocks are BLOCK and CRITICAL. Personally, I would not mind to reject it for SELECT TYPE, BLOCK, CRITICAL, ASSOCIATE on the basis that this is a legacy feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41781
[Bug tree-optimization/41783] New: r151561 (PRE fix) regresses zeusmp
zeusmp regressed by about 5% again with the PRE fix for PR41101, which is r151561. The problem is that PRE now finds a partial redundancy (where in reality there isn't any) and the PHI node to compensate for this prevents vectorization of a loop due to its value used outside that loop. Testcase extracted from zeusmp: % cat hsmoc-1.f subroutine hsmoc ( ) implicit NONE integer ijkn parameter(ijkn = 128+5) real*8 dt, fact, db(ijkn), w1dt(ijkn) integer i, is, ie, j, js, je common /rootr/ dt common /scratch/ w1dt do 9 i=is,ie do 807 j=js-1,je+1 db (j ) = j 807 continue fact = dt * i do 808 j=js,je+1 w1dt(j)= fact * db (j) 808 continue 9 continue return end (compile with -march=barcelona -O3 -ffast-math -funroll-loops -fpeel-loops) The problem is the access to 'dt' (rootr.dt), which PRE thinks is partially redundant in the first loop (!?), hence it creates this code: pretmp.11_53 = rootr.dt; Loop-i: prephitmp.12_51 = PHI ... Loop-j1 prephitmp.12_49 = PHI ... pretmp.11_52 = rootr.dt; goto Loop-j1 prephitmp.12_23 = PHI D.1376_20 = prephitmp.12_23; ... Loop-j2 Notice especially how we now read rootr.dt in the backedge for loop-j1, which is much more often than before. Originally we access it ie-is times, now we access it (ie-is)*(je-js) times. It's possible that this alone explains the speed regression, and not necessarily the missed vectorization. But the missed vectorization was much easier to detect. -- Summary: r151561 (PRE fix) regresses zeusmp Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at gcc dot gnu dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application
--- Comment #9 from maurice35 dot david at laposte dot net 2009-10-21 14:46 --- My version is: [r...@ build]# ccmips -V ccmips: `-V' option must have argument [r...@pace build]# ccmips --version ccmips (GCC) 3.3.2 20030904 (Wind River vxworks61) (built 20050516) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- maurice35 dot david at laposte dot net changed: What|Removed |Added CC||maurice35 dot david at ||laposte dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-21 14:53 --- Confirmed. Btw the loop is still vectorized for me. -- rguenth 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-10-21 14:53:32 date|| Summary|r151561 (PRE fix) regresses |r151561 (PRE fix) regresses |zeusmp |zeusmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug tree-optimization/41775] [4.5 Regression] IPA-SRA: ice in rewrite_stmt, at tree-into-ssa.c:1302
-- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-21 12:31:40 |2009-10-21 15:05:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41775
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-21 15:07 --- Btw, the 2nd insertion is really weird (the first one in bb9 is just loop invariant motion). : pretmp.7_45 = rootr.dt; goto ; : : # prephitmp.8_48 = PHI D.1375_18 = (real(kind=8)) i_3; D.1376_19 = prephitmp.8_48; fact_20 = D.1375_18 * D.1376_19; if (js_9(D) <= D.1351_12) goto ; else goto ; it looks to me that we fail to translate over the first loop and its header copy - something that partial-PRE ought to have accomplished. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #44 from pogma at gcc dot gnu dot org 2009-10-21 15:08 --- Subject: Bug 41313 Author: pogma Date: Wed Oct 21 15:07:59 2009 New Revision: 153057 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153057 Log: 2009-10-21 Jack Howarth PR c++/41313 * gcc/config/darwin10.h: Use default_emit_unwind_label. * gcc/config/darwin.c: Disable -freorder-blocks-and-partition when darwin_emit_unwind_label is used. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c trunk/gcc/config/darwin10.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug driver/25507] -print-multi-os-directory undocumented
--- Comment #2 from jakub at gcc dot gnu dot org 2009-10-21 15:13 --- Subject: Bug 25507 Author: jakub Date: Wed Oct 21 15:13:21 2009 New Revision: 153058 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153058 Log: PR other/25507 * doc/invoke.texi: Document -print-multi-os-directory. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25507
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-21 15:14 ---
C testcase showing the likely underlying issue:
int db[100];
int dt, fact;
int main()
{
int i;
do
{
for (i=0; i<100; ++i)
db[i] = i;
fact = dt * i;
}
while (1);
}
where we not only insert into BB2 but also BB3:
:
pretmp.4_16 = dt;
goto ;
:
db[i_1] = i_1;
i_3 = i_1 + 1;
pretmp.4_14 = dt;
:
# i_6 = PHI <0(6), i_3(3)>
# prephitmp.5_15 = PHI
:
# i_1 = PHI
# prephitmp.5_17 = PHI
if (i_1 <= 99)
goto ;
else
goto ;
:
dt.0_4 = prephitmp.5_17;
fact.1_5 = i_1 * dt.0_4;
fact = fact.1_5;
goto ;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-21 15:16 --- Which all is likely due to the fact that PHI translation does not properly value-number translated loads and thus we create extra full redundancies sometimes (usually resulting in extra PHI nodes, but here extra loads). Micha, you once had a patch to "fix" this issue, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #5 from matz at gcc dot gnu dot org 2009-10-21 15:20 --- Yes, I mean the second insertion. The phi node generated for that one (in the first j-loop) prevents vectorization in r151561 (I haven't really tested newer revs that r151590). Maybe some other stuff in later revs cleans this PHI node up again (or the vectorizer handles it) so that the first loop is vectorized for you. You are sure that you talk about the first j loop that is vectorized for you, right? The second is also vectorized for me, that's not the interesting one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #6 from matz at gcc dot gnu dot org 2009-10-21 15:22 --- Hmm, at least I don't remember any patch dealing with phi translation right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug fortran/41784] New: [OOP] ICE
The attached code produces the subject error. [sfili...@donald bug9]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 20091021 (experimental) (GCC) [sfili...@donald bug9]$ gfortran -c linmap_type_mod.f90 linmap_type_mod.f90:105:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Build: trunk at r153049 plus provisional patch for PR41781. -- Summary: [OOP] ICE Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41784
[Bug fortran/41784] [OOP] ICE
--- Comment #1 from sfilippone at uniroma2 dot it 2009-10-21 15:24 --- Created an attachment (id=18859) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18859&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41784
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-21 15:26 --- LIM cleans up the 2nd insertion for me and moves the load next to the first insertion. What remains is the full redundancy and elimination of all the PHIs, so yes, your PRE patch would solve this. And yes, it is only the 2nd loop that is vectorized for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.
--- Comment #7 from janus at gcc dot gnu dot org 2009-10-21 15:32 --- Created an attachment (id=18860) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18860&action=view) patch v2 With this updated patch the example in comment #4 is rejected with the correct error message. -- janus at gcc dot gnu dot org changed: What|Removed |Added Attachment #18858|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41781
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #8 from matz at gcc dot gnu dot org 2009-10-21 15:35 --- But the important one (for zeusmp) is the first loop. That isn't vectorized anymore (but was in r151560, i.e. there it vectorized two loops). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug fortran/41772] [4.4/4.5 Regression] Wrong code due to TRANSFER of EMPTY array section
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-21 15:37:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41772
[Bug fortran/41784] [OOP] ICE in load_derived_extensions
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-21 15:41 --- The ICE also happens with a clean trunk. Here is the backtrace: #0 0x7fcacadb56a0 in strcmp () from /lib/libc.so.6 #1 0x005419c6 in gfc_find_symtree (st=0x2bcdf30, name=0x0) at /home/jweil/gcc45/trunk/gcc/fortran/symbol.c:2319 #2 0x004ffd9a in load_derived_extensions () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:4011 #3 0x00500a26 in read_module () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:4450 #4 0x00502caf in gfc_use_module () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:5500 #5 0x0050a5f8 in accept_statement (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:1525 #6 0x0050bb61 in parse_spec (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:2548 #7 0x0050d81f in parse_module () at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:3944 #8 0x0050de8f in gfc_parse_file () at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:4180 #9 0x0054afa0 in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc45/trunk/gcc/fortran/f95-lang.c:239 #10 0x009b6efd in compile_file () at /home/jweil/gcc45/trunk/gcc/toplev.c:1049 #11 0x009b91e9 in do_compile () at /home/jweil/gcc45/trunk/gcc/toplev.c:2408 #12 0x009b92aa in toplev_main (argc=2, argv=0x7fffd395cd08) at /home/jweil/gcc45/trunk/gcc/toplev.c:2450 #13 0x005c8be7 in main (argc=2, argv=0x7fffd395cd08) at /home/jweil/gcc45/trunk/gcc/main.c:35 -- janus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|[OOP] ICE |[OOP] ICE in ||load_derived_extensions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41784
[Bug lto/41764] Bogus errors from gold with linker-plugin
--- Comment #1 from espindola at gcc dot gnu dot org 2009-10-21 15:51 --- The produced symbol table is incorrect: ~/binutils/inst/bin/nm test.o t MAIN__ U _gfortran_set_args U _gfortran_set_options 0001 C gnu_lto_v1 0006 T main r options.0.1383 B raewin_ D xxxran_ GNUTARGET=plugin ~/binutils/inst/bin/nm --plugin ./lto-plugin/.libs/liblto_plugin.so test.o U _gfortran_set_args U _gfortran_set_options T ix T ix T iy T iy T iz T iz T main T raewin_ Will try to find out why. -- espindola 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-10-21 15:51:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41764
[Bug fortran/41784] [OOP] ICE in load_derived_extensions
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-21 16:02 --- Here is a further reduced test case: module A_mod type :: A end type end module module B_mod use A_mod type, extends(A) :: B end type end module module C_mod use B_mod type :: C end type C end module use C_mod, only: C end with a slightly different backtrace: Program received signal SIGSEGV, Segmentation fault. 0x004ffcd5 in load_derived_extensions () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:3997 3997 gcc_assert (derived->attr.flavor == FL_DERIVED); (gdb) bt #0 0x004ffcd5 in load_derived_extensions () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:3997 #1 0x00500a26 in read_module () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:4450 #2 0x00502caf in gfc_use_module () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:5500 #3 0x0050a5f8 in accept_statement (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:1525 #4 0x0050bb61 in parse_spec (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:2548 #5 0x0050d40a in parse_progunit (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:3758 #6 0x0050dee9 in gfc_parse_file () at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:4192 #7 0x0054afa0 in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc45/trunk/gcc/fortran/f95-lang.c:239 #8 0x009b6efd in compile_file () at /home/jweil/gcc45/trunk/gcc/toplev.c:1049 #9 0x009b91e9 in do_compile () at /home/jweil/gcc45/trunk/gcc/toplev.c:2408 #10 0x009b92aa in toplev_main (argc=2, argv=0x7fffc79cfd78) at /home/jweil/gcc45/trunk/gcc/toplev.c:2450 #11 0x005c8be7 in main (argc=2, argv=0x7fffc79cfd78) at /home/jweil/gcc45/trunk/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41784
[Bug driver/25507] -print-multi-os-directory undocumented
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-21 16:04 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25507
[Bug debug/41717] [4.5 Regression] internal compiler error: in expand_debug_expr
--- Comment #12 from hjl at gcc dot gnu dot org 2009-10-21 16:05 --- Subject: Bug 41717 Author: hjl Date: Wed Oct 21 16:05:31 2009 New Revision: 153063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153063 Log: 2009-10-21 H.J. Lu 2009-10-16 Richard Guenther PR tree-optimization/41728 * gcc.c-torture/compile/pr41728.c: New testcase. 2009-10-15 Jakub Jelinek PR debug/41717 * gcc.dg/debug/pr41717.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr41728.c - copied unchanged from r153062, trunk/gcc/testsuite/gcc.c-torture/compile/pr41728.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/debug/pr41717.c - copied unchanged from r153062, trunk/gcc/testsuite/gcc.dg/debug/pr41717.c Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41717
[Bug tree-optimization/41728] [4.5 Regression] error: SSA name in freelist but still referenced
--- Comment #8 from hjl at gcc dot gnu dot org 2009-10-21 16:05 --- Subject: Bug 41728 Author: hjl Date: Wed Oct 21 16:05:31 2009 New Revision: 153063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153063 Log: 2009-10-21 H.J. Lu 2009-10-16 Richard Guenther PR tree-optimization/41728 * gcc.c-torture/compile/pr41728.c: New testcase. 2009-10-15 Jakub Jelinek PR debug/41717 * gcc.dg/debug/pr41717.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr41728.c - copied unchanged from r153062, trunk/gcc/testsuite/gcc.c-torture/compile/pr41728.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/debug/pr41717.c - copied unchanged from r153062, trunk/gcc/testsuite/gcc.dg/debug/pr41717.c Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41728
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-10-21 18:08 --- Ok, I'm pretty much sure what happens and what is wrong. I'll fix what is wrong and we'll need that phi-translation fix to fixup the regressions that'll cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug c++/41785] New: ICE on canonical types with variadic templates and CRTP
Source code below makes an ICE:
g++-mp-4.5 -std=c++0x bug.cc
bug.cc: In instantiation of 'derived':
bug.cc:20:16: instantiated from here
bug.cc:9:1: internal compiler error: canonical types differ for identical types
derived and derived
Source:
struct a {};
template < typename T, typename ENCLOSING >
struct base;
template < typename... T >
struct derived
: public base< T, derived< T... > >...
{};
template < typename... T>
struct base< a, derived< T... > >
{
typedef derived< T... >
Derived;
};
int main()
{
derived< a > instance;
}
g++-mp-4.5 -v
Using built-in specs.
Target: i386-apple-darwin9
Configured with: ../gcc-4.5-20091001/configure --prefix=/opt/local
--build=i386-apple-darwin9 --enable-languages=c,c++,objc,obj-c++
--libdir=/opt/local/lib/gcc45 --includedir=/opt/local/include/gcc45
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.5 --with-gxx-include-dir=/opt/local/include/gcc45/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.5.0 20091001 (experimental) (GCC)
--
Summary: ICE on canonical types with variadic templates and CRTP
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alban dot linard at gmail dot com
GCC build triplet: i386-apple-darwin9
GCC host triplet: i386-apple-darwin9
GCC target triplet: i386-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41785
[Bug c++/41786] New: misparsing an object declaration - parameter may not have variably modified type
The declaration
form proj (space(V[i]), V_new_i, "mass");
of an object 'proj' of class 'form' is not recognized,
see below
#include
using std::vector;
#include
struct space_component;
struct const_space_component;
template
class smart_pointer {
public:
// allocators:
smart_pointer (T* p = 0);
smart_pointer (const smart_pointer&);
~smart_pointer ();
smart_pointer& operator= (const smart_pointer&);
// accessors:
const T* pointer() const;
const T& data () const;
const T* operator-> () const;
const T& operator* () const;
// modifiers:
T* pointer ();
T* operator-> ();
T& data ();
T& operator* ();
// implementation:
};
typedef int basis;
class spacerep {
public:
typedef std::vector::size_type size_type;
spacerep();
};
class space : public smart_pointer {
public:
// typdefs:
typedef spacerep::size_type size_type;
// allocator/deallocator:
space ();
space(const const_space_component&);
space_component operator [] (size_type i_comp);
const_space_component operator [] (size_type i_comp) const;
};
struct space_component {
typedef space::size_type size_type;
space_component();
space_component(space& V, size_type i);
};
struct const_space_component {
typedef space::size_type size_type;
const_space_component();
const_space_component(const space_component&);
};
class form {
public :
form ();
form (const space& X, const space& Y, const std::string& op_name,
bool locked_boundaries=false);
};
int main() {
space V, V_new_i;
int i=1;
form proj (space(V[i]), V_new_i, "mass");
/* error: parameter may not have variably modified type
'space [(((long unsigned int)(((long int)i) + -0x1)) + 1)]'
*/
}
--
Summary: misparsing an object declaration - parameter may not
have variably modified type
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jarausch at igpm dot rwth-aachen dot de
GCC build triplet: x86-64
GCC host triplet: x86-64
GCC target triplet: x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41786
[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application
--- Comment #10 from mikpe at it dot uu dot se 2009-10-21 19:47 --- (In reply to comment #9) > My version is: > [r...@ build]# ccmips -V > ccmips: `-V' option must have argument > [r...@pace build]# ccmips --version > ccmips (GCC) 3.3.2 20030904 (Wind River vxworks61) (built 20050516) > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. That's an old vendor-modified compiler based on an ancient and no longer supported gcc version. Please direct your questions about that compiler to the vendor, Wind River. If you can reproduce your MIPS alignment problem using gcc-4.3 or newer, then that's something you should report here in a new bugzilla entry (so as to not confuse this ARM problem with a possibly unrelated MIPS problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
[Bug c++/41786] misparsing an object declaration - parameter may not have variably modified type
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-21 19:49 --- I don't think this is misparsing this at all. This is one place in the C++ standard that says it should be parsed as a function declaration rather than a variable declaration to resolve an ambiguous between those two. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|misparsing an object|misparsing an object |declaration - parameter may |declaration - parameter may |not have variably modified |not have variably modified |type|type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41786
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #5 from ghazi at gcc dot gnu dot org 2009-10-21 19:51 --- (In reply to comment #3) > > (Also, you don't mention what version of gmp you were using.) > Right, sorry: I've tried this with the latest version, gmp 4.3.1. Okay I checked gmp source tarballs, and it looks like the SUNPRO clauses defining __GMP_EXTERN_INLINE were added specifically in gmp-4.3.1. I don't see them in gmp-4.2.4 or gmp-4.3.0. Could you please verify bootstrapping gcc with those two versions of gmp plus Sun's cc to see if they work? If it does we should offer it as a workaround for users until we figure out how we want to solve this long-term. Recommending other versions of gmp as a workaround is helpful even if we hack up a patch to GCC, because gcc-4.3 and 4.4 will not see these "fixes" until some months in the future when we do another release. Alternatively we may end up recommending to the gmp maintainer(s) that they fix the problem in their package since that's what's really broken IMHO. Either way, it would be helpful to know whether using other versions of gmp would help. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-10-21 20:14 --- Created an attachment (id=18861) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18861&action=view) 1st part of a patch Like this. We should never produce new non-constant value-numbers during phi-translation as that may spuriously increase the maximal set and thus cause insertion of non-redundant values. We do so for NARYs anyway - I'm not sure if that is good though. Maybe the idea is that repeated translation can eventually lead to a known value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug tree-optimization/41497] [4.5 Regression] apparent integer wrong code bug
--- Comment #12 from spop at gcc dot gnu dot org 2009-10-21 23:05 --- Subject: Bug 41497 Author: spop Date: Wed Oct 21 23:05:39 2009 New Revision: 153441 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153441 Log: PR tree-optimization/41497 * tree-scalar-evolution.c (analyze_evolution_in_loop): Return chrec_dont_know if the evolution function returned by follow_ssa_edge is constant in the analyzed loop and is not compatible with the initial value before the loop. * tree-chrec.h (no_evolution_in_loop_p): Call STRIP_NOPS. * gcc.dg/tree-ssa/pr41497.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr41497.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.h trunk/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41497
[Bug tree-optimization/41497] [4.5 Regression] apparent integer wrong code bug
--- Comment #13 from spop at gcc dot gnu dot org 2009-10-21 23:10 --- Fixed. This bug is potentially latent in older branches. Should I test it in the 4.4 branch as well? -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41497
[Bug target/41787] New: Power7 code violates ABI
The power7 code that was added in July, violates the powerpc ABI in two ways due to the floating point registers overlap with the VSX registers. 1) HARD_REGNO_CALL_PART_CLOBBERED was not adjusted to disallow VSX registers 0..31 which overlap with the floating point registers to be live across function calls. Thus the compiler might think that a VSX register might be preserved across a call, when only the first double word will be. The Spec 2006 tests dealII, calculix, and GemsFDTD fail when compiled for vsx with some compiler options. 2) The VRSAVE register is not set if a function uses VSX registers that overlap with the floating point registers, because the register is only 32-bit and does not have room to indicate additional vector registers that overlap with floating point registers. The new ABI says that the VRSAVE only has to be non-zero if vector registers are used. I have patches for both of these problems that I am currently looking at. -- Summary: Power7 code violates ABI Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: meissner at gcc dot gnu dot org ReportedBy: meissner at gcc dot gnu dot org GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41787
[Bug tree-optimization/40556] [4.5 Regression] ICE in IPA-CP with recursion
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-10-21 23:58 --- Actually it catch quite interesting thinko in early inliner. We cut iterations of early inliner after fixed point of iterations but because of way the exit condition is written we end up not applying the inline plan after last iteration. Testing patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40556
[Bug c++/41788] New: -Wpacked option changes the layout of packed non-POD structs
When a packed non-POD struct is included in another packed struct,
the outer struct layout changes depending on whether -Wpacked is used or not.
It seems wrong that a warning option affects data layout and code generation.
The same behavior is observed with 4.4.2, 4.3.4, 4.2.1, 4.1.2.
It could be related to bug 26670.
% cat packed_nonpod.cpp
extern "C" int printf (__const char *__restrict __format, ...);
struct INNER {
virtual int foo() const { return 1; }
} __attribute__ ((packed));
struct OUTER {
char c;
INNER inner;
} __attribute__ ((packed));
int main()
{
OUTER outer;
printf("sizeof(outer) = %u\n", sizeof(outer));
printf("offset(inner) = %u\n", (char *)&outer.inner - (char *)&outer);
return 0;
}
% g++ packed_nonpod.cpp
% a.out
sizeof(outer) = 5
offset(inner) = 1
% g++ packed_nonpod.cpp -Wpacked
packed_nonpod.cpp:3: warning: packed attribute is unnecessary for 'INNER'
packed_nonpod.cpp:9: warning: ignoring packed attribute because of unpacked
non-POD field 'INNER OUTER::inner'
% a.out
sizeof(outer) = 8
offset(inner) = 4
--
Summary: -Wpacked option changes the layout of packed non-POD
structs
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nenad at tensilica 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=41788
[Bug middle-end/41730] ICE with -flto -fwhole-program
--- Comment #2 from hubicka at ucw dot cz 2009-10-22 00:29 --- Subject: Re: New: ICE with -flto -fwhole-program The problem here is that ipa-pure-const skips analysis of overwrittable nodes. But with LTO and whole program the nodes might look overwrittable at compile time, but at link time we want to use their analysis. Additionally we assume that function without bodies are opaque that is not true too, so in fact we are limitting the pass to single file only. Same problem is with the other ipa-* passes, I am testing patch for this pass and looking into others. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41730
[Bug c/41789] New: -Wmissing prototypes: nested functions shouldn't produce warnings if defined before first use
Currently, if one compiles with -Wmissing-prototypes, GCC will complain about a
nested function defined with no preceding prototype declaration, for example:
int foo(int a) {
auto int bar(int b) { return b; }
return bar(a);
}
According to bug 19635 comment #1, the "proper" way to do this is to explicitly
add a forward declaration:
int foo(int a) {
auto int bar(int b);
auto int bar(int b) { return b; }
return bar(a);
}
But this seems redundant to me, since the declaration is local to the enclosing
function and there's no danger of any external code calling the nested function
improperly. Would it be possible to have GCC treat nested functions like
file-scope static functions, and omit the missing prototype warning if the
function is properly defined (with auto) before its first use?
--
Summary: -Wmissing prototypes: nested functions shouldn't produce
warnings if defined before first use
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcczilla1 at achurch dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41789
[Bug c/36774] -Wmissing-prototypes triggers on nested functions
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-22 04:11 --- *** Bug 41789 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcczilla1 at achurch dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36774
[Bug c/41789] -Wmissing prototypes: nested functions shouldn't produce warnings if defined before first use
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-22 04:11 --- Yes I agree we should not warn but bug 19635 was about the workaround which is why I commented that way. Anyways this is a dup of bug 36774 (a still opened bug). *** This bug has been marked as a duplicate of 36774 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41789
[Bug rtl-optimization/41790] New: [4.5 Regression]: cris-elf g++.dg/torture/pr38811.C -O3
With revision 153024 this test passed. >From revision 153037 and on, this test has failed as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/torture/dg-torture.exp ... ... FAIL: g++.dg/torture/pr38811.C -O3 -g (internal compiler error) FAIL: g++.dg/torture/pr38811.C -O3 -g (test for excess errors) With the message in the logfile being: Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/g++/../../g++ -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/g++/../../ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/torture/pr38811.C -nostdinc++ -I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf -I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include -I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++ -I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/include/backward -I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O3 -g-S -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -o pr38811.s(timeout = 300) /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/torture/pr38811.C: In member function 'virtual long int AbcAbcdTracer::TestIsoAbcde(AbcZyParamType, double, int&)': /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/torture/pr38811.C:72:1: internal compiler error: in reload_combine_note_use, at postreload.c:1097 Author of the only suspect patches in above revision range CC:ed. (Yes, CRIS is an autoincdec target.) -- Summary: [4.5 Regression]: cris-elf g++.dg/torture/pr38811.C -O3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41790
[Bug c++/41791] New: LTO warnings with -Winline
Simple program:
#include
int
main(int,
char **)
{
std::string i;
i = "abc";
}
Compiled as:
/usr/local/bin/g++ -O3 -Winline -flto -Werror \
-o z.exe z.cc -lintl
Gives:
In file included from
/usr/local/lib/gcc/alphaev56-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/basic_string.h:296:0,
from :99:
z.cc: In function 'main':
/usr/local/lib/gcc/alphaev56-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/basic_string.h:502:7:
warning: inlining failed in call to '__comp_dtor ': call is unlikely and code
size would grow
z.cc:9:17: warning: called from here
So, first, -Winline gives warnings in system code I have no control over,
Second, -Werror should have turned it into an error anyway.
Warning goes away if -flto is removed.
uname -a
Linux alpha1 2.4.9-40 #1 Mon Sep 23 08:14:02 EDT 2002 alpha unknown
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/alphaev56-unknown-linux-gnu/4.5.0/lto-wrapper
Target: alphaev56-unknown-linux-gnu
Configured with: ../gcc/configure --verbose --enable-languages=c++
--disable-linux-futex --disable-nls --disable-tls --enable-lto
Thread model: posix
gcc version 4.5.0 20091017 (experimental) (GCC)
BUILDING:
alias CONFIGURECVS='../gcc/configure --verbose --enable-languages=c++
--disable-linux-futex --disable-nls --disable-tls --enable-lto 2>&1 | tee clog'
alias BUILD='nice gmake CFLAGS='\'''\'' BOOT_CFLAGS='\'''\''
LIBCFLAGS='\''-g'\'' LIBCXXFLAGS='\''-g'\'' bootstrap 2>&1 | tee log'
--
Summary: LTO warnings with -Winline
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckelvey at maskull dot com
GCC build triplet: alphaev56-unknown-linux-gnu
GCC host triplet: alphaev56-unknown-linux-gnu
GCC target triplet: alphaev56-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41791
[Bug libstdc++/40852] [parallel-mode] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9
--- Comment #9 from singler at gcc dot gnu dot org 2009-10-22 06:57 --- I can reproduce the bug on my machine (2 Quadcore Nehalems, 48GB RAM) 4 x 10^9 ints: 65 seconds used in sort 5 x 10^9 ints: 193 seconds used in sort -- singler at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |singler at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-22 06:57:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852
[Bug c/41789] -Wmissing prototypes: nested functions shouldn't produce warnings if defined before first use
--- Comment #2 from gcczilla1 at achurch dot org 2009-10-22 06:57 --- Sorry! Not sure how I missed that one in my search. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41789
