[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 --- Comment #9 from Uroš Bizjak ubizjak at gmail dot com --- I have tried to compile gcc.dg/comp-goto-1.c with the patched gcc, but compilation failed with: /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/comp-goto-1.c: In function 'f': /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/comp-goto-1.c:13:1: internal compiler error: Segmentation fault 0x120617ba3 crash_signal ../../gcc-svn/trunk/gcc/toplev.c:333 0x12025a570 fixup_reorder_chain ../../gcc-svn/trunk/gcc/cfgrtl.c:3436 0x12025a570 cfg_layout_finalize() ../../gcc-svn/trunk/gcc/cfgrtl.c:4055 0x12025b2d3 outof_cfg_layout_mode ../../gcc-svn/trunk/gcc/cfgrtl.c:3295 Please submit a full bug report,
[Bug c++/54588] Improved error messages by dropping out types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54588 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #3) I guess what information is most useful depends on the exact case. In my experience, however, knowing the types you are trying to convert from and to is usually the key. +1 G++ could certainly do better about printing types. It sometimes still spells out typedefs, when they don't make a difference. It could also be smarter when summarizing types, so for example here: [snip] there is no need to say 'Aclass X [with X = VeryComplicatedType]' (I think this is what we actually say now, no?) cannot convert to 'int', but we could say simply 'Aclass X' cannot convert to 'int' because it really doesn't matter what X is. or maybe it does. I'd be very careful about removing information from the diagnostics. I find cases where we are missing information (PR53822 for instance) much worse than those where we need to ignore a number of lines to find the right message. I can read a few more lines, I cannot invent what isn't there. So if there is any chance it might be useful, please at least keep it under some -fdetailed-diagnostic flag. c++filt could also do with some heuristics to avoid exponential growth of types, even if it doesn't know the typedef names used in the source.
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 --- Comment #10 from Uroš Bizjak ubizjak at gmail dot com --- Program received signal SIGSEGV, Segmentation fault. 0x000120345388 in fixup_reorder_chain () at ../../gcc-svn/trunk/gcc/cfgrtl.c:3436 3436 if (BB_HEADER (bb)) (gdb) bt #0 0x000120345388 in fixup_reorder_chain () at ../../gcc-svn/trunk/gcc/cfgrtl.c:3436 #1 0x0001203472d0 in cfg_layout_finalize () at ../../gcc-svn/trunk/gcc/cfgrtl.c:4055 #2 0x000120344f64 in outof_cfg_layout_mode () at ../../gcc-svn/trunk/gcc/cfgrtl.c:3295 #3 0x00012079a52c in execute_one_pass (pass=0x1212d8a30 pass_outof_cfg_layout_mode) at ../../gcc-svn/trunk/gcc/passes.c:2337 (gdb) p bb $1 = (basic_block) 0x1
[Bug c/57841] New: Assembler error on gcc for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57841
Bug ID: 57841
Summary: Assembler error on gcc for ARM
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: a.livenets at gmail dot com
Created attachment 30472
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30472action=edit
Source file with compilation errors
$ arm-cortex_a8-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-cortex_a8-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/chogori/x-tools/arm-cortex_a8-linux-gnueabi/libexec/gcc/arm-cortex_a8-linux-gnueabi/4.7.2/lto-wrapper
Target: arm-cortex_a8-linux-gnueabi
Configured with:
/home/chogori/arm-linux-toolchain/.build/src/gcc-4.7.2/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu
--target=arm-cortex_a8-linux-gnueabi
--prefix=/home/chogori/x-tools/arm-cortex_a8-linux-gnueabi
--with-sysroot=/home/chogori/x-tools/arm-cortex_a8-linux-gnueabi/arm-cortex_a8-linux-gnueabi/sysroot
--enable-languages=c,c++ --with-arch=armv7-a --with-cpu=cortex-a8
--with-tune=cortex-a8 --with-fpu=neon --with-float=softfp
--with-pkgversion='crosstool-NG 1.18.0' --disable-sjlj-exceptions
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp
--disable-libquadmath --disable-libquadmath-support
--with-gmp=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-mpfr=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-mpc=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-ppl=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-cloog=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-libelf=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm
-L/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools/lib
-lpwl' --enable-threads=posix --enable-target-optspace --enable-linker-build-id
--with-system-zlib --enable-multilib
--with-local-prefix=/home/chogori/x-tools/arm-cortex_a8-linux-gnueabi/arm-cortex_a8-linux-gnueabi/sysroot
--enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.2 (crosstool-NG 1.18.0)
The gcc cross-compiler for ARM fails to compile the attached source file
The error is following:
Assembler messages:
Error: ']' expected -- `vst2.32 {d16-d17},[r3:64]'
arm-gcc cross-compilation flags: -c -O3 -march=armv7a -mtune=cortex-a8
-mfpu=neon -mfloat-abi=softfp
When using -O2 flag or uncommenting the string 1, the compilation is
successful.
[Bug target/54531] vpermilpd(x, 2 or 10) is a move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54531 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- We now generate optimal (empty) code with -mavx or -mavx2.
[Bug fortran/57839] Reallocate on assignment does not work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57839 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 --- I think that's effectively a duplicate of PR57456.
[Bug fortran/57839] Reallocate on assignment does not work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57839 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #1) I think that's effectively a duplicate of PR57456. Scratch that. I misread the example. The example seems to work with GCC 4.7, but I get valgrind warnings for all list = [list, item] assignments: Conditional jump or move depends on uninitialised value. I haven't tried 4.8/4.9, yet.
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 --- Comment #11 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com --- --- Comment #9 from Uroš Bizjak ubizjak at gmail dot com --- I have tried to compile gcc.dg/comp-goto-1.c with the patched gcc, but compilation failed with: Huh, worked for me. What revision, what compiler options did you use?
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763
--- Comment #12 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to stevenb@gmail.com from comment #11)
--- Comment #9 from Uroš Bizjak ubizjak at gmail dot com ---
I have tried to compile gcc.dg/comp-goto-1.c with the patched gcc, but
compilation failed with:
Huh, worked for me. What revision, what compiler options did you use?
I have tried to bootstrap current mainline natively on alpha, the bootstrap
failed when checking for sjlj exceptions:
--cut here--
/* confdefs.h */
#define PACKAGE_NAME GNU C Runtime Library
#define PACKAGE_TARNAME libgcc
#define PACKAGE_VERSION 1.0
#define PACKAGE_STRING GNU C Runtime Library 1.0
#define PACKAGE_BUGREPORT
#define PACKAGE_URL http://www.gnu.org/software/libgcc/;
#define SIZEOF_DOUBLE 8
#define SIZEOF_LONG_DOUBLE 16
#define HAVE_GETIPINFO 1
/* end confdefs.h. */
void bar ();
void clean (int *);
void foo ()
{
int i __attribute__ ((cleanup (clean)));
bar();
}
--cut here--
just try to compile this source without any options.
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #10 from Tomasz Gajewski tomga at wp dot pl --- Created attachment 30473 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30473action=edit Patch to pretty printers testsuite to expose some problems This patch adds into the testsuite additional cases with typedefs and references to variables. This exposes problem described in this bug. My proposed earlier patch to 'printers.py' fixes some new testcases from this patch but not all of them.
[Bug c++/51786] [c++0x] Invalid declaration with decltype accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51786 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- On it.
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #11 from Tomasz Gajewski tomga at wp dot pl --- Created attachment 30474 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30474action=edit Patch that fixes all testcases added by me in previous patch to simple.cc
[Bug c++/54588] Improved error messages by dropping out types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54588 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Marc Glisse from comment #4) or maybe it does. I'd be very careful about removing information from the diagnostics. I find cases where we are missing information (PR53822 for I didn't say it was easy ;-) but clang shows that it is possible in some cases to elide things that don't matter and point out exactly the differences that matter. And there are even more clear-cut cases like PR43113 instance) much worse than those where we need to ignore a number of lines to find the right message. I can read a few more lines, I cannot invent what isn't there. So if there is any chance it might be useful, please at least keep it under some -fdetailed-diagnostic flag. Clang has some specific flags controlling this, I guess for the same reasons that you give. But in this specific case, how can the type of VeryComplicatedType change anything about the convertibility of A... to 'int'? Sorry if I lack imagination...
[Bug c++/54588] Improved error messages by dropping out types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54588 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #5) But in this specific case, how can the type of VeryComplicatedType change anything about the convertibility of A... to 'int'? Sorry if I lack imagination... 'A' could have partial/full specializations, it could have a conversion operator to a type that depends on the parameter, etc.
[Bug target/57841] Assembler error on gcc for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57841 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- What binutils version?
[Bug target/57841] Assembler error on gcc for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57841 Alexander Livenets a.livenets at gmail dot com changed: What|Removed |Added Target||arm-linux Host||x86-64 --- Comment #2 from Alexander Livenets a.livenets at gmail dot com --- binutils version 2.20.1a (In reply to Andrew Pinski from comment #1) What binutils version?
[Bug c++/57842] New: for statement not terminating properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842
Bug ID: 57842
Summary: for statement not terminating properly
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: groundup2360917182914017 at gmail dot com
In the program below. If I enter 0 through 10 it should print
0
1
2
3
4
5
6
7
8
9
10
But it doesn't. I think what it print is a error.
0
1
2
3
4
5
6
7
8
9
10
10
11
Source Code is
#include iostream
int main()
{
int number1, number2;
std::cout Enter two numbers to print the numbers between: ;
std::cin number1 number2;
if(number1 number2)
{
for(; number1 = number2; number1++)
{
std::cout number1 std::endl;
}
}
if(number1 number2)
{
for(; number2 = number1; number2++)
{
std::cout number2 std::endl;
}
}
if(number1 == number2)
{
std::cout number1 std::endl;
}
return 0;
}
[Bug c++/57842] for statement not terminating properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The reason why it prints 11 is because the second if is true after the first loop.
[Bug c++/57842] for statement not terminating properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842 --- Comment #2 from Anthony Brown groundup2360917182914017 at gmail dot com --- I see the problem with my code. There is no bug. The second if should be else if. Sorry. On Sun, Jul 7, 2013 at 12:15 PM, pinskia at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The reason why it prints 11 is because the second if is true after the first loop. -- You are receiving this mail because: You reported the bug.
[Bug fortran/57843] New: Polymorphic assignment for derived type is resolved with parent's generic instead of its own
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57843 Bug ID: 57843 Summary: Polymorphic assignment for derived type is resolved with parent's generic instead of its own Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The code below does not do what's expected when compiled with gfortran-4.9 (i.e., to print this is right instead of what am I doing here? every time the polymorphic assignment is invoked, and also printing the assigned values at the end, instead of the default ones. Maybe I still don't understand the semantics behind Fortran 2003+'s type-bound assignment (so I apologize in advance if this is not a bug), but it seems to me that the assign_itemType procedure is being used for assignment, even though it doesn't satisfy the requirement of exact type for the right argument ---is polymorphism being resolved at compile time even for dynamic cases? By commenting out the line marked with !*, I get an ICE with ifort 13.1.3, so I have no way to compare behavior. !-test_assign.f90 module mod1 implicit none type :: itemType contains procedure :: assign_itemType generic :: assignment(=) = assign_itemType end type type, abstract :: tableType class(itemType), allocatable :: table(:) contains procedure :: process procedure(i_setItem), nopass, deferred :: setItem end type abstract interface subroutine i_setItem(array, item) import character(*), intent(IN) :: array(:) class(itemType), allocatable, intent(OUT) :: item end subroutine end interface contains subroutine process(this) class(tableType), intent(INOUT) :: this integer :: i, j, n character(5), allocatable :: array(:) class(itemType), allocatable :: item, aux(:) do i = 1, 3 print '(/,item ,I0)', i array = [character(5) :: 'abc', '1', '12.3'] call this%setItem(array, item) if (ALLOCATED(this%table)) then n = SIZE(this%table) call MOVE_ALLOC(this%table, aux) allocate (this%table(n+1), MOLD = item) print *, 'table is same type as aux?:', SAME_TYPE_AS(this%table, aux) do j = 1, n this%table(j) = aux(j) enddo this%table(n+1) = item else allocate (this%table(1), SOURCE = item) endif print *, 'table is same type as item?:', SAME_TYPE_AS(this%table, item) print *, 'table is same type as itemType?:', SAME_TYPE_AS(this%table, itemType())!* print *, 'table extends type itemType?:', EXTENDS_TYPE_OF(this%table, itemType()) enddo end subroutine subroutine assign_itemType(left, right) class(itemType), intent(OUT) :: left type(itemType), intent(IN) :: right print *, 'what am I doing here?' end subroutine end module mod1 module mod2 use mod1 implicit none type, extends(itemType) :: myItem character(3) :: name = '' integer :: num = 0 real :: val = 0 contains procedure :: assign_myItem generic :: assignment(=) = assign_myItem end type type, extends(tableType) :: myTable contains procedure, nopass :: setItem procedure :: output end type contains subroutine setItem(array, item) character(*), intent(IN) :: array(:) class(itemType), allocatable, intent(OUT) :: item allocate (myItem :: item) select type (item) type is (myItem) print *, 'setting...' item%name = array(1) read (array(2), *) item%num read (array(3), *) item%val end select end subroutine subroutine assign_myItem(left, right) class(myItem), intent(OUT) :: left type(myItem), intent(IN) :: right print *, 'this is right' left%name = right%name left%num = right%num left%val = right%val end subroutine subroutine output(this) class(myTable), intent(IN) :: this integer :: i do i = 1, SIZE(this%table) select type (item = this%table(i)) type is (myItem) print *, i, item%name, item%num, item%val end select enddo end subroutine end module mod2 use mod2 implicit none type(myTable) :: table call table%process() call table%output() end !-test_assign.f90 The output obtained is: ...:~$ gfortran-4.9
[Bug c++/54310] Order of operations during overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54310 --- Comment #1 from Nathan Ridge zeratul976 at hotmail dot com --- Richard Smith has suggested that GCC is actually allowed not to instantiate 'metaint' as per [temp.inst]/p6: If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place. If this is really what's happening - GCC is not instantiating 'metaint' because it can determine without doing so that the first overload of 'foo' will not be chosen - then I guess we can close this PR as INVALID.
[Bug libstdc++/57844] New: avr-unknown-elf libstdc++v3 build causes internal compiler error: in extract_insn, at recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57844 Bug ID: 57844 Summary: avr-unknown-elf libstdc++v3 build causes internal compiler error: in extract_insn, at recog.c:2150 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bugzilla.gcc at buszta dot info Trying to compile GCC 4.8.1 (SVN trunk also applies) toolchain for avr-unknown-elf target with standard C++ library support. Configuration options: ../gcc-4.8.1/configure --prefix=/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf --target=avr-unknown-elf --disable-__cxa_atexit --disable-nls --disable-threads --disable-shared --enable-static --with-dwarf2 --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-ppl=/usr/local --enable-libstdcxx --enable-languages=c,c++ --with-newlib --disable-sjlj-exceptions Build with: binutils 2.23.2 gmp 5.0.5 mpc 0.9 mpfr 3.1.2 ppl 0.12.1 newlib 1.20.0 Host GCC: gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) Building make all-target-libstdc++-v3 gives error: (...) Making all in c++11 make[8]: Entering directory `/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src/c++11' /bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile /home/abuszta/Development/avr/gcc-4.8.1-build/./gcc/xgcc -shared-libgcc -B/home/abuszta/Development/avr/gcc-4.8.1-build/./gcc -nostdinc++ -L/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src -L/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src/.libs -B/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/bin/ -B/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/lib/ -isystem /home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/include -isystem /home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/sys-include -msp8 -I/home/abuszta/Development/avr/gcc-4.8.1/libstdc++-v3/../libgcc -I/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/include/avr-unknown-elf -I/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/include -I/home/abuszta/Development/avr/gcc-4.8.1/libstdc++-v3/libsupc++ -std=gnu++11 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=debug.lo -g -O2 -msp8 -c -o debug.lo ../../../../../../gcc-4.8.1/libstdc++-v3/src/c++11/debug.cc libtool: compile: /home/abuszta/Development/avr/gcc-4.8.1-build/./gcc/xgcc -shared-libgcc -B/home/abuszta/Development/avr/gcc-4.8.1-build/./gcc -nostdinc++ -L/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src -L/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src/.libs -B/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/bin/ -B/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/lib/ -isystem /home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/include -isystem /home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/sys-include -msp8 -I/home/abuszta/Development/avr/gcc-4.8.1/libstdc++-v3/../libgcc -I/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/include/avr-unknown-elf -I/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/include -I/home/abuszta/Development/avr/gcc-4.8.1/libstdc++-v3/libsupc++ -std=gnu++11 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=debug.lo -g -O2 -msp8 -c
[Bug middle-end/56977] gcc -Og incorrectly warns about 'constant zero length parameter'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977
Bastiaan Jacques bastiaan at bjacques dot org changed:
What|Removed |Added
CC||bastiaan at bjacques dot org
--- Comment #7 from Bastiaan Jacques bastiaan at bjacques dot org ---
The following program fd.cc:
#include sys/select.h
int some_socket = 0;
void
foo()
{
fd_set fdset;
struct timeval tval;
FD_ZERO(fdset);
FD_SET(some_socket, fdset);
}
When compiled with:
g++ -c -o fd.o fd.cc -D_FORTIFY_SOURCE=2 -Og
Generates the following warning:
fd.cc:12:219: warning: call to ‘__fdelt_warn’ declared with attribute warning:
bit outside of fd_set selected [enabled by default]
FD_SET(some_socket, fdset);
I think this might be another instance of this bug, because it goes away when
switching to -O2 (but I don't have a 4.8 branch handy to test whether the fix
also resolved this case).
[Bug c++/57842] for statement not terminating properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html select isn't broken, neither is 'for'
[Bug target/57722] Floating point problems when building with no-sse and no-mmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57722 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-unknown-linux-gnu Component|translation |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I want to prevent gcc from generating code with xmm registers on 64bit system. Does that even make sense since the ABI requires using those registers.
[Bug c++/57845] New: ICE with -freg-struct-return on Sparc target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
Bug ID: 57845
Summary: ICE with -freg-struct-return on Sparc target
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at os dot inf.tu-dresden.de
Host: x86_64
Target: sparc
The following code produces an ICE for a Sparc target, with 4.9.0. Also tested
4.7.4 and 4.8.2 with same result. No ICE for target x86 for any version tested.
No ICE with-freg-struct-return removed.
class foo
{
public:
struct r { };
};
class c
{
foo::r func(foo::r);
};
foo::r c::func(foo::r x)
{
return x;
}
$ sparc-linux-g++ -m32 -c -freg-struct-return x.i
x.i: In member function ‘foo::r c::func(foo::r)’:
x.i:15:10: internal compiler error: in emit_move_insn, at expr.c:3486
return x;
^
0x85ba84 emit_move_insn(rtx_def*, rtx_def*)
/tmp/gcc/head/gcc/gcc/expr.c:3485
0xa80620 expand_value_return
/tmp/gcc/head/gcc/gcc/stmt.c:1460
0x78f5f1 expand_gimple_stmt_1
/tmp/gcc/head/gcc/gcc/cfgexpand.c:2248
0x78f5f1 expand_gimple_stmt
/tmp/gcc/head/gcc/gcc/cfgexpand.c:2370
0x7910a7 expand_gimple_basic_block
/tmp/gcc/head/gcc/gcc/cfgexpand.c:4204
0x793806 gimple_expand_cfg
/tmp/gcc/head/gcc/gcc/cfgexpand.c:4723
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Adam
[Bug target/57722] Floating point problems when building with no-sse and no-mmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57722 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Well using -mno-sse breaks printf as that thinks the floating point value is in the xmm register.
[Bug c++/57846] New: CRTP, templates, metaprogramming, forwarding and static member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57846
Bug ID: 57846
Summary: CRTP, templates, metaprogramming, forwarding and
static member
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vince.rev at gmail dot com
This code (I could not find a simpler example) does not compile under g++ for
some obscure reasons (tested with 4.8.1 and 4.7.2) (see the related discussion
on stack overflow here :
http://stackoverflow.com/questions/17515079/crtp-templates-metaprogramming-forwarding-and-static-member-a-bug-in-g-4-8):
-
#include iostream
#include type_traits
#include utility
#include tuple
#include array
template class Crtp, class... Types struct Base
{
template unsigned int Index, class Type = typename
std::tuple_elementIndex, std::tupleTypes... ::type inline const Type
get() const {return std::getIndex(data);}
template unsigned int Index, class Type = typename
std::tuple_elementIndex, std::tupleTypes... ::type inline Crtp set(const
Type value) {std::getIndex(data) = value; return static_castCrtp(*this);}
std::tupleTypes... data;
};
template typename Type, unsigned int Size struct Derived : public
BaseDerivedType, Size, std::arrayType, Size
{
template class... Args, class Template = decltype(std::declvalconst
BaseDerivedType, Size, std::arrayType, Size().template
get0(std::declvalArgs()...)) inline Template test(Args... args) const
{return this-template get0(std::forwardArgs(args)...);}
template class... Args, class Template = decltype(std::declvalconst
BaseDerivedType, Size, std::arrayType, Size().template
set0(std::declvalArgs()...)) inline DerivedType, Size test(Args...
args) {return this-template set0(std::forwardArgs(args)...);}
static void check() {Deriveddouble, 3 derived;
std::coutderived.test()[0]std::endl;}
};
int main(int argc, char* argv[])
{
Deriveddouble, 3 derived; std::coutderived.test()[0]std::endl; //
Working
Deriveddouble, 3::check(); // Not working: error: no match for
‘operator[]’ (operand types are ‘Deriveddouble, 3u’ and ‘int’)
return 0;
}
-
[Bug c/57847] New: Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57847 Bug ID: 57847 Summary: Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lxz at knd dot com.cn Tested kernel version is 3.2.21 and 3.2. Kernel encounters data abort during initiation. Problem exists in gcc 4.7.3 and 4.8.1, but 4.6.3 works fine. Changing kernel configuration to SLAB allocator is a workaround.
[Bug target/57847] Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57847 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I have used GCC 4.7.0 with Linux 3.10 with the SLUB allocator and it works just fine. Can you provide the exact options you configured GCC with?
[Bug c/57848] New: internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 Bug ID: 57848 Summary: internal compiler error on build with mingw-w64 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dongsheng.song at gmail dot com $ svn info mingw-w64/trunk/ gcc/trunk/ Path: mingw-w64/trunk URL: svn://svn.code.sf.net/p/mingw-w64/code/trunk Repository Root: svn://svn.code.sf.net/p/mingw-w64/code Repository UUID: 4407c894-4637-0410-b4f5-ada5f102cad1 Revision: 5938 Node Kind: directory Schedule: normal Last Changed Author: sezero Last Changed Rev: 5936 Last Changed Date: 2013-07-07 17:12:42 +0800 (Sun, 07 Jul 2013) Path: gcc/trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 200744 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 200744 Last Changed Date: 2013-07-08 03:06:45 +0800 (Mon, 08 Jul 2013) $ make all-am make[1]: Entering directory `/home/cauchy/obj/i686-w64-mingw32-gcc49/mingw-w64-crt' i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt -m32 -I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/include -D_CRTBLD -I/home/cauchy/cross/i686-windows-gcc49/i686-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2 -MT intrincs/lib32_libkernel32_a-__movsb.o -MD -MP -MF intrincs/.deps/lib32_libkernel32_a-__movsb.Tpo -c -o intrincs/lib32_libkernel32_a-__movsb.o `test -f 'intrincs/__movsb.c' || echo '/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/'`intrincs/__movsb.c In file included from /home/cauchy/cross/i686-windows-gcc49/lib/gcc/i686-w64-mingw32/4.9.0/include/x86intrin.h:27:0, from /home/cauchy/cross/i686-windows-gcc49/i686-w64-mingw32/include/intrin.h:59, from /home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/intrincs/__movsb.c:1: /home/cauchy/cross/i686-windows-gcc49/lib/gcc/i686-w64-mingw32/4.9.0/include/ia32intrin.h:54:9: internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633 #pragma GCC target(sse4.2) ^ 0x531e8b c_builtin_function_ext_scope(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633 0x755f28 add_builtin_function_common /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561 0x7567e3 add_builtin_function_ext_scope(char const*, tree_node*, int, built_in_class, char const*, tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597 0xa04fc4 ix86_add_new_builtins /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27199 0xa04fc4 ix86_valid_target_attribute_tree(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4512 0x5b22a0 ix86_pragma_target_parse /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386-c.c:385 0x5a2abd handle_pragma_target /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-pragma.c:805 0x557a1e c_parser_pragma /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:8749 0x565ffb c_parser_external_declaration /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1345 0x566967 c_parser_translation_unit /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1251 0x566967 c_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:11000 0x5a0614 c_common_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-opts.c:1046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [intrincs/lib32_libkernel32_a-__movsb.o] Error 1 make[1]: Leaving directory `/home/cauchy/obj/i686-w64-mingw32-gcc49/mingw-w64-crt' make: *** [all] Error 2
[Bug target/57848] internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target Severity|blocker |normal
[Bug ada/57849] New: With Convention = C causes Bug box with -gnat2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57849 Bug ID: 57849 Summary: With Convention = C causes Bug box with -gnat2012 Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: prosfilaes at gmail dot com $ gcc -gnatd.n -gnat2012 -c -Wall g.adb /home/prosfilaes/bin/gcc-4.8.0/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/adainclude/system.ads g.adb +===GNAT BUG DETECTED==+ | 4.8.0 (x86_64-unknown-linux-gnu) GCC error: | | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:336 | | Error detected at g.adb:3:48 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). g.adb g.adb:3:04: warning: constant AR is not referenced compilation abandoned $ cat g.adb procedure g is type Glp_Matrix_Values_Array is array (Natural range ) of Long_Float; AR : constant Glp_Matrix_Values_Array (0 .. 12) := (others = 1.0) with Convention = C; begin null; end g;
[Bug target/57847] Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57847
--- Comment #2 from lxz at knd dot com.cn ---
I am using codesourcery and linaro compiler.
lxz@cdserver:~$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/arm/eabi/bin/../libexec/gcc/arm-none-eabi/4.7.3/lto-wrapper
Target: arm-none-eabi
Configured with:
/scratch/jbrown/2013.05-arm-eabi-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2013
-D__CS_SOURCERYGXX_MIN__=5 -D__CS_SOURCERYGXX_REV__=23
%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}'
--enable-languages=c,c++ --disable-shared --enable-lto --with-newlib
--with-pkgversion='Sourcery CodeBench Lite 2013.05-23'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/arm-none-eabi
--with-build-sysroot=/scratch/jbrown/2013.05-arm-eabi-release/install/arm-none-eabi
--with-gmp=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-libelf=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --enable-poison-system-directories
--with-build-time-tools=/scratch/jbrown/2013.05-arm-eabi-release/install/arm-none-eabi/bin
--with-build-time-tools=/scratch/jbrown/2013.05-arm-eabi-release/install/arm-none-eabi/bin
Thread model: single
gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-23)
lxz@lxzlinux:~/gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux/bin$
./arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=./arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/lxz/gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux/bin/../libexec/gcc/arm-linux-gnueabihf/4.8.1/lto-wrapper
Target: arm-linux-gnueabihf
Configured with:
/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/gcc-linaro-4.8-2013.05/configure
--build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu
--target=arm-linux-gnueabihf
--prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/install
--with-sysroot=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc
--enable-languages=c,c++,fortran --enable-multilib --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
--with-pkgversion='crosstool-NG linaro-1.13.1-4.8-2013.05 - Linaro GCC 2013.05'
--with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit
--enable-libmudflap --enable-libgomp --enable-libssp
--with-gmp=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-mpfr=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-mpc=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-isl=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-cloog=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-libelf=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id
--enable-gold
--with-local-prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc
--enable-c99 --enable-long-long --with-mode=thumb
Thread model: posix
gcc version 4.8.1 20130506 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.05
- Linaro GCC 2013.05)
(In reply to Andrew Pinski from comment #1)
I have used GCC 4.7.0 with Linux 3.10 with the SLUB allocator and it works
just fine.
Can you provide the exact options you configured GCC with?
[Bug target/57848] internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #1 from Dongsheng Song dongsheng.song at gmail dot com --- x86_64-w64-mingw32 failed with same errors: $ make all-am make[1]: Entering directory `/home/cauchy/obj/x86_64-w64-mingw32-gcc49/mingw-w64-crt' x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt -m64 -I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/include -D_CRTBLD -I/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2 -MT intrincs/lib64_libkernel32_a-__movsb.o -MD -MP -MF intrincs/.deps/lib64_libkernel32_a-__movsb.Tpo -c -o intrincs/lib64_libkernel32_a-__movsb.o `test -f 'intrincs/__movsb.c' || echo '/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/'`intrincs/__movsb.c In file included from /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intrin.h:27:0, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/intrin.h:59, from /home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/intrincs/__movsb.c:1: /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ia32intrin.h:54:9: internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633 #pragma GCC target(sse4.2) ^ 0x5357eb c_builtin_function_ext_scope(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633 0x75e618 add_builtin_function_common /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561 0x75eed3 add_builtin_function_ext_scope(char const*, tree_node*, int, built_in_class, char const*, tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597 0xa12124 ix86_add_new_builtins /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27199 0xa12124 ix86_valid_target_attribute_tree(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4512 0x5b5d90 ix86_pragma_target_parse /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386-c.c:385 0x5a65ad handle_pragma_target /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-pragma.c:805 0x55b37e c_parser_pragma /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:8749 0x56995b c_parser_external_declaration /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1345 0x56a2c7 c_parser_translation_unit /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1251 0x56a2c7 c_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:11000 0x5a4104 c_common_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-opts.c:1046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [intrincs/lib64_libkernel32_a-__movsb.o] Error 1 make[1]: Leaving directory `/home/cauchy/obj/x86_64-w64-mingw32-gcc49/mingw-w64-crt' make: *** [all] Error 2
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||vincenzo.innocente at cern dot ch --- Comment #25 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 57823 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/57823] restrict qualifier non effective with pointer returned by new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57823 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Marc Glisse from comment #2) Related to PR23383 as well, which could make restrict unnecessary in this case. It is a dup of that bug. *** This bug has been marked as a duplicate of bug 23383 ***
[Bug driver/57784] GCC inadvertedly truncates source text
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57784 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is hard to fix and will not be fixed as gcc does not know it is writing to a source file or a file you just happen to name to end with .cc . -lstdc++ is considered an object file enough to link with which is why you see this behavior with that only.
[Bug driver/57784] GCC inadvertedly truncates source text
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57784 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) This is hard to fix and will not be fixed as gcc does not know it is writing to a source file or a file you just happen to name to end with .cc . Uh, what's wrong about using a heuristic and refusing to compile when the name of the output file ends in .c, .C, .cc, .f90, etc (possibly unless some -fweird-output-name is also passed) and the file already exists?
