[Bug target/63354] New: -pg -mprofile-kernel creates unused stack frames on leaf functions on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354
Bug ID: 63354
Summary: -pg -mprofile-kernel creates unused stack frames on
leaf functions on ppc64le
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
The following testcase:
int foo(void)
{
return 1;
}
compiled with:
gcc -O2 -pg -mprofile-kernel -S foo.c
produces an unused stack frame:
foo:
mflr 0
std 0,16(1)
bl _mcount
mflr 0
li 3,1
std 0,16(1)
stdu 1,-32(1)
addi 1,1,32
ori 2,2,0
ld 0,16(1)
mtlr 0
blr
Note that older gcc versions allowed -mprofile-kernel to used on its own. While
there are issues with that (eg ignoring attribute no_instrument_function), it
does show the expected behaviour:
gcc -O2 -mprofile-kernel -S foo.c
foo:
mflr 0
std 0,16(1)
bl _mcount
li 3,1
blr
So it seems to be something to do with -pg.
[Bug c++/63353] New: libstdc++-v3/src/c++11/ios.cc:232: possible typo ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63353 Bug ID: 63353 Summary: libstdc++-v3/src/c++11/ios.cc:232: possible typo ? Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com [libstdc++-v3/src/c++11/ios.cc:232] -> [libstdc++-v3/src/c++11/ios.cc:232]: (style) Same expression on both sides of '&&'. Offending source code is if (!__lhs_local && !__lhs_local) Maybe if (!__lhs_local && !__rhs_local) or if (!__lhs_local) were intended.
[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253 --- Comment #12 from Marc Glisse --- (In reply to Agner Fog from comment #11) > Thanks for the links Marc. > You are right, the discussion in the gcc-patches mailing list ignores > integer vectors. You need a solution that also allows optimizations on > integer intrinsic functions (perhaps cast the vector type?). If you follow the links, you can find: https://gcc.gnu.org/ml/gcc-patches/2013-04/msg00374.html where I handled some integer vector intrinsics as well (there were some bugs in that patch, but the idea should be fine). > The proposed solution of using vector extensions will not work on masked > vector intrinsics in AVX512, so it wouldn't enable e.g. constant propagation > through a masked intrinsic, but that is probably too much to ask for :) I expect we can get most of the benefits from using vector extensions for very little effort, while handling the esoteric intrinsics would be a lot more work so it gets lower priority.
[Bug testsuite/63352] New: problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 Bug ID: 63352 Summary: problem with fmt_g0_1.f08 on i386-pc-solaris2.11 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Running the testsuite for gcc 4.9.1 I notice the following gfortran failures: === gfortran tests === Running target unix FAIL: gfortran.dg/default_format_1.f90 -O0 execution test FAIL: gfortran.dg/default_format_1.f90 -O1 execution test FAIL: gfortran.dg/default_format_1.f90 -O2 execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -g execution test FAIL: gfortran.dg/default_format_1.f90 -Os execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O0 execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O1 execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O2 execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -g execution test FAIL: gfortran.dg/fmt_g0_1.f08 -Os execution test Concerning the fmt_g0_1.f08 cases, I notice in particular that while debugging the following bits are the problem: 10 write(buffer, string) ':',1.0_8/3.0_8,':' │ 11 if (buffer.ne.":.1:") call abort │ after 10, the value of buffer is: (gdb) print buffer $1 = ':.', '3' , '2:', ' ' Testsuite problem or no? This is running on SunOS 5.11 (illumos) pkgsrc trunk Compiler version: 4.9.1 (GCC) Platform: i386-sun-solaris2.11 configure flags: --enable-languages='c obj-c++ objc go fortran c++' --enable-shared --enable-long-long --with-local-prefix=/opt/local/gcc49 --enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3 -Wl,-R/opt/local/gcc47/lib -Wl,-R/opt/local/lib ' --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpc=/opt/local --with-mpfr=/opt/local --with-isl=/opt/local --disable-isl-version-check --with-cloog=/opt/local --enable-__cxa_atexit --with-gxx-include-dir=/opt/local/gcc49/include/c++/ --with-gnu-as --with-as=/opt/local/bin/gas --without-gnu-ld --with-ld=/usr/bin/ld --with-libiconv-prefix=/opt/local --prefix=/opt/local/gcc49 --build=i386-sun-solaris2.11 --host=i386-sun-solaris2.11 --infodir=/opt/local/gcc49/info --mandir=/opt/local/gcc49/man
[Bug c/63351] New: Optimization: contract broadcast intrinsics when AVX512 is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63351
Bug ID: 63351
Summary: Optimization: contract broadcast intrinsics when
AVX512 is enabled
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: agner at agner dot org
The AVX512 instruction set allows instructions with broadcast, but there are no
corresponding intrinsic functions. The programmer has to write a broadcast
intrinsic followed by some other intrinsic and rely on the compiler to contract
this into a single instruction.
I would expect the optimizer to contract a broadcast intrinsic with any
subsequent intrinsic into a single instruction. For example:
// gcc -Ofast -mavx512f
#include "x86intrin.h"
void dummyz(__m512i a, __m512i b);
void broadcastz(__m512i a, int b) {
// expect reduction to instruction with broadcast,
// something like: vpaddd b, %zmm0, %zmm3 {1to16}
__m512i bb = _mm512_set1_epi32(b);
__m512i ab = _mm512_add_epi32(a,bb);
__m512i cc = _mm512_set1_epi32(5);
__m512i ac = _mm512_add_epi32(a,cc);
dummyz(ab, ac);
}
This should actually be possible for smaller vector sizes as well when AVX512
is enabled:
void dummyx(__m128 a, __m128 b);
void broadcastx(__m128 a, float b) {
// broadcasting should even be possible with smaller vectors
__m128 bb = _mm_set1_ps(b);
__m128 ab = _mm_add_ps(a,bb);
__m128 cc = _mm_set1_ps(5.0);
__m128 ac = _mm_add_ps(a,cc);
dummyx(ab, ac);
}
[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253 --- Comment #11 from Agner Fog --- Thanks for the links Marc. You are right, the discussion in the gcc-patches mailing list ignores integer vectors. You need a solution that also allows optimizations on integer intrinsic functions (perhaps cast the vector type?). I am not on any internal mailing list, so please post it there for me. The proposed solution of using vector extensions will not work on masked vector intrinsics in AVX512, so it wouldn't enable e.g. constant propagation through a masked intrinsic, but that is probably too much to ask for :) I will add a new bug report for contraction of broadcast with AVX512.
[Bug c++/63349] ICE with template in get_narrower fold-const.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63349 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-24 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.4 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed, seems to be quite an old issue.
[Bug c/63344] [5 Regression] Linux (makeallyes config) compilation error: error: apic_numachip causes a section type conflict with numachip_system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #3 from Andi Kleen --- Yes it's a kernel bug. I hit it earlier too. const always needs to go into separate sections. const __read_mostly is also meaningless.
[Bug lto/63350] LTO error: error: inlining failed in call to always_inline 'f': function body not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63350 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- In C++ all inline functions have to be defined in the translation unit you use them. >If I don't use LTO then the main loop is optimized out. How can that be?
[Bug lto/63350] New: LTO error: error: inlining failed in call to always_inline 'f': function body not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63350
Bug ID: 63350
Summary: LTO error: error: inlining failed in call to
always_inline 'f': function body not available
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: vic100 at mail dot com
If I don't use LTO then the main loop is optimized out. If I use LTO with
inline INLINE keywords then it's a linker error. If I use LTO without inline
INLINE keywords then it links but the main loop is not optimized out. If I use
LTO with only the INLINE keyword then it doesn't link, I get "error: inlining
failed in call to always_inline 'f': mismatched arguments." If I use LTO with
only the inline keyword I get "undefined reference to `scalar::f(scalar)'."
//contents of main.cpp :
#include "O.h"
int main()
{
for (int i = 0; i<20; i++)
{scalar test; test.f(9);}
return 0;
}
//contents of O.h :
#define INLINE __attribute__((always_inline))
class scalar
{
private:
float u;
public:
scalar();
scalar(const scalar &);
scalar(float);
inline INLINE void f(scalar);
};
//contents of O.cpp :
#include "O.h"
scalar::scalar() : u(0) {}
scalar::scalar(const scalar &rhs) : u(rhs.u) {}
scalar::scalar(float rhs) : u(rhs) {}
inline INLINE void scalar::f(scalar sc) {u = sc.u;}
-- Build: Debug in E (compiler: mingw-w64)---
g++.exe -O3 -flto -ffat-lto-objects -c C:\CodeBlocks\main.cpp -o
obj\Debug\main.o
In file included from C:\CodeBlocks\main.cpp:1:0:
C:\CodeBlocks\O.h:10:28: warning: inline function 'void scalar::f(scalar)' used
but never defined
inline INLINE void f(scalar);
^
g++.exe -O3 -flto -ffat-lto-objects -c C:\CodeBlocks\O.cpp -o obj\Debug\O.o
g++.exe -o bin\Debug\E.exe obj\Debug\main.o obj\Debug\O.o -O3 -flto
-ffat-lto-objects
C:\CodeBlocks\main.cpp: In function 'main':
C:\CodeBlocks\O.h:10:28: error: inlining failed in call to always_inline 'f':
function body not available
inline INLINE void f(scalar);
^
C:\CodeBlocks\main.cpp:5:28: error: called from here
{scalar test; test.f(9);}
^
lto-wrapper: g++.exe returned 1 exit status
C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe:
lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second(s))
2 error(s), 1 warning(s) (0 minute(s), 0 second(s))
[Bug tree-optimization/63302] [4.9,5.0 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #1 from John David Anglin --- This is with: dave@mx3210:~/debian/gcc/gcc/gcc-4.9-4.9.1$ gcc-4.9 -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc-4.9.real COLLECT_LTO_WRAPPER=/usr/lib/gcc/hppa-linux-gnu/4.9/lto-wrapper Target: hppa-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-14+b1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --disable-libitm --disable-libsanitizer --disable-libquadmath --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.9-hppa/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-hppa --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-hppa --with-arch-directory=parisc --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-libstdcxx-pch --enable-checking=release --build=hppa-linux-gnu --host=hppa-linux-gnu --target=hppa-linux-gnu Thread model: posix gcc version 4.9.1 (Debian 4.9.1-14+b1)
[Bug c++/63349] New: ICE with template in fold-const.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63349
Bug ID: 63349
Summary: ICE with template in fold-const.c
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Reported at https://gcc.gnu.org/ml/gcc-help/2014-09/msg00127.html .
Take:
struct timeval
{
int tv_sec;
};
// needs to be a template
template
int test(int flag)
{
struct timeval a, b;
return ((a.tv_sec == b.tv_sec ? false : true) + flag);
// needs to use `flag'/operator
}
[Bug c++/63349] ICE with template in fold-const.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63349 Andrew Pinski changed: What|Removed |Added Known to fail||4.7.0, 5.0 --- Comment #1 from Andrew Pinski --- It also fails on 4.7.0 and 5.0.
[Bug libstdc++/62313] Data race in debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 --- Comment #11 from Dmitry Vyukov --- Just test it with g++ test.cc -Wall -lpthread -fsanitize=thread -pie -fPIE -D_GLIBCXX_DEBUG -g -O2 There is nothing else I can do on top of that.
[Bug rtl-optimization/63348] regression gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 --- Comment #1 from baoshan --- I believe this regression is introduced by the code for cleanup_barriers() in jump.c of patch https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02164.html: The call insn was followed by a barrier insn, the try_split() would emit another barrier insn after call insn for this case( I don't know why, please let me know the reason); after applying that patch and with option "-g" there would be a note instruction between the call and barrier insns which result no barrier insn is emitted by try_split().
[Bug rtl-optimization/63348] New: regression gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 Bug ID: 63348 Summary: regression gcc.dg/pr43670.c fail on MIPS Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pangbw at gmail dot com 1. Build GCC: $ configure --enable-languages=c --target=mips-linux --with-as=PATH_TO_MIPS_AS (--with-as is needed to set TARGET_CPU_DEFAULT with MASK_EXPLICIT_RELOCS in tm.h) $ make 2. Compile $ ./xgcc -O -fcompare-debug pr43670.c -I. -c xgcc: error: pr43670.c: -fcompare-debug failure (length)
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-23 Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Andreas Schwab --- GCC 4.7 is no longer maintained. Please try to reproduce it with a newer version.
[Bug target/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #8 from Fredrik Hederstierna --- Created attachment 33544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33544&action=edit CSiBE test results size Attached some tests with CSiBE v2.1.1 for arm-eabi. It seems like the results are very scattered, sometimes GCC 4.8.3 produces smaller code than GCC 4.9.1, but on other files it seems to be vice versa. /Fredrik
[Bug libstdc++/63343] g++ accepts incompatible iterator assignemt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63343 --- Comment #2 from Pawel Sikora --- release code is scary, debug code is broken, nightmare :>
[Bug target/63347] New: m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
Bug ID: 63347
Summary: m68k misoptimisation with -fschedule-insns
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jifl-bugzilla at jifvik dot org
The following minimal test case (derived from much larger code) demonstrates a
problem which I could reproduce on m68k-elf-gcc 4.7.4. It can be built with
simply:
m68k-elf-gcc -c -O1 -fschedule-insns foo.c
extern int printf(const char *fmt, ...);
int print_info(unsigned int *ip_addr)
{
int invalid = 0;
if (ip_addr) {
unsigned int haddr = *ip_addr;
printf("%d.%d.%d.%d",
(int)((haddr >> 24) & 0xff),
(int)((haddr >> 16) & 0xff),
(int)((haddr >> 8) & 0xff),
(int)((haddr >> 0) & 0xff));
if (0x0 == haddr) {
invalid = 1;
}
printf("\n");
} else {
invalid = 1;
}
return invalid;
}
The problem manifests with the 'tstl' instruction corresponding to the 'if
(0x0==haddr)' simply disappearing, resulting in an incorrect return value.
Here's the relevant section of asm for a working version (without
-fschedule-insns):
48: 4fef 0014 lea %sp@(20),%sp
4c: 4a82tstl %d2
4e: 57c2seq %d2
50: 49c2extbl %d2
52: 4482negl %d2
54: 4879 pea 0
56: R_68K_32.rodata.str1.1+0xc
%d2 is later moved to %d0 to give the return value.
and for a broken version:
4c: 4fef 0014 lea %sp@(20),%sp
50: 4879 pea 0
52: R_68K_32.rodata.str1.1+0xc
56: 57c2seq %d2
58: 49c2extbl %d2
5a: 4482negl %d2
The 'tstl' insn is gone!
If you want to make this an executable, I added on the following which
demonstrates the problem:
int main(int argc, char *argv[])
{
unsigned int myaddr;
int ret;
myaddr = 0x0;
ret = print_info(&myaddr);
if (!ret)
printf("FAIL: addr 0 returned %d\n", ret);
myaddr = 0x01020304;
ret = print_info(&myaddr);
if (ret)
printf("FAIL: addr 1234 returned %d\n", ret);
return 0;
}
This worked in gcc 4.4.5, but I haven't tried 4.5 or 4.6. Of course other
changes in the optimizer would probably perturb things enough that this code
wouldn't trigger it any more with different gcc versions (including 4.8 or
4.9), even if the problem in the compiler still remains.
[Bug libstdc++/62313] Data race in debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 François Dumont changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org --- Comment #10 from François Dumont --- Created attachment 33543 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33543&action=edit Race condition patch Hi Dmitry, could you have a try with this patch to confirm that it is fixing the bug. It is a patch against libstdc++ trunk. Thanks
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 --- Comment #5 from Byoungyoung Lee --- Thank you for the quick response! The patch I've uploaded is simply the results by replacing all static_cast in the error reports with reinterpret_cast, so that the tool stops complaining and it servers as more like a pointer where the undefined happens. Please let me know if there's anything that I can help out (i.e., regression testing). Thanks!
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 Oleg Endo changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org, ||vmakarov at redhat dot com --- Comment #30 from Oleg Endo --- I thought I've CC'ed Vlad, but somehow I haven't. Trying again.
[Bug libstdc++/24693] Deque improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693
--- Comment #4 from Jonathan Wakely ---
Created attachment 33542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33542&action=edit
Patch to cache a free node.
(In reply to Paolo Carlini from comment #2)
> More interesting work to do:
>
> http://gcc.gnu.org/ml/libstdc++/2005-11/msg00241.html
Here's a proof of concept to prevent repeated reallocations for this case:
while (a long time)
{
dq.push_front(t);
...
dq.pop_back();
}
A single free node is cached in _M_map[-1], so there's no change to the layout
of the class.
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 --- Comment #4 from Jonathan Wakely --- (In reply to Marc Glisse from comment #3) > thanks for the report. I don't think we should blindly replace static_cast > with reinterpret_cast but rather try and understand what is going on. Yes, I strongly agree.
[Bug libstdc++/63343] g++ accepts incompatible iterator assignemt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63343 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Jonathan Wakely --- This is a Good Thing. See PR62169 and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2913.pdf
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 --- Comment #3 from Marc Glisse --- Hello, thanks for the report. I don't think we should blindly replace static_cast with reinterpret_cast but rather try and understand what is going on. For instance, for std::list, I believe the only case where the cast is wrong is for the sentinel, and we should find a way not to cast at all in that case (it might be enough to move the cast inside the loop).
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-23 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Thanks for the report, I'll go through the fixes and apply them (some of them conflict with changes I'm working on in stl_list.h and stl_tree.h)
[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253 --- Comment #10 from Marc Glisse --- Two random links into the latest conversation: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02288.html That version of the patch doesn't handle integer vectors IIRC, but it is the principle that matters, if the first step is accepted I'll extend it. I suppose I should ping it again soon...
[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253 --- Comment #9 from Agner Fog --- Many programmers are using a vector class library rather than writing intrinsic functions directly. Such libraries have overloaded operators which are inlined to produce intrinsic functions. Therefore, we cannot expect programmers to make optimizations like FMA contraction, algebraic reduction, constant propagation, etc. manually. I don't know if this more general discussion of optimizations on code with intrinsics fit into this bug or they need to be discussed elsewhere?
[Bug libstdc++/57840] ::std ::result_of is undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840 Jonathan Wakely changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-23 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- I'm not sure why the comment on the primary template doesn't show up (maybe doxygen is only interested in a definition) and adding comments to the partial specialization doesn't show up in the generated HTML either.
[Bug target/43744] SH: Error: pcrel too far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744 --- Comment #15 from John Paul Adrian Glaubitz --- Hmm, so for whatever reason, the problem does not occur again anymore and binutils just builds fine [1]. I did not upgrade the compiler, however it might be that the any dependencies were updated before the second (automated) build attempt. Will keep an eye on the problem. Adrian > [1] > http://buildd.debian-ports.org/status/fetch.php?pkg=binutils&arch=sh4&ver=2.24.51.20140918-1&stamp=1411252127
[Bug middle-end/63338] Compiling large amounts of large switch cases takes a large amount of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63338 --- Comment #4 from Steven Stewart-Gallus --- > What version of GCC and on which target? Right, I should have mentioned that earlier. > $ uname -a > Linux alonzo 3.13.0-34-generic #1trisquel1 SMP Sun Aug 24 04:17:04 UTC 2014 > x86_64 x86_64 x86_64 GNU/Linux > gcc --version > gcc (GCC) 4.9.1 > 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 PARTICULAR PURPOSE. > With -O2 GCC 4.9 takes 95s. That's somewhat reasonable (not the best obviously but if it's only one source file in the entire project that's okay.) I probably should have posted numbers earlier. For reference on my machine: > $ time gcc -std=gnu99 -c module.i > 11.365 secs > $ time gcc -std=gnu99 -O1 -c module.i > 161.176 secs
[Bug c/63346] New: xserver_xorg-server-1.15.1 crash on RaspberryPi when compiled with gcc-4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63346 Bug ID: 63346 Summary: xserver_xorg-server-1.15.1 crash on RaspberryPi when compiled with gcc-4.9 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ps.report at gmx dot net Hello, running xserver (driver fbdev) on RaspberryPi crashes when compiled with gcc-4.9 (-Os). Steps to reproduce (with buildroot-2014.05 release and additonal dillo package): $ cd buildroot-2014.05 Get Patch 'dillo: new package' $ wget http://git.buildroot.net/buildroot/patch/?id=65b47530229b1ebaa4e2d40ff765614bbd6423ca $ patch -p 1 < ../index.html\?id\=65b47530229b1ebaa4e2d40ff765614bbd6423ca $ cd .. $ mkdir build_gcc_4_9 $ make O=$PWD -C ../buildroot-2014.05 raspberrypi_defconfig Change to use gcc-4.9, glibc add dillo, xserver (and gdb/gdbserver): diff -u ../buildroot-2014.05/configs/raspberrypi_defconfig defconfig --- ../buildroot-2014.05/configs/raspberrypi_defconfig 2014-05-31 09:52:49.0 +0200 +++ defconfig 2014-06-07 23:34:23.070203324 +0200 @@ -1,22 +1,32 @@ BR2_arm=y BR2_arm1176jzf_s=y - -BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y -BR2_TOOLCHAIN_BUILDROOT_CXX=y - -BR2_TARGET_GENERIC_GETTY_PORT="tty1" - -BR2_PACKAGE_RPI_FIRMWARE=y - -# Lock to 3.12 headers as the RPi kernel is based off the 3.12 branch +BR2_ENABLE_DEBUG=y +BR2_STRIP_none=y BR2_KERNEL_HEADERS_VERSION=y BR2_DEFAULT_KERNEL_VERSION="3.12.18" BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12=y - +BR2_TOOLCHAIN_BUILDROOT_GLIBC=y +BR2_GCC_VERSION_4_9_X=y +BR2_TOOLCHAIN_BUILDROOT_CXX=y +BR2_PACKAGE_HOST_GDB=y +BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV=y +BR2_TARGET_GENERIC_GETTY_PORT="tty1" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://github.com/raspberrypi/linux.git" BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="b09a27249d61475e4423607f7632a5aa6e7b3a53" -BR2_LINUX_KERNEL_USE_DEFCONFIG=y BR2_LINUX_KERNEL_DEFCONFIG="bcmrpi_quick" BR2_LINUX_KERNEL_ZIMAGE=y +BR2_PACKAGE_GDB=y +BR2_PACKAGE_GDB_SERVER=y +BR2_PACKAGE_GDB_DEBUGGER=y +BR2_PACKAGE_STRACE=y +BR2_PACKAGE_XORG7=y +BR2_PACKAGE_XSERVER_XORG_SERVER=y +BR2_PACKAGE_XSERVER_XORG_SERVER_MODULAR=y +BR2_PACKAGE_XDRIVER_XF86_INPUT_KEYBOARD=y +BR2_PACKAGE_XDRIVER_XF86_INPUT_MOUSE=y +BR2_PACKAGE_XDRIVER_XF86_VIDEO_FBDEV=y +BR2_PACKAGE_DILLO=y +BR2_PACKAGE_XTERM=y +BR2_PACKAGE_RPI_FIRMWARE=y Run the following on RaspberryPi: (rpi)$ X& # _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/buildroot:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X.Org X Server 1.15.1 Release Date: 2014-04-13 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.7.10-1.32-desktop x86_64 Current Operating System: Linux buildroot 3.12.18-quick #1 PREEMPT Thu May 15 17:08:58 CEST 2014 armv6l Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1200 bcm2708.boardrev=0xf bcm2708.serial=0xd9096898 smsc95xx.macaddr=B8:27:EB:09:68:98 sdhci-bcm2708.emmc_clock_freq=25000 vc_mem.mem_base=0x1ec0 vc_mem.mem_size=0x2000 dwc_otg.fiq_fix_enable=1 sdhci-bcm2708.sync_after_dma=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 root=/dev/nfs nfsroot=172.16.0.1:/srv/nfs/rpi_gcc_001 ip=172.16.0.2 rootwait Build Date: 06 June 2014 12:09:00AM Current version of pixman: 0.32.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 1 00:08:24 1970 (==) Using default built-in configuration (21 lines) Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension DAMAGE Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension DPMS Initializing built-in extension Present Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA (rpi)$ export DISPLAY=localhost:0 (pri)$ dillo paths: Ca
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 --- Comment #1 from Byoungyoung Lee --- Created attachment 33541 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33541&action=edit Error reports in running Chromium browsers.
[Bug libstdc++/63345] New: Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 Bug ID: 63345 Summary: Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: blee at gatech dot edu Created attachment 33540 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33540&action=edit Patching undefined behaviors. Hi all, We have recently developed a runtime detection tool to identify undefined behaviors in static_cast<> (similar to -fsanitize=object-size/-fsanitize=vptr in Clang, but we generalized these functions and coverages), and found several undefined behaviors in libstdc++ (tested on 4.8, but also applicable to trunk version). This bug is related to the undefined behavior described in 5.2.9/11; down-casting is undefined if the object that the pointer to be casted points to is not a suboject of down-casting type. We also found that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 already fixed two cases that we are reporting here, but our tool reported 28 more cases. By manually looking up the error report we got from running chromium (attached the part of error reports: chromium_bits_errors.txt), we believe those are truly undefined behaviors as specified in 5.2.9/11. We also tried to fix this issues based on the report (attachment: undef_static_cast_in_bits.patch). Thanks, Byoungyoung
[Bug c++/61857] An init-capturing lambda is parsed incorrectly when used in a braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61857 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #4 from Paolo Carlini --- Fixed.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 61857, which changed state. Bug 61857 Summary: An init-capturing lambda is parsed incorrectly when used in a braced-init-list https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61857 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/61857] An init-capturing lambda is parsed incorrectly when used in a braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61857 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 23 18:07:59 2014 New Revision: 215528 URL: https://gcc.gnu.org/viewcvs?rev=215528&root=gcc&view=rev Log: /cp 2014-09-23 Paolo Carlini PR c++/61857 * parser.c (cp_parser_skip_to_closing_square_bracket, cp_parser_array_designator_p): New. (cp_parser_initializer_list): Use the latter. /testsuite 2014-09-23 Paolo Carlini PR c++/61857 * g++.dg/cpp1y/lambda-init10.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug target/58757] Advertise the lack of denormal support on alpha without -mieee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58757
--- Comment #4 from Uroš Bizjak ---
(In reply to Marc Glisse from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > Well, the testcase does fail on alpha:
>
> Thanks. In the original testcase (
> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00875.html ) I was xfailing on
> alpha, but Joseph asked me not to xfail it until someone has actually
> observed the failure. Could you please xfail it (or whatever similar option
> you prefer) until this PR is addressed? (Unless you want to fix this PR, of
> course ;-)
Something like ...
int
__attribute__((noinline, noclone))
checkz (const char *ptr, int n)
{
for ( ; n > 0; ptr++, --n)
if (*ptr != 0)
return 0;
return 1;
}
int main ()
{
volatile float f = FLT_TRUE_MIN;
volatile double d = DBL_TRUE_MIN;
volatile long double l = LDBL_TRUE_MIN;
if (checkz (&f, sizeof(f))
|| checkz (&d, sizeof(d))
|| checkz (&l, sizeof (l)))
__builtin_abort ();
return 0;
}
perhaps?
This works on alpha and x86 with some compilation warnings ...
[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #8 from Agner Fog ---
The same problem applies to other kinds of optimizations, such as algebraic
reductions and constant propagation.
The method of using operators such as * and + is not portable to other
compilers, and it doesn't work with integer vectors for other integer sizes
than 64-bits. (I know that there is no integer FMA on Intel CPUs, but I am also
talking about other optimizations).
Here are some other examples of optimizations I would like gcc to do:
#include "x86intrin.h"
void dummy2(__m128 a, __m128 b);
void dummyi2(__m128i a, __m128i b);
void commutative(__m128 a, __m128 b) {
// expect reduce a+b = b+a. This is the only reduction that actually works!
dummy2(_mm_add_ps(a,b), _mm_add_ps(b,a));
}
void associative(__m128i a, __m128i b, __m128i c) {
// expect reduce (a+b)+c = a+(b+c)
dummy2i(_mm_add_epi32(_mm_add_epi32(a,b),c),
_mm_add_epi32(a,_mm_add_epi32(b,c)));
}
void distributive(__m128i a, __m128i b, __m128i c) {
// expect reduce a*b+a*c = a*(b+c)
dummy2i(_mm_add_epi32(_mm_mul_epi32(a,b),_mm_mul_epi32(a,c)),
_mm_mul_epi32(a,_mm_add_epi32(b,c)));
}
void constant_propagation() {
// expect store c and d as precalculated constants
__m128i a = _mm_setr_epi32(1,2,3,4);
__m128i b = _mm_set1_epi32(5);
__m128i c = _mm_add_epi32(a,b);
__m128i d = _mm_mul_epi32(a,b);
dummyi2(c,d);
}
Of course, the same applies to 256-bit and 512-bit vectors.
[Bug fortran/63331] Fortran -fcompare-debug issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63331 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Sep 23 15:25:55 2014 New Revision: 215516 URL: https://gcc.gnu.org/viewcvs?rev=215516&root=gcc&view=rev Log: PR fortran/63331 * trans-types.c (gfc_get_array_descr_info): Build DEBUG_EXPR_DECL instead of VAR_DECL for base_decl. * gfortran.dg/pr63331.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr63331.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug c/49859] gcc could warn about statements between "switch" and first "case"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49859 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- For sure we do not need the old -Wunreachable here. Just when parsing a switch block, anything found before the first case is basically unreachable, no? (Why the standard does not consider this an error?)
[Bug c/63344] [5 Regression] Linux (makeallyes config) compilation error: error: apic_numachip causes a section type conflict with numachip_system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |INVALID --- Comment #2 from Andrew Pinski --- Actually this is not a dup but a bug in the kernel in this case. The error message is correct.
[Bug c/63344] [5 Regression] Linux (makeallyes config) compilation error: error: apic_numachip causes a section type conflict with numachip_system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 61848. *** This bug has been marked as a duplicate of bug 61848 ***
[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 Andrew Pinski changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #14 from Andrew Pinski --- *** Bug 63344 has been marked as a duplicate of this bug. ***
[Bug bootstrap/63280] [5 Regression] Double free in GCC compiled with LTO and -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63280 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from rsandifo at gcc dot gnu.org --- Sorry for the breakage.
[Bug bootstrap/63280] [5 Regression] Double free in GCC compiled with LTO and -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63280 --- Comment #1 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Sep 23 14:47:45 2014 New Revision: 215515 URL: https://gcc.gnu.org/viewcvs?rev=215515&root=gcc&view=rev Log: gcc/ PR bootstrap/63280 * target-globals.c (target_globals::~target_globals): Fix location of ira_int destruction. Modified: trunk/gcc/ChangeLog trunk/gcc/target-globals.c
[Bug c/63344] New: [5 Regression] Linux (makeallyes config) compilation error: error: apic_numachip causes a section type conflict with numachip_system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344
Bug ID: 63344
Summary: [5 Regression] Linux (makeallyes config) compilation
error: error: apic_numachip causes a section type
conflict with numachip_system
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mliska at suse dot cz
CC: hubicka at ucw dot cz
During testing of latest compiler, I've encountered an error in Linux kernel:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/x86/kernel/apic/apic_numachip.c?id=refs/tags/next-20140923
arch/x86/kernel/apic/apic_numachip.c:33:12: error: numachip_system causes a
section type conflict with apic_numachip
static int numachip_system __read_mostly;
^
arch/x86/kernel/apic/apic_numachip.c:205:26: note: 'apic_numachip' was declared
here
static const struct apic apic_numachip __refconst = {
There's a testcase reduced by creduce:
$ cat testcase.ii
struct apic {
int *name
} numachip_system __attribute__((__section__(".data..read_mostly")));
static const struct apic apic_numachip
__attribute__((__section__(".data..read_mostly")));
static const struct apic apic_numachip
__attribute__((__section__(""))) = {.name = ""};
$ gcc testcase.i -S
/home/marxin/Programming/testcases/kernel_numa/testcase.i:6:26: error:
apic_numachip causes a section type conflict with numachip_system
The problem started with: r211363
Older gcc produces:
/home/marxin/Programming/testcases/kernel_numa/testcase.i:3:1: warning: no
semicolon at end of struct or union [enabled by default]
} numachip_system __attribute__((__section__(".data..read_mostly")));
^
/home/marxin/Programming/testcases/kernel_numa/testcase.i:7:5: warning:
initialization from incompatible pointer type [enabled by default]
__attribute__((__section__(""))) = {.name = ""};
^
/home/marxin/Programming/testcases/kernel_numa/testcase.i:7:5: warning: (near
initialization for ‘apic_numachip.name’) [enabled by default]
I am not familiar with section attribute magic, but it looks like a regression.
Thank you,
Martin
[Bug c++/61945] [5 Regression] tree check fail with -Woverloaded-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945
--- Comment #3 from Markus Trippelsdorf ---
Another testcase:
markus@x4 tmp % cat t.ii
class A {
virtual int orbits();
};
class B : A {
template
void orbits();
};
(4.9 is fine)
markus@x4 tmp % g++ -Woverloaded-virtual -c t.ii
t.ii:2:15: warning: ‘virtual int A::orbits()’ was hidden [-Woverloaded-virtual]
virtual int orbits();
^
t.ii:6:8: warning: by ‘B::orbits()’ [-Woverloaded-virtual]
void orbits();
^
markus@x4 tmp % /var/tmp/gcc_test/usr/local/bin/g++ -Woverloaded-virtual -c
t.ii
t.ii:4:7: internal compiler error: tree check: expected function_decl, have
template_decl in warn_hidden, at cp/class.c:2824
class B : A {
^
0xdfbb14 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9177
0x640855 tree_check
../../gcc/gcc/tree.h:2733
0x640855 warn_hidden
../../gcc/gcc/cp/class.c:2824
0x640855 finish_struct_1(tree_node*)
../../gcc/gcc/cp/class.c:6518
0x640ec4 finish_struct(tree_node*, tree_node*)
../../gcc/gcc/cp/class.c:6698
0x66ef52 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19550
0x671870 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19778
0x671870 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14527
0x68c6f0 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11768
0x692639 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11358
0x673ab3 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11307
0x69e1a2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11204
0x69ce68 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11090
0x69e753 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4055
0x69e753 c_parse_file()
../../gcc/gcc/cp/parser.c:32012
0x7c5a62 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug libstdc++/63343] New: g++ accepts incompatible iterator assignemt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63343
Bug ID: 63343
Summary: g++ accepts incompatible iterator assignemt
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
hi, the current g++ accepts incompatible iterator assignment.
#include
int main()
{
std::map< int, int > m;
std::multimap< int, int >::iterator i = m.end();
}
only with _GLIBCXX_DEBUG there's an expected build error.
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-23 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Jakub Jelinek --- Created attachment 33539 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33539&action=edit gcc5-pr63341.patch Untested fix. Fixes the testcases on ppc32 -mcpu=power7 -mtune=power7 though.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #10 from Peter Bergner --- (In reply to boger from comment #9) > On ppc64le, this works as expected but on ppc64(be) the code that is > generated from this is not the address of the function but the address of > the .opd entry that is used to call the function. As a result the setting > of the deferring function is incorrect and it does not appear as if it can > recover because of the way __go_can_recover uses the deferring function's > address to see if it is in the correct range. On BE, a "function pointer" (unlike on LE or x64* or ...) always points to a function's function descriptor (ie, the .opd entry) and not the code address. The function descriptor contains 3 64-bit doublewords. The first doubleword is the address of the function's code. The second doubleword is the TOC value that needs to be in r2 while we execute the function and the third doubleword contains an environment pointer for languages such as Pascal and PL/1.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #9 from boger at us dot ibm.com ---
The patch to fix the recover.go problem causes significant regression in gccgo
when built for ppc64 (BE). There are 32 unexpected failures in the gcc go
testsuite with the patch 32 unexpected failures in the gcc libgo testsuite.
Without this patch on trunk there are 2 failures in the go testsuites and 1
failure in the libgo testsuite.
I did some debugging on one of the regression failures: bug113.go. I found
that the problem occurs in the new code in the patch in
go/gofrontend/statements.cc when creating the expression tree to call
__go_set_defering_fn. The argument that is being passed is generated through a
call to make_func_code_reference:
Expression* arg =
Expression::make_func_code_reference(function, location);
Expression* call = Runtime::make_call(Runtime::SET_DEFERING_FN,
location, 1, arg);
Statement* s = Statement::make_statement(call, true);
s->determine_types();
gogo->add_statement(s);
On ppc64le, this works as expected but on ppc64(be) the code that is generated
from this is not the address of the function but the address of the .opd entry
that is used to call the function. As a result the setting of the deferring
function is incorrect and it does not appear as if it can recover because of
the way __go_can_recover uses the deferring function's address to see if it is
in the correct range.
When I debug this using gdb:
Breakpoint 1, __go_set_defering_fn (defering_fn=0x10020150 ) at
/home/boger/gccgo.work/140922/src/libgo/runtime/go-defer.c:78
78 {
Missing separate debuginfos, use: debuginfo-install glibc-2.17-55.el7.ppc64
(gdb) info reg $r3
r3 0x10020150 268566864
>From the objdump, I see this address is in the .opd:
10020150 :
10020150: 00 00 00 00 .long 0x0
10020154: 10 00 1c 4c vsrov0,v0,v3
10020158: 00 00 00 00 .long 0x0
1002015c: 10 02 81 c0 .long 0x100281c0
but the code is actually here, which is the address that should be passed to
__go_set_defering_fn:
10001c4c <.main.$thunk0>:
main.$thunk0():
10001c4c: 7c 08 02 a6 mflrr0
10001c50: f8 01 00 10 std r0,16(r1)
10001c54: fb e1 ff f8 std r31,-8(r1)
10001c58: f8 21 ff 71 stdur1,-144(r1)
Note that the actual function code address is in the first 8 bytes of the .opd
entry for the function.
[Bug debug/63342] New: [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342 Bug ID: 63342 Summary: [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jtaylor.debian at googlemail dot com Created attachment 33538 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33538&action=edit preprocessed source with gcc 5 current svn rev 215503 attached file creates an ICE. Bisection showed it was caused by rev 214899 the fix to PR60655. $ gcc-5.0 -v -g -O2 -std=c99 -fopenmp -c image_iqe.i -fPIC Using built-in specs. COLLECT_GCC=/scratch/jtaylor/gcc/local-trunk/bin//gcc Target: x86_64-unknown-linux-gnu Configured with: /tmp/jtaylor/gcc.git/configure --disable-werror --enable-languages=c,c++,fortran --enable-tls --prefix=/scratch/jtaylor/gcc/local-trunk --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr --with-cloog=/usr --with-ppl=/usr --with-isl=/usr --disable-bootstrap Thread model: posix gcc version 5.0.0 20140923 (experimental) (GCC) COLLECT_GCC_OPTIONS='-ftrack-macro-expansion=2' '-v' '-g' '-O2' '-std=c99' '-fopenmp' '-c' '-fPIC' '-o' '/scratch/jtaylor/data/ccache/4/2/b32515ef366d48ae6a990ef3c32265-38727.o.tmp.ga014413.9629' '-mtune=generic' '-march=x86-64' '-pthread' /scratch/jtaylor/gcc/local-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1 -fpreprocessed image_iqe.i -quiet -dumpbase image_iqe.i -mtune=generic -march=x86-64 -auxbase-strip /scratch/jtaylor/data/ccache/4/2/b32515ef366d48ae6a990ef3c32265-38727.o.tmp.ga014413.9629 -g -O2 -std=c99 -version -ftrack-macro-expansion=2 -fopenmp -fPIC -o /tmp/ccq5QE77.s GNU C (GCC) version 5.0.0 20140923 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 5.0.0 20140923 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: b7b329711fd6ccb5f987647fb148652d image_iqe.c: In function ‘g2efunc’: image_iqe.c:90:1: internal compiler error: in loc_list_from_tree, at dwarf2out.c:14698 } ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341
--- Comment #6 from Jakub Jelinek ---
Another testcase:
typedef union U { unsigned short s; unsigned char c; } __attribute__((packed))
U;
struct S { char e __attribute__((aligned (16))); U s[32]; };
struct S t = {0, {{0x5010}, {0x5111}, {0x5212}, {0x5313}, {0x5414}, {0x5515},
{0x5616}, {0x5717},
{0x5818}, {0x5919}, {0x5a1a}, {0x5b1b}, {0x5c1c}, {0x5d1d}, {0x5e1e},
{0x5f1f},
{0x6020}, {0x6121}, {0x6222}, {0x6323}, {0x6424}, {0x6525}, {0x6626},
{0x6727},
{0x6828}, {0x6929}, {0x6a2a}, {0x6b2b}, {0x6c2c}, {0x6d2d}, {0x6e2e},
{0x6f2f}}};
unsigned short d[32];
int
main ()
{
int i;
for (i = 0; i < 32; i++)
d[i] = t.s[i].s + 4;
for (i = 0; i < 32; i++)
if (d[i] != t.s[i].s + 4)
__builtin_abort ();
else
asm volatile ("" : : : "memory");
return 0;
}
which fails similarly. For both testcases, if I manually change the addi
9,10,15 instruction to addi 9,10,16, it passes.
That instruction corresponds to the *.vect created:
vectp_t.9_3 = &MEM[(void *)&t + 15B];
and I change it to
vectp_t.9_3 = &MEM[(void *)&t + 16B];
Here is what the vectorizer emits for this second testcase:
:
vectp_t.5_19 = &MEM[(void *)&t + 1B];
vectp_t.5_5 = vectp_t.5_19 & 4294967280B;
vect__7.3_4 = MEM[(short unsigned int *)vectp_t.5_5];
vect__7.6_2 = __builtin_altivec_mask_for_load (vectp_t.5_19);
vectp_t.9_3 = &MEM[(void *)&t + 15B];
vect_cst_.13_33 = { 4, 4, 4, 4, 4, 4, 4, 4 };
vectp_d.15_35 = &d;
:
# i_24 = PHI
# ivtmp_21 = PHI
# vect__7.7_1 = PHI
# vectp_t.8_28 = PHI
# vectp_d.14_36 = PHI
# ivtmp_9 = PHI
vectp_t.8_30 = vectp_t.8_28 & 4294967280B;
vect__7.10_31 = MEM[(short unsigned int *)vectp_t.8_30];
vect__7.11_32 = REALIGN_LOAD ;
_7 = t.s[i_24].s;
vect__8.12_34 = vect__7.11_32 + vect_cst_.13_33;
_8 = _7 + 4;
MEM[(short unsigned int *)vectp_d.14_36] = vect__8.12_34;
i_10 = i_24 + 1;
ivtmp_20 = ivtmp_21 - 1;
vectp_t.8_29 = vectp_t.8_28 + 16;
vectp_d.14_37 = vectp_d.14_36 + 16;
ivtmp_39 = ivtmp_9 + 1;
if (ivtmp_39 < 4)
goto ;
else
goto ;
:
goto ;
SSA_NAMEs _1, _31 aren't really used for anything but arguments for
REALIGN_LOAD, so as long as the targets that support this (seems only rs6000
and spu)
handle the misaligned units fine (it is about whether
__builtin_altivec_mask_for_load computes the right mask for the permutations),
I'd say just fixing up the offset should be all that is needed.
Note that at least two of the three negative == true cases I saw on one x86_64
testcase use negative offset and depend on it not to have the low bits set
(so offset -7 must become -14 for V8HImode and not -15).
So, at least as a hack, adding step - 1 to offset in
vect_create_addr_base_for_vector_ref if offset is non-NULL and positive might
DTRT (because in all the 3 negative cases offset will be negative).
But perhaps cleaner will be a bool flag that the offset is already in bytes or
something similar.
[Bug c++/61945] [5 Regression] tree check fail with -Woverloaded-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-23 CC||trippels at gcc dot gnu.org Known to work||4.8.3, 4.9.1 Version|4.9.2 |5.0 Target Milestone|--- |5.0 Summary|tree check fail with|[5 Regression] tree check |-Woverloaded-virtual|fail with ||-Woverloaded-virtual Ever confirmed|0 |1 Known to fail||5.0 --- Comment #2 from Markus Trippelsdorf --- Also happens during Firefox build.
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341
--- Comment #5 from Richard Biener ---
Note that vect_create_addr_base_for_vector_ref _does_ multiply offset by
the scalar element size (even if it calls it 'step'):
tree step = TYPE_SIZE_UNIT (TREE_TYPE (DR_REF (dr)));
...
if (offset)
{
offset = fold_build2 (MULT_EXPR, sizetype,
fold_convert (sizetype, offset), step);
so that would be consistent with the interpretation and all uses I can see.
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341 --- Comment #4 from Richard Biener --- Btw, should be reproducible with negative step cases on x86_64 as well, as we do there if (negative) offset = size_int (-TYPE_VECTOR_SUBPARTS (vectype) + 1); ? I suppose interpreting offset in terms of scalar element size is what was intended.
[Bug c++/61857] An init-capturing lambda is parsed incorrectly when used in a braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61857 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- Mine.
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341 --- Comment #3 from Richard Biener --- Hum, from the comment on vect_create_data_ref_ptr I would expect offset to be in units of the _vector_ size ... Output: 1. Declare a new ptr to vector_type, and have it point to the base of the data reference (initial addressed accessed by the data reference). For example, for vector of type V8HI, the following code is generated: v8hi *ap; ap = (v8hi *)initial_address; if OFFSET is not supplied: initial_address = &a[init]; if OFFSET is supplied: initial_address = &a[init + OFFSET]; Return the initial_address in INITIAL_ADDRESS. looking at the implementation it expects byte offsets.
[Bug lto/62026] [4.9/5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026
--- Comment #13 from Markus Trippelsdorf ---
A bit more reduced (just testing upcoming creduce release):
class C;
class F {
virtual C m_fn1();
};
class C {
public:
virtual int *m_fn3(int);
};
class G : F, C {
int offsets;
int *m_fn3(int);
};
C *a;
int *G::m_fn3(int) {
if (offsets) return 0;
}
void fn1() {
for (;;) a->m_fn3(0);
}
[Bug c++/61945] tree check fail with -Woverloaded-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945
--- Comment #1 from tbsaunde at gcc dot gnu.org ---
minimized test case
class A
{
virtual void NotifyDialMMISuccess();
};
class : A
{
template <0> void NotifyDialMMISuccess();
};
ICEs with g++ -Woverloaded-virtual -std=gnu++11
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341 --- Comment #2 from Jakub Jelinek --- I see non-NULL offset passed to vect_create_data_ref_ptr by vectorizable_store (for negative case), vectorizable_load (for this dr_explicit_realign_optimized), and to vect_create_addr_base_for_vector_ref in vect_gen_niters_for_prolog_loop (for negative case) and vect_create_cond_for_align_checks (also for negative case). So guess we'd need to check all these cases what we really want in those cases.
[Bug lto/62026] [4.9/5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #12 from Martin Jambor --- Thanks a lot for the testcase. I have talked about it with Honza on IRC yesterday he said that that the problem was that lto_output() was attempting to copy the function instead of outputting it and that he would have a look ;-)
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |4.8.4
Summary|[4.8/4.9/5 |[4.8/4.9/5 Regression]
|RegressionVectorizer|Vectorization
||miscompilation with
||-mcpu=power7
--- Comment #1 from Jakub Jelinek ---
The following testcase is miscompiled on powerpc64-linux with -O2
-ftree-vectorize -m32 -mcpu=power7 -mtune=power7:
typedef union U { unsigned short s; unsigned char c; } __attribute__((packed))
U;
struct S { char e __attribute__((aligned (16))); U s[32]; };
struct S t = {0, {{1}, {2}, {3}, {4}, {5}, {6}, {7}, {8},
{9}, {10}, {11}, {12}, {13}, {14}, {15}, {16},
{17}, {18}, {19}, {20}, {21}, {22}, {23}, {24},
{25}, {26}, {27}, {28}, {29}, {30}, {31}, {32}}};
unsigned short d[32];
int
main ()
{
int i;
for (i = 0; i < 32; i++)
d[i] = t.s[i].s;
if (__builtin_memcmp (d, t.s, sizeof d))
__builtin_abort ();
return 0;
}
The problem as I see is that the loop is vectorized with
dr_explicit_realign_optimized, and calls vect_create_data_ref_ptr with offset
of TYPE_VECT_SUBPARTS (type) - 1, which is 7 in this case. This function
then calls vect_create_addr_base_for_vector_ref which multiplies the offset
by step (2 in this case), and thus adds 14 bytes to the base address. The
base address is &t + 1 and &t is 16 bytes aligned, so it loads the first part
from (&t + 1) & -16 (correct) and the second part from (&t + 1 + 14) & -16,
which is still wrong, because (&t + 15) & -16 is still &t, not &t + 16 we want
to use. The problem is that as the offset given to vect_create_data_ref_ptr is
not in bytes, but in number of subparts, after multiplying it by step we end up
with offset that doesn't have the lowest bit(s) set, which is required for this
kind of realignment. Richard, thoughts on this? Either we'd need the offset
always already in bytes and let all the callers ensure it is in bytes, or some
flag whether offset is in bytes or units, or some flag to add not just
offset * step, but offset * step + (step - 1), or do that always.
[Bug rtl-optimization/63340] [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340
--- Comment #3 from Andreas Schwab ---
Reduced:
extern void abort (void);
extern void exit (int);
#define TEST_COMPOUND(TYPE, LHSVAL, RHSVAL, OP)\
do\
{\
static volatile _Atomic (TYPE) a = (TYPE) (LHSVAL);\
if ((a OP##= (RHSVAL)) != (TYPE) ((TYPE) (LHSVAL) OP (RHSVAL)))\
abort ();\
if (a != (TYPE) ((TYPE) (LHSVAL) OP (RHSVAL)))\
abort ();\
}\
while (0)
#define TEST_COMPOUND_ARITH(LHSVAL, RHSVAL, OP)\
do\
{\
TEST_COMPOUND (float, (LHSVAL), (RHSVAL), OP);\
TEST_COMPOUND (double, (LHSVAL), (RHSVAL), OP);\
}\
while (0)
static void
test_mult (void)
{
TEST_COMPOUND_ARITH (1, 2, *);
}
int
main (void)
{
test_mult ();
exit (0);
}
[Bug tree-optimization/63341] New: [4.8/4.9/5 RegressionVectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341 Bug ID: 63341 Summary: [4.8/4.9/5 RegressionVectorizer Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org
[Bug rtl-optimization/63340] [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340 --- Comment #2 from Andreas Schwab --- setf.s f6 = r14 vs. setf.sig f6 = r14 setf.d f6 = r14 vs. setf.sig f6 = r14
[Bug rtl-optimization/63340] [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug rtl-optimization/63340] [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340 --- Comment #1 from Andreas Schwab --- Created attachment 33537 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33537&action=edit Assembler output w/ r215449 reverted
[Bug rtl-optimization/63340] New: [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340 Bug ID: 63340 Summary: [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: rsandifo at gcc dot gnu.org Target: ia64-*-* Created attachment 33536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33536&action=edit Assembler output Broken by r215449. $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c -Bia64-suse-linux/./libatomic/ -Lia64-suse-linux/./libatomic/.libs -latomic -O2 -std=c11 -pedantic-errors -lm -o ./c11-atomic-exec-2.exe $ LD_LIBRARY_PATH=:gcc:ia64-suse-linux/./libatomic/.libs::gcc:ia64-suse-linux/./libatomic/.libs:ia64-suse-linux/libstdc++-v3/src/.libs:ia64-suse-linux/libssp/.libs:ia64-suse-linux/libgomp/.libs:ia64-suse-linux/libatomic/.libs:./gcc:./prev-gcc ./c11-atomic-exec-2.exe Aborted (gdb) bt #0 0xa0040721 in __kernel_syscall_via_break () #1 0x201d3190 in *__GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 #2 0x201d5a70 in *__GI_abort () at abort.c:92 #3 0x40016ac0 in test_mult () at ../gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:67 #4 0x47f0 in main () at ../gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:160 (gdb) f 3 #3 0x40016ac0 in test_mult () at ../gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:67 67TEST_COMPOUND_ARITH (1, 2, *);
[Bug lto/63333] lto, 1to1 segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-23 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- No, there are no known debug-info related ICEs with LTO on 4.9 - please provide a testcase.
[Bug testsuite/61606] About GCC install, testing step (mostly check...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61606 --- Comment #2 from Fernando G. Tinetti --- (In reply to kargl from comment #1) > (In reply to Fernando G. Tinetti from comment #0) > > Hi, > > > > I'm making my own todo list for GCC install from sources, given that at some > > point I would like to contribute to gfortran, if possible (I'm rather far > > from it right now). Just to be clear, my todo list to install from sources > > is at > > http://fernando.usr.me/GCC-gfortran-install.html > > (maybe it would be useful some day for enhancing the online documentation... > > maybe not...). > > > > Please the installation instructions at https://gcc.gnu.org/install/ > Your custom installation method as outlines in your blog above is > clearly broken. > > -- > steve Hi steve, thanks for asking. I cannot see how "is clearly broken", I think I've followed the installation steps you point out (also referred to in my "custom method"). Would you please tell me what I did miss/misunderstand/broke? I'm also confused since following the steps in my custom method actually works at least sometimes, and the initial difference is "only" about the reported timeout in the failing cases. Also, please take a look at my questions about >>> Is there a single way to look for PASS/FAIL answer to the GCC check >>> step? I mean: nothing went out of normal would mean PASS, otherwise >>> FAIL. >>> >>> Are the *.sum and *.log in the directories shown/used by >>> ../gcc-4.9.0/contrib/test_summary? since I cannot find the answers to these questions in the URL you provided. TIA, Fernando.
[Bug c++/58751] [C++11] Inheriting constructors do not work properly with virtual inheritance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58751 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-23 Ever confirmed|0 |1
[Bug middle-end/63338] Compiling large amounts of large switch cases takes a large amount of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63338 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-23 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- And what compiler options? With -O1 on x86_64-linux it takes around 1m30s to compile with GCC 4.8 with the biggest offenders being alias stmt walking : 64.95 (70%) usr 0.15 (12%) sys 65.11 (69%) wall 0 kB ( 0%) ggc tree SSA incremental: 11.83 (13%) usr 0.18 (14%) sys 12.04 (13%) wall 47726 kB (12%) ggc tree copy propagation : 4.12 ( 4%) usr 0.00 ( 0%) sys 4.13 ( 4%) wall 515 kB ( 0%) ggc TOTAL : 92.99 1.2994.23 383497 kB with GCC 4.9 this improves to alias stmt walking : 55.67 (66%) usr 0.26 (18%) sys 55.95 (65%) wall 0 kB ( 0%) ggc tree copy propagation : 4.90 ( 6%) usr 0.01 ( 1%) sys 4.94 ( 6%) wall 522 kB ( 0%) ggc tree SSA incremental: 10.89 (13%) usr 0.20 (14%) sys 11.02 (13%) wall 47751 kB (12%) ggc TOTAL : 83.95 1.4585.55 390402 kB most time is spent in early local cleanups at -O1. With -O2 GCC 4.9 takes 95s.
[Bug c++/62155] ICE in tsubst_copy, at cp/pt.c:12544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62155 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Paolo Carlini --- Done.
[Bug c++/62155] ICE in tsubst_copy, at cp/pt.c:12544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62155 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 23 08:09:14 2014 New Revision: 215497 URL: https://gcc.gnu.org/viewcvs?rev=215497&root=gcc&view=rev Log: 2014-09-23 Paolo Carlini PR c++/62155 * g++.dg/cpp0x/lambda/lambda-62155.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-62155.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/62155] ICE in tsubst_copy, at cp/pt.c:12544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62155 --- Comment #1 from Paolo Carlini --- Since it's just an ICE on invalid, I'm adding the testcase and closing the bug.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 Michael T. changed: What|Removed |Added CC||m.j.thayer at googlemail dot com --- Comment #35 from Michael T. --- (In reply to Florian Weimer from comment #25) > I contemplated using any comment whatsoever as an indicator that > fall-through is expected. Coverity do that: http://security.coverity.com/blog/2013/Sep/gimme-a-break.html
