[Bug c++/61577] New: [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Bug ID: 61577 Summary: [4.9.0] can't compile on hp-ux v3 ia64 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: FBergemann at web dot de Target: HP-UX v3 ia64 I cannot compile gcc-4.9.0 on a hp-ux B.11.31 (v3) ia64 machine. I used following component: > ls -tlr total 40 drwxr-xr-x 18 frank os_int 8192 Jun 17 09:40 binutils-2.24 drwxr-xr-x 16 frank os_int 8192 Jun 17 15:31 gmp-6.0.0 drwxr-xr-x 10 frank os_int 8192 Jun 17 15:34 mpfr-3.1.2 drwxr-xr-x 7 frank os_int 8192 Jun 17 15:35 mpc-1.0.2 drwxr-xr-x 35 frank os_int 8192 Jun 21 09:31 gcc-4.9.0 +) binutis had been compiled separately first into a /gs/frank/hp-ux/gcc-4.9.0/ dir) +) gmp, mpfr and mpc source directories had been linked below gcc directory. +) $PATH had been set to select /usr/local/gcc-4.7.2 for compilation (compiler provided by HP) +) compilation is for 32bit +) ../configure --prefix=/gs/frank/hp-ux/gcc-4.9.0 --enable-languages=c,c++ --with-gnu-as --with-as=/gs/frank/hp-ux/gcc-4.9.0/bin/as --without-gnu-ld --disable-nls --disable-shared > cat configure.out.fbe checking build system type... ia64-hp-hpux11.31 checking host system type... ia64-hp-hpux11.31 checking target system type... ia64-hp-hpux11.31 checking for a BSD-compatible install... /usr/local/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/sed checking for gawk... gawk checking for libatomic support... yes checking for libcilkrts support... no checking for libitm support... no checking for libsanitizer support... no checking for libvtv support... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for gnatbind... no checking for gnatmake... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs checking for version 0.10 of ISL... no checking for version 0.11 of ISL... no checking for version 0.12 of ISL... no *** This configuration is not supported in the following subdirectories: target-libcilkrts target-libitm target-libsanitizer target-libvtv gnattools target-libada target-libgfortran target-libgo target-libffi target-libbacktrace target-zlib target-libjava target-libobjc target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... no checking for ar... ar checking for as... as checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... objcopy checking for objdump... objdump checking for readelf... readelf checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... no checking for gccgo... no checking for ar... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ar checking for as... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/nm checking for objdump... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/objdump checking for ranlib... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ranlib checking for readelf... no checking for readelf... readelf checking for strip... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/strip checking for windres... no checking for windres... no checking for windmc... no checking for windmc... no checking where to find the target ar... pre-installed in /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin checking where to find the target as... pre-installed in /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bi
[Bug target/61563] better 387 code for float x == (int)x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61563 --- Comment #3 from Uroš Bizjak --- (In reply to Jay Foad from comment #0) > I think the x == (int)x pattern is fairly common, and it would be nice if > GCC generated better 387 code for it. Please note that -msse3 will generate fistt insn that doesn't need control word changes.
[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-06-21 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Markus Trippelsdorf --- Please provide a preprocessed file, see: https://gcc.gnu.org/bugs/ .
[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 --- Comment #6 from Jürgen Reuter --- (In reply to Markus Trippelsdorf from comment #5) > Please provide a preprocessed file, see: https://gcc.gnu.org/bugs/ . Uff, I never had to do this in my 30 or so bug reports before, but I will try. As I was saying, this is not my code, so debugging for me is _really_ difficult!
[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 --- Comment #7 from Markus Trippelsdorf --- (In reply to Jürgen Reuter from comment #6) > (In reply to Markus Trippelsdorf from comment #5) > > Please provide a preprocessed file, see: https://gcc.gnu.org/bugs/ . > > Uff, I never had to do this in my 30 or so bug reports before, but I will > try. > As I was saying, this is not my code, so debugging for me is _really_ > difficult! It's as simple as adding --save-temps to the compiler invocation and posting the *.ii file here.
[Bug c++/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #1 from Frank Bergemann --- when i use --with-gnu-ld -with-ld=/usr/local/gcc-4.7.2/bin/g++ i get following error: gmake[3]: Entering directory `/tmp/FBE/gcc-4.9.0/obj3/gcc' gmake[3]: Leaving directory `/tmp/FBE/gcc-4.9.0/obj3/gcc' Checking multilib configuration for libgcc... Configuring stage 1 in ia64-hp-hpux11.31/libgcc configure: loading cache ./config.cache checking build system type... ia64-hp-hpux11.31 checking host system type... ia64-hp-hpux11.31 checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/local/bin/install -c checking for gawk... gawk checking for ia64-hp-hpux11.31-ar... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ar checking for ia64-hp-hpux11.31-lipo... lipo checking for ia64-hp-hpux11.31-nm... /tmp/FBE/gcc-4.9.0/obj3/./gcc/nm checking for ia64-hp-hpux11.31-ranlib... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ranlib checking for ia64-hp-hpux11.31-strip... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/strip checking whether ln -s works... yes checking for ia64-hp-hpux11.31-gcc... /tmp/FBE/gcc-4.9.0/obj3/./gcc/xgcc -B/tmp/FBE/gcc-4.9.0/obj3/./gcc/ -B/gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ -B/gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/lib/ -isystem /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/include -isystem /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/sys-include sendsig: useracc failed. 0xb200 0x005000 Pid 18125 was killed due to failure in writing the signal context - possible stack overflow. checking for suffix of object files... sendsig: useracc failed. 0xb200 0x005000 Pid 18130 was killed due to failure in writing the signal context - possible stack overflow. configure: error: in `/tmp/FBE/gcc-4.9.0/obj3/ia64-hp-hpux11.31/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage1-target-libgcc] Error 1 gmake[2]: Leaving directory `/tmp/FBE/gcc-4.9.0/obj3' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/FBE/gcc-4.9.0/obj3' gmake: *** [all] Error 2
[Bug c/61578] New: Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 Bug ID: 61578 Summary: Code size increase for ARM thumb compared to 4.8.x when compiling with -Os Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fredrik.hederstie...@securitas-direct.com We have problems when trying to switch from GCC 4.8.3 to GCC 4.9.0 (arm-eabi thumb1 for arm966e-s core) due to significant code size increase (1-2%). I attach our toolchain build scripts and two small example programs, though I'm not fully convinced that these examples fully catch the issue. Although the examples show increase +4.81% and +2% growth, though the examples are slightly constructed. First I suspected it was related to Bug 59535, since the code size decrease significantly when compiling without LRA (-mno-lra), though still it does not make the full picture, since still the codes size is ~1% bigger then GCC 4.8.3. We also tried with and without LTO, but it does not solve our problem either. See attached example. Build with 'make' and compare with 'make compare'. Thanks and Best Regards, /Fredrik
[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #1 from Fredrik Hederstierna --- Created attachment 32980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32980&action=edit Toolchain build script.
[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #2 from Fredrik Hederstierna --- Created attachment 32981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32981&action=edit Toolchain build script 4.9.0
[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #3 from Fredrik Hederstierna --- Created attachment 32982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32982&action=edit Makefile for examples.
[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #4 from Fredrik Hederstierna --- Created attachment 32983 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32983&action=edit Example source 1.
[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #5 from Fredrik Hederstierna --- Created attachment 32984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32984&action=edit Example source 2.
[Bug c++/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Frank Bergemann changed: What|Removed |Added Severity|blocker |major --- Comment #2 from Frank Bergemann --- Change importance. First problem, that was hit, is about the native 'ld'. Second problem could be stack size issue (however stack size used on hpux is larger than used on other reference systems). \Frank
[Bug c/61579] New: -Wwrite-strings does not behave as a warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579 Bug ID: 61579 Summary: -Wwrite-strings does not behave as a warning option Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Unlike other -W family options, -Wwrite-strings does not actually behave as a warning option but as an option that alters the language semantics. I think this inconsistency should be considered a bug and fixed. It leads to multiple issues: 1. Warning messages wrongly show as [enabled by default] rather than [-Wwrite-strings], since discarding const qualifier is enabled by default. 2. Some code which should produce a warning actually produces an error. As a trivial but stupid example, if(0)*""=0; One can of course construct non-trivial, non-stupid examples of this, particularly with the ?: operator. 3. The semantics of code using __typeof__, ?:, and now more importantly with C11, _Generic, are changed by -Wwrite-strings. As a particularly bad case, I think this could lead to the introduction of aliasing violations and undefined behavior in code that had well-defined behavior without -Wwrite-strings. Ideally the current implementation of -Wwrite-strings should be scrapped and replaced with one that actually detects particular usage that's deemed dangerous rather than changing the language semantics.
[Bug c++/61580] New: stoi function unknown on W7/Cygwin/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61580
Bug ID: 61580
Summary: stoi function unknown on W7/Cygwin/x86_64
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zosrothko at orange dot fr
Hello
The following program
$ cat stoi.cpp
#include
int main()
{
std::string s = "123";
int i = std::stoi(s);
}
does not compile on a W7/Cygwin/x86_64 platform. here the log
$ g++ -v stoi.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.3-2/src/gcc-4.8.3/configure
--srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.3-2/src/gcc-4.8.3
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --enable-shared
--enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs
--enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --libexecdir=/usr/lib
Thread model: posix
gcc version 4.8.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/cc1plus.exe -quiet -v -Dunix -idirafter
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/../include/w32api
-idirafter ../../include/w32api stoi.cpp -quiet -dumpbase stoi.cpp
-mtune=generic -march=x86-64 -auxbase stoi -version -o /tmp/ccZYgiXq.s
GNU C++ (GCC) version 4.8.3 (x86_64-pc-cygwin)
compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/include"
ignoring nonexistent directory "../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include/c++
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include/c++/x86_64-pc-cygwin
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include/c++/backward
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include-fixed
/usr/include
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/../include/w32api
End of search list.
GNU C++ (GCC) version 4.8.3 (x86_64-pc-cygwin)
compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 636b2526cba54f47bd98b825d7c95d49
stoi.cpp: In function 'int main()':
stoi.cpp:6:12: error: 'stoi' is not a member of 'std'
int i = std::stoi(s);
^
IMHO? the problem should come from the basic_string.h include where the
definition of stoi is guarded by
#if ((__cplusplus >= 201103L) && defined(_GLIBCXX_USE_C99) \
&& !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF))
and _GLIBCXX_USE_C99 is not defined
FrancisANDRE@idefix /lib/gcc/x86_64-pc-cygwin/4.8.3/include/c++/bits
$ g++ -xc++ -std=gnu++11 -dM -E - < /dev/null | sort | grep _GLIB
FrancisANDRE@idefix /lib/gcc/x86_64-pc-cygwin/4.8.3/include/c++/bits
$ g++ -xc++ -std=c++11 -dM -E - < /dev/null | sort | grep _GLIB
Rgds
[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 --- Comment #8 from Jürgen Reuter --- The .ii file is too big, you can find it here: http://desy.de/~reuter/PDF.ii Note that the headers I attached (besides of the boost headers, of course) are marked as being in /usr/local/include in the .ii file.
[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 --- Comment #9 from Markus Trippelsdorf --- (In reply to Jürgen Reuter from comment #8) > The .ii file is too big, you can find it here: > http://desy.de/~reuter/PDF.ii Thanks. I cannot reproduce the issue. It may already been fixed. To double check, please post the full compiler output with -v.
[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 --- Comment #10 from Jürgen Reuter --- $ g++ --version g++ (GCC) 4.10.0 20140613 (experimental) It's svn r211649
[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 --- Comment #11 from Markus Trippelsdorf --- (In reply to Jürgen Reuter from comment #10) > $ g++ --version > g++ (GCC) 4.10.0 20140613 (experimental) > > It's svn r211649 Sorry, I need the output from: $ g++ -v -c PDF.ii
[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
--- Comment #12 from Jürgen Reuter ---
Here it is:
g++ -v -c PDF.ii
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-apple-darwin11.4.2
Configured with: ../configure --prefix=/usr/local/ --with-gmp=/usr/local/
--with-mpfr=/usr/local/ --with-mpc=/usr/local/ --enable-languages=c,c++,fortran
--no-create --no-recursion
Thread model: posix
gcc version 4.10.0 20140613 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-v' '-c' '-shared-libgcc'
'-mtune=core2'
/usr/local/libexec/gcc/x86_64-apple-darwin11.4.2/4.10.0/cc1plus -fpreprocessed
PDF.ii -fPIC -quiet -dumpbase PDF.ii -mmacosx-version-min=10.7.4 -mtune=core2
-auxbase PDF -version -o
/var/folders/47/rlmwph0j5m1f65g8z84_d7qhgn/T//ccWSHAv9.s
GNU C++ (GCC) version 4.10.0 20140613 (experimental)
(x86_64-apple-darwin11.4.2)
compiled by GNU C version 4.10.0 20140613 (experimental), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.10.0 20140613 (experimental)
(x86_64-apple-darwin11.4.2)
compiled by GNU C version 4.10.0 20140613 (experimental), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 853e12eacaeeb3508bcef25eb74eb286
PDF.cc: In member function ‘virtual void
boost::exception_detail::error_info_injector::_ZThn24_N5boost16exception_detail19error_info_injectorINS_2io17bad_format_stringEED1Ev()’:
PDF.cc:29:1: error: unrecognizable insn:
}
^
(call_insn/j 3 2 4 (call (mem/u/c:DI (const:DI (unspec:DI [
(symbol_ref/i:DI
("_ZN5boost16exception_detail19error_info_injectorINS_2io17bad_format_stringEED1Ev")
[flags 0x1] )
] UNSPEC_GOTPCREL)) [0 S8 A8])
(const_int 0 [0])) /opt/local/include/boost/exception/exception.hpp:330
-1
(nil)
(nil))
PDF.cc:29:1: internal compiler error: in insn_default_length, at
config/i386/i386.md:1787
PDF.cc:29:1: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
[Bug target/61387] [4.10 Regression] ~900 test failures on on x86_64-apple-darwin13 for g++ with -m64 after r211089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387 Markus Trippelsdorf changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #10 from Markus Trippelsdorf --- *** Bug 61506 has been marked as a duplicate of this bug. ***
[Bug target/61506] [4.10 Regression] ICE triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 Markus Trippelsdorf changed: What|Removed |Added Target|x86_64-*-* |x86_64-apple-darwin11.4.2 Status|WAITING |RESOLVED Host||x86_64-apple-darwin11.4.2 Resolution|--- |DUPLICATE Build||x86_64-apple-darwin11.4.2 Severity|blocker |normal --- Comment #13 from Markus Trippelsdorf --- Dup of Bug 61387. *** This bug has been marked as a duplicate of bug 61387 ***
[Bug c/61579] -Wwrite-strings does not behave as a warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579 Manuel López-Ibáñez changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org, ||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- Agreed. It seems that in order to get the desired warning, the solution was to change the type and warn implicitly, rather than detect the potential cases explicitly. This is a quite ugly hack. On the other hand, I don't expect an existing GCC developer to fix this, given the long history of -Wwrite-strings. Someone new will have to step up, implement it and defend it in front of the C FE maintainers.
[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909 Alex changed: What|Removed |Added CC||alex.wolf at gmail dot com --- Comment #6 from Alex --- 3 years later and it still doesn't work... gcc version 4.8.3, installed using homebrew on OSX 10.9.3.
[Bug c++/61581] New: [C++11] Bogus error: uninitialized const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61581
Bug ID: 61581
Summary: [C++11] Bogus error: uninitialized const member
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/15789654
Fails with current trunk, and all older versions I've tried.
g++ -c t.cc -std=c++11
t.cc: In function 'void Bar()':
t.cc:9:11: error: uninitialized const member 'Foo::b'
Fn( {1} );
^
/// -- cut ---
struct Foo {
long a;
const long b;
};
void Fn(const Foo&);
void Bar() {
Fn( {1} );
}
/// -- cut ---
Removing 'const' and examining assembly shows that GCC *does* initialize 'b' to
0 (as it should).
[Bug target/45207] The -Os flag generates wrong code for ARM966e-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207 Fredrik Hederstierna changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Fredrik Hederstierna --- It seems like functions are not always 4-aligned, even if -falign-functions=4 is passed, but I see no problem with this currently. I was running thumb not-interworking code, and wrote custom ISR handler using ARM-code trampoline function, but I found a work-around.
[Bug c++/61574] Confusing .debug_line generation by -g option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61574 --- Comment #2 from jamesgua at ca dot ibm.com --- (In reply to Andrew Pinski from comment #1) > This is deconstructors. I mean why we have those line numbers "17 9 17 9 17", debugger follow the line number information and user may think the program running backward instead the incremental way. This is not intuitive.
[Bug c++/61574] Confusing .debug_line generation by -g option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61574 --- Comment #3 from Andrew Pinski --- (In reply to jamesgua from comment #2) > (In reply to Andrew Pinski from comment #1) > > This is deconstructors. > > I mean why we have those line numbers "17 9 17 9 17", debugger follow the > line number information and user may think the program running backward > instead the incremental way. This is not intuitive. Yes I know. I was just saying what is causing it. And I think there might be another bug for this already too.
