[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de --- I can confirm this problem on the GCC 4.9.0 release. This is a bit unfortunate since on 2014-04-17 everything was fine: http://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01349.html
[Bug tree-optimization/60930] [4.8/4.9/4.10 Regression] Wrong folding of - ((unsigned long long) a * (unsigned long long) (unsigned int)-1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60930
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-04-23
CC||jakub at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
Target Milestone|--- |4.8.3
Summary|Wrong folding of - |[4.8/4.9/4.10 Regression]
|((unsigned long long) a * |Wrong folding of -
|(unsigned long long)|((unsigned long long) a *
|(unsigned int)-1) |(unsigned long long)
||(unsigned int)-1)
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Indeed, started with r188989.
int x = 1;
__attribute__((noinline, noclone)) void
foo (unsigned long long t)
{
asm volatile ( : : r (t));
if (x == 1)
__builtin_abort ();
}
int
main ()
{
unsigned long long t = 0xULL * (0xUL * x);
if (t != 0x0001ULL)
foo (t);;
return 0;
}
[Bug tree-optimization/60902] [4.9/4.10 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 --- Comment #27 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #26) Testing is good. Just trying to build a nice little testcase for the regression suite. Thanks. Another thing I've noticed is that ac3 audio doesn't work (no sound at all) when ffmpeg is compiled by gcc-4.9. I haven't figured it out yet, but it appears to be a different issue, because it also happens with r205279 reverted.
[Bug go/60931] New: libgo has issues when page size is not 4k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931 Bug ID: 60931 Summary: libgo has issues when page size is not 4k Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: anton at samba dot org Created attachment 32659 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32659action=edit Bump page size to 64kB We are seeing random failures with go programs on a 64kB page size ppc64 box. It looks like garbage collection issues - sometimes we SEGV in timer code, sometimes we SEGV in the code that wraps a kernel read syscall. If I prevent the garbage collector from running, the programs work. The libgo malloc hard codes the page size so I wrote a quick hack to bump this (and a few other dependent variables). This makes the problem go away, but we will need to come up with a better way to do this at runtime.
[Bug go/60931] libgo has issues when page size is not 4k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is going to be true on AARCH64 also where most distros are going to be using 64k pages (some might use 4k pages if they also support AARCH32). MIPS has many different page sizes too (4k, 8k, 16k, 32k, and 64k). So hard coding the page size seems wrong, maybe you should call getpagesize instead.
[Bug c/60932] New: stdatomic.h is not C++ compatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 Bug ID: 60932 Summary: stdatomic.h is not C++ compatible Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Should stdatomic.h work with C++? I use GCC as a cross-compiler for RTEMS targets. RTEMS uses Newlib as C library. I ported the FreeBSD version of stdatomic.h to Newlib and use this successfully with C/C++ and GCC pre-4.9 versions. http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?revision=263998view=markup Now with GCC 4.9 I have the problem that two stdatomic.h files are installed, e.g. find /opt/rtems-4.11/ -name stdatomic.h /opt/rtems-4.11/lib64/gcc/sparc-rtems4.11/4.9.0/include/stdatomic.h /opt/rtems-4.11/sparc-rtems4.11/include/stdatomic.h The first is provided by GCC, the second by Newlib. The GCC version is the one used. Now I get this when I compile a C++ source which indirectly includes stdatomic.h: sparc-rtems4.11-g++ -std=c++11 somefile.cc /opt/rtems-4.11/lib64/gcc/sparc-rtems4.11/4.9.0/include/stdatomic.h:40:9: error: '_Atomic' does not name a type typedef _Atomic _Bool atomic_bool; Is this working as intended?
[Bug go/60931] libgo has issues when page size is not 4k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931 --- Comment #2 from Anton Blanchard anton at samba dot org --- I agree, but when I tried this I found a few places that expect PageSize to be a compile time constant so it is not as trivial as I had hoped.
[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added Summary|[4.10 regression] Memory |[4.9/4.10 regression] |leak with INTENT(OUT) CLASS |Memory leak with |argument w/ allocatable |INTENT(OUT) CLASS argument |CLASS components|w/ allocatable CLASS ||components --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it --- Yup, it is a regression in 4.9.0 as well. [sfilippo@epsilon IMAGING]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/gnu/4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.0/configure --prefix=/opt/gnu/4.9.0 --enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp --with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc --with-cloog=/usr/local/travel/GNU/cloog Thread model: posix gcc version 4.9.0 (GCC) [sfilippo@epsilon IMAGING]$ gfortran -o test_leak_490 -O3 test_leak.f90 [sfilippo@epsilon IMAGING]$ valgrind ./test_leak_490 ==4473== Memcheck, a memory error detector ==4473== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==4473== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==4473== Command: ./test_leak_490 ==4473== Iteration1 Iteration2 ==4473== ==4473== HEAP SUMMARY: ==4473== in use at exit: 6,291,552 bytes in 5 blocks ==4473== total heap usage: 32 allocs, 27 frees, 10,497,741 bytes allocated ==4473== ==4473== LEAK SUMMARY: ==4473==definitely lost: 48 bytes in 1 blocks ==4473==indirectly lost: 2,097,152 bytes in 1 blocks ==4473== possibly lost: 0 bytes in 0 blocks ==4473==still reachable: 4,194,352 bytes in 3 blocks ==4473== suppressed: 0 bytes in 0 blocks ==4473== Rerun with --leak-check=full to see details of leaked memory ==4473== ==4473== For counts of detected and suppressed errors, rerun with: -v ==4473== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
[Bug sanitizer/60275] [UBSAN] Add -f[no-]sanitize-recover/-fsanitize-undefined-trap-on-error to make UBSAN's runtime errors fatal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60275 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Apr 23 08:20:12 2014 New Revision: 209672 URL: http://gcc.gnu.org/viewcvs?rev=209672root=gccview=rev Log: PR sanitizer/60275 * common.opt (fsanitize-recover, fsanitize-undefined-trap-on-error): New options. * gcc.c (sanitize_spec_function): Don't return for undefined if flag_sanitize_undefined_trap_on_error. * sanitizer.def (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW_ABORT, BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS_ABORT, BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE_ABORT, BUILT_IN_UBSAN_HANDLE_TYPE_MISMATCH_ABORT, BUILT_IN_UBSAN_HANDLE_ADD_OVERFLOW_ABORT, BUILT_IN_UBSAN_HANDLE_SUB_OVERFLOW_ABORT, BUILT_IN_UBSAN_HANDLE_MUL_OVERFLOW_ABORT, BUILT_IN_UBSAN_HANDLE_NEGATE_OVERFLOW_ABORT, BUILT_IN_UBSAN_HANDLE_LOAD_INVALID_VALUE_ABORT): New builtins. * ubsan.c (ubsan_instrument_unreachable): Return __builtin_trap () if flag_sanitize_undefined_trap_on_error. (ubsan_expand_null_ifn): Emit __builtin_trap () if flag_sanitize_undefined_trap_on_error and __ubsan_handle_type_mismatch_abort if !flag_sanitize_recover. (ubsan_expand_null_ifn, ubsan_build_overflow_builtin, instrument_bool_enum_load): Emit __builtin_trap () if flag_sanitize_undefined_trap_on_error and __builtin_handle_*_abort () if !flag_sanitize_recover. * doc/invoke.texi (-fsanitize-recover, -fsanitize-undefined-trap-on-error): Document. c-family/ * c-ubsan.c (ubsan_instrument_return): Return __builtin_trap () if flag_sanitize_undefined_trap_on_error. (ubsan_instrument_division, ubsan_instrument_shift, ubsan_instrument_vla): Likewise. Use __ubsan_handle_*_abort () if !flag_sanitize_recover. testsuite/ * g++.dg/ubsan/return-2.C: Revert 2014-03-24 changes, add -fno-sanitize-recover to dg-options. * g++.dg/ubsan/cxx11-shift-1.C: Remove c++11 target restriction, add -std=c++11 to dg-options. * g++.dg/ubsan/cxx11-shift-2.C: Likewise. * g++.dg/ubsan/cxx1y-vla.C: Remove c++1y target restriction, add -std=c++1y to dg-options. * c-c++-common/ubsan/undefined-1.c: Revert 2014-03-24 changes, add -fno-sanitize-recover to dg-options. * c-c++-common/ubsan/overflow-sub-1.c: Likewise. * c-c++-common/ubsan/vla-4.c: Likewise. * c-c++-common/ubsan/pr59503.c: Likewise. * c-c++-common/ubsan/vla-3.c: Likewise. * c-c++-common/ubsan/save-expr-1.c: Likewise. * c-c++-common/ubsan/overflow-add-1.c: Likewise. * c-c++-common/ubsan/shift-3.c: Likewise. * c-c++-common/ubsan/overflow-1.c: Likewise. * c-c++-common/ubsan/overflow-negate-2.c: Likewise. * c-c++-common/ubsan/vla-2.c: Likewise. * c-c++-common/ubsan/overflow-mul-1.c: Likewise. * c-c++-common/ubsan/pr60613-1.c: Likewise. * c-c++-common/ubsan/shift-6.c: Likewise. * c-c++-common/ubsan/overflow-mul-3.c: Likewise. * c-c++-common/ubsan/overflow-add-3.c: New test. * c-c++-common/ubsan/overflow-add-4.c: New test. * c-c++-common/ubsan/div-by-zero-6.c: New test. * c-c++-common/ubsan/div-by-zero-7.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/div-by-zero-6.c trunk/gcc/testsuite/c-c++-common/ubsan/div-by-zero-7.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-add-3.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-add-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-ubsan.c trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/gcc.c trunk/gcc/sanitizer.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/ubsan/overflow-1.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-add-1.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-mul-1.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-mul-3.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-negate-2.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-sub-1.c trunk/gcc/testsuite/c-c++-common/ubsan/pr59503.c trunk/gcc/testsuite/c-c++-common/ubsan/pr60613-1.c trunk/gcc/testsuite/c-c++-common/ubsan/save-expr-1.c trunk/gcc/testsuite/c-c++-common/ubsan/shift-3.c trunk/gcc/testsuite/c-c++-common/ubsan/shift-6.c trunk/gcc/testsuite/c-c++-common/ubsan/undefined-1.c trunk/gcc/testsuite/c-c++-common/ubsan/vla-2.c trunk/gcc/testsuite/c-c++-common/ubsan/vla-3.c trunk/gcc/testsuite/c-c++-common/ubsan/vla-4.c trunk/gcc/testsuite/g++.dg/ubsan/cxx11-shift-1.C trunk/gcc/testsuite/g++.dg/ubsan/cxx11-shift-2.C trunk/gcc/testsuite/g++.dg/ubsan/cxx1y-vla.C trunk/gcc/testsuite/g++.dg/ubsan/return-2.C trunk/gcc/ubsan.c
[Bug tree-optimization/60891] [4.9/4.10 Regression] ICE: SIGSEGV (Invalid write/read) in pre_and_rev_post_order_compute_fn with -O -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60891 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 08:23:33 2014 New Revision: 209673 URL: http://gcc.gnu.org/viewcvs?rev=209673root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de PR middle-end/60891 * loop-init.c (loop_optimizer_init): Make sure to apply LOOPS_MAY_HAVE_MULTIPLE_LATCHES before fixing up loops. * gcc.dg/torture/pr60891.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr60891.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-init.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/60891] [4.9/4.10 Regression] ICE: SIGSEGV (Invalid write/read) in pre_and_rev_post_order_compute_fn with -O -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60891 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 08:25:56 2014 New Revision: 209674 URL: http://gcc.gnu.org/viewcvs?rev=209674root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de PR middle-end/60891 * loop-init.c (loop_optimizer_init): Make sure to apply LOOPS_MAY_HAVE_MULTIPLE_LATCHES before fixing up loops. * gcc.dg/torture/pr60891.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr60891.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/loop-init.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/60895] [4.8/4.9/4.10 Regression] error: address taken, but ADDRESSABLE bit not set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60895 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 08:27:00 2014 New Revision: 209675 URL: http://gcc.gnu.org/viewcvs?rev=209675root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de PR middle-end/60895 * tree-inline.c (declare_return_variable): Use mark_addressable. * g++.dg/torture/pr60895.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr60895.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug tree-optimization/60895] [4.8/4.9/4.10 Regression] error: address taken, but ADDRESSABLE bit not set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60895 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 08:27:37 2014 New Revision: 209676 URL: http://gcc.gnu.org/viewcvs?rev=209676root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de PR middle-end/60895 * tree-inline.c (declare_return_variable): Use mark_addressable. * g++.dg/torture/pr60895.C: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/torture/pr60895.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-inline.c
[Bug tree-optimization/60891] [4.9/4.10 Regression] ICE: SIGSEGV (Invalid write/read) in pre_and_rev_post_order_compute_fn with -O -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60891 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.10.0, 4.9.1 Resolution|--- |FIXED Known to fail|4.10.0 | --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/60895] [4.8 Regression] error: address taken, but ADDRESSABLE bit not set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60895 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.10.0, 4.9.1 Summary|[4.8/4.9/4.10 Regression] |[4.8 Regression] error: |error: address taken, but |address taken, but |ADDRESSABLE bit not set |ADDRESSABLE bit not set Known to fail||4.9.0
[Bug lto/60720] clisp fails to build with -flto: internal compiler error: tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60720 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 08:31:48 2014 New Revision: 209677 URL: http://gcc.gnu.org/viewcvs?rev=209677root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de Backport from mainline 2014-04-14 Richard Biener rguent...@suse.de PR lto/60720 * lto-streamer-out.c (wrap_refs): New function. (lto_output): Wrap symbol references in global initializes in type-preserving MEM_REFs. * gcc.dg/lto/pr60720_0.c: New testcase. * gcc.dg/lto/pr60720_1.c: Likewise. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr60720_0.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr60720_1.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/lto-streamer-out.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug lto/60720] clisp fails to build with -flto: internal compiler error: tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60720 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.1 Target Milestone|--- |4.9.1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed for 4.9.1.
[Bug lto/60720] clisp fails to build with -flto: internal compiler error: tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60720 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug bootstrap/60923] Building of gcc fails on sparc solaris 9, In function '__muldi3' internal compiler error: Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60923 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-23 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Severity|blocker |normal --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- But this works for everyone else so you'll need to debug yourself... A few remarks/questions: 1. What does this gcc64 mean in the various paths? 2. What's the base compiler? 3. Which binutils (as/ld) version?
[Bug tree-optimization/60930] [4.8/4.9/4.10 Regression] Wrong folding of - ((unsigned long long) a * (unsigned long long) (unsigned int)-1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60930 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||x86_64-*-*, i?86-*-* Priority|P3 |P2
[Bug debug/60929] [4.8/4.9/4.10 regression] ICE in get_ref_die_offset, at dwarf2out.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60929 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-23 Known to work||4.7.3 Target Milestone|--- |4.8.3 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug target/60925] [4.9/4.10 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.1 Summary|[4.9 Regression] hppa: |[4.9/4.10 Regression] hppa: |can't find a register in|can't find a register in |class 'R1_REGS' while |class 'R1_REGS' while |reloading 'asm' |reloading 'asm'
[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P4 Target Milestone|--- |4.9.1
[Bug sanitizer/60275] [UBSAN] Add -f[no-]sanitize-recover/-fsanitize-undefined-trap-on-error to make UBSAN's runtime errors fatal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60275 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Implemented now.
[Bug bootstrap/60923] Building of gcc fails on sparc solaris 9, In function '__muldi3' internal compiler error: Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60923 --- Comment #2 from Mukul Gupta mukul.gupta at aricent dot com --- (In reply to Eric Botcazou from comment #1) But this works for everyone else so you'll need to debug yourself... A few remarks/questions: 1. What does this gcc64 mean in the various paths? 2. What's the base compiler? 3. Which binutils (as/ld) version? Hi Eric, I am not that knowledgeable about how compilers are implemented, so i doubt that i will be able to debug it myself. 1. It's just a notation to state that we will be using this compiler to build 64 bit applications. 2. Base compiler is 3.4.6 # /usr/local/bin/gcc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.6 3. Binutils version: 2.18
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |c++ Summary|stdatomic.h is not C++|make stdatomic.h compatible |compatible |with C++ Severity|normal |enhancement --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The answer is no. Use atomic for C++11 code instead (since that is what the standard defines).
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #27 from Mircea Namolaru mircea.namolaru at inria dot fr --- Hi, Many thanks. I've passed over the meta-bug opened by you for Graphite, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 and seems to me that many of the problem have been already solved (some by you) or at least as in case of some compile-time/memory usage/missed optimization issues we know how to solve it - some form of delinearization of array accesses that for sure was not for GCC 4.9. Btw, there is also another Graphite bug in this list http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586 that was solved but didn't make it for GCC 4.9.0. Mircea - Original Message - From: rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: mircea namolaru mircea.namol...@inria.fr Sent: Tuesday, April 22, 2014 3:34:09 PM Subject: [Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #26 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Apr 22 13:33:37 2014 New Revision: 209633 URL: http://gcc.gnu.org/viewcvs?rev=209633root=gccview=rev Log: 2014-04-22 Richard Biener rguent...@suse.de Backport from mainline 2014-04-14 Richard Biener rguent...@suse.de PR middle-end/55022 * fold-const.c (negate_expr_p): Don't negate directional rounding division. (fold_negate_expr): Likewise. * gcc.dg/graphite/pr55022.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr55022.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/fold-const.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog -- You are receiving this mail because: You are on the CC list for the bug.
[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 --- Comment #2 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Sorry, but my test run on 2014-04-17 used --disable-multilib, so it didn't build the multilib in question. So the problem was also present on 2014-04-17.
[Bug web/60933] New: Please do not advertise outdated version of gmp, mpfr, mpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
Bug ID: 60933
Summary: Please do not advertise outdated version of gmp, mpfr,
mpc
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: andreas.enge at inria dot fr
This problem does not only concern the web, but documentation of
prerequisites in a broader sense.
On the mailing lists of gmp, mpfr and mpc we regularly receive reports with
installation errors concerning very old and no longer maintained versions of
our software, which creates quite some noise. For instance,
https://gmplib.org/~tege/stats/usage_201404.html#TOPURLS
shows that gmp-4.3.2 is the most downloaded version, while gmp-5.0.0 came out
in early 2010, and gmp-6.0.0 this year. Mpc-1.0.0 came out in fall 2012, and
the 0.8 and 0.9 branches are no longer maintained.
I believe the culprit is gcc too actively promoting the minimally required
versions of the libraries. It is fine if gcc still compiles with older
versions, but all communication should point to the most recent releases.
For instance, trying to install gcc-4.9.0 without gmp results in the following:
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
http://gcc.gnu.org/install/prerequisites.html for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.
(As an aside, the minimal version numbers seem to be wrong here.) Your ftp
server mentioned in the message provides the outdated libraries corresponding
to the minimal versions with which gmp compiles (and not even the latest bug
fix release in a given release series). If you provide our libraries on your
server, please make sure to always copy the most up-to-date release. Or if this
is too much work, you may prefer to link to ftp.gnu.org/gnu/{gmp,mpfr,mpc}.
On the web at:
http://gcc.gnu.org/install/prerequisites.html
the text
GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
could be changed to something like:
GNU Multiple Precision Library (GMP), preferably the latest version,
but at least 4.3.2.
I did not make an exhaustive search of the gcc documentation, but there may be
other places where you could point to the most recent gmp, mpfr and mpc
releases to ease our work and to make sure people use up-to-date software in
conjunction with gcc.
Your collaboration is very much appreciated.
Andreas
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731
Ondrej Bilka neleai at seznam dot cz changed:
What|Removed |Added
CC||neleai at seznam dot cz
--- Comment #9 from Ondrej Bilka neleai at seznam dot cz ---
I started to looking what STB_UNIQUE purpose is so I have several questions.
First does suggestion below really work?
http://gcc.gnu.org/ml/gcc-help/2011-05/msg00450.html
Say you have foo.so with unique symbol foo and function
bar *getfoo() {
return (void *) foo;
}
which gets loaded and unloaded like
void *h = dlopen(foo.so,RTLD_NOW);
bar *p1 = dlsym(h,getfoo)();
dlclose(h);
foo-baz();
h = dlopen(foo.so,RTLD_NOW);
bar *p2 = dlsym(h,getfoo)();
dlclose(h);
Are p1 and p2 supposed to point to same object?
Also is foo-baz(); legal or not? If its so we cannot call destructors.
There could be fix to add zombie state where we call destructors but not free
memory so we can reinitialize object at same address but I need to know that
calling destructor is always intended behaviour.
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 --- Comment #2 from Sebastian Huber sebastian.hu...@embedded-brains.de --- So I cannot use C libraries using atomics with C++ on GCC targets? With FreeBSD and clang this works fine.
[Bug tree-optimization/60903] [4.8/4.9/4.10 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647: : edge from 13 to 14 should be marked irreducible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60903 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- LIM is the culprit - it does CFG building but those don't properly update BB/EDGE_IRREDUCIBLE_LOOP.
[Bug tree-optimization/60902] [4.9/4.10 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 --- Comment #28 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #27) (In reply to Jeffrey A. Law from comment #26) Testing is good. Just trying to build a nice little testcase for the regression suite. Another thing I've noticed is that ac3 audio doesn't work (no sound at all) when ffmpeg is compiled by gcc-4.9. I haven't figured it out yet, but it appears to be a different issue, because it also happens with r205279 reverted. Luckily this issue is already fixed on the gcc-4.9 branch.
[Bug c++/60924] __attribute__((no_sanitize_address)) and friends should (only?) be allowed at function definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60924 --- Comment #5 from Timur Iskhodzhanov timu at google dot com --- Jakub wrote: all other attributes are allowed on both declarations and definitions Can you please point me at the documentation that says that attributes are allowed on definitions? The page I referenced above only mentions declarations. Also, I believe all the existing/old attributes do X, so all the new ones should do X as well isn't an optimal long-term strategy. It's just not flexible / generic enough. Andrew wrote: More consistent with what By more consistent I meant there will be fewer ways to use the attribute and this would reduce the number of places one has to look at to find out whether a given attribute is applied. Is there is only one coding style in this world? This is indeed subjective. Still, I think my point #3 (re: implementation detail) should be true in most reasonable coding styles? Modules for the win. True -- but they aren't used yet in most codebases AFAICT :)
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Sebastian Huber from comment #2)
So I cannot use C libraries using atomics with C++ on GCC targets? With
FreeBSD and clang this works fine.
Until the c++ front-end implements _Atomic keyword, that is correct.
You could exactly what FreeBSD does (but take into account gcc 4.9 c front end
implementing _Atomic):
271#if !__has_extension(c_atomic) !__has_extension(cxx_atomic)
272/*
273 * No native support for _Atomic(). Place object in structure to prevent
274 * most forms of direct non-atomic access.
275 */
276#define _Atomic(T) struct { T volatile __val; }
277#endif
But this is not correct and in most cases broken. You could also just use c++11
atomic header.
[Bug bootstrap/60923] Building of gcc fails on sparc solaris 9, In function '__muldi3' internal compiler error: Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60923 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I am not that knowledgeable about how compilers are implemented, so i doubt that i will be able to debug it myself. Knowing compiler internals is not required, you just need to debug the segfault as for any other application. 3. Binutils version: 2.18 Very likely too old, please upgrade to 2.23 at this point.
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 --- Comment #4 from Sebastian Huber sebastian.hu...@embedded-brains.de --- It is surely not the fault of GCC developers that C and C++ diverge more and more, but for embedded systems developers this is quite painful. It is clear that you cannot use C++ header files from C. So if you want to provide a library intended for C and C++ applications you must use C as the base line. With this C++ incompatible stdatomic.h you cannot do this for applications requiring atomic operations. So you are forced to provide two implementations. I don't think this is the spirit of the atomics provided by the recent C/C++ standards. GCC provides also a C++ compatible stdbool.h for example.
[Bug tree-optimization/60902] [4.9/4.10 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 --- Comment #29 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #28) (In reply to Markus Trippelsdorf from comment #27) (In reply to Jeffrey A. Law from comment #26) Testing is good. Just trying to build a nice little testcase for the regression suite. Another thing I've noticed is that ac3 audio doesn't work (no sound at all) when ffmpeg is compiled by gcc-4.9. I haven't figured it out yet, but it appears to be a different issue, because it also happens with r205279 reverted. Luckily this issue is already fixed on the gcc-4.9 branch. Ah, it only happens with r205279 reverted. It could be a latent issue. Would be good to check if it happens with your fix, too. Could you attach your patch?
[Bug debug/59105] -fdebug-prefix-map doesn't affect DW_AT_comp_dir.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59105 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Pawel Sikora pluto at agmk dot net --- my fault, the trailing slash in -fdebug-prefix-map was a problem.
[Bug ipa/60912] [4.10 Regression] wrong code with -O -fno-inline -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60912 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Likely related to PR60911, waiting for that to be resolved.
[Bug ipa/60911] [4.9/4.10 Regression] wrong code with -O2 -flto -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- The issue is that IPA-PTA sees main () still as calling f but the cgraph has it calling f.constprop.0. For some reason the IPA-CP transform has not been applied to main () (yet?). In .simdclone I see a call to f.constprop.0. Honza? Martin? Late IPA passes need all regular IPA transforms applied and clones materialized.
[Bug c/60934] New: Strtoll Function Always Appears to Return 0 on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934
Bug ID: 60934
Summary: Strtoll Function Always Appears to Return 0 on Solaris
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: william.speak at sophos dot com
This bug seems to happen when two variables of `long long` and `double` are
declared in
a function with the same name.
A minimalistic example:
// bug.c
#include stdio.h
#include stdlib.h
int main(int argc, const char* argv[])
{
char* value = 12345;
char* end = NULL;
double bug;
{
long long bug = 6789;
bug = strtoll(value, end, 10);
printf(%ld\n, bug);
}
return 0;
}
Compiling with `gcc bug.c -o bug` and running with `./bug` produces
the follwing output:
$ ./bug
0
The expected output would be `12345`. Changing the type of the inner
`bug` to `long` or renaming it fixes the issue and `12345` is printed.
Running `gcc --version`:
gcc (GCC) 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.
Running `gcc -v`:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/toolchain/libexec/gcc/sparc-sun-solaris2.9/4.8.2/lto-wrapper
Target: sparc-sun-solaris2.9
Configured with: ../gcc-4.8.2/configure --prefix=/opt/toolchain
--with-gmp=/opt/toolchain --with-mpfr=/opt/toolchain --with-mpc=/opt/toolchain
--with-gnu-as --with-as=/opt/toolchain/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --enable-languages=c,c++ --disable-lto
Thread model: posix
gcc version 4.8.2 (GCC)
Running `gcc bug.c -S` produces the following assembly
.file bug.c
.section.rodata
.align 8
.LLC0:
.asciz 12345
.align 8
.LLC1:
.asciz %ld\n
.section.text
.align 4
.global main
.type main, #function
.proc 04
main:
save%sp, -120, %sp
st %i0, [%fp+68]
st %i1, [%fp+72]
sethi %hi(.LLC0), %g1
or %g1, %lo(.LLC0), %g1
st %g1, [%fp-4]
st %g0, [%fp-20]
mov 0, %g2
sethi %hi(6144), %g3
or %g3, 645, %g3
std %g2, [%fp-16]
add %fp, -20, %g1
ld [%fp-4], %o0
mov %g1, %o1
mov 10, %o2
callstrtoll, 0
nop
std %o0, [%fp-16]
sethi %hi(.LLC1), %g1
or %g1, %lo(.LLC1), %o0
ld [%fp-16], %o1
ld [%fp-12], %o2
callprintf, 0
nop
mov 0, %g1
mov %g1, %i0
return %i7+8
nop
.size main, .-main
.ident GCC: (GNU) 4.8.2
And finally `bug.i`:
# 1 bug.c
# 1 command-line
# 1 bug.c
# 1
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/stdio.h 1 3 4
# 14
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/stdio.h 3 4
# 1 /opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include/stdarg.h 1
3 4
# 40 /opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include/stdarg.h 3
4
typedef __builtin_va_list __gnuc_va_list;
# 15
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/stdio.h 2 3 4
# 34
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/stdio.h 3 4
#pragma ident @(#)stdio.h 1.7901/04/16 SMI
# 1
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/iso/stdio_iso.h
1 3 4
# 41
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/iso/stdio_iso.h
3 4
#pragma ident @(#)stdio_iso.h 1.2 99/10/25 SMI
# 1
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/sys/feature_tests.h
1 3 4
# 22
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/sys/feature_tests.h
3 4
#pragma ident @(#)feature_tests.h 1.1899/07/26 SMI
# 1 /usr/include/sys/isa_defs.h 1 3 4
# 9 /usr/include/sys/isa_defs.h 3 4
#pragma ident @(#)isa_defs.h 1.2099/05/04 SMI
# 25
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/sys/feature_tests.h
2 3 4
# 45
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/iso/stdio_iso.h
2 3 4
# 1
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/sys/va_list.h
1 3 4
# 18
/opt/toolchain/lib/gcc/sparc-sun-solaris2.9/4.8.2/include-fixed/sys/va_list.h
3 4
[Bug c/60934] Strtoll Function Always Appears to Return 0 on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Please add -Wall -Wextrra to gcc's command line and see what the warnings are.
[Bug c/60934] Strtoll Function Always Appears to Return 0 on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I give you a hint the format for printing long long is %lld and not just %ld.
[Bug c++/60935] New: Endless loop when compiling a recursive function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60935
Bug ID: 60935
Summary: Endless loop when compiling a recursive function
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: miskcoo at gmail dot com
[g++ 4.8.2 on Arch Linux (Linux version 3.14.1-1-ARCH) ]
The g++ compiler is in an endless loop when I compile the following code, but
clang++ will give a compile error.
namespace strange
{
templatetypename T1, typename T2
struct strange_pack {};
struct strange_class {};
templatetypename T1, typename T2
strange_packT1, T2
operator % (T1, T2) {}
templatetypename T1, typename T2
void strange_recursive(T1 a, T2 b)
{
strange_recursive(b, a % b);
}
}
int main()
{
strange::strange_class a, b;
strange::strange_recursive(a, b);
return 0;
}
[Bug libstdc++/60936] New: Binary code bloat with std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
Bug ID: 60936
Summary: Binary code bloat with std::string
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Test program:
#includestring
int hello()
{
std::string st(abc);
return st.length();
}
Build:
$ g++ -shared -fPIC -static-libgcc -static-libstdc++ -Wl,-s -o $@ $?
Sizes of result:
gcc-4_7-string.so: 171744
gcc-4_8-string.so: 185808
gcc-4_9-string.so: 635960
[Bug c/60934] Strtoll Function Always Appears to Return 0 on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934 --- Comment #3 from william.speak at sophos dot com --- (In reply to Andrew Pinski from comment #2) I give you a hint the format for printing long long is %lld and not just %ld. Yep. That was from when I was seeing what could trigger the bug. Replacing the format specifier does solve the problem of printing the value in this case. The real issue though appeared to be that `strtoll` is not defined in `c99` and so is assumed to be returning an integer if -std=gnu99 is used or if no standard is specified I can't reproduce the 'bug'.
[Bug tree-optimization/60903] [4.8/4.9/4.10 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647: : edge from 13 to 14 should be marked irreducible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60903 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 11:25:27 2014 New Revision: 209694 URL: http://gcc.gnu.org/viewcvs?rev=209694root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de PR tree-optimization/60903 * tree-ssa-loop-im.c (analyze_memory_references): Remove commented code block. (execute_sm_if_changed): Properly apply IRREDUCIBLE_LOOP loop flags to newly created BBs and edges. * gcc.dg/torture/pr60903.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr60903.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug tree-optimization/60903] [4.8/4.9/4.10 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647: : edge from 13 to 14 should be marked irreducible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60903 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 11:27:29 2014 New Revision: 209695 URL: http://gcc.gnu.org/viewcvs?rev=209695root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de PR tree-optimization/60903 * tree-ssa-loop-im.c (analyze_memory_references): Remove commented code block. (execute_sm_if_changed): Properly apply IRREDUCIBLE_LOOP loop flags to newly created BBs and edges. * gcc.dg/torture/pr60903.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr60903.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-loop-im.c
[Bug c/60937] New: -Os -fprofile-arcs breaks __attribute__((error()))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60937 Bug ID: 60937 Summary: -Os -fprofile-arcs breaks __attribute__((error())) Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kirill at shutemov dot name Created attachment 32660 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32660action=edit Reduced test case Use of -Os and -fprofile-arcs break __attribute__((error())) behavior on attached test case. It false-positively triggers compile time error: $ gcc -Wall -Os -fprofile-arcs -c -o mm/.tmp_gup.o gup.i gup.i: In function ‘__get_user_pages’: gup.i:29:44: error: call to ‘__compiletime_assert’ declared with attribute error: BUILD_BUG failed __compiletime_assert(); Switching to other optimization level (above 0) or remove -fprofile-arcs does not lead to that: $ gcc -Wall -O1 -fprofile-arcs -c -o mm/.tmp_gup.o gup.i $ gcc -Wall -Os -c -o mm/.tmp_gup.o gup.i
[Bug ipa/60911] [4.9/4.10 Regression] wrong code with -O2 -flto -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) Late IPA passes need all regular IPA transforms applied and clones materialized. I agree that would make sense but it is not what we do. Just look at compile() in cgraphunit.c. When late IPA passes run, clones are already materialized but transformation phases of regular IPA passes have not been run yet. Apart from the fact that late-IPA passes do not see the bodies transformed and inlining performed it also means that call statements have not been updated to reflect call redirections performed at analysis stage which is the problem here and which is (for reasons I have never quite grasped) done as a part of inlining transformation phase. OTOH, I am all for moving the call to execute_all_ipa_transforms() from expand_function() to compile(), at least in trunk.
[Bug ipa/60911] [4.9/4.10 Regression] wrong code with -O2 -flto -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
--- Comment #4 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 23 Apr 2014, jamborm at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
Late IPA passes need all regular IPA transforms applied and clones
materialized.
I agree that would make sense but it is not what we do. Just look at
compile() in cgraphunit.c. When late IPA passes run, clones are
already materialized but transformation phases of regular IPA passes
have not been run yet. Apart from the fact that late-IPA passes do
not see the bodies transformed and inlining performed it also means
that call statements have not been updated to reflect call
redirections performed at analysis stage which is the problem here and
which is (for reasons I have never quite grasped) done as a part of
inlining transformation phase.
Hmm, ok. But that makes simple IPA passes work on a limbo state.
I think we delay applying IPA transforms as optimization with
respect to compile-time/memory-use as in theory we only require
a single function body in memory during LTRANS. I wonder why
it works without LTO ... because there I _do_ see the IPA
transform applied to main ().
OTOH, I am all for moving the call to execute_all_ipa_transforms()
from expand_function() to compile(), at least in trunk.
We also have, in execute_one_pass,
/* SIPLE IPA passes do not handle callgraphs with IPA transforms in it.
Apply all trnasforms first. */
if (pass-type == SIMPLE_IPA_PASS)
{
bool applied = false;
do_per_function (apply_ipa_transforms, (void *)applied);
if (applied)
symtab_remove_unreachable_nodes (true, dump_file);
/* Restore current_pass. */
current_pass = pass;
but that doesn't seem to work ... at least with LTO? Which is
because for main()
FOR_EACH_DEFINED_FUNCTION (node)
if (node-analyzed gimple_has_body_p (node-decl)
(!node-clone_of || node-decl != node-clone_of-decl))
{
this doesn't trigger (for f.constprop it does).
gimple_has_body_p (node-decl) is false.
main/1 (main) @0x76daf148
Type: function definition analyzed
Visibility: externally_visible prevailing_def public
References:
Referring:
Read from file: /tmp/ccED1aQr.ltrans0.o
Availability: available
First run: 0
Function flags: only_called_at_startup
Called by:
Calls: abort/2 (0.00 per call) f.constprop.0/3 (1.00 per call)
it's probably not yet streamed in?
[Bug libgcc/60938] New: AIX: exceptions not caught when calling function via pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60938
Bug ID: 60938
Summary: AIX: exceptions not caught when calling function via
pointer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: lbl2007 at gmx dot net
The attached test program throws a std::runtime_error, but the corresponding
catch block is not executed. This only happens under certain circumstances.
After some testing I found that the following conditions make the error appear:
(1) The function foo() doing the try/catch is in a compilation unit
different from main().
(2) foo() is called from main() via a function pointer (pfoo).
(3) pfoo is initialized in a global static constructor in a compilation
unit different from main.
To reproduce the error:
g++ -g -o demo a.cc b.cc
./demo
BEGIN
terminate called after throwing an instance of 'std::runtime_error'
what(): TILT
IOT/Abort trap (core dumped)
Test program (both raw and preprocessed sources are in the attached TAR file):
FILE a.cc
#include stdio.h
#include stdexcept
extern void (*pFoo)();
void foo()
{
fputs(BEGIN\n,stderr);
try { throw std::runtime_error(TILT); }
catch( const std::runtime_error e ) { }
fputs(OK\n,stderr);
}
struct Init { Init() { pFoo = foo; } } init;
FILE b.cc
extern void foo();
void (*pFoo)() = 0;
int main( int argc, char *argv[] )
{
pFoo();
return 0;
}
Version info:
g++ -v
Using built-in specs.
COLLECT_GCC=/common/mringe/gcc482/local/bin/g++
COLLECT_LTO_WRAPPER=/common/mringe/gcc482/local/libexec/gcc/powerpc-ibm-aix6.1.0.0/4.8.2/lto-wrapper
Target: powerpc-ibm-aix6.1.0.0
Configured with: /common/mringe/gcc482/gcc-4.8.2/configure
--prefix=/common/mringe/gcc482/local --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --enable-languages=c,c++
--enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd
--with-gmp=/common/mringe/gcc482/local --with-mpfr=/common/mringe/gcc482/local
--with-mpc=/common/mringe/gcc482/local
--with-local-prefix=/common/mringe/gcc482/local
Thread model: aix
gcc version 4.8.2 (GCC)
uname -a
AIX srva001 1 6 00F817FA4C00 AIX
[Bug libgcc/60939] New: AIX: exceptions not caught when calling function via pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
Bug ID: 60939
Summary: AIX: exceptions not caught when calling function via
pointer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: lbl2007 at gmx dot net
The attached test program throws a std::runtime_error, but the corresponding
catch block is not executed. This only happens under certain circumstances.
After some testing I found that the following conditions make the error appear:
(1) The function foo() doing the try/catch is in a compilation unit
different from main().
(2) foo() is called from main() via a function pointer (pfoo).
(3) pfoo is initialized in a global static constructor in a compilation
unit different from main.
To reproduce the error:
g++ -g -o demo a.cc b.cc
./demo
BEGIN
terminate called after throwing an instance of 'std::runtime_error'
what(): TILT
IOT/Abort trap (core dumped)
Test program (both raw and preprocessed sources are in the attached TAR file):
FILE a.cc
#include stdio.h
#include stdexcept
extern void (*pFoo)();
void foo()
{
fputs(BEGIN\n,stderr);
try { throw std::runtime_error(TILT); }
catch( const std::runtime_error e ) { }
fputs(OK\n,stderr);
}
struct Init { Init() { pFoo = foo; } } init;
FILE b.cc
extern void foo();
void (*pFoo)() = 0;
int main( int argc, char *argv[] )
{
pFoo();
return 0;
}
Version info:
g++ -v
Using built-in specs.
COLLECT_GCC=/common/mringe/gcc482/local/bin/g++
COLLECT_LTO_WRAPPER=/common/mringe/gcc482/local/libexec/gcc/powerpc-ibm-aix6.1.0.0/4.8.2/lto-wrapper
Target: powerpc-ibm-aix6.1.0.0
Configured with: /common/mringe/gcc482/gcc-4.8.2/configure
--prefix=/common/mringe/gcc482/local --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --enable-languages=c,c++
--enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd
--with-gmp=/common/mringe/gcc482/local --with-mpfr=/common/mringe/gcc482/local
--with-mpc=/common/mringe/gcc482/local
--with-local-prefix=/common/mringe/gcc482/local
Thread model: aix
gcc version 4.8.2 (GCC)
uname -a
AIX srva001 1 6 00F817FA4C00 AIX
[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939 --- Comment #1 from lbl2007 at gmx dot net --- Created attachment 32661 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32661action=edit Test program
[Bug libstdc++/60936] Binary code bloat with std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #1 from __vic d.v.a at ngs dot ru --- If we use iostream classes (without std::string) the difference isn't so dramatic: 4.7: 800320 4.8: 838944 4.9: 868664 May be it's connected with locales? Has std::string any dependences on it in 4.9?
[Bug c/60934] Strtoll Function Always Appears to Return 0 on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Closing.
[Bug libgcc/60938] AIX: exceptions not caught when calling function via pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60938 lbl2007 at gmx dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from lbl2007 at gmx dot net --- Duplicate, please delete *** This bug has been marked as a duplicate of bug 60939 ***
[Bug ipa/60911] [4.9/4.10 Regression] wrong code with -O2 -flto -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Ah, and tree-ssa-structalias.c does
/* Build the constraints. */
FOR_EACH_DEFINED_FUNCTION (node)
{
varinfo_t vi;
/* Nodes without a body are not interesting. Especially do not
visit clones at this point for now - we get duplicate decls
there for inline clones at least. */
if (!cgraph_function_with_gimple_body_p (node) || node-clone_of)
continue;
cgraph_get_body (node);
but doesn't apply IPA transforms. I think the kludge in the pass manager
should do that instead. I wonder how the above doesn't trigger the
in_lto_p assert in cgraph_get_body though ... (maybe the odd DECL_RESULT
check makes sure we don't trigger that path).
Ick. That code path triggers also with
2171 do_per_function (clear_last_verified, NULL);
doing the push/pop_cfun game on each fn just to clear last_verified ...
in WPA stage ... same for
2179 do_per_function (update_properties_after_pass, pass);
and more. Trying to make
Index: gcc/passes.c
===
--- gcc/passes.c(revision 209677)
+++ gcc/passes.c(working copy)
@@ -1506,9 +1506,11 @@ do_per_function (void (*callback) (void
{
struct cgraph_node *node;
FOR_EACH_DEFINED_FUNCTION (node)
- if (node-analyzed gimple_has_body_p (node-decl)
+ if (node-analyzed
+cgraph_function_with_gimple_body_p (node)
(!node-clone_of || node-decl != node-clone_of-decl))
{
+ cgraph_get_body (node);
push_cfun (DECL_STRUCT_FUNCTION (node-decl));
callback (data);
if (!flag_wpa)
not ICE ...
Index: gcc/passes.c
===
--- gcc/passes.c(revision 209677)
+++ gcc/passes.c(working copy)
@@ -1506,18 +1506,24 @@ do_per_function (void (*callback) (void
{
struct cgraph_node *node;
FOR_EACH_DEFINED_FUNCTION (node)
- if (node-analyzed gimple_has_body_p (node-decl)
+ if (node-analyzed
+cgraph_function_with_gimple_body_p (node)
(!node-clone_of || node-decl != node-clone_of-decl))
{
- push_cfun (DECL_STRUCT_FUNCTION (node-decl));
- callback (data);
if (!flag_wpa)
+ cgraph_get_body (node);
+ if (gimple_has_body_p (node-decl))
{
- free_dominance_info (CDI_DOMINATORS);
- free_dominance_info (CDI_POST_DOMINATORS);
+ push_cfun (DECL_STRUCT_FUNCTION (node-decl));
+ callback (data);
+ if (!flag_wpa)
+ {
+ free_dominance_info (CDI_DOMINATORS);
+ free_dominance_info (CDI_POST_DOMINATORS);
+ }
+ pop_cfun ();
+ ggc_collect ();
}
- pop_cfun ();
- ggc_collect ();
}
}
}
works though.
[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939 --- Comment #2 from lbl2007 at gmx dot net --- *** Bug 60938 has been marked as a duplicate of this bug. ***
[Bug ipa/60911] [4.9/4.10 Regression] wrong code with -O2 -flto -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Seems like simd_clone_create gets along with this because it does if (!cgraph_function_with_gimple_body_p (old_node)) return NULL; cgraph_get_body (old_node); new_node = cgraph_function_versioning (old_node, vNULL, NULL, NULL, false, NULL, NULL, simdclone); and cgraph_function_versioning applies IPA transforms?
[Bug ipa/60911] [4.9/4.10 Regression] wrong code with -O2 -flto -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Anyway, that push/pop_cfun stuff should be pushed to the callbacks, not be done in do_per_function (). Likewise the ggc_collect (). Btw, same code in do_per_function_toporder.
[Bug tree-optimization/60930] [4.8/4.9/4.10 Regression] Wrong folding of - ((unsigned long long) a * (unsigned long long) (unsigned int)-1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60930 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #3 from Bill Schmidt wschmidt at gcc dot gnu.org --- Also reproduces on powerpc64le-linux-gnu for 4.10. I'll investigate.
[Bug libstdc++/60936] Binary code bloat with std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #2 from __vic d.v.a at ngs dot ru --- Non-stripped binary built with 4.9 has many symbols from locale. 4.8 - doesn't. How std::string uses locales???
[Bug tree-optimization/59132] Missing aggressive array based optimisation warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59132 --- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com --- Ping
[Bug middle-end/58970] [4.7 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970 Jan Smets jan.sm...@alcatel-lucent.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #31 from Jan Smets jan.sm...@alcatel-lucent.com --- Fixed in 4.8 and newer.
[Bug lto/60635] [4.8 Regression] ICE when mixing C and Fortran lto1: error: use operand missing for stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60635 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 12:45:23 2014 New Revision: 209696 URL: http://gcc.gnu.org/viewcvs?rev=209696root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de PR middle-end/60635 * gimplify.c (gimple_regimplify_operands): Update the re-gimplifed stmt. * gfortran.dg/lto/pr60635_0.f90: New testcase. * gfortran.dg/lto/pr60635_1.c: Likewise. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/lto/pr60635_0.f90 branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/lto/pr60635_1.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/gimplify.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/60740] [4.8 Regression] ICE in extract_affine w/ -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 12:49:04 2014 New Revision: 209697 URL: http://gcc.gnu.org/viewcvs?rev=209697root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de Backport from mainline 2014-04-02 Richard Biener rguent...@suse.de PR middle-end/60729 * optabs.c (expand_abs_nojump): Honor flag_trapv only for MODE_INTs. Properly use negv_optab. (expand_abs): Likewise. * g++.dg/vect/pr60729.cc: New testcase. 2014-04-03 Richard Biener rguent...@suse.de PR tree-optimization/60740 * graphite-scop-detection.c (stmt_simple_for_scop_p): Iterate over all GIMPLE_COND operands. * gcc.dg/graphite/pr60740.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/vect/pr60729.cc branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/graphite/pr60740.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/graphite-scop-detection.c branches/gcc-4_8-branch/gcc/optabs.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/60729] [4.8 Regression] Compiler failure for combination of -ftrapv and -O3: compiler error: in prepare_cmp_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60729 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 23 12:49:04 2014 New Revision: 209697 URL: http://gcc.gnu.org/viewcvs?rev=209697root=gccview=rev Log: 2014-04-23 Richard Biener rguent...@suse.de Backport from mainline 2014-04-02 Richard Biener rguent...@suse.de PR middle-end/60729 * optabs.c (expand_abs_nojump): Honor flag_trapv only for MODE_INTs. Properly use negv_optab. (expand_abs): Likewise. * g++.dg/vect/pr60729.cc: New testcase. 2014-04-03 Richard Biener rguent...@suse.de PR tree-optimization/60740 * graphite-scop-detection.c (stmt_simple_for_scop_p): Iterate over all GIMPLE_COND operands. * gcc.dg/graphite/pr60740.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/vect/pr60729.cc branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/graphite/pr60740.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/graphite-scop-detection.c branches/gcc-4_8-branch/gcc/optabs.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug lto/60635] [4.8 Regression] ICE when mixing C and Fortran lto1: error: use operand missing for stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60635 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/60729] [4.8 Regression] Compiler failure for combination of -ftrapv and -O3: compiler error: in prepare_cmp_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60729 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 60740, which changed state. Bug 60740 Summary: [4.8 Regression] ICE in extract_affine w/ -O2 -ftree-loop-linear http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/60740] [4.8 Regression] ICE in extract_affine w/ -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Sebastian Huber from comment #4)
It is clear that you cannot use C++ header files from C. So if you want to
provide a library intended for C and C++ applications you must use C as the
base line. With this C++ incompatible stdatomic.h you cannot do this for
applications requiring atomic operations. So you are forced to provide two
implementations.
Not true, I think this should work fine:
#ifdef __cplusplus
#include atomic
using namespace std;
#else
#include stdatomic.h
#endif
atomicint i;
int main()
{
atomic_store(i, 0);
return atomic_load(i);
}
The fact it doesn't looks like a problem with libstdc++'s atomic not
stdatomic.h
I don't think we want to support the _Atomic qualifier in C++.
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #5) #ifdef __cplusplus #include atomic using namespace std; #else #include stdatomic.h #endif atomicint i; Doh, sorry, that should say atomic_int not atomicint (I changed my testcase after finding the atomic_int version failed with libstdc++)
[Bug libstdc++/56019] max_align_t should be in std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56019 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jobst.Ziebell from comment #4) Presumably this bug also occurs when #defining the other '__need_*' macros. Which user code should never be doing anyway. GMP is broken (and already fixed upstream). This is documented at http://gcc.gnu.org/gcc-4.9/porting_to.html and isn't going to be changed to accomodate broken libraries.
[Bug libstdc++/55817] [C++11] void return value in std::vectorT::insert() c++11 should be an iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55817 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Version|4.9.0 |4.7.1 Resolution|WORKSFORME |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, fixed for 4.9.0 by r200571
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Sebastian Huber from comment #2) With FreeBSD and clang this works fine. Not on my freebsd host: $ clang++ -std=c++11 a.cc In file included from a.cc:5: /usr/include/stdatomic.h:187:17: error: unknown type name '_Bool' typedef _Atomic(_Bool) atomic_bool; ^ /usr/include/stdatomic.h:187:26: error: C++ requires a type specifier for all declarations typedef _Atomic(_Bool) atomic_bool; ~~~ ^ [... and other similar errors]
[Bug libstdc++/60940] New: general operations on atomic t ypes do not work with atomic integral typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60940
Bug ID: 60940
Summary: general operations on atomic t ypes do not work with
atomic integral typedefs
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
This is rejected because the atomic operations only accept std::atomicT not
the std::__atomic_baseT base classes:
#ifdef __cplusplus
#include atomic
using namespace std;
#else
#include stdatomic.h
#endif
atomic_int i;
int main()
{
atomic_store(i, 0);
return atomic_load(i);
}
[Bug ipa/60911] [4.9/4.10 Regression] wrong code with -O2 -flto -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32662 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32662action=edit cleanup patch
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Sebastian Huber from comment #4) I don't think this is the spirit of the atomics provided by the recent C/C++ standards. The atomics are supposed to be roughly source-compatible, in that the relevant headers for each language define types and functions and macros with the same names and equivalent effects. But the two languages define those features in different headers. If you want to use atomics in C, use stdatomic.h, and if you want to use them in C++, use atomic and appropriate using-declarations or a using-directive. I've created Bug 60940 for the libstdc++ issue.
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #9 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
(In reply to Jonathan Wakely from comment #5)
(In reply to Sebastian Huber from comment #4)
It is clear that you cannot use C++ header files from C. So if you want to
provide a library intended for C and C++ applications you must use C as the
base line. With this C++ incompatible stdatomic.h you cannot do this for
applications requiring atomic operations. So you are forced to provide two
implementations.
Not true, I think this should work fine:
#ifdef __cplusplus
#include atomic
using namespace std;
#else
#include stdatomic.h
#endif
atomicint i;
int main()
{
atomic_store(i, 0);
return atomic_load(i);
}
The fact it doesn't looks like a problem with libstdc++'s atomic not
stdatomic.h
I don't think we want to support the _Atomic qualifier in C++.
Ok, but if I create a data structure definition like for example in example.h:
#ifdef __cplusplus
#include atomic
using namespace std;
#else
#include stdatomic.h
#endif
struct s {
atomic_int i;
};
Who guarantees that this definition is binary compatible in C and C++?
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Sebastian Huber from comment #9) Who guarantees that this definition is binary compatible in C and C++? The compiler/stdlib implementors. The same people who you want to guarantee that if you include stdatomic.h with a C++ compiler that understands the _Atomic keyword that the results will be binary compatible with C code including the same header.
[Bug c++/60932] make stdatomic.h compatible with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #11 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Ok, I will use this #ifdef __cplusplus #include atomic using namespace std; #else #include stdatomic.h #endif approach, but from my point of view this is quite an unsatisfactory user experience.
[Bug c/60915] confusing diagnostic from attribute on function definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60915
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #0)
First, while this is not the correct syntax, it seems natural
enough that I've written it several times by mistake now.
Is there any chance it could be blessed?
It looks like it. Quoting from
http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax: An
attribute specifier list may, in future, be permitted to appear after the
declarator in a function definition (before any old-style parameter
declarations or the function body).
Second, I think the diagnostic could be improved. For example
it could mention that an attribute is not valid in this position
on a definition, and suggest an alternative.
Yep. The following (untested) patch should bring hopefully better error
message; do you agree with the wording?
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1688,7 +1688,19 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
fndef_ok,
if (c_parser_next_token_is_keyword (parser, RID_ASM))
asm_name = c_parser_simple_asm_expr (parser);
if (c_parser_next_token_is_keyword (parser, RID_ATTRIBUTE))
- postfix_attrs = c_parser_attributes (parser);
+ {
+ postfix_attrs = c_parser_attributes (parser);
+ if (c_parser_next_token_is (parser, CPP_OPEN_BRACE))
+ {
+ /* This means there is an attribute specifier after
+the declarator in a function definition. Provide
+some more information for the user. */
+ error_at (here, attributes should be specified before the
+ declarator in a function definition);
+ c_parser_skip_to_end_of_block_or_statement (parser);
+ return;
+ }
+ }
if (c_parser_next_token_is (parser, CPP_EQ))
{
tree d;
This would of course go away if we decide to support attribute specifier after
the declarator in a function definition.
Third, the manual could use an example of how to do this.
Yeah, an example never hurts.
[Bug target/60941] New: gcc 4.8.3/sparc64 miscompiles firefox javascript interpreter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60941
Bug ID: 60941
Summary: gcc 4.8.3/sparc64 miscompiles firefox javascript
interpreter
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
System: NetBSD/sparc64; NetBSD in-tree version of gcc:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: sparc64--netbsd
Configured with: /usr/src6/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=sparc64--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb1 20120916' --with-system-zlib --enable-__cxa_atexit
--with-mpc-lib=/var/obj/mknative/sparc64/usr/src6/external/lgpl3/mpc/lib/libmpc
--with-mpfr-lib=/var/obj/mknative/sparc64/usr/src6/external/lgpl3/mpfr/lib/libmpfr
--with-gmp-lib=/var/obj/mknative/sparc64/usr/src6/external/lgpl3/gmp/lib/libgmp
--with-mpc-include=/usr/src6/external/lgpl3/mpc/dist/src
--with-mpfr-include=/usr/src6/external/lgpl3/mpfr/dist/src
--with-gmp-include=/usr/src6/external/lgpl3/gmp/lib/libgmp/arch/sparc64
--enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch
--build=x86_64-unknown-netbsd6.0. --host=sparc64--netbsd
--with-sysroot=/var/obj/mknative/sparc64/usr/src6/destdir.sparc64
Thread model: posix
gcc version 4.8.3 (NetBSD nb2 20140304)
When building a firefox 28 with gcc 4.8 and at least -O2 the javascript
interpreter misbehaves and causes firefox to crash. An example URL that
triggers this is:
https://github.com/mconf/ffmpeg/blob/master/doc/optimization.txt
The bug itself is a bit subtle - hope I get it clear:
The firefox javascript interpreter has a very special way to represent all
kinds of values in a single 64 bit value (which makes it impossible to
represent certain double NaN values and some pointer values - however, this is
all properly taken care of). The definition of the Value type is:
typedef union jsval_layout
{
uint64_t asBits;
struct {
JSValueTag tag : 17;
uint64_t payload47 : 47;
} debugView;
struct {
uint32_t padding;
union {
int32_ti32;
uint32_t u32;
JSWhyMagic why;
} payload;
} s;
double asDouble;
void *asPtr;
size_t asWord;
uintptr_t asUIntPtr;
} JSVAL_ALIGNMENT jsval_layout;
There is a helper macro that constructs new Values from 32bit ints:
static inline JS_VALUE_CONSTEXPR jsval_layout
INT32_TO_JSVAL_IMPL(int32_t i32)
{
JS_RETURN_LAYOUT_FROM_BITS(((uint64_t)(uint32_t)i32) |
JSVAL_SHIFTED_TAG_INT32);
}
and JS_RETURN_LAYOUT_FROM_BITS is (depending on ifdefs) in this case defined
as:
# define JS_RETURN_LAYOUT_FROM_BITS(BITS) \
return (jsval_layout) { .asBits = (BITS) }
Now ignoring a few details, the values with tag 0xfff88 in the high order bits
are int32 values, and the low order bits just contain the value.
With some printf instrumentation, right before the crash happens, the
interpreter stack looks like:
end of JSOP_INT8 top of stack: fff88019
end of JSOP_URSH top of stack: fff88028
end of JSOP_BITXOR top of stack: fff8814e18ab
end of JSOP_GETLOCAL top of stack: fff88000510e527f
end of JSOP_INT8 top of stack: fff8801a
now you see 0x510e527f and 0x1a as the topmost values, both int32. Next a
logical shift left is done with these two.
The assembler code generated loads the args into %g2 and %g3 and does a sll:
(gdb) p/x $g3
$1 = 0x510e527f
(gdb) p/x $g2
$2 = 0x1a
0xfe4d97e0 sll %g3, %g2, %g2
now sll leaves the high 32 bits in undefined state, so after the sll we get
0x1443949fc00 instead of 0xfc00 in %g2. Unfortunately the code now ors
the correct tag bits into this and stores it directly as a 64bit value:
= 0xfe4d97e4 ldx [ %l7 + %o0 ], %o0
0xfe4d97e8 add %g1, -8, %g3
0xfe4d97ec or %g2, %g4, g2
0xfe4d97f0 stx %g3, [ %fp + 0x727 ]
(the 0xfff88 tag bits had been precomputed in %g4 earlier). This leads to
broken jsvalue_layout data, as the result now looks like a pointer to a
javascript object to the interpreter, and when trying to call methods of that,
the crash happens.
The code in the interpreter loop (slightly unriddled a few macros) looks
correct to me:
CASE(JSOP_LSH)
{
int32_t i, j;
if (!ToInt32(cx, REGS.stackHandleAt(-2), i))
goto error;
if (!ToInt32(cx, REGS.stackHandleAt(-1), j))
goto error;
i = i (j 31);
REGS.sp--;
REGS.sp[-1].setInt32(i);
}
END_CASE(JSOP_LSH)
The setInt32() function is the accessor mentioned earlier:
void setInt32(int32_t i) {
data
[Bug target/60941] gcc 4.8.3/sparc64 miscompiles firefox javascript interpreter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60941
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
Here is a small test program:
---8---
#include stdio.h
#include stdlib.h
int main(int argc, char **argv)
{
unsigned long v[2], *p;
int a, b;
for (int i = 0; i 2 i argc; i++) {
v[i] = atol(argv[i+1]) | 0xfff88000;
printf(i = %d, got: %lx\n, i, v[i]);
}
p = v[1];
a = *p-- 0x0;
b = *p 0x0;
printf(a = %08x b= %08x\n, a, b);
b = a (b 31);
*p = ((uint64_t)(uint32_t)b) | 0xfff88000;
printf(res: %08lx\n, *p);
return 0;
}
---8---
compile with c++ -Wall -O2 test.c and run as:
./a.out 26 1359893119
i = 0, got: fff8801a
i = 1, got: fff88000510e527f
a = 510e527f b= 001a
res: fffcb949fc00
I would have expected res: 0xfff88000fc00 (and on amd64 I get exactly that)
[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2014-04-23 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I believe the culprit is gcc too actively promoting the minimally required versions of the libraries. It is fine if gcc still compiles with older versions, but all communication should point to the most recent releases. It's common practice to list the minimally required versions of dependencies for software packages, so I'm not sure why we shouldn't do it for GCC. Besides, we don't want to force the users to upgrade the libraries if this is not necessary.
[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- We've had situations in the past where the minimum suggested versions work and the latest versions prevented GCC from building. The suggested versions are known to work and have been thoroughly tested, which might not be true of the latest versions.
[Bug gcov-profile/52416] Branch coverage differences between 4.4 and 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52416 SANTOS.RAMÍREZ santos.ramirez at siemens dot com changed: What|Removed |Added CC||santos.ramirez at siemens dot com --- Comment #1 from SANTOS.RAMÍREZ santos.ramirez at siemens dot com --- Hi, Do you know why using gcc 4.4 and 4.6 a simple line as p = new class; has two branches (50% coverage) ? How can we cover 100% for this type of lines ? 63 [ + - ][ + - ]: 12 : new TConfigDatabase (this); 64 :: 65 :: // Die eigentliche Odometrie erzeugen... 66 [ + - ][ + - ]: 12 : mOdometry= new SDM_Odometry_C (this); 67 :: Thanks a lot
[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 --- Comment #4 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- Alternatively you should say that: * these minimal versions should be used with GCC only, and should not be installed on the system; * bugs related to them should be reported to some GCC mailing-list, not to upstream. Even though they work with GCC, they may be too buggy for some other use...
[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Alternatively you should say that: * these minimal versions should be used with GCC only, and should not be installed on the system; * bugs related to them should be reported to some GCC mailing-list, not to upstream. Even though they work with GCC, they may be too buggy for some other use... But, again, other software packages don't do that so I'm not sure why GCC should do it (and we certainly don't want to get bug reports for anything else than GCC, we already have enough of them).
[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 --- Comment #3 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Eric Botcazou from comment #1) It's common practice to list the minimally required versions of dependencies for software packages, so I'm not sure why we shouldn't do it for GCC. I don't think that the message itself is a problem: if the user doesn't have some prerequisite, he will probably get the latest version. The fault comes from the vendors or old links to obsolete versions on the web. The main issue here is that ftp://gcc.gnu.org/pub/gcc/infrastructure/ contains obsolete versions, and this is not common practice to do so.
[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 --- Comment #6 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Eric Botcazou from comment #5) But, again, other software packages don't do that so I'm not sure why GCC should do it I'm not aware of other software packages that provide such old versions of GMP and MPFR. (and we certainly don't want to get bug reports for anything else than GCC, we already have enough of them). and GMP and MPFR developers don't want to get bug reports for obsolete, no longer maintained versions of GMP and MPFR.
[Bug target/60909] ICE: in extract_insn, at recog.c:2202 (unrecognizable insn) with -mrdrnd and __builtin_ia32_rdrand32_step()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60909
--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Apr 23 16:23:36 2014
New Revision: 209709
URL: http://gcc.gnu.org/viewcvs?rev=209709root=gccview=rev
Log:
Backport from mainline
2014-04-21 Uros Bizjak ubiz...@gmail.com
PR target/60909
* config/i386/i386.c (ix86_expand_builtin)
case IX86_BUILTIN_RDRAND{16,32,64}_STEP: Use temporary
register for target RTX.
case IX86_BUILTIN_RDSEED{16,32,64}_STEP: Ditto.
testsuite/ChangeLog:
Backport from mainline
2014-04-21 Uros Bizjak ubiz...@gmail.com
PR target/60909
* gcc.target/i386/pr60909-1.c: New test.
* gcc.target/i386/pr60909-2.c: Ditto.
Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr60909-1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr60909-2.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 --- Comment #7 from Andreas andreas.enge at inria dot fr --- As stated in my report, there is no problem with mentioning the minimal versions of helper libraries required to compile gcc. The problem is with actively promoting outdated versions, which can be helped by choosing different wordings, for instance as I suggested in the report. And a worse problem is created by actively pushing outdated versions upon the users via ftp://gcc.gnu.org/pub/gcc/infrastructure/. I do not know the policy of gcc with regards to continuous integration; I think gcc should always be thoroughly tested with the latest versions of its helper libraries, and potential problems be reported upstream; after all, we should help each other out in improving our free GNU software! (But this becomes somewhat off-topic.) Even if you are weary of the latest and greatest version, a position I can understand, you should not actively distribute releases that have been unmaintained for quite a while and contain known bugs. I would like to point out that this position is shared by the current maintainers of GNU MPC (me) and GNU MPFR (Vincent) and the main developer of GNU MP (Torbjörn, see his posting on the gmp mailing list at https://gmplib.org/list-archives/gmp-devel/2014-April/003770.html ). Andreas
[Bug tree-optimization/60902] [4.9/4.10 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 --- Comment #30 from Jeffrey A. Law law at redhat dot com --- Sorry. I expect to check the fix testcase onto the trunk today. For various reasons my work time is limited right now. For the 4.9.x releases, final call will be with jakub, jsm and richi as the releaes managers.
[Bug go/60931] libgo has issues when page size is not 4k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- It would be extremely helpful if you could find a test case that can recreate this problem with some reliability. There is no obvious dependency on the system page size in libgo. The PageSize constant is the unit that the memory allocator deals in, and should have no direct relationship to the system page size. I believe that there is a bug, but we need to track it down. If you set the environment variable GOGC=1 the garbage collector will run much more frequently; perhaps that will help get a reproducible test case.
[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Andreas from comment #7) Even if you are weary of the latest and greatest version, a position I can understand, you should not actively distribute releases that have been unmaintained for quite a while and contain known bugs. I tend to agree with this and think it would be good if we updated the versions at ftp://gcc.gnu.org/pub/gcc/infrastructure/ and made the corresponding update to the contrib/download_prerequisites script.
[Bug libstdc++/60940] general operations on atomic types do not work with atomic integral typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60940 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Additionally, we fail to meet this requirement: 29.6.2 Templated operations on atomic types [atomics.types.operations.templ] The implementation shall declare but not define the function templates identified as “templated operations on atomic types” in 29.2. We only declare those functions templates when they need to be defined, i.e. for arguments of type __atomic_base or atomicT*. The declarations would need to be constrained with SFINAE to prevent them being used for types derived from __atomic_base.
