[Bug target/60169] [4.8/4.9 Regression] ICE ARM thumb1 handles far jump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60169 Joey Ye joey.ye at arm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Joey Ye joey.ye at arm dot com --- Fixed in http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=208217
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Paul A. Bristow pbristow at hetp dot u-net.com changed: What|Removed |Added CC||pbristow at hetp dot u-net.com --- Comment #12 from Paul A. Bristow pbristow at hetp dot u-net.com --- This still exists at 4.8.2 and is a *showstopper* for running the Boost.Math library at all the available precisions, up to 128-bit precision where available. typeid(type).name() fails with: undefined reference to `typeinfo for __float128' We can check that the library seems to work OK by ugly hacking of error handling and a few examples of test code (out of the hundreds of tests), but we absolutely need this before it can be fully tested at 128-bit precision and released. Getting this library to pass is part of a demonstration of the proposed C++ and C library additions by Christopher Kormanyos and John Maddock Floating-Point Typedefs Having Specified Widths - N3626 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1703.pdf Everything is working to provide full C++ 128-bit floating-point - apart from this :-( So we are very keen to have a fix.
[Bug c++/60386] New: [C++11] Crash on a template class containing array initialized in-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60386
Bug ID: 60386
Summary: [C++11] Crash on a template class containing array
initialized in-class
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a.matveyakin at gmail dot com
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-15ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-15ubuntu3)
Compiling the code below with “g++ -std=c++11 filename.cpp” causes segmentation
fault in the compiler.
class A
{
};
templatetypename T
class B
{
public:
A v[1] = {};
};
Bint b;
[Bug c++/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387 Nistor, Mihail-Marian m_nistor at yahoo dot com changed: What|Removed |Added Severity|critical|blocker
[Bug c++/60387] New: The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387 Bug ID: 60387 Summary: The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards. Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: m_nistor at yahoo dot com The gcc compiler for the ppc architecture doesn't use DWARF Register Number Mapping that is defined in the PPC ABI standards. Just an example for the first vector register (vr0): the ppc gcc generates 100 instead of 1124. The gcc compiler doesn't emit .debug_frame section and it prefers to emit only the .eh_fram e section. The .eh_frame section is used by application to handle the exception. This section is part of the C++ ABI. The .eh_frame section is not a debug section and this section should not be used by debugger for unwinding stack frame, this statement was also done by Michael Eager who is Chair of DWARF Standards Committee Members. You can see below more information about this: http://wiki.dwarfstd.org/index.php?title=Exception_Handling Relationship with DWARF Although the C++ ABI data in the .eh_frame section uses the data format described by the DWARF Standard (with some extensions), this section (and other sections used by exception handling, such as .eh_frame_hdr and .gcc_except_table) are not defined by the DWARF Standard. The DWARF Standard does not describe the extensions to support exception handling nor the routines which must be called by a program to use this data. The DWARF Debugging Format Committee does not specify the contents of these sections or the functionality which must be provided by the language run time system to support exception handling. The .eh_frame section is not used for debugging. Whether it is generated or not is independent of whether DWARF debug data is generated. All DWARF data is contained in sections with names starting with .debug, which may be removed from a program without affecting the program's normal execution. It is common practice to strip debugging sections from a program before putting it into production, either to reduce the program size, make reverse engineering more difficult, or both. Removing the .eh_frame section (whether the DWARF .debug sections are left in place or not) has a high likelihood of adversely affecting a program's behaviour, especially when it encounters an unexpected condition. Unfortunately, it has been a common shorthand to refer to the C++ ABI exception handling methodology using .eh_frame with DWARF exception handling, or similar phrases. Perhaps this because it is easier to say this than the unwieldy C++ exception handling using the DWARF Call Frame Information format with extensions, or the misleading C++ ABI for IA-64 or SVR4 ABI AMD64 Processor Supplement, especially when discussing a processor other than Itanium or AMD-64. This leads to occasional confusion, where people may look at the DWARF Specification for a description of the C++ ABI exception handling method, or where vulnerabilities in the EH scheme are incorrectly characterized as DWARF vulnerabilities, as in the otherwise excellent paper mentioned below.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #13 from Marc Glisse glisse at gcc dot gnu.org --- It looks like emit_support_tinfos (rtti.c) should go through registered_builtin_types (hidden in c-common.c) in addition to the hardcoded fundamentals list.
[Bug c++/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Severity|blocker |normal
[Bug c++/60367] Default argument object is not getting constructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367 --- Comment #1 from rob.desbois at gmail dot com --- ...having realised that this might look like I just don't grok move construction I expanded my test - adding copy move constructors assignment operators to foo and re-running the test still gives the same result, i.e. the address of the function argument is not the address of a constructed object: constructed foo @ 0x7fff80e0f25f default argument is at 0x7fff80e0f240 (I can attach the enhanced test on request)
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #50 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- (In reply to Marc Glisse from comment #49) large pieces of my patch as nonsense). Fixing this particular issue should not be too hard, there must be a place in the compiler that merges a number of properties from the early declaration into the definition, and we need to add extern C to that list. It's not exactly a single place. For C, in c/c-decl.c, we got duplicate_decls, which uses merge_decls. For C++, in cp/decl.c, we got another function called duplicate_decls.
[Bug c++/60371] std::vector::emplace_back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60371
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Дилян Палаузов from comment #3)
Indeed, adding
z (const z x) { var = strdup (x.var); }
solves the problem. However, I don't understand how that y.clear();
between the y.emplace_back() in the original program avoids the double free.
In the original program the vector is resized on the second insertion, so the
existing element must be copied to the new storage (which results in a shallow
copy of the malloc'd memory, and leads to a double free).
When you clear the vector it doesn't need to be resized, so no element is
copied, so no shallow copy.
[Bug c++/60367] Default argument object is not getting constructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Possibly the same issue as Bug 59713
[Bug libstdc++/43622] no C++ typeinfo for __float128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Summary|no C++ typeinfo for |no C++ typeinfo for |__float128 and __int128 |__float128 --- Comment #14 from Marc Glisse glisse at gcc dot gnu.org --- Updating the title: it seems to me that typeinfo for __int128 has been available for a while, it is only __float128 that is missing.
[Bug fortran/60236] gfortran.dg/vect/pr32380.f fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236 --- Comment #8 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Sun Mar 2 18:06:49 2014 New Revision: 208257 URL: http://gcc.gnu.org/viewcvs?rev=208257root=gccview=rev Log: 2014-03-02 Bernd Edlinger bernd.edlin...@hotmail.de PR fortran/60236 * gfortran.dg/vect/pr32380.f: Fix expected test results. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/pr32380.f
[Bug target/55181] [4.7/4.8/4.9 Regression] Expensive shift loop where a bit-testing instruction could be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181 --- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org --- The first if (...) b++; is transformed to a bit extraction (right shift + and), because the result is either b = 0 or b = 1. The second if (...) b++ uses an and + zero-compare + branch around add. The and + zero-compare are then combined to a bit test insn. The first bit extraction could be turned into a bit test followed by a test result store by implementing the according zero_extract combine pattern: (set (reg:SI 169) (zero_extract:SI (reg/v:SI 165 [ number ]) (const_int 1 [0x1]) (const_int 29 [0x1d]))) Although doing so resulted in problems when matching bit test insns, if I remember correctly. The second bit test + branch + add is a bit more difficult, as it is always expanded as a branch + add. On SH there are multiple minimal sequences, depending on the context / surrounding code. The following branchless variant could used if the tested reg dies after the tests and the whole thing is not inside a (inner) loop: mov r4,r0// r0 = number shlr8 r0 // r0 = r0 8 (logical shift) tst #(1 (13-8)),r0// T = (r0 (1 (13-8))) == 0 shlr8 r0 // r0 = r0 8 (logical shift) movrt r1 // r1 = !T tst #(1 (29-16)),r0 // T = (r0 (1 (26-16))) == 0 movrt r0 // r0 = !T rts add r1,r0// r0 = r0 + r1 If the code is in a loop, it's more efficient to load constants (which might require a constant pool on SH): mov.l (1 13),r1 mov.l (1 29),r2 mov #0,r0 ... loop: ... // r4 = number from somewhere tst r1,r4 // T = (r4 (1 13)) == 0 movrt r3 // r3 = !T tst r2,r4 // T = (r4 (1 29)) == 0 add r3,r0 // r0 = r0 + r3 movrt r3 // r3 = !T add r3,r0 ... cbranch loop Using shift + and is usually worse on SH for these kind of sequences. I've tried adding the standard name pattern extzvmode but it doesn't seem to be used neither for the first if (...) nor for the second during RTL expansion. Maybe if-convert could be taught to transform the second if (...) to a zero_extract as well. But probably it's better to catch this earlier.
[Bug c++/60376] [4.9 Regression] [c++1y] ICE with invalid use of using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60376 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-02 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug fortran/60341] [4.7/4.8/4.9 Regression] ICE compiling Nonmem 6.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60341 --- Comment #11 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Sun Mar 2 18:36:42 2014 New Revision: 208258 URL: http://gcc.gnu.org/viewcvs?rev=208258root=gccview=rev Log: fortran/ PR fortran/60341 * frontend-passes.c (optimize_comparison): Guard two union accesses with the corresponding tag checks. testsuite/ PR fortran/60341 * gfortran.dg/str_comp_optimize_1.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/str_comp_optimize_1.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/frontend-passes.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c/60388] New: Program received signal SIGSEGV, Segmentation fault. 0xb7fb62ff in __pthread_create_2_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60388
Bug ID: 60388
Summary: Program received signal SIGSEGV, Segmentation fault.
0xb7fb62ff in __pthread_create_2_1
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sree.gooogle at gmail dot com
Created attachment 32242
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32242action=edit
c program used for Segmentation fault at line number 563 in pthread_create.c
Hi,
Please take a look at this issue. I have faced a SIGSEGV at line number 563 in
pthread_create.c. The program Crashed in the below fashion:
(gdb)s
514 in pthread_create.c
(gdb)
518 in pthread_create.c
(gdb)
563 in pthread_create.c
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0xb7fb62ff in __pthread_create_2_1 (newthread=0x0, attr=0x0,
start_routine=0x80484cc mx_thrd, arg=0x0) at pthread_create.c:563
563 in pthread_create.c
(gdb)
(gdb) bt
#0 0xb7fb62ff in __pthread_create_2_1 (newthread=0x0, attr=0x0,
start_routine=0x80484cc mx_thrd, arg=0x0) at pthread_create.c:563
#1 0x0804853c in main () at max_trd_creation.c:22
(gdb) i frame
Stack level 0, frame at 0xb670:
eip = 0xb7fb62ff in __pthread_create_2_1 (pthread_create.c:563); saved eip
0x804853c
called by frame at 0xb6a0
source language c.
Arglist at unknown address.
Locals at unknown address, Previous frame's sp is 0xb670
Saved registers:
ebx at 0xb65c, ebp at 0xb668, esi at 0xb660, edi at 0xb664,
eip at 0xb66c
(gdb)s
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
I am going through the below link for details about the line number 563 in
pthread_create.c
http://code.woboq.org/userspace/glibc/nptl/pthread_create.c.html
557if (iattr-flags ATTR_FLAG_SCHED_SET)
558memcpy (pd-schedparam, iattr-schedparam,
559sizeof (struct sched_param));
560else if ((pd-flags ATTR_FLAG_SCHED_SET) == 0)
561{
562INTERNAL_SYSCALL (sched_getparam, scerr, 2, 0, pd-schedparam);
563pd-flags |= ATTR_FLAG_SCHED_SET;
564}
What is the gcc version which I have used?
==
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
How I compiled the program and what are all the options given and the warnings
produced?
===
labro@ubuntu:~/Desktop/sree/DevUnix$ gcc max_trd_creation.c -g -lpthread
max_trd_creation.c: In function âmainâ:
max_trd_creation.c:22:3: warning: passing argument 1 of âpthread_createâ makes
pointer from integer without a cast [enabled by default]
In file included from max_trd_creation.c:2:0:
/usr/include/pthread.h:225:12: note: expected âpthread_t * __restrict__â but
argument is of type âpthread_tâ
I have attached the piece of code which I have used for producing this seg
fault.
Kindly ignore this if you dot see something useful.
Thanks and Regards,
Sreenath
[Bug c/60388] Program received signal SIGSEGV, Segmentation fault. 0xb7fb62ff in __pthread_create_2_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60388 Sreenath U S sree.gooogle at gmail dot com changed: What|Removed |Added Keywords||diagnostic CC||sree.gooogle at gmail dot com Severity|normal |minor
[Bug fortran/60341] [4.7/4.8/4.9 Regression] ICE compiling Nonmem 6.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60341 --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Sun Mar 2 18:49:18 2014 New Revision: 208259 URL: http://gcc.gnu.org/viewcvs?rev=208259root=gccview=rev Log: fortran/ PR fortran/60341 * frontend-passes.c (optimize_comparison): Guard two union accesses with the corresponding tag checks. testsuite/ PR fortran/60341 * gfortran.dg/str_comp_optimize_1.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/str_comp_optimize_1.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/frontend-passes.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/55181] [4.7/4.8/4.9 Regression] Expensive shift loop where a bit-testing instruction could be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181
--- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #9)
Maybe if-convert could be taught to transform the second if (...) to a
zero_extract as well. But probably it's better to catch this earlier.
... which would make the original example
unsigned char lfsr (unsigned long number)
{
unsigned char b = 0;
if (number (1L 29)) b++;
if (number (1L 13)) b++;
return b;
}
produce the same code as
unsigned char lfsr (unsigned long number)
{
return ((number (1L 29)) != 0) + ((number (1L 13)) != 0);
}
[Bug fortran/60341] [4.7/4.8/4.9 Regression] ICE compiling Nonmem 6.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60341 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Mikael Morin mikael at gcc dot gnu.org --- Problem fixed for 4.7.4, 4.8.3 and 4.9.0. Thanks for reporting it.
[Bug c/60388] Program received signal SIGSEGV, Segmentation fault. 0xb7fb62ff in __pthread_create_2_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60388 --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- User error. s/pthread_create(tid,/pthread_create(tid1[i],/g fixes it, as gcc's warnings correctly identified.
[Bug fortran/58842] libgfortran configuration error in 32-bit mode for GCC 4.8 with MacPorts universal installation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58842 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #3 from Eric Gallager egall at gwmail dot gwu.edu --- I am running into this error as well. I attached my relevant logfiles in the downstream ticket that the OP linked to. (In reply to Dominique d'Humieres from comment #1) Check (1) that you have the right versions of this libraries in /opt/local that pass 'make check' without error; Local-Admins-MacBook-Pro:~ ericgallager$ port installed gmp mpfr libmpc The following ports are currently installed: gmp @5.1.2_0+universal (active) libmpc @1.0.2_0+universal (active) mpfr @3.1.1-p2_0+universal (active) I lost my results for their testsuites, but I suppose that I can run them again... (2) that you don't have other such libraries which may interfere with the one in /opt/local (look into /usr/local for instance). MacPorts sanitizes its build environment to avoid finding things in places like /usr/local. That is a moot point though, as I do not have any of gmp, mpfr, or libmpc installed in /usr/local anyways.
[Bug target/59778] FAIL: gcc.dg/atomic/c11-atomic-exec-5.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59778 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Target|hppa-unknown-linux-gnu |hppa*-*-* Host|hppa-unknown-linux-gnu |hppa*-*-* Target Milestone|4.9.0 |--- Build|hppa-unknown-linux-gnu |hppa*-*-*
[Bug c/60388] Program received signal SIGSEGV, Segmentation fault. 0xb7fb62ff in __pthread_create_2_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60388 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- Not a bug.
[Bug bootstrap/52466] C++ fails to build for --target=lm32-rtems4.11 (no exception model)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466 --- Comment #9 from jbeniston at gcc dot gnu.org jbeniston at gcc dot gnu.org --- Author: jbeniston Date: Sun Mar 2 19:58:24 2014 New Revision: 208260 URL: http://gcc.gnu.org/viewcvs?rev=208260root=gccview=rev Log: PR bootstrap/48230 PR bootstrap/50927 PR bootstrap/52466 PR target/46898 * config/lm32/lm32.c (lm32_legitimate_constant_p): Remove, as incorrect. (TARGET_LEGITIMATE_CONSTANT_P): Undefine, as not needed. * config/lm32/lm32.md (movsi_insn): Add 32-bit immediate support. (simple_return, *simple_return): New patterns * config/lm32/predicates.md (movsi_rhs_operand): Remove as obsolete. * configure.ac (force_sjlj_exceptions): Force sjlj exceptions for lm32. Modified: trunk/gcc/ChangeLog trunk/gcc/config/lm32/lm32.c trunk/gcc/config/lm32/lm32.md trunk/gcc/config/lm32/predicates.md trunk/gcc/configure.ac
[Bug bootstrap/50927] lm32 ICE seg fauit compiling libgcc2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50927 --- Comment #4 from jbeniston at gcc dot gnu.org jbeniston at gcc dot gnu.org --- Author: jbeniston Date: Sun Mar 2 19:58:24 2014 New Revision: 208260 URL: http://gcc.gnu.org/viewcvs?rev=208260root=gccview=rev Log: PR bootstrap/48230 PR bootstrap/50927 PR bootstrap/52466 PR target/46898 * config/lm32/lm32.c (lm32_legitimate_constant_p): Remove, as incorrect. (TARGET_LEGITIMATE_CONSTANT_P): Undefine, as not needed. * config/lm32/lm32.md (movsi_insn): Add 32-bit immediate support. (simple_return, *simple_return): New patterns * config/lm32/predicates.md (movsi_rhs_operand): Remove as obsolete. * configure.ac (force_sjlj_exceptions): Force sjlj exceptions for lm32. Modified: trunk/gcc/ChangeLog trunk/gcc/config/lm32/lm32.c trunk/gcc/config/lm32/lm32.md trunk/gcc/config/lm32/predicates.md trunk/gcc/configure.ac
[Bug bootstrap/48230] bootstrapping gcc-4.6.0-RC-20110321 fails for lm32-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48230 --- Comment #1 from jbeniston at gcc dot gnu.org jbeniston at gcc dot gnu.org --- Author: jbeniston Date: Sun Mar 2 19:58:24 2014 New Revision: 208260 URL: http://gcc.gnu.org/viewcvs?rev=208260root=gccview=rev Log: PR bootstrap/48230 PR bootstrap/50927 PR bootstrap/52466 PR target/46898 * config/lm32/lm32.c (lm32_legitimate_constant_p): Remove, as incorrect. (TARGET_LEGITIMATE_CONSTANT_P): Undefine, as not needed. * config/lm32/lm32.md (movsi_insn): Add 32-bit immediate support. (simple_return, *simple_return): New patterns * config/lm32/predicates.md (movsi_rhs_operand): Remove as obsolete. * configure.ac (force_sjlj_exceptions): Force sjlj exceptions for lm32. Modified: trunk/gcc/ChangeLog trunk/gcc/config/lm32/lm32.c trunk/gcc/config/lm32/lm32.md trunk/gcc/config/lm32/predicates.md trunk/gcc/configure.ac
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 --- Comment #17 from jbeniston at gcc dot gnu.org jbeniston at gcc dot gnu.org --- Author: jbeniston Date: Sun Mar 2 19:58:24 2014 New Revision: 208260 URL: http://gcc.gnu.org/viewcvs?rev=208260root=gccview=rev Log: PR bootstrap/48230 PR bootstrap/50927 PR bootstrap/52466 PR target/46898 * config/lm32/lm32.c (lm32_legitimate_constant_p): Remove, as incorrect. (TARGET_LEGITIMATE_CONSTANT_P): Undefine, as not needed. * config/lm32/lm32.md (movsi_insn): Add 32-bit immediate support. (simple_return, *simple_return): New patterns * config/lm32/predicates.md (movsi_rhs_operand): Remove as obsolete. * configure.ac (force_sjlj_exceptions): Force sjlj exceptions for lm32. Modified: trunk/gcc/ChangeLog trunk/gcc/config/lm32/lm32.c trunk/gcc/config/lm32/lm32.md trunk/gcc/config/lm32/predicates.md trunk/gcc/configure.ac
[Bug c++/60033] [c++1y] ICE in retrieve_specialization while compiling recursive generic lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033
--- Comment #6 from Adam Butcher abutcher at gcc dot gnu.org ---
A further reduced testcase:
// PR c++/60033
// { dg-options -std=c++1y }
template typename... T
auto f(T... ts)
{
return sizeof...(ts);
}
template typename... T
auto g(T... ts) {
return [] (int v) {
return f(ts...);
};
}
int main()
{
return g(1,2,3,4)(5) == 4 ? 0 : 1;
}
[Bug c++/60033] [c++1y] ICE in retrieve_specialization while compiling recursive generic lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033
--- Comment #7 from Adam Butcher abutcher at gcc dot gnu.org ---
(In reply to Adam Butcher from comment #6)
return [] (int v) {
return f(ts...);
};
Should have been:
return [] (auto v) {
return f(ts...);
};
The 'int' version works as expected.
[Bug lto/55113] ICE with LTO and -fshort-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113 --- Comment #17 from pmatos at gcc dot gnu.org --- Patch submitted to gcc-patches.
[Bug ipa/60306] [4.9 Regression] Incorrect devirtualization pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60306 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sun Mar 2 20:51:48 2014 New Revision: 208261 URL: http://gcc.gnu.org/viewcvs?rev=208261root=gccview=rev Log: PR ipa/60306 Revert: 2013-12-14 Jan Hubicka j...@suse.cz PR middle-end/58477 * ipa-prop.c (stmt_may_be_vtbl_ptr_store): Skip clobbers. * testsuite/g++.dg/ipa/devirt-29.C: New testcase Added: trunk/gcc/testsuite/g++.dg/ipa/devirt-29.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58477] [4.9 Regression] ice in cgraph_speculative_call_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sun Mar 2 20:51:48 2014 New Revision: 208261 URL: http://gcc.gnu.org/viewcvs?rev=208261root=gccview=rev Log: PR ipa/60306 Revert: 2013-12-14 Jan Hubicka j...@suse.cz PR middle-end/58477 * ipa-prop.c (stmt_may_be_vtbl_ptr_store): Skip clobbers. * testsuite/g++.dg/ipa/devirt-29.C: New testcase Added: trunk/gcc/testsuite/g++.dg/ipa/devirt-29.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60389] New: [4.8/4,9 Regression] ICE with inheriting constructors and wrong usage of constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60389
Bug ID: 60389
Summary: [4.8/4,9 Regression] ICE with inheriting constructors
and wrong usage of constexpr
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++11) triggers
an ICE since GCC 4.8.0:
===
struct A
{
templatetypename...T A(T...) {}
};
struct B : A
{
using A::A;
};
constexpr B b;
===
bug.cc:11:13: error: the type 'const B' of constexpr variable 'b' is not
literal
constexpr B b;
^
bug.cc:6:8: note: 'B' is not literal because:
struct B : A
^
bug.cc:6:8: note: 'B' is not an aggregate, does not have a trivial default
constructor, and has no constexpr constructor that is not a copy or move
constructor
bug.cc:8:12: note: 'templateclass ... T B::B(T ...)' is not usable as a
constexpr function because:
using A::A;
^
bug.cc:8:12: internal compiler error: tree check: expected function_decl, have
template_decl in is_valid_constexpr_fn, at cp/semantics.c:7434
0xdc0f54 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9192
0x73e7f7 tree_check
../../gcc/gcc/tree.h:2709
0x73e7f7 is_valid_constexpr_fn
../../gcc/gcc/cp/semantics.c:7434
0x742fd0 explain_invalid_constexpr_fn(tree_node*)
../../gcc/gcc/cp/semantics.c:8019
0x73f4f2 ensure_literal_type_for_constexpr_object(tree_node*)
../../gcc/gcc/cp/semantics.c:7374
0x5dcddf cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6206
0x6ce58d cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16819
0x6cfd49 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6b3003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6da2d2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d8fc8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da87a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da87a c_parse_file()
../../gcc/gcc/cp/parser.c:31590
0x7fa103 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug c++/60389] [4.8/4,9 Regression] [c++11] ICE with inheriting constructors and wrong usage of constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60389 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.0 Target Milestone|--- |4.8.3 Summary|[4.8/4,9 Regression] ICE|[4.8/4,9 Regression] |with inheriting |[c++11] ICE with inheriting |constructors and wrong |constructors and wrong |usage of constexpr |usage of constexpr Known to fail||4.8.0, 4.9.0
[Bug c++/60376] [4.9 Regression] [c++1y] ICE using member function in a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60376
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Keywords|error-recovery |ice-on-valid-code
Summary|[4.9 Regression] [c++1y]|[4.9 Regression] [c++1y]
|ICE with invalid use of |ICE using member function
|using |in a template function
--- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org ---
While the original testcase was invald, here's a valid one that crashes
in the same place:
struct A
{
void foo();
};
templatetypename T void bar(T)
{
(A().foo)();
}
bug.cc: In function 'void bar(T)':
bug.cc:8:13: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:20901
(A().foo)();
^
0x6049a1 type_dependent_expression_p(tree_node*)
../../gcc/gcc/cp/pt.c:20900
0x734ef4 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2199
0x6b8901 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6164
0x6bb493 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7170
0x6bc17f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7874
0x6bc661 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8112
0x6bea73 cp_parser_expression
../../gcc/gcc/cp/parser.c:8274
0x6bf29c cp_parser_expression
../../gcc/gcc/cp/parser.c:8313
0x6bf29c cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:9622
0x6b4788 cp_parser_statement
../../gcc/gcc/cp/parser.c:9473
0x6b5559 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9745
0x6b56c6 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9699
0x6c667b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18694
0x6c667b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18730
0x6cdc12 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22843
0x6ceab1 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22755
0x6ceab1 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16589
0x6cee4a cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:23164
0x6cf134 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:22966
0x6da4d9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10947
Please submit a full bug report, [etc.]
[Bug c++/60390] New: [c++1y] ICE with declaring function with auto parameter as friend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60390
Bug ID: 60390
Summary: [c++1y] ICE with declaring function with auto
parameter as friend
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
CC: abutcher at gcc dot gnu.org
The following valid code snippet (compiled with -std=c++1y) triggers
an ICE on trunk:
===
struct A
{
void foo(auto);
};
struct B
{
friend void A::foo(auto);
};
===
bug.cc:8:26: internal compiler error: in poplevel_class, at
cp/name-lookup.c:2951
friend void A::foo(auto);
^
0x783a07 poplevel_class()
../../gcc/gcc/cp/name-lookup.c:2951
0x667d28 popclass()
../../gcc/gcc/cp/class.c:7129
0x66818a pop_nested_class()
../../gcc/gcc/cp/class.c:7275
0x6c2cf1 cp_parser_direct_declarator
../../gcc/gcc/cp/parser.c:17479
0x6c2cf1 cp_parser_declarator
../../gcc/gcc/cp/parser.c:16947
0x6ac38d cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20353
0x6afa74 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:20034
0x6afa74 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19268
0x6afa74 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19495
0x6afa74 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14305
0x6c8f70 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6cfb49 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11137
0x6b2ff3 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6da2b2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d8fa8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da85a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da85a c_parse_file()
../../gcc/gcc/cp/parser.c:31595
0x7f9f53 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
This is similar to PR60064.
Adam, you might want to have a look.
[Bug c++/60391] New: [c++1y] ICE with auto parameter for operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60391
Bug ID: 60391
Summary: [c++1y] ICE with auto parameter for operator
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
CC: abutcher at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++1y) triggers
an ICE on trunk:
===
namespace N
{
int operator _X(auto) {}
}
namespace N {}
===
bug.cc:3:25: error: 'int N::operator_X(auto:1)' has invalid argument list
int operator _X(auto) {}
^
bug.cc:6:13: internal compiler error: in resume_scope, at cp/name-lookup.c:1656
namespace N {}
^
0x77fc2e resume_scope
../../gcc/gcc/cp/name-lookup.c:1656
0x78aa0c push_namespace(tree_node*)
../../gcc/gcc/cp/name-lookup.c:3717
0x6d9154 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:15771
0x6da3b1 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10971
0x6d8fa8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da85a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da85a c_parse_file()
../../gcc/gcc/cp/parser.c:31595
0x7f9f53 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
Adam, you might want to have a look at that one, too.
[Bug bootstrap/48230] bootstrapping gcc-4.6.0-RC-20110321 fails for lm32-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48230 Sebastien Bourdeauducq lekernel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||lekernel at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org --- (In reply to jbenis...@gcc.gnu.org from comment #1)
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 --- Comment #1 from Alexander Vogt a.vogt at fulguritus dot com --- Created attachment 32243 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32243action=edit Sample code
[Bug fortran/60392] New: Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 Bug ID: 60392 Summary: Problem with TRANSPOSE and CONTIGUOUS dummy arguments Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.vogt at fulguritus dot com When I use the TRANSPOSE intrinsic for function calls where the CONTIGUOUS statement is set I get wrong results. In the attached sample code I have two subroutines that multiply a 3x3 matrix with another one. One subroutine has the contiguous attribute set for the input, the other one does not. Using gfortran, I get a different result from both calls when the TRANSPOSE intrinsic is used: Normal: 0. Transposed: 6.9428321395983108 Ifort (14.0.1) shows no deviations. I am using gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.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 --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-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
[Bug bootstrap/50927] lm32 ICE seg fauit compiling libgcc2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50927 Sebastien Bourdeauducq lekernel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org --- Fixed, see comment #4
[Bug c++/60377] [c++1y] ICE with invalid function parameter in conjunction with auto parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60377 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org --- Fixed for GCC 4.9.0 by Adam's patch.
[Bug bootstrap/52466] C++ fails to build for --target=lm32-rtems4.11 (no exception model)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466 Sebastien Bourdeauducq lekernel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org --- Fixed, see comment #9
[Bug c++/60393] New: [c++1y] ICE with with invalid functions with auto parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60393
Bug ID: 60393
Summary: [c++1y] ICE with with invalid functions with auto
parameters
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
CC: abutcher at gcc dot gnu.org
The following invalid code snippets (compiled with -std=c++1y) trigger
an ICE on trunk:
==
void (*f)(auto) + 0;
struct A
{
int i;
};
==
bug.cc:1:17: error: expected initializer before '+' token
void (*f)(auto) + 0;
^
bug.cc:5:7: error: data member 'i' cannot be a member template
int i;
^
bug.cc:5:7: internal compiler error: in poplevel, at cp/decl.c:568
0x5c54a3 poplevel(int, int, int)
../../gcc/gcc/cp/decl.c:568
0x5feba8 end_template_decl()
../../gcc/gcc/cp/pt.c:3807
0x6a3941 finish_fully_implicit_template
../../gcc/gcc/cp/parser.c:32052
0x6acafc cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20487
0x6afa74 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:20034
0x6afa74 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19268
0x6afa74 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19495
0x6afa74 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14305
0x6c8f70 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6cfb49 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11137
0x6b2ff3 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6da2b2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d8fa8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da85a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da85a c_parse_file()
../../gcc/gcc/cp/parser.c:31595
0x7f9f53 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
==
struct A
{
void foo();
};
void A::foo(auto) {}
struct B
{
int i;
};
==
bug.cc:6:6: error: prototype for 'void A::foo(auto:1)' does not match any in
class 'A'
void A::foo(auto) {}
^
bug.cc:3:8: error: candidate is: void A::foo()
void foo();
^
bug.cc:10:7: error: data member 'i' cannot be a member template
int i;
^
bug.cc:10:7: internal compiler error: in poplevel, at cp/decl.c:568
0x5c54a3 poplevel(int, int, int)
../../gcc/gcc/cp/decl.c:568
0x5feba8 end_template_decl()
../../gcc/gcc/cp/pt.c:3807
0x6a3941 finish_fully_implicit_template
../../gcc/gcc/cp/parser.c:32052
0x6acafc cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20487
0x6afa74 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:20034
0x6afa74 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19268
0x6afa74 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19495
0x6afa74 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14305
0x6c8f70 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6cfb49 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11137
0x6b2ff3 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6da2b2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d8fa8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da85a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da85a c_parse_file()
../../gcc/gcc/cp/parser.c:31595
0x7f9f53 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
Adam, these look similar to PR60377 you just fixed.
Could you please have a look?
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 Sebastien Bourdeauducq lekernel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org --- Fixed, see comment #17
[Bug target/43807] lm32-elf infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43807 Sebastien Bourdeauducq lekernel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||lekernel at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org --- Works now
[Bug target/50996] segfault cross-compiling for lm32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50996 Sebastien Bourdeauducq lekernel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||lekernel at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org --- Just checked it works with the current trunk (after Jon Beniston's recent patch).
[Bug target/54176] lm32-elf-gcc: internal compiler error: Segmentation fault (program cc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54176 Sebastien Bourdeauducq lekernel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org --- Fixed in trunk by Jon Beniston's recent patch.
[Bug ipa/60243] IPA is slow on large cgraph tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 32244 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32244action=edit WIP patch this patch cuts some redundant work on estimating size of functions that will be too large to be inlined anyway. Currently inliner spends a lot of time compuing properties of these functions (since small and inlinable functions are also fast to estimate) The patch doesn't really save much time building libreoffice/firefox. I will experiment with it a bit more.
[Bug lto/60150] [4.9 Regression] ICE in function_and_variable_visibility, at ipa.c:1000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60150 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sun Mar 2 22:19:37 2014 New Revision: 208262 URL: http://gcc.gnu.org/viewcvs?rev=208262root=gccview=rev Log: PR ipa/60150 * ipa.c (function_and_variable_visibility): When dissolving comdat group, also set all symbols to local. * g++.dg/lto/pr60150.H: New testcase. * g++.dg/lto/pr60150_0.C: New testcase. * g++.dg/lto/pr60150_1.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/pr60150.H trunk/gcc/testsuite/g++.dg/lto/pr60150_0.C trunk/gcc/testsuite/g++.dg/lto/pr60150_1.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog
[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org --- I no longer get the ICE that I think was caused by an alias. The mixup in between PREVAILING_DEF/PREVAILING_DEF_ORONLY_EXP however ought to be fixed on gold side. Can you, please, verify that the ICE is gone and fill in gold PR? This would lead to rather important missed optimizations.
[Bug ipa/60306] [4.9 Regression] Incorrect devirtualization pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60306 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed, even though for next stage1 we need more work.
[Bug lto/60150] [4.9 Regression] ICE in function_and_variable_visibility, at ipa.c:1000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60150 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug c++/60367] Default argument object is not getting constructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367 --- Comment #3 from rob.desbois at gmail dot com --- Adding a destructor didn't fix it for me - though it was destroyed for the same address as the constructed object. constructed foo @ 0x7fffa012e5ef default argument is at 0x7fffa012e5d0 destructed foo @ 0x7fffa012e5ef For what it's worth I tried putting a size_t member into the object being constructed, and using a member-initializer to set it to an identifiable bit pattern - even though the temporary was at an 'unconstructed' address, the size_t was repeatedly correct. The gremlins are messing with my head...
[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733 --- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org --- Forgot to mention, I think the ICE is solved by the following patch: 2014-02-14 Jan Hubicka hubi...@ucw.cz * lto-partition.c (add_symbol_to_partition_1, undo_partition, lto_balanced_map): Aliases have no defined size. (lto_balanced_map): Do not follow refering variables if they can be optimized out. the ICE however happens because we fail to optimize out the dead code because gold us it is used by non-LTO object file in the same DSO. This is clear bug.
[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- We need to handle functions whose bodies was read back as if they were created internally, that is trnaslate stmt uids into stmt pointers. I will try to look into this.
[Bug tree-optimization/60382] [4.8/4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu (in vect_create_epilog_for_reduction, at tree-vect-loop.c:4352)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60382 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-02 CC||jakub at gcc dot gnu.org Version|unknown |4.8.3 Target Milestone|--- |4.8.3 Summary|ICE on valid code at -O3 on |[4.8/4.9 Regression] ICE on |x86_64-linux-gnu (in|valid code at -O3 on |vect_create_epilog_for_redu |x86_64-linux-gnu (in |ction, at |vect_create_epilog_for_redu |tree-vect-loop.c:4352) |ction, at ||tree-vect-loop.c:4352) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r206460.
[Bug lto/60394] New: LTO link fails when -fno-builtin is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60394 Bug ID: 60394 Summary: LTO link fails when -fno-builtin is specified Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: patrick at motec dot com.au Attached are three test cases which demonstrate: 1. Successful link with -Os -flto -nostdlib 2. Successful link with -Os -fno-builtin -nostdlib 3. Failed link with -Os -flto -fno-builtin -nostdlib Test case attached. Full -v log for the failed link: Using built-in specs. COLLECT_GCC=powerpc-eabispe-gcc COLLECT_LTO_WRAPPER=/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/lto-wrapper Target: powerpc-eabispe Configured with: /home/patrick/src/e7/toolchain/src/gcc-4.8.2/configure --prefix=/home/patrick/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c,c++ --with-sysroot=/home/patrick/src/e7/toolchain/../prex_sysroot --disable-nls --disable-werror --with-newlib --with-gmp=/home/patrick/src/e7/toolchain/stage2 --with-mpfr=/home/patrick/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp --with-cpu=8540 Thread model: single gcc version 4.8.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-Os' '-flto' '-fno-builtin' '-nostdlib' '-o' 'test3' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/cc1 -quiet -v test.c -quiet -dumpbase test.c -mcpu=8540 -auxbase test -Os -version -flto -fno-builtin -o /tmp/ccKQLXfn.s GNU C (GCC) version 4.8.2 (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.1.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /home/patrick/src/e7/toolchain/../prex_sysroot/usr/local/include #include ... search starts here: #include ... search starts here: /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/include /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/include-fixed /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/include /home/patrick/src/e7/toolchain/../prex_sysroot/usr/include End of search list. GNU C (GCC) version 4.8.2 (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.1.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 1cf996be489ceb10fd0eea05167fda0c COLLECT_GCC_OPTIONS='-v' '-Os' '-flto' '-fno-builtin' '-nostdlib' '-o' 'test3' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/bin/as -me500 -many -mbig -o /tmp/cc651b3O.o /tmp/ccKQLXfn.s COLLECT_GCC_OPTIONS='-v' '-Os' '-flto' '-fno-builtin' '-nostdlib' '-o' 'test3' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/cc1 -quiet -v string.c -quiet -dumpbase string.c -mcpu=8540 -auxbase string -Os -version -flto -fno-builtin -o /tmp/ccKQLXfn.s GNU C (GCC) version 4.8.2 (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.1.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /home/patrick/src/e7/toolchain/../prex_sysroot/usr/local/include #include ... search starts here: #include ... search starts here: /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/include /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/include-fixed /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/include /home/patrick/src/e7/toolchain/../prex_sysroot/usr/include End of search list. GNU C (GCC) version 4.8.2 (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.1.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 1cf996be489ceb10fd0eea05167fda0c COLLECT_GCC_OPTIONS='-v' '-Os' '-flto' '-fno-builtin' '-nostdlib' '-o' 'test3' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/bin/as -me500 -many -mbig -o /tmp/ccYvBHUg.o /tmp/ccKQLXfn.s COMPILER_PATH=/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/:/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/:/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/:/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/:/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/:/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/bin/
[Bug lto/60395] New: LTO link fails when -fno-builtin is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60395 Bug ID: 60395 Summary: LTO link fails when -fno-builtin is specified Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: patrick at motec dot com.au Attached are three test cases which demonstrate: 1. Successful link with -Os -flto -nostdlib 2. Successful link with -Os -fno-builtin -nostdlib 3. Failed link with -Os -flto -fno-builtin -nostdlib Test case attached. Full -v log for the failed link: Using built-in specs. COLLECT_GCC=powerpc-eabispe-gcc COLLECT_LTO_WRAPPER=/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/lto-wrapper Target: powerpc-eabispe Configured with: /home/patrick/src/e7/toolchain/src/gcc-4.8.2/configure --prefix=/home/patrick/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c,c++ --with-sysroot=/home/patrick/src/e7/toolchain/../prex_sysroot --disable-nls --disable-werror --with-newlib --with-gmp=/home/patrick/src/e7/toolchain/stage2 --with-mpfr=/home/patrick/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp --with-cpu=8540 Thread model: single gcc version 4.8.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-Os' '-flto' '-fno-builtin' '-nostdlib' '-o' 'test3' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/cc1 -quiet -v test.c -quiet -dumpbase test.c -mcpu=8540 -auxbase test -Os -version -flto -fno-builtin -o /tmp/ccKQLXfn.s GNU C (GCC) version 4.8.2 (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.1.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /home/patrick/src/e7/toolchain/../prex_sysroot/usr/local/include #include ... search starts here: #include ... search starts here: /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/include /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/include-fixed /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/include /home/patrick/src/e7/toolchain/../prex_sysroot/usr/include End of search list. GNU C (GCC) version 4.8.2 (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.1.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 1cf996be489ceb10fd0eea05167fda0c COLLECT_GCC_OPTIONS='-v' '-Os' '-flto' '-fno-builtin' '-nostdlib' '-o' 'test3' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/bin/as -me500 -many -mbig -o /tmp/cc651b3O.o /tmp/ccKQLXfn.s COLLECT_GCC_OPTIONS='-v' '-Os' '-flto' '-fno-builtin' '-nostdlib' '-o' 'test3' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/cc1 -quiet -v string.c -quiet -dumpbase string.c -mcpu=8540 -auxbase string -Os -version -flto -fno-builtin -o /tmp/ccKQLXfn.s GNU C (GCC) version 4.8.2 (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.1.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /home/patrick/src/e7/toolchain/../prex_sysroot/usr/local/include #include ... search starts here: #include ... search starts here: /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/include /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/include-fixed /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/include /home/patrick/src/e7/toolchain/../prex_sysroot/usr/include End of search list. GNU C (GCC) version 4.8.2 (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.1.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 1cf996be489ceb10fd0eea05167fda0c COLLECT_GCC_OPTIONS='-v' '-Os' '-flto' '-fno-builtin' '-nostdlib' '-o' 'test3' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/bin/as -me500 -many -mbig -o /tmp/ccYvBHUg.o /tmp/ccKQLXfn.s COMPILER_PATH=/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/:/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.8.2/:/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/:/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/:/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/:/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.8.2/../../../../powerpc-eabispe/bin/
[Bug lto/60395] LTO link fails when -fno-builtin is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60395 --- Comment #1 from Patrick Oppenlander patrick at motec dot com.au --- Created attachment 32245 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32245action=edit Test cases
[Bug c++/60396] New: Missing time_get::get() functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60396 Bug ID: 60396 Summary: Missing time_get::get() functions Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lcarreon at bigpond dot net.au According to the ISO 14882:2011 standard, the time_get facet has two additional get() functions. I have checked locale_facets_nonio.h where time_get is declared and the 2 get() functions do not appear there.
[Bug rtl-optimization/60155] ICE: in get_pressure_class_and_nregs at gcse.c:3438
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60155 --- Comment #9 from dave.anglin at bell dot net --- Something like this? -- John David Anglindave.ang...@bell.net
[Bug lto/60394] LTO link fails when -fno-builtin is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60394 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 60395 *** This bug has been marked as a duplicate of bug 60395 ***
[Bug lto/60395] LTO link fails when -fno-builtin is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60395 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 60394 has been marked as a duplicate of this bug. ***
[Bug lto/60395] LTO link fails when -fno-builtin is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60395 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Related to bug 58203 (or even a dup of that bug).
[Bug c++/60397] New: The value of char16_t u'\uffff' is 0xdfff instead of 0xffff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60397 Bug ID: 60397 Summary: The value of char16_t u'\u' is 0xdfff instead of 0x Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wjl at icecavern dot net CC: daniel.kruegler at googlemail dot com Created attachment 32247 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32247action=edit u.c++ -- program that shows the problem +++ This bug was initially created as a clone of Bug #59873 +++ I found another major bug with char16_t literals when trying to encode a U+. 1) A incorrect warning is emitted. 2) The value is incorrectly changed from U+ to U+DFFF (a low surrogate). This is very similar to, but different that, bug #59873. Because this problem seems related, I've shown both the U+ and U+ problem in the provided example code that triggers the bug. Notice that they fail in similar, but different, ways. (For reference to those who care about other compilers, none of these problems appear using clang 3.5.) The following demonstrates the problem with both g++ 4.8.2 (released) and g++ 4.9.0 (trunk): # First with g++ 4.8.2 $ g++ --version g++ (Debian 4.8.2-14) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ -std=c++11 u.c++ u.c++:3:16: warning: character constant too long for its type [enabled by default] static_assert(u'\u'== 0x, FAILS); ^ u.c++:7:16: warning: character constant too long for its type [enabled by default] static_assert(u'\U'== 0x, FAILS); ^ u.c++:19:16: warning: character constant too long for its type [enabled by default] static_assert(u'\u'!= 0xdfff, FAILS); ^ u.c++:21:16: warning: character constant too long for its type [enabled by default] static_assert(u'\U'!= 0xdfff, FAILS); ^ u.c++: In function ‘int main()’: u.c++:3:2: error: static assertion failed: FAILS static_assert(u'\u'== 0x, FAILS); ^ u.c++:7:2: error: static assertion failed: FAILS static_assert(u'\U'== 0x, FAILS); ^ u.c++:11:2: error: static assertion failed: FAILS static_assert(u\u[0] == 0x, FAILS); ^ u.c++:15:2: error: static assertion failed: FAILS static_assert(u\U[0] == 0x, FAILS); ^ u.c++:19:2: error: static assertion failed: FAILS static_assert(u'\u'!= 0xdfff, FAILS); ^ u.c++:21:2: error: static assertion failed: FAILS static_assert(u'\U'!= 0xdfff, FAILS); ^ u.c++:28:2: error: static assertion failed: FAILS static_assert(u'\u'== 0x, FAILS); ^ u.c++:30:2: error: static assertion failed: FAILS static_assert(U'\u'== 0x, FAILS); ^ u.c++:32:2: error: static assertion failed: FAILS static_assert(u'\U'== 0x, FAILS); ^ u.c++:34:2: error: static assertion failed: FAILS static_assert(U'\U'== 0x, FAILS); ^ u.c++:36:2: error: static assertion failed: FAILS static_assert(u\u[0] == 0x, FAILS); ^ u.c++:38:2: error: static assertion failed: FAILS static_assert(U\u[0] == 0x, FAILS); ^ u.c++:40:2: error: static assertion failed: FAILS static_assert(u\U[0] == 0x, FAILS); ^ u.c++:42:2: error: static assertion failed: FAILS static_assert(U\U[0] == 0x, FAILS); ^ u.c++:45:2: error: static assertion failed: FAILS static_assert(u'\u'!= 0x0001, FAILS); ^ u.c++:46:2: error: static assertion failed: FAILS static_assert(U'\u'!= 0x0001, FAILS); ^ u.c++:47:2: error: static assertion failed: FAILS static_assert(u'\U'!= 0x0001, FAILS); ^ u.c++:48:2: error: static assertion failed: FAILS static_assert(U'\U'!= 0x0001, FAILS); ^ u.c++:49:2: error: static assertion failed: FAILS static_assert(u\u[0] != 0x0001, FAILS); ^ u.c++:50:2: error: static assertion failed: FAILS static_assert(U\u[0] != 0x0001, FAILS); ^ u.c++:51:2: error: static assertion failed: FAILS static_assert(u\U[0] != 0x0001, FAILS); ^ u.c++:52:2: error: static assertion failed: FAILS static_assert(U\U[0] != 0x0001, FAILS); ^ # Change to g++ 4.9.0 $ g++ --version g++ (Debian 4.9-20140218-1) 4.9.0 20140218 (experimental) [trunk revision 207856] Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 --- Comment #10 from Wesley J. Landaker wjl at icecavern dot net --- Created attachment 32248 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32248action=edit u.c++ -- program that shows this problem, and bug #60397's problem I opened new bug #60397 that is a similar issue, but not the same problem. I've attached a new program that more simply shows the problem just using static_assert.
[Bug c++/60354] fails to demangle _Z3fooIPUlvE_EvT_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60354
Jan Engelhardt jengelh at inai dot de changed:
What|Removed |Added
CC||jengelh at inai dot de
--- Comment #1 from Jan Engelhardt jengelh at inai dot de ---
Manually decomposing _Z3fooIPUlvE_EvT_, there is:
- PUlvE_: {lambda(void)#1}*
- I PULvE_ E: templatethat
- finally, 3foo IPUlvE_E vT_ is
fooT returning void taking (T)
Looks correctly mangled to me.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Mar 3 07:25:50 2014 New Revision: 208267 URL: http://gcc.gnu.org/viewcvs?rev=208267root=gccview=rev Log: PR middle-end/60175 * function.c (expand_function_end): Don't emit clobber_return_register sequence if clobber_after is a BARRIER. * cfgexpand.c (construct_exit_block): Append instructions before return_label to prev_bb. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/function.c
[Bug testsuite/59308] [4.9 Regression] gcc.dg/tree-ssa/ssa-ifcombine-ccmp-[1456] tests fail on arm cortex-a5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308 --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org --- It's not as simple as updating the target selector. LONSC_P depends on BRANCH_COST, which can vary depending on the specific micro-architecture for the target system.
[Bug testsuite/59308] [4.9 Regression] gcc.dg/tree-ssa/ssa-ifcombine-ccmp-[1456] tests fail on arm cortex-a5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- So the test can then be improved for ARM by testing GCC predefined macros or something similar, to make check_effective_target_logical_op_short_circuit more precise. Are you sure check_effective_target_arm_cortex_m isn't good enough for ARM?
[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED URL||https://sourceware.org/bugz ||illa/show_bug.cgi?id=16650 Resolution|--- |FIXED --- Comment #13 from Markus Trippelsdorf trippels at gcc dot gnu.org --- https://sourceware.org/bugzilla/show_bug.cgi?id=16650 I can confirm that the ICE is gone.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
