[Bug c++/51186] New: declaring main() with auto but without --std=c++11 gives inconsistent error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51186
Bug #: 51186
Summary: declaring main() with auto but without --std=c++11
gives inconsistent error messages
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wswik...@poczta.fm
When I try to compile this code without specifying C++11 or C++0x standard
auto main()-int
{
}
the following conflicting messages are generated:
cpp.cpp:1:14: error: top-level declaration of 'main' specifies 'auto'
cpp.cpp:1:14: error: 'main' function with late return type not declared
with 'auto' type specifier
The second one should be disabled when not in C++11 mode, or replaced with one
saying that funtions with late return type are not allowed.
[Bug c/51187] New: gcc 4.6.2 miscompiles genrecog.c when building gcc 4.5.3 with --target=avr on Debian/sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51187 Bug #: 51187 Summary: gcc 4.6.2 miscompiles genrecog.c when building gcc 4.5.3 with --target=avr on Debian/sparc Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ju...@wooyd.org Hello, We discovered this bug in gcc 4.6.2 in Debian due to build failure of gcc-avr package on sparc (tracked in Debian as http://bugs.debian.org/648016), which uses gcc 4.5 source to build an AVR cross-compiler. I was not able to come up with a nice self-contained test-case, but here are the steps to reproduce the failure. 1. Download the gcc-4.5.3.tar.bz2 release tarball. 2. Configure it with ./configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --disable-libssp --build=sparc-linux-gnu --host=sparc-linux-gnu --target=avr Unfortunately, this will probably require binutils-avr to be installed, even though I believe the build never gets far enough to actually use them. 3. Start the build with 'make' using gcc 4.6. In my case the default Debian system compiler used to build utilities (including genrecog.c): jurij@debian:~$ sparc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=sparc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc-linux-gnu/4.6/lto-wrapper Target: sparc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --with-long-double-128 --enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu Thread model: posix gcc version 4.6.2 (Debian 4.6.2-4) 4. Build will fail with the following messages: [...] sparc-linux-gnu-gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../.././gcc -I../.././gcc/build -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND -I/usr/include/libelf \ -o build/genrecog.o ../.././gcc/genrecog.c sparc-linux-gnu-gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genrecog \ build/genrecog.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../../build-sparc-linux-gnu/libiberty/libiberty.a build/genrecog ../.././gcc/config/avr/avr.md \ insn-conditions.md tmp-recog.c /bin/bash: line 1: 22105 Bus error build/genrecog ../.././gcc/config/avr/avr.md insn-conditions.md tmp-recog.c make[2]: *** [s-recog] Error 138 make[2]: Leaving directory `/home/jurij/gcc/gcc-4.5-upstream/gcc-4.5.3/host-sparc-linux-gnu/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/jurij/gcc/gcc-4.5-upstream/gcc-4.5.3' make: *** [all] Error 2 The output of the genrecog.c compilation with -v -save-temps added to the above command line: Using built-in specs. COLLECT_GCC=sparc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc-linux-gnu/4.6/lto-wrapper Target: sparc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,ob j-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads= posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plug in --enable-objc-gc --enable-targets=all --with-long-double-128 --enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu
[Bug c/51187] gcc 4.6.2 miscompiles genrecog.c when building gcc 4.5.3 with --target=avr on Debian/sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51187 --- Comment #1 from Jurij Smakov jurij at wooyd dot org 2011-11-17 09:01:06 UTC --- Created attachment 25843 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25843 Preprocessed genrecog.c code
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #1 from Chris Jefferson chris at bubblescope dot net 2011-11-17 09:11:02 UTC --- This was necessary because (I believe) it is impossible to implement the piecewise_construct_t constructor without compiler support for forwarding constructors. Last time I checked, they hadn't been implemented yet. If they have been implemented, I can supply the code to make this work correctly.
[Bug c++/51188] New: invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 Bug #: 51188 Summary: invalid static_cast from type 'XBase' to type 'int' Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mario-baum...@web.de Created attachment 25844 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25844 c++ source Hi all, i found a strange bug while compiling the attached c++ file g++ -c x.cpp x.cpp: In member function 'std::pairint, int X::getImp() const': x.cpp:15:57: error: invalid static_cast from type 'XBase' to type 'int' if I remove any of the superfluous statements in x.cpp it works fine! mario. -- uname -a Linux ahsoka.intec.dom 2.6.32-131.17.1.el6.x86_64 #1 SMP Thu Sep 29 10:24:25 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux rpm -qa glibc* | grep -e 'glibc-[0-9]' | sort -u glibc-2.12-1.25.el6_1.3.i686 glibc-2.12-1.25.el6_1.3.x86_64 g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/app2/gcc/4.7.0-2017-svn181436/x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/app2/gcc/4.7.0-2017-svn181436/x86_64 --enable-languages=c,c++,fortran --disable-nls --with-gmp=/app2/gcc/4.7.0-2017-svn181436/x86_64/aux --with-mpfr=/app2/gcc/4.7.0-2017-svn181436/x86_64/aux --with-mpc=/app2/gcc/4.7.0-2017-svn181436/x86_64/aux --with-ppl=/app2/gcc/4.7.0-2017-svn181436/x86_64/aux --with-cloog=/app2/gcc/4.7.0-2017-svn181436/x86_64/aux Thread model: posix gcc version 4.7.0 2017 (experimental) (GCC) ld -v GNU ld (GNU Binutils) 2.22.51.2017
[Bug c/51187] gcc 4.6.2 miscompiles genrecog.c when building gcc 4.5.3 with --target=avr on Debian/sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51187 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-11-17 09:18:12 UTC --- Have you seen this issue on other hosts than sparc32, such as x86-64 or sparc64? Have you checked if other versions of the host gcc work, such as gcc-4.6.1, gcc-4.5.3, or gcc-4.4.6?
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #1 from fabien at gcc dot gnu.org 2011-11-17 09:25:55 UTC --- Yet another bug caused by my recent changes with using declarations.
[Bug c++/51189] New: [4.7 Regression] ICE in force_decl_die, at dwarf2out.c:19261
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51189
Bug #: 51189
Summary: [4.7 Regression] ICE in force_decl_die, at
dwarf2out.c:19261
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following code snippet triggers an ICE on x86_64-unknown-linux-gnu when
compiled with -g:
=
struct A
{
int i1, i2, i3, i4, i5, i6;
};
struct B : A
{
using A::i1;
using A::i2;
using A::i3;
using A::i4;
using A::i5;
using A::i6;
};
struct C : B
{
using B::i1;
};
=
bug.cc:16:8: internal compiler error: in force_decl_die, at dwarf2out.c:19261
Please submit a full bug report, [etc.]
[Bug c++/51189] [4.7 Regression] ICE in force_decl_die, at dwarf2out.c:19261
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51189 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.7.0
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-17 09:30:41 UTC --- nope, they haven't
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-17 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from fabien at gcc dot gnu.org 2011-11-17 09:52:40 UTC --- (In reply to comment #0) [...] if I remove any of the superfluous statements in x.cpp it works fine! There is a strange thing here, if we reach 7 members in a class, things are done differently in the compiler. Jason, I'd like to run the testsuite without this 7 member rule, how could I do that ? Thanks.
[Bug libstdc++/51185] [C++0x] false-positive results of std::is_constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51185 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-17 10:18:19 UTC --- Daniel, can you have a look?
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-17 Depends on||43674 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-17 10:19:14 UTC --- I've updated the C++11 status table in the manual to say that piecewise construction requires an accessible copy/move constructor, and marked this as dependent on PR 43674
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #3 from fabien at gcc dot gnu.org 2011-11-17 10:21:30 UTC --- (In reply to comment #2) (In reply to comment #0) [...] Jason, I'd like to run the testsuite without this 7 member rule, how could I do that ? To clarify, I mean 0 instead of 7.
[Bug c++/51190] New: [4.7 Regression] 'using' causing trouble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51190
Bug #: 51190
Summary: [4.7 Regression] 'using' causing trouble
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following valid code snippet is rejected on trunk:
struct A
{
int i;
};
templatetypename struct B
{
A* p;
};
templatetypename T struct C : BT
{
using BT::p;
C() { p-i; }
int i1, i2, i3, i4, i5;
};
CA c;
bug.cc: In instantiation of 'CT::C() [with T = A]':
bug.cc:20:6: required from here
bug.cc:15:9: error: base operand of '-' has non-pointer type 'BA'
I think this is also related to PR 51189. It looks something with 'using' got
screwed up.
[Bug c++/51190] [4.7 Regression] 'using' causing trouble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51190 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug objc++/51159] build failure with --enable-build-with-cxx in gcc-4.6.2/gcc/objc/objc-next-runtime-abi-02.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51159 --- Comment #2 from sebastian.heg...@tu-dresden.de 2011-11-17 10:44:33 UTC --- Fixed in trunk r173723, not fixed in gcc-4.6-branch. --enable-build-with-cxx is an officially supported build option, so it should work reliably in releases.
[Bug c++/51189] [4.7 Regression] ICE in force_decl_die, at dwarf2out.c:19261
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51189 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-17 CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug libstdc++/51185] [C++0x] false-positive results of std::is_constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51185 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2011-11-17 10:58:09 UTC --- (In reply to comment #1) The root of the problem is that __is_base_to_derived_ref works on source references solely. I need a bit time for a proper fix.
[Bug c++/51190] [4.7 Regression] 'using' causing trouble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51190 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-17 CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug middle-end/50598] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598
vincenzo Innocente vincenzo.innocente at cern dot ch changed:
What|Removed |Added
CC||vincenzo.innocente at cern
||dot ch
--- Comment #25 from vincenzo Innocente vincenzo.innocente at cern dot ch
2011-11-17 11:11:34 UTC ---
confirm solved
cat once.cpp
#includemutex
#includeiostream
int main() {
std::once_flag flag;
std::call_once(flag,[](){std::cout hi std::endl;});
return 0;
}
Vincenzos-MacBook-Pro:ExercisesBertinoro09 innocent$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.2.0
Configured with: ./configure --enable-languages=c,c++,fortran
--disable-multilib --disable-bootstrap --enable-lto -disable-libitm
Thread model: posix
gcc version 4.7.0 2012 (experimental) (GCC)
Vincenzos-MacBook-Pro:ExercisesBertinoro09 innocent$ c++ -Ofast -pthread
-std=gnu++11 once.cpp
Undefined symbols for architecture x86_64:
___emutls_v._ZSt15__once_callable, referenced from:
_main in ccCeliaX.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
Vincenzos-MacBook-Pro:ExercisesBertinoro09 innocent$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.2.0
Configured with: ./configure --enable-languages=c,c++,fortran
--disable-multilib --disable-bootstrap --enable-lto -disable-libitm
Thread model: posix
gcc version 4.7.0 2017 (experimental) (GCC)
Vincenzos-MacBook-Pro:ExercisesBertinoro09 innocent$ c++ -Ofast -pthread
-std=gnu++11 once.cpp
[Bug libstdc++/51185] [C++0x] false-positive results of std::is_constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51185 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-17 Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-17 11:14:59 UTC --- Thanks a lot!
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 --- Comment #4 from Marc Glisse marc.glisse at normalesup dot org 2011-11-17 11:44:55 UTC --- (In reply to comment #1) This was necessary because (I believe) it is impossible to implement the piecewise_construct_t constructor without compiler support for forwarding constructors. Ah, right, makes sense, thank you.
[Bug c/51187] gcc 4.6.2 miscompiles genrecog.c when building gcc 4.5.3 with --target=avr on Debian/sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51187 Peter Green plugwash at p10link dot net changed: What|Removed |Added CC||plugwash at p10link dot net --- Comment #3 from Peter Green plugwash at p10link dot net 2011-11-17 11:47:35 UTC --- Have you seen this issue on other hosts than sparc32, such as x86-64 or sparc64? gcc-avr fails around the same place on a number of architectures. I do not know enough about gcc to say if they are all results of the same issue or not (note: architecture names are debian architectures). sparc: gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genrecog \ build/genrecog.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../build-sparc-linux-gnu/libiberty/libiberty.a build/genrecog ../../src/gcc/config/avr/avr.md \ insn-conditions.md tmp-recog.c /bin/bash: line 1: 22778 Bus error build/genrecog ../../src/gcc/config/avr/avr.md insn-conditions.md tmp-recog.c make[3]: *** [s-recog] Error 138 sparc64: gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmddeps \ build/genmddeps.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../build-sparc64-linux-gnu/libiberty/libiberty.a build/genmddeps ../../src/gcc/config/avr/avr.md tmp-mddeps /bin/bash: line 1: 24043 Segmentation fault build/genmddeps ../../src/gcc/config/avr/avr.md tmp-mddeps make[3]: *** [s-mddeps] Error 139 mips/mipsel: gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmddeps \ build/genmddeps.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../build-mips-linux-gnu/libiberty/libiberty.a build/genmddeps ../../src/gcc/config/avr/avr.md tmp-mddeps ../../src/gcc/config/avr/avr.md:78: missing name or number ../../src/gcc/config/avr/avr.md:78: following context is `predicates.md)' make[3]: *** [s-mddeps] Error 1 sh4: gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengenrtl \ build/gengenrtl.o build/errors.o ../build-sh4-linux-gnu/libiberty/libiberty.a build/gengenrtl -h tmp-genrtl.h /bin/sh: line 1: 29938 Segmentation fault build/gengenrtl -h tmp-genrtl.h make[3]: *** [s-genrtl-h] Error 139 amd64, armel, hurd-i386, i386, ia64, kfreebsd-i386, kfreebsd-amd64, powerpc, s390, armhf and s390x all built gcc-avr successfully. alpha, avr32, hppa, m68k and powerpcspe have not tried to build gcc-avr due to unavailable binutils-avr. Have you checked if other versions of the host gcc work, such as gcc-4.6.1, gcc-4.5.3, or gcc-4.4.6? I'm not aware of anyone trying this.
[Bug c++/51191] New: [C++0x] SEGV on deducing template aliases with non-template alias declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51191
Bug #: 51191
Summary: [C++0x] SEGV on deducing template aliases with
non-template alias declarations
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com
Code:
template class T
class ClassTemplate {};
template class T
struct Metafunction {
typedef T type;
};
template class T
using TemplateAlias = ClassTemplate typename MetafunctionT::type ;
using Alias = TemplateAliasint;
// no SEGV if changed to typedef TemplateAliasint Alias;
template class T
void f( TemplateAliasT );
int main()
{
Alias x; // no SEGV if changed to TemplateAliasint x;
f( x ); // no SEGV if changed to fint(x);
}
Message:
In function 'int main()':
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
GCC version:
gcc-4.7-2012
[Bug c/51192] New: h8300 ICE building libgcov.c in int_mode_for_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51192 Bug #: 51192 Summary: h8300 ICE building libgcov.c in int_mode_for_mode Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org Thu Nov 17 04:24:24 UTC 2011 (revision 181435) Target: h8300-rtems4.11 Regression since 4.6.2 and on head since h8300-rtems4.11-gcc (GCC) 4.7.0 2015 (experimental) [trunk revision 181395] I expect all h8300 targets should have same issue. /home2/joel/build/b-h8300-gcc/./gcc/xgcc -B/home2/joel/build/b-h8300-gcc/./gcc/ -nostdinc -B/home2/joel/build/b-h8300-gcc/h8300-rtems4.11/newlib/ -isystem /home2/joel/build/b-h8300-gcc/h8300-rtems4.11/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/h8300-rtems4.11/bin/ -B/users/joel/test-gcc/install-svn/h8300-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-svn/h8300-rtems4.11/include -isystem /users/joel/test-gcc/install-svn/h8300-rtems4.11/sys-include-g -O2 -mh -O2 -I/users/joel/test-gcc/gcc-svn/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -DDF=SF -I. -I. -I../../.././gcc -I/users/joel/test-gcc/gcc-svn/libgcc -I/users/joel/test-gcc/gcc-svn/libgcc/. -I/users/joel/test-gcc/gcc-svn/libgcc/../gcc -I/users/joel/test-gcc/gcc-svn/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _gcov_indirect_call_profiler.o -MT _gcov_indirect_call_profiler.o -MD -MP -MF _gcov_indirect_call_profiler.dep -DL_gcov_indirect_call_profiler -c /users/joel/test-gcc/gcc-svn/libgcc/libgcov.c /users/joel/test-gcc/gcc-svn/libgcc/unwind-dw2-fde.c: In function 'search_object': /users/joel/test-gcc/gcc-svn/libgcc/unwind-dw2-fde.c:763:21: internal compiler error: in int_mode_for_mode, at stor-layout.c:424 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/51193] New: std::cout is behaving strangely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51193 Bug #: 51193 Summary: std::cout is behaving strangely Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pva89c...@ya.ru coutrCount(5, 0, arr1) in http://pastebin.com/t62Yamen does 32767 if you change cout rCount(...) by coutsmthrCount(...) all right couttestrCount(5, 0, arr1) does 0
[Bug c++/51194] New: ICE about template aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51194
Bug #: 51194
Summary: ICE about template aliasing
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fate66...@gmail.com
compiler option: -Wall -std=c++0x
error message:
242:43: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in lookup_template_class_1, at cp/pt.c:7293
code:
/*
including, boost/mpl/and.hpp
boost/type_traits/is_same.hpp
*/
template bool, class T = void
enable_if_c
{
typedef T type;
};
template class T
enable_if_cfalse, T
{ };
template class Cond, class T = void
using enable_if = enable_if_cCond::value, T;
template template class... class... Conds
struct condition_and
{
template class... Types
using enable = enable_ifboost::mpl::and_CondsTypes...;
};
template class T, class U = T
using Test = typename condition_and
// For any two parameters meta-functions, same error occurs.
boost::is_same
, boost::is_same
, boost::is_same
::template enableT, U; // here
[Bug c++/51193] std::cout is behaving strangely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51193 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-17 12:47:09 UTC --- the code is simply buggy - valgrind shows loads of errors
[Bug c++/51193] std::cout is behaving strangely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51193 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-17 13:19:11 UTC --- you should compile with warnings before reporting bugs: b.cc: In function 'int rCount(int, int, int*)': b.cc:30: warning: control reaches end of non-void function
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target|s390x-ibm-linux |s390x-ibm-linux, ||powerpc*-*-* Status|RESOLVED|REOPENED CC||dje at gcc dot gnu.org Host|s390x-ibm-linux |s390x-ibm-linux, ||powerpc*-*-* Resolution|FIXED | Build|s390x-ibm-linux |s390x-ibm-linux, ||powerpc*-*-* --- Comment #12 from David Edelsohn dje at gcc dot gnu.org 2011-11-17 13:54:29 UTC --- The committed patch breaks structs on AIX and Darwin. AIX and Darwin differ from PPC64 Linux in the way structs are padded into words. See aix.h:#define AGGREGATES_PAD_UPWARD_ALWAYS 1 linux64.h:#define AGGREGATES_PAD_UPWARD_ALWAYS 0 and darwin_rs6000_special_round_type_align I suspect that store_bit_field behavior should be honoring those macros and instead is imposing a single model.
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #13 from David Edelsohn dje at gcc dot gnu.org 2011-11-17 14:02:47 UTC --- The comment for the new code show the error in logic: /* If the remaining chunk doesn't have full wordsize we have to make sure that for big endian machines the higher order bits are used. */ The statement in the comment is not true. This depends on the target ABI's aggregate padding rules.
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 15:17:35 UTC --- (In reply to comment #2) There is a strange thing here, if we reach 7 members in a class, things are done differently in the compiler. Jason, I'd like to run the testsuite without this 7 member rule, how could I do that ? Look for if (n_fields 7) in finish_struct_1.
[Bug middle-end/39976] [4.5/4.6/4.7 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
William J. Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment #37 from William J. Schmidt wschmidt at gcc dot gnu.org
2011-11-17 15:15:49 UTC ---
Using Pat's reduced test case, I found that the problem occurs when the back
arc along 7-7 (the innermost loop) is split by the following:
Inserting a partition copy on edge BB7-BB7 :PART.153 = PART.45
Coalescing previously determined the following for these partitions:
Partition 45 (prephitmp.35_113 - 113 222 225 343 )
Partition 153 (prephitmp.35_322 - 322 )
Below, I've cut down the tree dump at the time of coalescing to show just the
statements involving prephitmp.35 and control flow, except for block 7 which
I've reproduced in its entirety. The problem can be seen in block 7, where
there are two PHIs with the identical RHS:
# prephitmp.35_322 = PHI prephitmp.35_59(6), prephitmp.35_113(7)
# prephitmp.35_225 = PHI prephitmp.35_59(6), prephitmp.35_113(7)
225 is coalesced with 113, but 322 is not. From what I can tell, 322 should be
equally as good a candidate for coalescing as 225. If the duplicates had been
removed, it seems the existing coalescing algorithm would have avoided
inserting the partition copy that created the extra block.
I'm thinking these kinds of duplicate phis should be cleaned up before we get
to expand. Is that already the intent, and this is just a bug, or is that
something that needs to be implemented somewhere in the late tree phases?
Alternatively, should coalesce have done better here?
For what it's worth, here are the origins of the duplicate PHIs in block 7.
The first PHI is introduced in 094t.pre:
# prephitmp.35_322 = PHI zlvj.5_59(9), cikve.14_113(12)
This is changed as follows in 099t.copyprop4:
# prephitmp.35_322 = PHI zlvj.5_59(6), cikve.14_113(8)
# cikve_lsm.48_225 = PHI zlvj.5_59(6), cikve.14_113(8)
Finally, these are renamed in 138t.copyrename4:
# prephitmp.35_322 = PHI prephitmp.35_59(6), prephitmp.35_113(7)
# prephitmp.35_225 = PHI prephitmp.35_59(6), prephitmp.35_113(7)
==
thin6d (integer(kind=4) restrict nthinerr)
{
...
# BLOCK 5 freq:2800
# PRED: 4 [100.0%] (fallthru,exec) 9 [86.0%] (dfs_back,false,exec)
# prephitmp.35_221 = PHI prephitmp.35_284(4), prephitmp.35_228(9)
...
prephitmp.35_32 = D.2028_14 * pretmp.34_287 + D.2038_31;
...
prephitmp.35_59 = D.2036_27 * pretmp.34_287 + D.2189_18;
D.2050_70 = prephitmp.35_32 * pretmp.37_297 + pretmp.37_295;
prephitmp.42_77 = prephitmp.35_59 * pretmp.37_299 + D.2050_70;
D.2190_76 = -prephitmp.35_59;
...
prephitmp.42_95 = prephitmp.35_32 * pretmp.37_299 + D.2057_88;
if (nmz.1_3 2)
goto bb 6;
else
goto bb 9;
# SUCC: 6 [50.0%] (true,exec) 9 [50.0%] (false,exec)
# BLOCK 6 freq:1400
# PRED: 5 [50.0%] (true,exec)
...
# SUCC: 7 [100.0%] (fallthru,exec)
# BLOCK 7 freq:1
# PRED: 6 [100.0%] (fallthru,exec) 7 [86.0%] (dfs_back,false,exec)
# prephitmp.35_321 = PHI prephitmp.35_32(6), prephitmp.35_106(7)
# prephitmp.35_322 = PHI prephitmp.35_59(6), prephitmp.35_113(7)
# prephitmp.42_325 = PHI prephitmp.42_77(6), prephitmp.42_133(7)
# prephitmp.42_326 = PHI prephitmp.42_95(6), prephitmp.42_152(7)
# prephitmp.35_229 = PHI prephitmp.35_32(6), prephitmp.35_203(7)
# prephitmp.35_225 = PHI prephitmp.35_59(6), prephitmp.35_113(7)
# ivtmp.56_220 = PHI ivtmp.56_219(6), ivtmp.56_227(7)
# ivtmp.62_218 = PHI ivtmp.62_290(6), ivtmp.62_217(7)
D.2067_105 = prephitmp.35_59 * prephitmp.35_322;
D.2191_94 = -D.2067_105;
prephitmp.35_106 = prephitmp.35_32 * prephitmp.35_321 + D.2191_94;
D.2070_112 = prephitmp.35_32 * prephitmp.35_225;
prephitmp.35_113 = prephitmp.35_59 * prephitmp.35_229 + D.2070_112;
ivtmp.56_227 = ivtmp.56_220 + 8;
D.2155_289 = (void *) ivtmp.56_227;
D.2075_120 = MEM[base: D.2155_289, offset: 0B];
D.2078_124 = prephitmp.35_106 * D.2075_120 + prephitmp.42_325;
ivtmp.62_217 = ivtmp.62_218 + 8;
D.2156_283 = (void *) ivtmp.62_217;
D.2079_130 = MEM[base: D.2156_283, offset: 0B];
prephitmp.42_133 = prephitmp.35_113 * D.2079_130 + D.2078_124;
D.2192_132 = -prephitmp.35_113;
D.2084_143 = D.2192_132 * D.2075_120 + prephitmp.42_326;
prephitmp.42_152 = prephitmp.35_106 * D.2079_130 + D.2084_143;
prephitmp.35_203 = prephitmp.35_106;
if (ivtmp.56_227 == D.2161_30)
goto bb 8;
else
goto bb 7;
# SUCC: 8 [14.0%] (true,exec) 7 [86.0%] (dfs_back,false,exec)
# BLOCK 8 freq:1400
# PRED: 7 [14.0%] (true,exec)
...
# SUCC: 9 [100.0%] (fallthru,exec)
# BLOCK 9 freq:2800
# PRED: 5 [50.0%] (false,exec) 8 [100.0%] (fallthru,exec)
...
# prephitmp.35_223 = PHI prephitmp.35_32(5), prephitmp.35_106(8)
#
[Bug c++/43674] Delegating constructors are not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43674 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 15:21:01 UTC --- A completed patch is at http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00058.html We're just waiting for copyright paperwork before putting it in.
[Bug middle-end/39976] [4.5/4.6/4.7 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976 --- Comment #38 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-11-17 15:17:53 UTC --- Created attachment 25845 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25845 Expand details dump for reduced test case Attaching the full details dump from cfgexpand for the reduced test case.
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #14 from Andreas Krebbel krebbel at gcc dot gnu.org 2011-11-17 15:23:26 UTC --- As the tests from Ian Sandoe and Dominique d'Humieres show, the Darwin/AIX regressions disappear when limiting the extract_bit_field invocation to fieldmode == BLKmode (as it was in the Experimental fix attached to the bugzilla). But I'm not sure this is the right fix. In general also the other modes need correct handling here. If the correct extraction of the source operand really depends on things like function arg padding the handling in store_bit_field is doomed to be incomplete. Richard, could you please have a look!
[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219 Sean McGovern gseanmcg at gmail dot com changed: What|Removed |Added CC||gseanmcg at gmail dot com --- Comment #13 from Sean McGovern gseanmcg at gmail dot com 2011-11-17 15:49:33 UTC --- Confirming that this also still fails on i386-pc-solaris2.10. Should probably change the bug title and the target as it fails on more than just powerpc.
[Bug web/51195] New: viewcvs can't display gcc/testsuite/gcc.dg/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51195 Bug #: 51195 Summary: viewcvs can't display gcc/testsuite/gcc.dg/ Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: gsean...@gmail.com Causes a 500 Internal Server Error.
[Bug target/45102] mm/page-writeback.c:820: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 15:56:37 UTC --- (In reply to comment #7) Was this a fix for PR45102 or PR45012 ? 45012, oops.
[Bug middle-end/50741] [4.7 Regression] remove_unused_locals causes seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741 --- Comment #8 from Michael Matz matz at gcc dot gnu.org 2011-11-17 16:04:04 UTC --- Author: matz Date: Thu Nov 17 16:03:56 2011 New Revision: 181443 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181443 Log: PR middle-end/50644 PR middle-end/50741 * tree-ssa-live.c (mark_all_vars_used_1): Recurse only for decls of current function. (remove_unused_locals): Ditto. testsuite/ * g++.dg/tree-ssa/pr50741.C: New. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr50741.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-live.c
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #20 from Michael Matz matz at gcc dot gnu.org 2011-11-17 16:04:04 UTC --- Author: matz Date: Thu Nov 17 16:03:56 2011 New Revision: 181443 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181443 Log: PR middle-end/50644 PR middle-end/50741 * tree-ssa-live.c (mark_all_vars_used_1): Recurse only for decls of current function. (remove_unused_locals): Ditto. testsuite/ * g++.dg/tree-ssa/pr50741.C: New. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr50741.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-live.c
[Bug c++/45012] Invalid ambiguity on partial class specialization matching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45012 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-17 16:03:34 UTC --- It was fixed actually by this commit . Author: jason Date: Tue Sep 27 02:13:00 2011 New Revision: 179230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179230 Log: PR c++/45102 * pt.c (tsubst_copy_and_build) [CONST_DECL]: Don't pull out constant value if we're still in a template. Added: trunk/gcc/testsuite/g++.dg/template/partial13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/50741] [4.7 Regression] remove_unused_locals causes seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Michael Matz matz at gcc dot gnu.org 2011-11-17 16:08:38 UTC --- Fixed.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #21 from Michael Matz matz at gcc dot gnu.org 2011-11-17 16:08:12 UTC --- Fixed. Sorry it took so long, but thanks for the testcase.
[Bug web/51195] viewcvs can't display gcc/testsuite/gcc.dg/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51195 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-17 16:19:15 UTC --- it happens all the time, not just with that directory. retry and it sometimes works eventually
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-11-17 16:33:59 UTC --- As the tests from Ian Sandoe and Dominique d'Humieres show, the Darwin/AIX regressions disappear when limiting the extract_bit_field invocation to fieldmode == BLKmode (as it was in the Experimental fix attached to the bugzilla). I confirm that revision 181405 breaks the tests in gcc.dg-struct-layout-1/* on powerpc-apple-darwin9 with -m32 (but not with -m64). These failures are gone if I revert r181405 and reapply the Experimental fix I have tested before.
[Bug c++/51137] [C++0x] [4.7 Regression] ICE with -std=c++0x and virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51137 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 16:35:08 UTC --- Author: jason Date: Thu Nov 17 16:34:59 2011 New Revision: 181444 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181444 Log: PR c++/51137 * class.c (build_base_path): Don't do calculation in templates. Added: trunk/gcc/testsuite/g++.dg/template/virtual2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug web/51195] viewcvs can't display gcc/testsuite/gcc.dg/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51195 --- Comment #2 from Sean McGovern gseanmcg at gmail dot com 2011-11-17 16:37:59 UTC --- Wondering if it's the same issue as http://viewvc.tigris.org/issues/show_bug.cgi?id=454 -- if so it's been fixed in viewvc 1.1.12 which was just released 2 weeks ago.
[Bug c++/51196] New: FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51196 Bug #: 51196 Summary: FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: greta.yo...@arm.com CC: ja...@redhat.com, paolo.carl...@oracle.com Target: arm-none-eabi The warnings for variable pmf are not produced as expected in this test. The test was introduced by a patch for PR44277. FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C (test for warnings, line 66) FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C (test for warnings, line 78) FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C (test for warnings, line 90) FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C (test for warnings, line 102) FAIL: g++.dg/warn/Wzero-as-null-pointer-constant-1.C -std=gnu++98 (test for warnings, line 53) FAIL: g++.dg/warn/Wzero-as-null-pointer-constant-1.C -std=gnu++98 (test for warnings, line 65) FAIL: g++.dg/warn/Wzero-as-null-pointer-constant-1.C -std=gnu++98 (test for warnings, line 77) FAIL: g++.dg/warn/Wzero-as-null-pointer-constant-1.C -std=gnu++98 (test for warnings, line 89) FAIL: g++.dg/warn/Wzero-as-null-pointer-constant-1.C -std=gnu++11 (test for warnings, line 53) FAIL: g++.dg/warn/Wzero-as-null-pointer-constant-1.C -std=gnu++11 (test for warnings, line 65) FAIL: g++.dg/warn/Wzero-as-null-pointer-constant-1.C -std=gnu++11 (test for warnings, line 77) FAIL: g++.dg/warn/Wzero-as-null-pointer-constant-1.C -std=gnu++11 (test for warnings, line 89) Target: arm-none-eabi Configured with: --with-cpu=cortex-a9 --with-float=softfp --with-fpu=neon --enable-checking=release --disable-gdbtk --disable-werror --disable-tui --disable-rda --disable-sid --disable-utils --disable-lto --disable-lto --disable-werror --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran --with-newlib Thread model: single gcc version 4.7.0 2007 (experimental) (GCC)
[Bug middle-end/39976] [4.5/4.6/4.7 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #39 from Michael Matz matz at gcc dot gnu.org 2011-11-17 16:56:10 UTC --- Actually the second (redundant) PHI node is introduced in lim1 for me. Which makes sense as the loop-invarant load and store from/to cikve (and crkveuk) are optimized. It's just that the values would have been available already in one PHI node, but lim isn't setup to avoid this redundancy. We have plenty of passes after lim1 that could be enabled to remove this redundancy. Unfortunately right now only PRE does. Even scheduling a PRE pass (e.g. right before 2nd pass_dominator) doesn't fully help this problem, because then we're left with this BB7: # prephitmp.35_361 = PHI prephitmp.35_39(6), prephitmp.35_125(7) # prephitmp.35_362 = PHI prephitmp.35_72(6), prephitmp.35_132(7) # prephitmp.42_366 = PHI prephitmp.42_93(6), prephitmp.42_156(7) # prephitmp.42_367 = PHI prephitmp.42_114(6), prephitmp.42_179(7) # ivtmp.58_257 = PHI ivtmp.58_256(6), ivtmp.58_264(7) D.3099_121 = prephitmp.35_361 * prephitmp.35_39; D.3101_124 = prephitmp.35_362 * prephitmp.35_72; prephitmp.35_125 = D.3099_121 - D.3101_124; --- (1) D.3103_128 = prephitmp.35_361 * prephitmp.35_72; --- (2) No redundant PHI nodes anymore, but still _125 can't be coalesced with _361 (to avoid a backedge copy), because the setting of _125 at (1) conflicts with the use of _361 at (2). Swapping both instructions (or moving (1) down, or (2) up) would alleviate this last problem. Removing the redundant PHI node seems to be a classic lookup problem, not so much a propagation problem. Hence I think it would best fit into dom, for now.
[Bug c++/51137] [C++0x] [4.7 Regression] ICE with -std=c++0x and virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51137 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 17:05:27 UTC --- Fixed.
[Bug rtl-optimization/50663] conditional propagation missed in cprop.c pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50663 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-17 17:11:30 UTC --- Author: ebotcazou Date: Thu Nov 17 17:11:16 2011 New Revision: 181446 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181446 Log: PR rtl-optimization/50663 * cprop.c (implicit_set_indexes): New global variable. (insert_set_in_table): Add additional parameter and record implicit set information. (hash_scan_set): Add additional parameter and pass it to above. (hash_scan_insn): Pass false to hash_scan_set. (compute_hash_table_work): Pass true to hash_scan_set. (compute_cprop_data): Add implicit set to AVIN of block which the implicit set is recorded for. (one_cprop_pass): Handle implicit_set_indexes array. Modified: trunk/gcc/ChangeLog trunk/gcc/cprop.c
[Bug rtl-optimization/50663] conditional propagation missed in cprop.c pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50663 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-17 17:14:39 UTC --- Patch installed.
[Bug tree-optimization/51118] [4.7 Regression] ICE: tree check: expected tree that contains ‘typed’ structure, have ‘block’ in fold_checksum_tree, at fold-const.c:14160
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51118 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2011-11-17 17:21:29 UTC --- The patch: --cut here-- Index: fold-const.c === --- fold-const.c(revision 181443) +++ fold-const.c(working copy) @@ -14157,7 +14157,8 @@ } } md5_process_bytes (expr, tree_size (expr), ctx); - fold_checksum_tree (TREE_TYPE (expr), ctx, ht); + if (TREE_CODE_CLASS (code) == tcc_type) +fold_checksum_tree (TREE_TYPE (expr), ctx, ht); if (TREE_CODE_CLASS (code) != tcc_type TREE_CODE_CLASS (code) != tcc_declaration code != TREE_LIST --cut here--
[Bug c++/51194] ICE about template aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51194
--- Comment #1 from dodji at seketeli dot org dodji at seketeli dot org
2011-11-17 17:33:28 UTC ---
I could not reproduce the ICE with svn trunk revision r181378. Here is
what I get:
$ cat -n test.cc
1#include boost/mpl/and.hpp
2#include boost/type_traits/is_same.hpp
3
4template bool, class T = void
5enable_if_c
6{
7typedef T type;
8};
9template class T
10enable_if_cfalse, T
11{ };
12
13template class Cond, class T = void
14using enable_if = enable_if_cCond::value, T;
15
16template template class... class... Conds
17struct condition_and
18{
19template class... Types
20using enable = enable_ifboost::mpl::and_CondsTypes...;
21};
22
23template class T, class U = T
24using Test = typename condition_and
25
26// For any two parameters meta-functions, same error occurs.
27boost::is_same
28, boost::is_same
29, boost::is_same
30::template enableT, U; // here
$ g++ -std=c++0x test.cc
test.cc:5:1: erreur: ‘enable_if_c’ does not name a type
test.cc:10:1: erreur: ‘enable_if_c’ does not name a type
test.cc:14:19: erreur: expected type-specifier before ‘enable_if_c’
test.cc:14:19: erreur: expected ‘;’ before ‘enable_if_c’
test.cc:14:19: erreur: ‘enable_if_c’ does not name a type
test.cc:14:19: erreur: mismatched argument pack lengths while expanding
‘CondsTypes’
$
Note that the code is not valid.
If you are still getting an ICE, please provide the pre-processed output
(using the option -save-temps, for instance) so that I can be sure to
use a similar environment as the one you used.
Thanks.
[Bug c++/51196] FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51196 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-17 17:33:43 UTC --- That's a pity, but personally frankly I don't think I will be able to seriously debug for this target in the near future. Or maybe Jason has something to suggest. Otherwise I propose to xfail on arm, for 4.7.
[Bug c++/51191] [C++0x] SEGV on deducing template aliases with non-template alias declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51191 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-17 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-17 17:40:02 UTC --- --- Comment #18 from Iain Sandoe iains at gcc dot gnu.org 2011-11-15 09:34:00 UTC --- (In reply to comment #16) --- Comment #15 from Iain Sandoe iains at gcc dot gnu.org 2011-11-14 08:47:16 UTC --- Created attachment 25814 [details] -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25814 adjustment to final.c (just a heads up) although not a bootstrap issue, this revision also caused a fair number of regressions at m64 on i686/powerpc-darwin9. This is where the m32 target has an m64 multilib. I am testing the patch on *-darwin9 and x86-64-darwin10. The patch fixes those particular fails for me on *-darwin9, if it works for you then should it be posted - or does Jason want to amend? Indeed: the patch is still necessary to get sort-of decent testsuite results on i386-pc-solaris2.1[01]. Rainer
[Bug c++/51196] FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51196 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 17:44:54 UTC --- (In reply to comment #1) I don't think I will be able to seriously debug for this target in the near future. It's easy to build a cross-compiler for compile-time tests like this. Just .../configure --target arm-none-eabi --enable-languages=c++ make all-gcc should get as far as building cc1plus, which is all you need to debug most PRs.
[Bug tree-optimization/51118] [4.7 Regression] ICE: tree check: expected tree that contains ‘typed’ structure, have ‘block’ in fold_checksum_tree, at fold-const.c:14160
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51118 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2011-11-17 17:50:44 UTC --- Better patch: --cut here-- Index: fold-const.c === --- fold-const.c(revision 181443) +++ fold-const.c(working copy) @@ -14157,7 +14157,8 @@ } } md5_process_bytes (expr, tree_size (expr), ctx); - fold_checksum_tree (TREE_TYPE (expr), ctx, ht); + if (CODE_CONTAINS_STRUCT (code, TS_TYPED)) +fold_checksum_tree (TREE_TYPE (expr), ctx, ht); if (TREE_CODE_CLASS (code) != tcc_type TREE_CODE_CLASS (code) != tcc_declaration code != TREE_LIST --cut here--
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094 --- Comment #20 from Iain Sandoe iains at gcc dot gnu.org 2011-11-17 17:50:09 UTC --- (In reply to comment #19) --- Comment #18 from Iain Sandoe iains at gcc dot gnu.org 2011-11-15 09:34:00 UTC --- (In reply to comment #16) --- Comment #15 from Iain Sandoe iains at gcc dot gnu.org 2011-11-14 08:47:16 UTC --- Created attachment 25814 [details] -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25814 adjustment to final.c (just a heads up) although not a bootstrap issue, this revision also caused a fair number of regressions at m64 on i686/powerpc-darwin9. This is where the m32 target has an m64 multilib. I am testing the patch on *-darwin9 and x86-64-darwin10. The patch fixes those particular fails for me on *-darwin9, if it works for you then should it be posted - or does Jason want to amend? Indeed: the patch is still necessary to get sort-of decent testsuite results on i386-pc-solaris2.1[01]. I think the patch needs a tweak - - the case of largest negative int in the case where HOST_WIDE_INT is long long. I wonder if it's simply OK to bail to the original printf for that corner-case, or whether it's worth handling specially.
[Bug c++/50306] ambiguous templated conversion operators accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50306 --- Comment #1 from Marc-Andre Laperle malaperle at omnialabs dot net 2011-11-17 18:00:27 UTC --- I have never worked with the GCC source code before, any pointers to where I should start to look to fix this issue? Thanks!
[Bug c++/51191] [C++0x] SEGV on deducing template aliases with non-template alias declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51191 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added CC|dodji at gcc dot gnu.org| --- Comment #1 from Dodji Seketeli dodji at gcc dot gnu.org 2011-11-17 18:02:24 UTC --- Confirmed.
[Bug other/51174] AIX unexpected error_mark node in new TM tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51174 --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-11-17 18:06:20 UTC --- The rs6000.c failure looks like rs6000_xcoff_section_type_flags() should deal with decl == NULL. But the other similar failure is in trans-mem.c: (gdb) where #0 internal_error ( How can I reproduce this additional error in trans-mem.c? David, after using your patch handling NULL in rs6000_xcoff_section_type_flags(), I can cc1/cc1plus all the aforementioned failures in this PR correctly (with a cross to powerpc-ibm-aix5.3.0.0). Is this similar failure you mention something else? Is there a testcase?
[Bug c++/51196] FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51196 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-17 18:14:16 UTC --- I'll see what I can do... At the moment really I have no idea why for this target only we have a different behavior.
[Bug c++/50306] ambiguous templated conversion operators accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50306 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-11-17 18:27:00 UTC --- (In reply to comment #1) I have never worked with the GCC source code before, any pointers to where I should start to look to fix this issue? Thanks! http://gcc.gnu.org/wiki/DebuggingGCC You could put a breakpoint for the second testcase in error(). Find out why the error triggers, and then find out what is the difference with the first testcase. In any case, the relevant code is in gcc/cp/. I hope you don't get scared by the looks. It ain't pretty. However, this seems to be fixed in trunk (at least revision 180166): manuel@gcc12:~$ ~/trunk/180166/build/gcc/cc1plus pr50306.cc void func(SmartPtrA) int main() pr50306.cc:15:9: error: conversion from ‘SmartPtrB’ to ‘SmartPtrA’ is ambiguous pr50306.cc:14:15: note: candidates are: pr50306.cc:7:3: note: SmartPtrT::operator SmartPtrA() const [with T = B] pr50306.cc:6:3: note: SmartPtrT::operator const SmartPtrA() const [with T = B] pr50306.cc:10:6: error: initializing argument 1 of ‘void func(SmartPtrA)’ Maybe you should try 4.6.2?
[Bug other/51174] AIX unexpected error_mark node in new TM tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51174 --- Comment #8 from David Edelsohn dje at gcc dot gnu.org 2011-11-17 18:37:36 UTC --- How can I reproduce this additional error in trans-mem.c? I believe that you need to use a target that does not define HAVE_COMDAT_GROUP. Other targets do not fill in DECL_COMDAT_GROUP, but do use DECL_COMDAT. The rest of GCC blindly copies around NULLs and the value never is used. The TM code assumes that all targets with DECL_COMDAT fill in the DECL_COMDAT_GROUP node with a specific content and format that it should mangle. My proposed patch, which appears to work, reverts to copying NULLs if DECL_COMDAT_GROUP is NULL. One could test if (DECL_COMDAT (new_decl) HAVE_COMDAT_GRUOP) and that probably is more consistent with the rest of varasm.c After using your patch handling NULL in rs6000_xcoff_section_type_flags(), I can cc1/cc1plus all the aforementioned failures in this PR correctly (with a cross to powerpc-ibm-aix5.3.0.0). I do not understand what you are asking. You can reproduce the failures or you cannot? My rs6000.c patch fixes some of the failures. The varasm.c patch is necessary to fix the rest of the failures -- the ones in trans-mem.c. Is this similar failure you mention something else? Is there a testcase? Is what similar? When this is broken, the existing TM testcases fail all over the place, so I don't think there is a need for additional testcases.
[Bug other/51174] AIX unexpected error_mark node in new TM tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51174 --- Comment #9 from Aldy Hernandez aldyh at redhat dot com 2011-11-17 19:04:43 UTC --- I do not understand what you are asking. You can reproduce the failures or you cannot? My rs6000.c patch fixes some of the failures. The varasm.c patch is necessary to fix the rest of the failures -- the ones in trans-mem.c. Oh sorry, I cannot reproduce the failures after your NULL handling patch went into mainline. Which failures are you still seeing, after your patch?
[Bug other/51174] AIX unexpected error_mark node in new TM tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51174 --- Comment #10 from David Edelsohn dje at gcc dot gnu.org 2011-11-17 19:23:11 UTC --- My patch did not fix the testsuite failures in trans-mem.c:tm_mangle() where ipa_tm_create_version() and ipa_tm_create_version_alias() call tm_mangle() with DECL_COMDAT_GROUP field NULL. tm_mangle() tries to reference the field. As I wrote in comment 6, I suggest that ipa_tm_create_version() and ipa_tm_create_version_alias() only invoke tm_mangle if the platform defines HAVE_COMDAT_GROUP, otherwise copy the NULL value like the rest of GCC: /* Perform the same remapping to the comdat group. */ if (DECL_COMDAT (new_decl) HAVE_COMDAT_GROUP) DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl)); else DECL_COMDAT_GROUP (new_decl) = DECL_COMDAT_GROUP (old_decl); One could have tm_mangle() check for NULL, but I think it is reasonable for it to expect a non-NULL argument and it is used in other mangling situations. The problem, IMHO, is calling tm_mangle() with DECL_COMDAT_GROUP argument assuming that field of the decl is non-NULL.
[Bug middle-end/51182] [ipa-iterations] running multiple passes of early IPA on a file produces different code when it shouldn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51182 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-17 19:25:56 UTC --- This kind of changes are not interesting (and I doubt anyone will investigate). Interesting are code changes that make a difference in performance. Btw, the code path with the most recent patch for one and two early iterations are not the same (due to the separation into different IPA phases). This alone probably explains the (spurious) differences you see. To eliminate them make sure we go the three IPA phases path even with just one iteration.
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 19:32:13 UTC --- It looks like the sorted fields code in lookup_field_1 needs to handle using_decl like the unsorted fields code does. I think this will also fix PR51141 (instead of the patch you already posted).
[Bug fortran/51197] New: [4.7 Regression] Backtrace information less useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197 Bug #: 51197 Summary: [4.7 Regression] Backtrace information less useful Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: anl...@gmx.de Hi, the backtrace facility is less useful with 4.7 than with 4.6. Example: program backtrace implicit none print *, foo (0.0) contains function foo (x) real, intent (in) :: x real :: foo foo = 1 / x end function foo end program backtrace gfortran 4.7 (svn revision 181390, arch is i686-pc-linux-gnu): % /opt/gcc/4.7/bin/gfortran -g -fbacktrace gfcbug113.f90 -ffpe-trap=zero,overflow,invalid -static-libgfortran % ./a.out A fatal error occurred! Backtrace for this error: #0 0x80588BF in _gfortrani_show_backtrace at backtrace.c:261 #1 0x80494B7 in _gfortrani_backtrace_handler at compile_options.c:46 #2 0xE3FF #3 0x80493B3 in foo at gfcbug113.f90:8 #4 0x804940B in backtrace at gfcbug113.f90:3 Floating point exception (core dumped) With gfortran 4.6: Program received signal 8 (SIGFPE): Floating-point exception. Backtrace for this error: + [0xe400] + function foo (0x80494B3) at line 8 of file gfcbug113.f90 + function backtrace (0x804950C) at line 3 of file gfcbug113.f90 + /lib/libc.so.6(__libc_start_main+0xe5) [0xb7641705] Same for SIGSEGV etc. It would be nice if I got back the old behaviour where the actual error is displayed. I'm not always good at guessing... Harald
[Bug fortran/51197] [4.7 Regression] Backtrace information less useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-11-17 20:04:07 UTC --- (In reply to comment #0) Hi, the backtrace facility is less useful with 4.7 than with 4.6. Example: program backtrace implicit none print *, foo (0.0) contains function foo (x) real, intent (in) :: x real :: foo foo = 1 / x end function foo end program backtrace gfortran 4.7 (svn revision 181390, arch is i686-pc-linux-gnu): % /opt/gcc/4.7/bin/gfortran -g -fbacktrace gfcbug113.f90 -ffpe-trap=zero,overflow,invalid -static-libgfortran % ./a.out A fatal error occurred! Backtrace for this error: #0 0x80588BF in _gfortrani_show_backtrace at backtrace.c:261 #1 0x80494B7 in _gfortrani_backtrace_handler at compile_options.c:46 #2 0xE3FF #3 0x80493B3 in foo at gfcbug113.f90:8 #4 0x804940B in backtrace at gfcbug113.f90:3 Floating point exception (core dumped) With gfortran 4.6: Program received signal 8 (SIGFPE): Floating-point exception. Backtrace for this error: + [0xe400] + function foo (0x80494B3) at line 8 of file gfcbug113.f90 + function backtrace (0x804950C) at line 3 of file gfcbug113.f90 + /lib/libc.so.6(__libc_start_main+0xe5) [0xb7641705] Same for SIGSEGV etc. It would be nice if I got back the old behaviour where the actual error is displayed. I'm not always good at guessing... What exactly do you want? In 4.7, the last line of the backtrace is Floating point exception (core dumped). That matches the first line from 4.6 Program received signal 8 (SIGFPE): Floating-point exception. In 4.7, the line #3 0x80493B3 in foo at gfcbug113.f90:8 contains all of the information from 4.6 + function foo (0x80494B3) at line 8 of file gfcbug113.f90 -- steve
[Bug fortran/51197] [4.7 Regression] Backtrace information less useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197 --- Comment #2 from Harald Anlauf anlauf at gmx dot de 2011-11-17 20:17:32 UTC --- (In reply to comment #1) A fatal error occurred! Backtrace for this error: #0 0x80588BF in _gfortrani_show_backtrace at backtrace.c:261 #1 0x80494B7 in _gfortrani_backtrace_handler at compile_options.c:46 #2 0xE3FF #3 0x80493B3 in foo at gfcbug113.f90:8 #4 0x804940B in backtrace at gfcbug113.f90:3 Floating point exception (core dumped) With gfortran 4.6: Program received signal 8 (SIGFPE): Floating-point exception. Backtrace for this error: + [0xe400] + function foo (0x80494B3) at line 8 of file gfcbug113.f90 + function backtrace (0x804950C) at line 3 of file gfcbug113.f90 + /lib/libc.so.6(__libc_start_main+0xe5) [0xb7641705] What exactly do you want? In 4.7, the last line of the backtrace is Floating point exception (core dumped). That matches the first line from 4.6 Program received signal 8 (SIGFPE): Floating-point exception. In 4.7, the line #3 0x80493B3 in foo at gfcbug113.f90:8 contains all of the information from 4.6 + function foo (0x80494B3) at line 8 of file gfcbug113.f90 Well, thanks for pointing out I was not precise enough. While reducing the problem, I forgot that the difference lies in where the line Floating point exception (core dumped) ends up. Try redirecting stderr, you'll see that in the first case (bash on linux) this line does *not* go to stderr, while in the second case (4.6) it does. When running programs in a shell with output redirected, the information will end up in different places. So it would be nice to actually write the SIG* information also to stderr. Harald
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188
--- Comment #6 from fabien at gcc dot gnu.org 2011-11-17 20:24:56 UTC ---
(In reply to comment #5)
It looks like the sorted fields code in lookup_field_1 needs to handle
using_decl like the unsorted fields code does. I think this will also fix
PR51141 (instead of the patch you already posted).
Thanks, I'm current testing the below patch:
Index: class.c
===
--- class.c(revision 181436)
+++ class.c(working copy)
@@ -6000,7 +6000,7 @@ finish_struct_1 (tree t)
hierarchy), and we want this failure to occur quickly. */
n_fields = count_fields (TYPE_FIELDS (t));
- if (n_fields 7)
+ if (n_fields 0)
{
struct sorted_fields_type *field_vec = sorted_fields_type_new
(n_fields);
add_fields_to_record_type (TYPE_FIELDS (t), field_vec, 0);
Index: search.c
===
--- search.c(revision 181436)
+++ search.c(working copy)
@@ -424,8 +424,9 @@ lookup_field_1 (tree type, tree name, bo
if (want_type)
{
do
-field = fields[i--];
+field = strip_using_decl (fields[i--]);
while (i = lo DECL_NAME (fields[i]) == name);
+
if (TREE_CODE (field) != TYPE_DECL
!DECL_TYPE_TEMPLATE_P (field))
field = NULL_TREE;
@@ -433,7 +434,7 @@ lookup_field_1 (tree type, tree name, bo
else
{
do
-field = fields[i++];
+field = strip_using_decl (fields[i++]);
while (i hi DECL_NAME (fields[i]) == name);
}
return field;
[Bug libstdc++/51181] [4.7 regression] libstdc++.so __sync_sub_and_fetch_4 linkage error causing many test suite failures on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51181 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-17 CC||danglin at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-11-17 20:54:31 UTC --- Also seen on hppa64-hp-hpux11.11. There is no hardware or kernel support for compare and swap as far as I know on HP PARISC. Thus the best that can be done is a mutex implementation.
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #7 from fabien at gcc dot gnu.org 2011-11-17 20:57:16 UTC --- FYI, it fixes the following PRs: c++/51190, c++/51189, c++/51188, c++/51152, c++/51141.
[Bug c++/51190] [4.7 Regression] 'using' causing trouble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51190 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #1 from fabien at gcc dot gnu.org 2011-11-17 20:58:46 UTC --- Marked as duplicate. *** This bug has been marked as a duplicate of bug 51188 ***
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 fabien at gcc dot gnu.org changed: What|Removed |Added CC||reichelt at gcc dot gnu.org --- Comment #8 from fabien at gcc dot gnu.org 2011-11-17 20:58:46 UTC --- *** Bug 51190 has been marked as a duplicate of this bug. ***
[Bug c++/51152] [4.7 Regression] error: X has no member named Y on code that seems valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51152 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #2 from fabien at gcc dot gnu.org 2011-11-17 21:00:17 UTC --- Marked as duplicate. *** This bug has been marked as a duplicate of bug 51188 ***
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #9 from fabien at gcc dot gnu.org 2011-11-17 20:59:37 UTC --- *** Bug 51189 has been marked as a duplicate of this bug. ***
[Bug c++/51189] [4.7 Regression] ICE in force_decl_die, at dwarf2out.c:19261
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51189 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #1 from fabien at gcc dot gnu.org 2011-11-17 20:59:37 UTC --- Marked as duplicate. *** This bug has been marked as a duplicate of bug 51188 ***
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 fabien at gcc dot gnu.org changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #11 from fabien at gcc dot gnu.org 2011-11-17 21:01:06 UTC --- *** Bug 51141 has been marked as a duplicate of this bug. ***
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 21:03:31 UTC --- (In reply to comment #6) do -field = fields[i--]; +field = strip_using_decl (fields[i--]); while (i = lo DECL_NAME (fields[i]) == name); Let's wait and strip_using_decl after the loop (i.e. at the return statement), since a USING_DECL has the same name. We also need to check is_overloaded_decl.
[Bug c++/51186] declaring main() with auto but without --std=c++11 gives inconsistent error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51186 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 21:05:00 UTC --- Fixed to say x.C:3:14: error: trailing return type only available with -std=c++11 or -std=gnu++11
[Bug c++/51186] declaring main() with auto but without --std=c++11 gives inconsistent error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51186 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-11-17 21:00:34 UTC --- Author: jason Date: Thu Nov 17 21:00:30 2011 New Revision: 181455 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181455 Log: PR c++/51186 * decl.c (grokdeclarator): Improve C++98 trailing return diagnostic. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto27.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/trailing2.C
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 fabien at gcc dot gnu.org changed: What|Removed |Added CC||cas43 at cs dot ||stanford.edu --- Comment #10 from fabien at gcc dot gnu.org 2011-11-17 21:00:17 UTC --- *** Bug 51152 has been marked as a duplicate of this bug. ***
[Bug c++/51141] [4.7 regression] rev181359 causes Chromium build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51141 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #3 from fabien at gcc dot gnu.org 2011-11-17 21:01:06 UTC --- Marked as duplicate. *** This bug has been marked as a duplicate of bug 51188 ***
[Bug libstdc++/51181] [4.7 regression] libstdc++.so __sync_sub_and_fetch_4 linkage error causing many test suite failures on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51181 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-11-17 21:06:54 UTC --- FWIW, classic m68k has compare-and-swap, while ColdFire Linux uses kernel helpers (available in both vDSO and syscall forms; the syscall forms are probably rather easier to use from libgcc than the vDSO is).
[Bug libstdc++/51181] [4.7 regression] libstdc++.so __sync_sub_and_fetch_4 linkage error causing many test suite failures on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51181 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-17 21:10:25 UTC --- I would recommend figuring out which specific patch part of the recent TM / C++ atomic work is at the root of the problem and thus CC-ing either Aldy or Andrew or Rth about it
[Bug middle-end/51144] r181279 possibly miscompilation of genmddeps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51144 --- Comment #5 from Steve Ellcey sje at gcc dot gnu.org 2011-11-17 21:22:15 UTC --- Author: sje Date: Thu Nov 17 21:22:11 2011 New Revision: 181457 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181457 Log: 2011-11-17 Steve Ellcey s...@cup.hp.com PR middle-end/51144 * output.h (fprint_w): Remove. * final.c (fprint_w): Remove. (output_addr_const): Change fprint_w back to fprintf. Modified: trunk/gcc/ChangeLog trunk/gcc/final.c trunk/gcc/output.h
[Bug c++/51145] [C++11][DR 1131] Alias template in elaborated-type-specifier accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51145 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-17 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug objc++/51159] build failure with --enable-build-with-cxx in gcc-4.6.2/gcc/objc/objc-next-runtime-abi-02.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51159 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-17 21:36:17 UTC --- (In reply to comment #2) --enable-build-with-cxx is an officially supported build option, so it should work reliably in releases. But this is not a regression so closing as fixed for 4.7.0.
[Bug objc++/51159] build failure with --enable-build-with-cxx in gcc-4.6.2/gcc/objc/objc-next-runtime-abi-02.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51159 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-17 21:37:12 UTC --- (In reply to comment #2) --enable-build-with-cxx is an officially supported build option, so it should work reliably in releases. But this is not a regression so closing as fixed for 4.7.0. And it was not really a supported build option, it was an experimental option.
[Bug libstdc++/51181] [4.7 regression] libstdc++.so __sync_sub_and_fetch_4 linkage error causing many test suite failures on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51181 --- Comment #4 from dave.anglin at bell dot net 2011-11-17 21:46:40 UTC --- Symbol is from libsupc++/eh_tm.cc.
[Bug other/51011] FAIL: gcc.dg/atomic-generic.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51011 --- Comment #8 from Andrew Macleod amacleod at redhat dot com 2011-11-17 21:49:44 UTC --- Created attachment 25846 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25846 potential second patch What I dont get is why HP PARISC doesn't have this same problem with __sync. __atomic isnt really used anywhere that __sync wasn't before, it simply supplements it. or is suppose to. If __sync doesn't have any issues, then the first patch when applied should resolve the HP PARISC issues, it should make all the __atomic library calls be CODE labels. If there is actually a __sync issue, the second patch does the same for both __atomic and __sync. I believe the secondary failures you have run across with __atomic_exchange_1 should be gone due to the implementation of __atomic_test_and_set and __atomic_clear which was checked in on Nov 10, but you'll have to let me know.
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188
--- Comment #13 from fabien at gcc dot gnu.org 2011-11-17 21:53:15 UTC ---
(In reply to comment #12)
Let's wait and strip_using_decl after the loop (i.e. at the return statement),
since a USING_DECL has the same name. We also need to check
is_overloaded_decl.
Like that ?
Index: search.c
===
--- search.c(revision 181386)
+++ search.c(working copy)
@@ -436,6 +436,14 @@ lookup_field_1 (tree type, tree name, bo
field = fields[i++];
while (i hi DECL_NAME (fields[i]) == name);
}
+
+ if (field)
+{
+ field = strip_using_decl (field);
+ if (is_overloaded_fn (field))
+field = NULL_TREE;
+}
+
return field;
}
}
[Bug c/19820] How to get results from a V2SF ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19820 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|pinskia at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-17 21:54:48 UTC --- This is now fixed in 4.7.0, you can do [0] for C (not for C++).
[Bug middle-end/30142] [meta-bug] invalid gimple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30142 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-17 21:58:55 UTC --- This has now been fixed so close it as such.
