[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 --- Comment #16 from Denis Excoffier g...@denis-excoffier.org 2013-03-24 07:06:40 UTC --- Bootstrap of gcc-4.7-20130323 works perfectly. Thanks.
[Bug c/56705] New: 4.8-20130319 misdiagnoses initialized var (regression from 4.7.2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56705 Bug #: 56705 Summary: 4.8-20130319 misdiagnoses initialized var (regression from 4.7.2) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: egg...@gnu.org Created attachment 29711 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29711 test program, abstracted from Emacs source code This is GCC 4.8-20130319, x86-64, compiled on Fedora 17. I ran into this problem when building a test version of Emacs. Compiling the attached program with: gcc -std=gnu99 -S -Wall -Werror -O3 t.i yields the following diagnostic. t.i: In function 'egetenv': t.i:195:9: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized] char *value; ^ The diagnostic appears to be incorrect, as there's no path through egetenv where 'value' may be unused. The diagnostic is not generated by GCC 4.7.2. Removing the seemingly-unrelated function Fgetenv_internal makes the diagnostic go away.
[Bug fortran/45586] [4.8/4.9 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2012-12-13 09:36:18 |2012-03-24 --- Comment #93 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-24 08:04:17 UTC --- reconfirmed with current (4.9) trunk. 4.8 branch now passes, obviously. An unfortunate side-effect is that I can't test LTO in my trunk based, checking enabled, tester. So, I overlooked that LTO fails, for a different reason, to build CP2K (I'll try to file a separate PR in the near future for that).
[Bug middle-end/56705] 4.8-20130319 misdiagnoses initialized var (regression from 4.7.2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56705 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-24 08:15:48 UTC --- Looks like a missing jump threading which is causing this warning to show up: bb 24: # _48 = PHI 0(28), prephitmp_80(31), 0(23) # value_89 = PHI value_84(D)(28), value_93(31), value_84(D)(23) bb 25: # _16 = PHI prephitmp_107(30), _48(24) # value_85 = PHI value_45(30), value_89(24) if (_16 != 0) goto bb 27; else goto bb 26; bb 26: bb 27: # _1 = PHI value_85(25), 0B(26) return _1;
[Bug lto/56706] New: failure building CP2K at -flto -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Bug #: 56706 Summary: failure building CP2K at -flto -O3 Classification: Unclassified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch The 4.8.1 branch fails to build CP2K in LTO mode. At linking, the following error message appears: /data/vjoost/clean/cp2k/cp2k/makefiles/../src/dbcsr_lib/dbcsr_blas_operations.F:64: error: undefined reference to 'iseed.2556.979179.13933' /data/vjoost/clean/cp2k/cp2k/makefiles/../src/dbcsr_lib/dbcsr_blas_operations.F:62: error: undefined reference to 'iseed.2556.979179.13933' /data/vjoost/clean/cp2k/cp2k/makefiles/../src/dbcsr_lib/dbcsr_blas_operations.F:58: error: undefined reference to 'iseed.2556.979179.13933' /data/vjoost/clean/cp2k/cp2k/makefiles/../src/dbcsr_lib/dbcsr_blas_operations.F:60: error: undefined reference to 'iseed.2556.979179.13933' collect2: error: ld returned 1 exit status The error is absent if the optimization options used are -flto -O1 instead of -flto -O2. I have not been able to reduce this to a small testcase, so I'll post as simple as possible build instructions in a next comment
[Bug lto/56706] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch Summary|failure building CP2K at|failure building CP2K at |-flto -O3 |-flto -O2 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-24 09:26:30 UTC --- Get trunk CP2K and build with lto (note, this requires checking=release, PR45586) and a couple of minutes on a larger machine. svn co svn://svn.code.sf.net/p/cp2k/code/trunk/cp2k cp2k cd cp2k/makefiles/ cat ../arch/lto.sopt # and check all is appropriate (note blas/lapack linking) make -j48 ARCH=lto VERSION=sopt starting a fresh build goes with make -j48 ARCH=lto VERSION=sopt realclean
[Bug lto/56706] [4.8 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Known to work||4.7.2 Summary|failure building CP2K at|[4.8 Regression] failure |-flto -O2 |building CP2K at -flto -O2 Known to fail||4.8.1 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-24 09:31:04 UTC --- The failure is absent on the 4.7 branch
[Bug libfortran/56696] [4.8/4.9 Regression] Formatted (list-directed) input fails to signal end of record
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56696 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-24 11:15:58 UTC --- Author: burnus Date: Sun Mar 24 10:16:33 2013 New Revision: 197019 URL: http://gcc.gnu.org/viewcvs?rev=197019root=gccview=rev Log: 2013-03-24 Tobias Burnus bur...@net-b.de PR fortran/56696 * io/list_read.c (read_real): Fix EOF diagnostic. 2013-03-24 Tobias Burnus bur...@net-b.de PR fortran/56696 * gfortran.dg/eof_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/eof_5.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug tree-optimization/56707] New: [4.7 regression] ICE in distance_non_agu_define_in_bb for -mtune=atom -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56707 Bug #: 56707 Summary: [4.7 regression] ICE in distance_non_agu_define_in_bb for -mtune=atom -O2 Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: xarthisius...@gmail.com Created attachment 29712 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29712 Reduced testcase With gcc-4.7 compiled as: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-werror --enable-languages=c,c++ attached testcase fails for: build/gcc/cc1plus -mtune=atom -O2 bug461694.i Program received signal SIGSEGV, Segmentation fault. distance_non_agu_define_in_bb (...) at /dev/shm/gcc/gcc/config/i386/i386.c:16558 16558 if (prev == BB_HEAD (bb)) yielding: #0 distance_non_agu_define_in_bb (regno1=regno1@entry=3, regno2=regno2@entry=4294967295, insn=insn@entry=0x75d661b0, distance=distance@entry=2, start=optimized out, found=found@entry=0x7fffe23b ) at /dev/shm/gcc/gcc/config/i386/i386.c:16558 #1 0x00c4adbc in distance_non_agu_define (insn=0x75d661b0, regno2=4294967295, regno1=3) at /dev/shm/gcc/gcc/config/i386/i386.c:16612 #2 ix86_lea_outperforms (insn=0x75d661b0, regno0=0, regno1=3, regno2=4294967295, split_cost=0) at /dev/shm/gcc/gcc/config/i386/i386.c:16782 #3 0x00d862f0 in output_53 (operands=0x1631ac0 recog_data, insn=0x75d661b0) at /dev/shm/gcc/gcc/config/i386/i386.md:2224 #4 0x00827bd3 in final_scan_insn (insn=insn@entry=0x75d661b0, file=file@entry=0x16b2ef0, optimize_p=optimize_p@entry=2, nopeepholes=nopeepholes@entry=0, seen=seen@entry=0x7fffe39c) at /dev/shm/gcc/gcc/final.c:2682 #5 0x00828690 in final (first=0x75d45a00, file=0x16b2ef0, optimize_p=2) at /dev/shm/gcc/gcc/final.c:1786 #6 0x0082898a in rest_of_handle_final () at /dev/shm/gcc/gcc/final.c:4319 #7 0x0097b23d in execute_one_pass (pass=pass@entry=0x1519d60 pass_final) at /dev/shm/gcc/gcc/passes.c:2180 #8 0x0097b5c5 in execute_pass_list (pass=0x1519d60 pass_final) at /dev/shm/gcc/gcc/passes.c:2235 #9 0x0097b5d7 in execute_pass_list (pass=0x151aa40 pass_postreload) at /dev/shm/gcc/gcc/passes.c:2236 #10 0x0097b5d7 in execute_pass_list (pass=0x151aaa0 pass_rest_of_compilation) at /dev/shm/gcc/gcc/passes.c:2236 #11 0x00774397 in tree_rest_of_compilation (node=0x75c1c850) at /dev/shm/gcc/gcc/cgraphunit.c:1898 #12 0x00778b12 in cgraph_expand_function (node=0x75c1c850) at /dev/shm/gcc/gcc/cgraphunit.c:1968 #13 0x0077aaaf in cgraph_expand_all_functions () at /dev/shm/gcc/gcc/cgraphunit.c:2033 #14 cgraph_optimize () at /dev/shm/gcc/gcc/cgraphunit.c:2724 #15 0x0077afb5 in cgraph_finalize_compilation_unit () at /dev/shm/gcc/gcc/cgraphunit.c:2810 #16 0x005ac36b in cp_write_global_declarations () at /dev/shm/gcc/gcc/cp/decl2.c:4072 #17 0x00a17f4a in compile_file () at /dev/shm/gcc/gcc/toplev.c:572 #18 do_compile () at /dev/shm/gcc/gcc/toplev.c:1938 #19 toplev_main (argc=4, argv=0x7fffe6b8) at /dev/shm/gcc/gcc/toplev.c:2014 #20 0x7664d9b5 in __libc_start_main (main=0x4d13b0 main, argc=4, ubp_av=0x7fffe6b8, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffe6a8) at libc-start.c:225 Regression was introduced by: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=181077 (bug 50962) ICE disappears with: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=186451 Bug is still present in gcc-4.7 branch. Tested with: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch@197001 Please check if revision 186451 is a proper fix and backport to gcc-4.7 branch. TIA!
[Bug lto/56700] Optimizing at compile and link result in different binary size than only optimizing at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56700 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||INVALID --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-24 11:39:15 UTC --- So not optimizing for size during compile leads to worse results than omitting lto at all for gcc-4.8 I thought optimizations can be ommitted completely during compile, when doing lto. Absolutely not, where did you get this info from? You should pass the same optimization options at compile and link stage, the compiler will do the rest.
[Bug bootstrap/56704] rlim_t problem gcc 4.8.0 on Solaris 2.10/sparc?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56704 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-03-24 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-24 11:46:16 UTC --- I don't have it on the Solaris 10 machine I use: (botcazou@ob) /nile.build/botcazou/gcc-head/sparc-sun-solaris2.10/gcc $ grep rlim_t auto-host.h /* #undef rlim_t */ What's your configuration line?
[Bug fortran/56708] New: [4.9 Regression] Failure calling random_seed with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56708 Bug #: 56708 Summary: [4.9 Regression] Failure calling random_seed with optimization Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org ig25@linux-fd1f:~/Krempel/Random cat random.f90 program main implicit none call init_random_seed contains SUBROUTINE init_random_seed() INTEGER :: i, n, clock INTEGER, DIMENSION(:), ALLOCATABLE :: seed CALL RANDOM_SEED(size = n) ALLOCATE(seed(n)) CALL SYSTEM_CLOCK(COUNT=clock) seed = clock + 37 * (/ (i - 1, i = 1, n) /) CALL RANDOM_SEED(PUT = seed) DEALLOCATE(seed) END SUBROUTINE init_random_seed end program main ig25@linux-fd1f:~/Krempel/Random gfortran random.f90 ig25@linux-fd1f:~/Krempel/Random ./a.out ig25@linux-fd1f:~/Krempel/Random gfortran -O1 random.f90 ig25@linux-fd1f:~/Krempel/Random ./a.out Fortran runtime error: Array size of PUT is too small. ig25@linux-fd1f:~/Krempel/Random I am investigating further to see if 4.8 is also affected.
[Bug fortran/56708] [4.9 Regression] Failure calling random_seed with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56708 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Target Milestone|--- |4.9.0 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-03-24 13:30:50 UTC --- Sorry, it seems this was caused by a local patch. I'll have to revisit that one.
[Bug c++/56709] New: Should the passed command parameters result into the same error messages for a configuration test?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56709
Bug #: 56709
Summary: Should the passed command parameters result into the
same error messages for a configuration test?
Classification: Unclassified
Product: gcc
Version: 4.8.0
URL: http://gcc.gnu.org/ml/gcc-help/2013-02/msg00138.html
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: markus.elfr...@web.de
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
I try to generate the Luyten release of a library combination with the current
compiler again also on my openSUSE Tumbleweed system.
I wonder about the following results here.
elfring@Sonne:~/Projekte/OpalVoip/OPAL/3.10.10 ./configure
--disable-libavcodec
...
checking PTLIB has expat... yes
checking PTLIB has video... no
...
Excerpt from ~/Projekte/OpalVoip/OPAL/3.10.10/config.log:
...
/usr/local/lib64/libpt_s.a(vsdl.o): In function `_GLOBAL__sub_I_vsdl.cxx':
vsdl.cxx:(.text.startup+0x4d): undefined reference to
`PPlugin_PVideoInputDevice_Application_link()'
/usr/local/lib64/libpt_s.a(vfakeio.o): In function
`_GLOBAL__sub_I_vfakeio.cxx':
vfakeio.cxx:(.text.startup+0x4d): undefined reference to
`PPlugin_PVideoInputDevice_Application_link()'
...
elfring@Sonne:~/Projekte/OpalVoip/OPAL/Probe cat Video2.cpp
#define PACKAGE_NAME
#define PACKAGE_TARNAME
#define PACKAGE_VERSION
#define PACKAGE_STRING
#define PACKAGE_BUGREPORT
#define PACKAGE_URL
#define STDC_HEADERS 1
#define OPAL_MAJOR 3
#define OPAL_MINOR 10
#define OPAL_BUILD 10
#define OPAL_VERSION 3.10.10
#define OPAL_PLUGIN_DIR /usr/local/lib64/opal-3.10.10
#define OPAL_PTLIB_SSL 1
#define OPAL_PTLIB_ASN 1
#define OPAL_PTLIB_EXPAT 1
#include ptbuildopts.h
#include ptlib.h
#include ptlib/video.h
int main(void)
{
PVideoChannel vc;
return 0;
}
elfring@Sonne:~/Projekte/OpalVoip/OPAL/Probe LANG=C g++ -o Video2 -Wall
-Wextra -Wstrict-aliasing -Wfloat-equal -Wno-comment -Wno-unused -Winit-self
-Wno-missing-field-initializers -Wreorder -fexceptions -fPIC -DP_64BIT
-DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -I/usr/local/include
-I/usr/include/SDL -L/usr/local/lib64 -lpt_s -lrt -lsasl2 -lldap -llber
-lldap_r -lssl -lcrypto -lexpat -llua -lSDL -lpthread -lodbc -lresolv -ldl
Video2.cpp
/tmp/cc26k0ex.o: In function `main':
Video2.cpp:(.text+0x17): undefined reference to
`PVideoChannel::PVideoChannel()'
Video2.cpp:(.text+0x2b): undefined reference to
`PVideoChannel::~PVideoChannel()'
/tmp/cc26k0ex.o: In function `__static_initialization_and_destruction_0(int,
int)':
Video2.cpp:(.text+0x8c): undefined reference to
`PFactoryLoader::PluginLoaderStartup_link()'
Video2.cpp:(.text+0x97): undefined reference to
`PPlugin_PVideoInputDevice_FakeVideo_link()'
Video2.cpp:(.text+0xa2): undefined reference to
`PPlugin_PVideoInputDevice_Application_link()'
Video2.cpp:(.text+0xad): undefined reference to
`PPlugin_PVideoInputDevice_FFMPEG_link()'
Video2.cpp:(.text+0xb8): undefined reference to
`PPlugin_PVideoInputDevice_YUVFile_link()'
Video2.cpp:(.text+0xc3): undefined reference to
`PPlugin_PVideoOutputDevice_SDL_link()'
collect2: error: ld returned 1 exit status
I find it strange that the reduced command parameter set (deletion of
duplicated options and preprocessor symbols) shows differences in the error
messages.
[Bug c++/56709] Should the passed command parameters result into the same error messages for a configuration test?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56709 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-03-24 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-24 14:06:46 UTC --- What is the question? You've only shown one GCC command, what is the other one?
[Bug c++/56709] Should the passed command parameters result into the same error messages for a configuration test?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56709 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-24 14:08:53 UTC --- Bugzilla is not the right place for this, if you'd asked a real question and provided both commands when you sent it to gcc-help you might have got an answer. Please follow up on the mailing list.
[Bug bootstrap/56644] --disable-nls requires symbols from libintl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56644 Markus Eisenmann meisenmann@fh-salzburg.ac.at changed: What|Removed |Added CC||meisenmann.lba@fh-salzburg. ||ac.at --- Comment #5 from Markus Eisenmann meisenmann@fh-salzburg.ac.at 2013-03-24 14:23:27 UTC --- I have got the same error messages if I have builder an i386-elf cross compiler toolchain. Also based on MinGw (4.7.2), GCC release 4.8.0 and (only) if configured with --disable-nls.
[Bug c++/56710] New: Using reserved double underscore variable name in a lambda causes internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56710
Bug #: 56710
Summary: Using reserved double underscore variable name in a
lambda causes internal compiler error
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: non...@nurd.se
When using any reserved double underscore prefix variable name within a lambda
combined with a non-double underscore variable with the same name will cause a
name lookup internal compiler error.
Minimal example:
int main()
{
int t = 0;
return []() - int {int __t; __t = t; return __t; }();
}
command line and output from the latest git snapshot of 4.9.0:
(fyi. g++ 4.7.2-2ubuntu1 produces similar results but with less verbose output,
so the bug was likely introduced before or with 4.7.2)
$ g++ -v -save-temps -std=c++0x -o test test.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.9.0 20130324 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-o' 'test'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -E -quiet -v
-imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE test.cpp -mtune=generic
-march=x86-64 -std=c++11 -fpch-preprocess -o test.ii
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0/x86_64-unknown-linux-gnu/.
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0/backward
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include
/usr/local/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-o' 'test'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -fpreprocessed
test.ii -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test
-std=c++11 -version -o test.s
GNU C++ (GCC) version 4.9.0 20130324 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.0 20130324 (experimental), GMP version 5.0.2,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.9.0 20130324 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.0 20130324 (experimental), GMP version 5.0.2,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 06fd05e24840af5f20c0ad55456ec1cf
test.cpp: In lambda function:
test.cpp:4:53: internal compiler error: in pop_binding, at cp/name-lookup.c:380
return []() - int {int __t; __t = t; return __t; }();
^
0x6c1c4e pop_binding(tree_node*, tree_node*)
../.././gcc/cp/name-lookup.c:380
0x523427 poplevel(int, int, int)
../.././gcc/cp/decl.c:731
0x66fbb3 do_poplevel(tree_node*)
../.././gcc/cp/semantics.c:436
0x673cf9 finish_compound_stmt(tree_node*)
../.././gcc/cp/semantics.c:1287
0x603241 cp_parser_lambda_body
../.././gcc/cp/parser.c:8725
0x603241 cp_parser_lambda_expression
../.././gcc/cp/parser.c:8272
0x603241 cp_parser_primary_expression
../.././gcc/cp/parser.c:4087
0x604f78 cp_parser_postfix_expression
../.././gcc/cp/parser.c:5643
0x607545 cp_parser_unary_expression
../.././gcc/cp/parser.c:6711
0x60815b cp_parser_binary_expression
../.././gcc/cp/parser.c:7403
0x60860f cp_parser_assignment_expression
../.././gcc/cp/parser.c:7639
0x60a483 cp_parser_expression
../.././gcc/cp/parser.c:7801
0x601462 cp_parser_expression
../.././gcc/cp/parser.c:7840
0x601462 cp_parser_jump_statement
../.././gcc/cp/parser.c:10109
0x601462 cp_parser_statement
../.././gcc/cp/parser.c:8843
0x601cde cp_parser_statement_seq_opt
../.././gcc/cp/parser.c:9207
0x601e26 cp_parser_compound_statement
../.././gcc/cp/parser.c:9161
0x613253 cp_parser_function_body
../.././gcc/cp/parser.c:17775
0x613253 cp_parser_ctor_initializer_opt_and_function_body
../.././gcc/cp/parser.c:17811
0x6142df cp_parser_function_definition_after_declarator
[Bug c++/56710] Using reserved double underscore variable name in a lambda causes internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56710 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-24 Ever Confirmed|0 |1
[Bug c++/56709] Should the passed command parameters result into the same error messages for a configuration test?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56709 Markus Elfring Markus.Elfring at web dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #3 from Markus Elfring Markus.Elfring at web dot de 2013-03-24 14:48:24 UTC --- (In reply to comment #1) What is the question? 1. Why do I get error messages about undefined references here? 2. Should the shown commands be equivalent? You've only shown one GCC command, what is the other one? From ~/Projekte/OpalVoip/OPAL/3.10.10/config.log: configure:6101: g++ -o conftest -Wall -Wextra -Wstrict-aliasing -Wfloat-equal -Wno-comment -Wno-unused -Winit-self -Wno-missing-field-initializers -DP_64BIT -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fexceptions -I/usr/local/include -I/usr/include/SDL -felide-constructors -Wreorder -fPIC -DP_64BIT -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fexceptions -I/usr/local/include -I/usr/include/SDL -felide-constructors -Wreorder -DP_64BIT -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fexceptions -I/usr/local/include -I/usr/include/SDL conftest.cpp -L/usr/local/lib64 -lpt_s -lrt -lsasl2 -lldap -llber -lldap_r -lssl -lcrypto -lexpat -llua -lSDL -lpthread -lodbc -lresolv -ldl 5 (In reply to comment #2) It seems that no other software developer was interested so far to add constructive feedback for this issue on the mailing list.
[Bug c++/56709] Should the passed command parameters result into the same error messages for a configuration test?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56709 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-24 14:59:22 UTC --- (In reply to comment #3) It seems that no other software developer was interested so far to add constructive feedback for this issue on the mailing list. So ping the list again, bugzilla is not the right place to ask questions. As I said, your question was unclear, you asked why there's a difference between two commands and only show one command. Noone's going to waste their time trying to answer you if your question is unclear and can't be understood.
[Bug rtl-optimization/56711] New: spectaculary bad code generated for __uint128_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56711
Bug #: 56711
Summary: spectaculary bad code generated for __uint128_t
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: felix-...@fefe.de
Consider this function:
size_t scan_ulong(const char* src,unsigned long int* dest) {
register const char *tmp=src;
register unsigned long int l=0;
register unsigned char c;
while ((c=*tmp-'0')10) {
__uint128_t x=(__uint128_t)l*10+c;
if ((unsigned long)x != x) break;
l=(unsigned long)x;
++tmp;
}
if (tmp-src) *dest=l;
return tmp-src;
}
I'm compiling this with gcc -Os -c test.c on an amd64-linux box.
The code gcc generates is 92 bytes long, the one from clang only 65. What is
happening here? What are all that code doing that gcc is generating there?
[Bug c/56712] New: constuctor function is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 Bug #: 56712 Summary: constuctor function is called twice Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernd.edlin...@hotmail.de Created attachment 29713 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29713 cnt++ is accidentally called twice at -O2 or higher The attached test program has a constructor function with the __attribute__((constructor)) that is split up into two parts construct.part.0 and construct construct.part.0 is the part after if (xx != 0) return; The problem is that both are put into the .ctors section first the construct.part.0 and then construct. Unfortunately the construct function is called before construct.part.0 which has the check removed. Therefore basically the constuctor is called twice: cnt=2 at -O2 or -O3, but cnt=1 at -O1 or less.
[Bug target/52305] [avr] ICE in avr_print_operand: unknown mode (const_double)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52305 Pitchumani pitchumani.s at atmel dot com changed: What|Removed |Added CC||pitchumani.s at atmel dot ||com --- Comment #2 from Pitchumani pitchumani.s at atmel dot com 2013-03-24 15:58:29 UTC --- not reproducible with gcc-4.7.2. may be got fixed already?
[Bug middle-end/56712] constuctor function is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-24 17:02:38 UTC --- I think this has been fixed already.
[Bug tree-optimization/56711] missed optimization for __uint128_t of (unsigned long long)x != x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56711
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-linux-gnu
Status|UNCONFIRMED |NEW
Keywords||missed-optimization
Last reconfirmed||2013-03-24
Component|rtl-optimization|tree-optimization
Ever Confirmed|0 |1
Summary|spectaculary bad code |missed optimization for
|generated for __uint128_t |__uint128_t of (unsigned
||long long)x != x
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-24
17:22:57 UTC ---
The code gcc generates is 92 bytes long, the one from clang only 65.
If you are going to compare GCC to clang with respect of code size then you
should analyze the code at least. It is very obvious what GCC is not doing.
Well looking at the generated code GCC does not optimize:
if ((unsigned long)x != x) break;
Into just:
x64 == 0
An another example is:
int f(unsigned a)
{
return (unsigned short)a != a;
}
int g(unsigned a)
{
return a16 == 0;
}
[Bug libstdc++/56002] [C++11] allow generic locks to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-24 17:51:52 UTC --- Fixed for 4.8.1 by this patch: Author: redi Date: Sun Mar 24 17:50:44 2013 New Revision: 197020 URL: http://gcc.gnu.org/viewcvs?rev=197020root=gccview=rev Log: PR libstdc++/56002 * include/std/mutex (lock_guard, unique_lock, lock): Define without depending on _GLIBCXX_HAS_GTHREADS. * testsuite/30_threads/lock_guard/cons/1.cc: Run on all targets. Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/std/mutex branches/gcc-4_8-branch/libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc
[Bug libstdc++/53221] [C++11] basic_string lacks copy/move constructors with allocator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53221 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.1 |4.9.0
[Bug c++/53159] Missing narrowing check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53159 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/56701] [C++11] The *this* pointer fails to bind to rvalue reference to pointer type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56701 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-24 Summary|[C++11]The *this* pointer |[C++11] The *this* pointer |fails to bind to rvalue |fails to bind to rvalue |reference to pointer type |reference to pointer type Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-24 20:12:51 UTC --- Confirmed, the reference should be bound to a temporary of type A*
[Bug libfortran/56696] [4.8/4.9 Regression] Formatted (list-directed) input fails to signal end of record
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56696 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-24 20:26:51 UTC --- Author: burnus Date: Sun Mar 24 20:19:23 2013 New Revision: 197022 URL: http://gcc.gnu.org/viewcvs?rev=197022root=gccview=rev Log: 2013-03-24 Tobias Burnus bur...@net-b.de PR fortran/56696 * io/list_read.c (read_real): Fix EOF diagnostic. 2013-03-24 Tobias Burnus bur...@net-b.de PR fortran/56696 * gfortran.dg/eof_5.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/eof_5.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/list_read.c
[Bug libfortran/56696] [4.8/4.9 Regression] Formatted (list-directed) input fails to signal end of record
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56696 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-24 20:27:34 UTC --- FIXED on the 4.9 trunk and on the 4.8 branch. Thanks for the report and sorry for the regression.
[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47308 --- Comment #19 from Zouzou internet at 123gen dot com 2013-03-24 20:56:40 UTC --- Hi, This appears to have been fixed. I can no longer reproduce it with GCC 4.8 and GDB 7.5.
[Bug bootstrap/56714] New: [4.9 regression] Bootstrap failure libitm/local_atomic:1580:3: error: always_inline f unction might not be inlinable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56714 Bug #: 56714 Summary: [4.9 regression] Bootstrap failure libitm/local_atomic:1580:3: error: always_inline f unction might not be inlinable Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ger...@pfeifer.com This appeared in the last 24-48 hours from what I can tell, both on i386-unknown-freebsd10.0 and amd64-unknown-freebsd8.3. In file included from /scratch2/tmp/gerald/gcc-HEAD/libitm/libitm_i.h:40:0, from /scratch2/tmp/gerald/gcc-HEAD/libitm/aatree.cc:28: /scratch2/tmp/gerald/gcc-HEAD/libitm/local_atomic:1580:3: error: always_inline f unction might not be inlinable [-Werror=attributes] atomic_flag_clear(volatile atomic_flag* __a) noexcept ^ /scratch2/tmp/gerald/gcc-HEAD/libitm/local_atomic:1576:3: error: always_inline f unction might not be inlinable [-Werror=attributes] atomic_flag_clear(atomic_flag* __a) noexcept ^ /scratch2/tmp/gerald/gcc-HEAD/libitm/local_atomic:1572:3: error: always_inline f unction might not be inlinable [-Werror=attributes] atomic_flag_test_and_set(volatile atomic_flag* __a) noexcept ^ : cc1plus: all warnings being treated as errors gmake[4]: *** [aatree.lo] Error 1 gmake[4]: Leaving directory `/scratch2/tmp/gerald/OBJ-0324-1745/i386-unknown-fre ebsd10.0/libitm' For bootstrap-lean, in stage 3 it seems (lost the stage information).
[Bug middle-end/56712] constructor function is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 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 2013-03-24 22:21:28 UTC --- Works for me with 4.7/4.8/4.9, and 4.5 and older, but fails with 4.6. The bug was fixed for 4.7.0 by r180700; that change has no BZ PR entry, but the patch submission (http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02486.html) described a scenario involving cloned constructor functions much like this one.
[Bug libstdc++/56170] Extension debug_allocator seems non-compliant w.r.t. rebind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56170 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-24 22:42:09 UTC --- Fixed on trunk by the commit below, which makes debug_allocator a conforming C++03 and C++11 allocator which can wrap any C++03 or C++11 allocator. Author: redi Date: Sun Mar 24 22:10:29 2013 New Revision: 197023 URL: http://gcc.gnu.org/viewcvs?rev=197023root=gccview=rev Log: PR libstdc++/56170 * include/ext/debug_allocator.h (debug_allocator): Add missing members to meet allocator requirements. * testsuite/ext/debug_allocator/56170.cc: New. Added: trunk/libstdc++-v3/testsuite/ext/debug_allocator/56170.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/debug_allocator.h
[Bug fortran/45824] Update expr.c's check_inquiry for C_SIZEOF, compiler_version/_options, etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45824 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-24 23:15:42 UTC --- http://gcc.gnu.org/ml/fortran/2013-03/msg00117.html adds some initial support - but it might break for use-association of modules which use iso_fortran_env - assuming/because from_intmod/intmod_sym_id might not be set.
[Bug c++/56715] New: Explicit Reg Vars are being ignored for consts when using g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
Bug #: 56715
Summary: Explicit Reg Vars are being ignored for consts when
using g++
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: goswin-...@web.de
Created attachment 29714
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29714
example source that experiences the bug
I'm trying to pass a value to an `asm' operand using a specific register for
arm with a freestanding compiler. Following the example from the info pages I
have the following code:
void foo() {
register const int r4 asm(r4) = 0x1000;
asm volatile(swi #1 : : r(r4));
}
void bar() {
register int r4 asm(r4) = 0x1000;
asm volatile(swi #1 : : r(r4));
}
Both foo() and bar() compile correct when using gcc. But when using g++ the
foo() function suddenly uses the r3 register instead of r4. The bar()
function remains correct.
% arm-none-eabi-g++ -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-g++
COLLECT_LTO_WRAPPER=/usr/local/cross/libexec/gcc/arm-none-eabi/4.7.2/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.7.2/configure --target=arm-none-eabi
--prefix=/usr/local/cross --disable-nls --enable-languages=c,c++
--without-headers
Thread model: single
gcc version 4.7.2 (GCC)
% arm-none-eabi-gcc -O2 -save-temps -S bug.c good code
% arm-none-eabi-g++ -O2 -save-temps -S bug.c bad code
--
_Z3foov:
.fnstart
.LFB0:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #4096
@ 3 bug.c 1
swi #1
@ 0 2
bx lr
--
The source explicitly asked for r4 but g++ uses r3 instead.
[Bug c++/56715] Explicit Reg Vars are being ignored for consts when using g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-24 23:33:16 UTC --- const is a bit special in C++, it can be used as part of a const integer expression which is what is happening here.
[Bug c++/56715] Explicit Reg Vars are being ignored for consts when using g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715 --- Comment #2 from Goswin von Brederlow goswin-v-b at web dot de 2013-03-25 00:07:19 UTC --- (In reply to comment #1) const is a bit special in C++, it can be used as part of a const integer expression which is what is happening here. How does that make it right to ignore the register specification? Or how do you specify which register to use to pass the constant to asm in a specific register? To me it seems wrong to ignore the asm(r4) without even a warning. This does break asm() statements that expect specific registers to be used.
[Bug c/56716] New: during gcc 4.8.0 build on Cygwin: bid128_fma.c:4460:1: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56716 Bug #: 56716 Summary: during gcc 4.8.0 build on Cygwin: bid128_fma.c:4460:1: internal compiler error: Segmentation fault Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pen7...@yahoo.com Created attachment 29715 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29715 pre-processed file bid128_fma.i While building gcc 4.8.0 on Cygwin [CYGWIN_NT-6.1-WOW64 1.7.17(0.262/5/3)], the compile stops with ../../../libgcc/config/libbid/bid128_fma.c:4460:1: internal compiler error: Segmentation fault prompt% /usr/tmp/gcc-4.8.0/objdir/./gcc/xgcc -v Using built-in specs. COLLECT_GCC=/usr/tmp/gcc-4.8.0/objdir/./gcc/xgcc Target: i686-pc-cygwin Configured with: ../configure --prefix=/usr/local/gcc/480/ --enable-version-specific-runtime-libs Thread model: single gcc version 4.8.0 (GCC) make[4]: Leaving directory `/usr/tmp/gcc-4.8.0/objdir/i686-pc-cygwin/libgcc' /usr/tmp/gcc-4.8.0/objdir/./gcc/xgcc -B/usr/tmp/gcc-4.8.0/objdir/./gcc/ -B/usr/local/gcc/480/i686-pc-cygwin/bin/ -B/usr/local/gcc/480/i686-pc-cygwin/lib/ -isystem /usr/local/gcc/480/i686-pc-cygwin/include -isystem /usr/local/gcc/480/i686-pc-cygwin/sys-include-g -O2 -O2 -I../../../libgcc/../winsup/w32api/include -I../../../libgcc/../winsup/include -I../../../libgcc/../winsup/cygwin/include -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include-g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -I../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_EMUTLS -o bid_from_int.o -MT bid_from_int.o -MD -MP -MF bid_from_int.dep -c ../../../libgcc/config/libbid/bid_from_int.c ../../../libgcc/config/libbid/bid128_fma.c:4460:1: internal compiler error: Segmentation fault } ^ Please submit a full bug report, with preprocessed source if appropriate.
[Bug c/56716] during gcc 4.8.0 build on Cygwin: bid128_fma.c:4460:1: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56716 pen7cmc at yahoo dot com changed: What|Removed |Added Severity|blocker |major
[Bug preprocessor/56686] gcc cannot find include header file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56686 --- Comment #4 from Pan Ruochen panruochen at gmail dot com 2013-03-25 03:21:34 UTC --- I find something interesting: With -I. option, gcc works well. With -I./ option, gcc fails. gcc -v says: ignoring nonexistent directory ./ But even on Windows, both . and ./ stand for current directory, don't they?
[Bug preprocessor/56686] gcc cannot find include header file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56686 --- Comment #5 from Pan Ruochen panruochen at gmail dot com 2013-03-25 03:28:24 UTC --- Created attachment 29716 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29716 screen snapshot
[Bug preprocessor/56686] gcc cannot find include header file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56686 Pan Ruochen panruochen at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | --- Comment #6 from Pan Ruochen panruochen at gmail dot com 2013-03-25 03:29:24 UTC --- This error does exist on my environment. And found more details.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #2 from Jonathan Liu net147 at gmail dot com 2013-03-25 04:12:41 UTC --- I can reproduce this with MinGW-w64 GCC 4.8.0 x86 DW2/SJLJ. It does not occur with MinGW-w64 GCC 4.8.0 x86_64 SEH/SJLJ.
[Bug preprocessor/33415] Can't compile .cpp file with UTF-8 BOM.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415 Vikas chalakella at yahoo dot com changed: What|Removed |Added CC||chalakella at yahoo dot com --- Comment #8 from Vikas chalakella at yahoo dot com 2013-03-25 05:02:57 UTC --- Hi Experts I am facing the same kind of problem.. I had an c++ application which uses unicode string inside it, I had compiled the solution using Visual Studio 2012. The file is saved in utf-8 with BOM(byte order marker). When I run the same file in linux, I got the following errors:- error: stray '\239' in program 1: error: stray '\187' in program 1: error: stray '\191' in program I found that gcc won't support BOM in the c++ file.If I remove the BOM from the file error get resolved. Is there a way by which I can compile my application containing files saved in utf-8 with BOM ? I am compiling the application in Red hat enterprise Linux 4 edition , where GCC version 3.4.6. Please help me in this regard. Thanks Regards Vikas
[Bug lto/55113] internal compiler error: in emit_library_call_value_1, at calls.c:3739
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113 --- Comment #7 from Patrick Oppenlander patrick at motec dot com.au 2013-03-25 05:41:48 UTC --- Still present in 4.8 etpu/etpu_port.c: In function 'tpu_port_status_get.isra.26': etpu/etpu_port.c:326:2: internal compiler error: in emit_library_call_value_1, at calls.c:3757 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make: *** [/tmp/ccad0BqF.ltrans2.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.8.0/../../../../powerpc-eabispe/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug lto/55112] internal compiler error: in simplify_subreg, at simplify-rtx.c:5424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55112 Patrick Oppenlander patrick at motec dot com.au changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from Patrick Oppenlander patrick at motec dot com.au 2013-03-25 05:51:28 UTC --- Cannot reproduce with 4.8.0.
