[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #11 from Andrew Pinski --- Closing as invalid as requested.
[Bug pch/57242] precompiled headers ignored unless the .gch and TU's are compiled with certain combinations of -g flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57242 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- Not a bug, ccache getting in the way.
[Bug target/57288] cfi_restore should precede cfi_def_cfa_offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57288 Andrew Pinski changed: What|Removed |Added Target||x86_64-*-linux-gnu Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-10 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source which is used to create this assembly file?
[Bug middle-end/57436] Linux kernel gives file system corruption when built with gcc 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57436 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-10 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Waiting on a testcase.
[Bug ada/40986] [4.7/4.8/4.9 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986 Andrew Pinski changed: What|Removed |Added Target Milestone|4.6.4 |4.7.4 Summary|[4.6 regression]|[4.7/4.8/4.9 regression] |Assert_Failure |Assert_Failure |sinfo.adb:360, error|sinfo.adb:360, error |detected at |detected at |a-unccon.ads:23:27 |a-unccon.ads:23:27
[Bug target/50807] [avr] Constructor writing to RAM for variable in Flash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50807 Andrew Pinski changed: What|Removed |Added Component|c++ |target Target Milestone|4.6.4 |---
[Bug lto/50293] -flto fails if GCC is installed in directory with space in path name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50293 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #41 from Andrew Pinski --- Closing as won't fix since Tru64 UNIX has since been removed.
[Bug target/41025] v4.3.3, 4.4.1, etc -ftracer sometimes fails by "is already defined"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41025 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- No preprocessed source in 4 years so closing.
[Bug middle-end/44984] gcc passes unsigned instead of int for printf width/precision (warnings generated)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44984 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- No feedback in 3 years so closing.
[Bug middle-end/46822] printf( "%f" ) segv when called from pthread_once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46822 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- No feedback in over 2 years so closing.
[Bug middle-end/48563] EOF not at EOL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48563 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- No feedback in over 2 years so closing.
[Bug c/49233] Please un-deprecate rvalues in memory constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49233 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- No feedback in over 2 years so closing.
[Bug bootstrap/7881] Cannot compile gcc on Tru64 4G or 5.X if gnu libiconv is installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7881 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX Target Milestone|--- |4.8.0 --- Comment #29 from Andrew Pinski --- Tru64 support has been removed so closing.
[Bug bootstrap/40014] GGC build on Solaris 8 system fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40014 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- No attachment in 4 years so closing.
[Bug bootstrap/42932] unknown endianness, Solaris 10 SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42932 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-10 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Does this work now?
[Bug middle-end/59037] [4.8/4.9 Regression] ICE when accessing invalid element (nelts + 1) of vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037 --- Comment #5 from Marc Glisse --- (In reply to vries from comment #4) > Tentative patch: > ... > diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c > index 93b8970..6f2b4fb 100644 > --- a/gcc/tree-ssa-forwprop.c > +++ b/gcc/tree-ssa-forwprop.c > @@ -3046,6 +3046,8 @@ simplify_bitfield_ref (gimple_stmt_iterator *gsi) >if (TREE_CODE (m) != VECTOR_CST) > return false; >nelts = VECTOR_CST_NELTS (m); Add a comment here explaining why this isn't an assert? > + if (idx >= nelts) > + return false; >idx = TREE_INT_CST_LOW (VECTOR_CST_ELT (m, idx)); >idx %= 2 * nelts; >if (idx < nelts) I think it would be even better to fix whatever created that BIT_FIELD_REF, if you are motivated (though your patch isn't wrong).
[Bug middle-end/57436] Linux kernel gives file system corruption when built with gcc 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57436 --- Comment #3 from Andreas Radke --- I moved away from XFS file system and so can't reproduce it anymore. The bug should be in XFS code probably triggering a change in gcc behavior. Feel free to close this one. note: we had a similar issue in libdrm. maybe it's related or not. this one is now fixed: http://cgit.freedesktop.org/mesa/drm/commit/?id=482abbfafb56cbceaf5355c026434e638cddd0f1
[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032
vries at gcc dot gnu.org changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #2 from vries at gcc dot gnu.org ---
Tentative patch:
...
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index bcb8782..8566e58 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5665,7 +5665,8 @@ cp_build_unary_op (enum tree_code code, tree xarg, int
noconvert,
/* Report invalid types. */
- if (!(arg = build_expr_type_conversion (WANT_ARITH | WANT_POINTER,
+ if (!(arg = build_expr_type_conversion (WANT_INT | WANT_FLOAT
+ | WANT_POINTER,
arg, true)))
{
if (code == PREINCREMENT_EXPR)
...
WANT_ARITH is defined as:
...
#define WANT_ARITH (WANT_INT | WANT_FLOAT | WANT_VECTOR_OR_COMPLEX)
...
so the patch effectively removes WANT_VECTOR_OR_COMPLEX. AFAIU the COMPLEX case
is already handled at this point, so there shouldn't be any effect for those.
This patch brings back the old error message:
...
test.c: In function ‘void foo()’:
test.c:4:5: error: no pre-increment operator for type
++v;
^
...
[Bug c++/54427] Expose more vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427 --- Comment #15 from Marc Glisse --- Related PRs involving || and && for vectors: PR 57198 and PR 58845. PR 58845 contains information about having a sequence point in the gimplification of those operators.
[Bug ipa/59008] [4.9 Regression] ICEs in try_make_edge_direct_simple_call / propagate_controlled_uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59008 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-10 Ever confirmed|0 |1
[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032 --- Comment #3 from Marc Glisse --- I wonder if it would take more than replacing: inc = integer_one_node; with something like: inc = VECTOR_TYPE_P (argtype) ? build_one_cst (argtype) : integer_one_node; (or even unconditionally build_one_cst) to support increment/decrement for vectors. We already support v=v+1, so it wouldn't be a large extension.
[Bug rtl-optimization/59064] New: [4.9 regression] FAIL: gcc.dg/vect/vect-ivdep-1.c (test for bogus messages, line )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59064 Bug ID: 59064 Summary: [4.9 regression] FAIL: gcc.dg/vect/vect-ivdep-1.c (test for bogus messages, line ) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target: ia64-*-* $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -O3 -fopt-info-vec-optimized -S -o vect-ivdep-1.s ../gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c:11:3: note: loop vectorized ../gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c:11:3: note: loop versioned for vectorization to enhance alignment
[Bug fortran/59065] New: questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 Bug ID: 59065 Summary: questionable bounds for unassociated allocatable/pointer arrays? Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com ! gfortran produces SIGSEV at run time for access to unassociated allocatable/pointer arrays ! questionable bounds for unassociated allocatable/pointer arrays? ! such arrays properties are undefined but I suggest lbound be 1, ubound 0, size 0 ! to minimize damage to erroneous code accessing such arrays ! -fcheck=all does not help ! Linux Fedora 19 bash shell 4.2.45-1 real, pointer :: ap(:)=>null() real, allocatable :: aa(:) print *,lbound(aa),ubound(aa),size(aa) ! displays "0 garbage garbage" should be "1 0 0"? print *,lbound(ap),ubound(ap),size(ap) ! displays "0 0 1" should be "1 0 0"? call sub(aa,ap) contains subroutine sub(va,vp) real, intent(in) :: vp(:) real, intent(in) :: va(:) print *,lbound(va),ubound(va),size(va) ! displays "1 garbage garbage" should be "1 0 0"? print *,lbound(vp),ubound(vp),size(vp) ! displays "1 1 1" should be "1 0 0"? print *,va(1) ! SIGSEGV here -fcheck=all does not detect it print *,vp(1) ! ditto end subroutine end
[Bug target/49376] ICE when compiling linux kernel on mipsel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49376 Aurelien Jarno changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Aurelien Jarno --- I am able to reproduce the problem with GCC 4.4.5 or 4.4.5, but not with GCC 4.4.7 nor with GCC 4.8.2. I am therefore marking the bug as resolved fixed.
[Bug other/58712] [4.9 Regression] issues found by --enable-checking=valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712 octoploid at yandex dot com changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #8 from octoploid at yandex dot com --- Too summarize. There are three different issues right now. Issue 2) from above is still unfixed. Plus two new issues. 1) (This is issue 2 from above) ==23547== Use of uninitialised value of size 8 ==23547==at 0x886D95: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==23547==by 0x886E14: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:147) ==23547==by 0x7EEDB4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:175) ==23547==by 0x6BBECF: compile() (cgraphunit.c:1993) ==23547==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==23547==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==23547==by 0x91709C: compile_file() (toplev.c:559) ==23547==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==23547==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==23547== Uninitialised value was created by a stack allocation ==23547==at 0x7EE8B0: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:289) ==23547== ==23547== Conditional jump or move depends on uninitialised value(s) ==23547==at 0x886D9C: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==23547==by 0x886E14: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:147) ==23547==by 0x7EEDB4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:175) ==23547==by 0x6BBECF: compile() (cgraphunit.c:1993) ==23547==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==23547==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==23547==by 0x91709C: compile_file() (toplev.c:559) ==23547==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==23547==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==23547== Uninitialised value was created by a stack allocation ==23547==at 0x7EE8B0: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:289) ==23547== ==23547== Use of uninitialised value of size 8 ==23547==at 0x886E27: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:150) ==23547==by 0x7EEDB4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:175) ==23547==by 0x6BBECF: compile() (cgraphunit.c:1993) ==23547==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==23547==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==23547==by 0x91709C: compile_file() (toplev.c:559) ==23547==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==23547==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==23547== Uninitialised value was created by a stack allocation ==23547==at 0x7EE8B0: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:289) ==23547== ==23547== Use of uninitialised value of size 8 ==23547==at 0x886D95: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==23547==by 0x886DCD: pointer_set_contains(pointer_set_t const*, void const*) (pointer-set.c:116) ==23547==by 0x7D1356: (anonymous namespace)::pass_ipa_devirt::execute() (ipa-devirt.c:1027) ==23547==by 0x87DD29: execute_one_pass(opt_pass*) (passes.c:2215) ==23547==by 0x87E56A: execute_ipa_pass_list(opt_pass*) (passes.c:2579) ==23547==by 0x6BC003: compile() (cgraphunit.c:2028) ==23547==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==23547==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==23547==by 0x91709C: compile_file() (toplev.c:559) ==23547==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==23547==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==23547== Uninitialised value was created by a stack allocation ==23547==at 0x7D1050: (anonymous namespace)::pass_ipa_devirt::execute() (ipa-devirt.c:1182) ==26207== Use of uninitialised value of size 8 ==26207==at 0x886D95: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==26207==by 0x886E14: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:147) ==26207==by 0x7EEDB4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:175) ==26207==by 0x6BBD0C: compile() (cgraphunit.c:2152) ==26207==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==26207==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==26207==by 0x91709C: compile_file() (toplev.c:559) ==26207==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==26207==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==26207== Uninitialised value was created by a stack allocation ==26207==at 0x6BDEA5: cgr
[Bug driver/57525] cc1.exe: fatal error: help-dummy: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57525 Kai Tietz changed: What|Removed |Added Target|avr | Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-10 CC||ktietz at gcc dot gnu.org Host|i386-mingw32|*-*-* Ever confirmed|0 |1 Known to fail||4.7.2, 4.8.0, 4.9.0 Build|i686-linux-gnu | --- Comment #1 from Kai Tietz --- Confirmed. This happens on any linux-host, too.
[Bug c++/59066] New: Segmentation fault.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59066 Bug ID: 59066 Summary: Segmentation fault. Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alexandre.hamez at gmail dot com Created attachment 31188 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31188&action=edit Preprocessed sources. G++ crashes with the following backtrace : g++ -std=c++11 ./bug.ii -O0 ./bug.ii: In member function 'SDD homomorphism::operator()(SDD) [with C = conf0]': ./bug.ii:1203:60: internal compiler error: Segmentation fault return apply_binary_visitor(evaluation(), **this, *x); 0x8a386f crash_signal ../.././gcc/toplev.c:332 0xa37012 make_decl_rtl(tree_node*) ../.././gcc/varasm.c:1197 0x64ac37 rtx_for_function_call ../.././gcc/calls.c:1675 0x64ac37 expand_call(tree_node*, rtx_def*, int) ../.././gcc/calls.c:2983 0x6f8f4b expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) ../.././gcc/expr.c:10246 0x655e20 expand_call_stmt ../.././gcc/cfgexpand.c:2114 0x655e20 expand_gimple_stmt_1 ../.././gcc/cfgexpand.c:2152 0x655e20 expand_gimple_stmt ../.././gcc/cfgexpand.c:2304 0x65668d expand_gimple_basic_block ../.././gcc/cfgexpand.c:4138 0x6586e6 gimple_expand_cfg ../.././gcc/cfgexpand.c:4657 G++ is called as follow: g++ -std=c++11 ./bug.ii -O0
[Bug middle-end/15996] __builtin_longjmp just after another __builtin_longjmp fails with null dereferencing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15996 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #12 from Eric Botcazou --- __builtin_longjmp and __builtin_setjmp cannot be used for the same buffer in the same function.
[Bug c++/59066] Segmentation fault.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59066 --- Comment #1 from Alexandre Hamez --- I managed to reduce the code causing the segfault of gcc to ~1200 lines, but there are certainly still a lot of useless lines (coming from ).
[Bug target/57982] GetModuleHandle in __register_frame_info causes abort on unload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Kai Tietz --- Ups, this bug didn't shown up in my search-list ... Issue fixed for 4.7, 4.8, and trunk at rev 204635-204637.
[Bug c++/59066] Segmentation fault.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59066 Jonathan Wakely changed: What|Removed |Added Severity|blocker |normal
[Bug c++/59066] C+11, 'using' instead of 'typedef' causes a segmentation fault.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59066 Alexandre Hamez changed: What|Removed |Added Summary|Segmentation fault. |C+11, 'using' instead of ||'typedef' causes a ||segmentation fault. --- Comment #2 from Alexandre Hamez --- I've found what causes the crash. On line 1199 of bug.ii, if 'using data_type = variant>' is changed to 'typedef variant> data_type', the segmentation no longer occurs [1]. I changed the summary to reflect that. [1] Note that this particular code will fail to compile because of a missing member.
[Bug target/57288] cfi_restore should precede cfi_def_cfa_offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57288 --- Comment #2 from Mike Sharov --- (In reply to Andrew Pinski from comment #1) > Can you attach the preprocessed source which is used to create this assembly > file? I'm afraid not. This call has been created by a gigantic collection of templates, macros, and inline functions, so is too large to attach. Futhermore, when compiled with the current gcc 4.8.2, the .cfi directives are entirely different, with no .cfi_restore instructions emitted. If you really can't figure out what the cause was, I'd have to wait until I see another function showing the behavior.
[Bug sanitizer/59067] New: libsanitizer doesn't build with binutils 2.17.50.0.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59067 Bug ID: 59067 Summary: libsanitizer doesn't build with binutils 2.17.50.0.6 on x86_64-unknown-linux-gnu Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Trying to build trunk rev. 204619 with --enable-languages=c,c++,fortran on x86_64-unknown-linux-gnu, I get a build error in stage1-target-libsanitizer: > ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: Assembler > messages: > ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821: > Error: .cfi_endproc without corresponding .cfi_startproc > :21806: Error: open CFI at the end of file; missing .cfi_endproc directive I’m building with binutils 2.17.50.0.6, which is a bit old but I cannot find any mention of needing later binutils on the installation notes. It's not even test at configure-time.
[Bug sanitizer/59068] New: libsanitizer doesn't build on x86_64-unknown-linux-gnu with Linux 2.6.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59068 Bug ID: 59068 Summary: libsanitizer doesn't build on x86_64-unknown-linux-gnu with Linux 2.6.18 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Bootstrapping gcc on my x86_64-unknown-linux-gnu fails with: > ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:25:30: > fatal error: linux/perf_event.h: No such file or directory I'm using trunk binutils (to avoid PR59067), and running Linux 2.6.18, with kernel headers installed. Are there stricter requirements on the linux version in GCC? Where is it documented?
[Bug other/49892] Error in configure test xgcc in x86_64-apple-darwin11.0.0/libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49892 --- Comment #4 from Jack Howarth --- (In reply to Andrew Pinski from comment #3) > Bug in the compiler originally used so closing as invalid. Just to note that Apple finally back ported the llvm-gcc bug fix in Xcode 4.6.1 or later upon their switch from llvm-gcc to clang as the default compiler.
[Bug tree-optimization/58921] [4.9 Regression] ICE with segfault on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58921 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #2 from Mikael Pettersson --- Started with r203842. With checking it fails on gcc_assert (vec_stmt); in case vect_internal_def of vect_get_vec_def_for_operand.
[Bug bootstrap/34881] Bootstrap fails on building libstdc++: can't find file for: -lgcc_s.10.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34881 --- Comment #3 from Ed Smith-Rowland <3dw4rd at verizon dot net> --- On 11/09/2013 06:02 PM, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34881 > > Andrew Pinski changed: > > What|Removed |Added > > Status|WAITING |RESOLVED > Resolution|--- |INVALID > > --- Comment #2 from Andrew Pinski --- > No feedback in over a year now so closing. > OK. I can't even get the box to work anymore. I shoulda closed it myself. Thanks, Ed
[Bug other/38077] strict aliasing is not controllable via the option pragma or is not documented that way
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38077
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #2 from Bernd Edlinger ---
As of current 4.9 trunk, that may have changed a bit.
but it still does not do what one would expect:
struct s
{
int x:8;
int y:24;
};
#pragma GCC push
#pragma GCC optimize ("strict-volatile-bitfields")
int foo(volatile struct s *x)
{
return x->x;
}
#pragma GCC pop
#pragma GCC push
#pragma GCC optimize ("no-strict-volatile-bitfields")
int bar(volatile struct s *x)
{
return x->x;
}
#pragma GCC pop
Both foo and bar are compiled as if -fno-strict-volatile-bitfields
was used on gcc-invocation. Whatever pragma is used last, wins...
push/pop are ignored, and does not restore the original settings.
[Bug middle-end/38318] moving the allocation of temps out of loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 Joost VandeVondele changed: What|Removed |Added CC||glisse at gcc dot gnu.org, ||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #6 from Joost VandeVondele --- Marc, I think your recently posted patch: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01049.html could fix the problem with the testcase subroutine S1, even though 'moving allocations out of loops' is more or less a side effect.
[Bug middle-end/38318] moving the allocation of temps out of loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 --- Comment #7 from Marc Glisse --- (In reply to Joost VandeVondele from comment #6) > Marc, I think your recently posted patch: > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01049.html > could fix the problem with the testcase subroutine S1, even though 'moving > allocations out of loops' is more or less a side effect. I don't speak fortran fluently so I tried compiling S1 with an unpatched compiler and -O2 -fdump-tree-optimized, but I don't see any call to malloc in there. Could you explain, with references to a dump, what the internal functions mean and where my patch might help?
[Bug preprocessor/47756] Warning for #include " " instead of < >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756 Olaf van der Spek changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from Olaf van der Spek --- Comment 2 contains a clear definition. If "" is used but you don't find the file after looking relative to the current file (but before looking in the include path) a warning should be issued.
[Bug ada/57902] Bugbox in Ada 95 mode, at ada/gcc-interface/decl.c:342
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57902 Florian Weimer changed: What|Removed |Added Attachment #30507|0 |1 is obsolete|| --- Comment #1 from Florian Weimer --- Created attachment 31189 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31189&action=edit dnslogger.adb Reduced test case, just one file. Still needs to be compiled with -gnat95; this has something to do with by-reference return of limited records.
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Severity|normal |enhancement --- Comment #1 from kargl at gcc dot gnu.org --- The code is invalid, so gfortran's current behavior is accepted. What do other compilers do with the code? Although I think this should be closed with WONTFIX, I've changes the status to enhancement.
[Bug middle-end/38318] moving the allocation of temps out of loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 --- Comment #8 from Joost VandeVondele --- (In reply to Marc Glisse from comment #7) > (In reply to Joost VandeVondele from comment #6) > > Marc, I think your recently posted patch: > > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01049.html > > could fix the problem with the testcase subroutine S1, even though 'moving > > allocations out of loops' is more or less a side effect. > > I don't speak fortran fluently so I tried compiling S1 with an unpatched > compiler and -O2 -fdump-tree-optimized, but I don't see any call to malloc > in there. Could you explain, with references to a dump, what the internal > functions mean and where my patch might help? Marc, looks like the fortran FE changed a lot since this bug was filed, and there is no explicit allocate anymore, in fact the variable is created on stack by the frontend... this is controlled by -fmax-stack-var-size=0 (putting it to zero, will yield your __builtin_malloc() that I recalled, in the PR38318.f90.003t.original dump). You have a precedent for getting the a reasonable size (32768 for fortran). The _gfortran_internal_(un)pack is a fortran FE thing, that guarantees that memory is contiguous... clearly a missed frontend optimization in this case. So now, the proper testcase would be: > cat PR38318-3.f90 SUBROUTINE S1(N,A) REAL :: A(3) REAL, DIMENSION(:), ALLOCATABLE :: B DO I=1,N ALLOCATE(B(3)) B=-A CALL S2(B) DEALLOCATE(B) ENDDO END SUBROUTINE which really should contain any call to _gfortran_runtime_error_at, _gfortran_os_error, __builtin_malloc, __builtin_free if all were perfect, and certainly not in the loop
[Bug preprocessor/47756] Warning for #include " " instead of < >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756 --- Comment #5 from Jonathan Wakely --- The C++ standard has a note saying: in general programmers should use the < > form for headers provided with the implementation, and the " " form for sources outside the control of the implementation. which your warning would contradict, unless you only suggest it applies to standard headers that are part of the implementation (i.e. GCC and libc)
[Bug target/48155] Reload doesn't handle subreg properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48155 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from H.J. Lu --- Should be fixed now in 4.7.0.
[Bug fortran/59069] New: Bogus error wording for passing array to scalar dummies with user-defined operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59069 Bug ID: 59069 Summary: Bogus error wording for passing array to scalar dummies with user-defined operator Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following error message is very misleading. The problem is not the type but that the operands are arrays and the user-defined operator is not elemental: print *, any( many == single ) 1 Error: Operands of comparison operator '==' at (1) are TYPE(latvec)/TYPE(latvec) Found at https://groups.google.com/forum/#!topic/comp.lang.fortran/tuy1wUmVBkY module Overloading implicit none type Latvec integer :: hkl(3) end type Latvec interface operator (==) procedure :: Latvec_equals end interface operator (==) contains pure function Latvec_equals(latvec1, latvec2) result(equals) implicit none type(Latvec), intent(in) :: latvec1, latvec2 logical :: equals equals = all(latvec1%hkl == latvec2%hkl) end function Latvec_equals end module Overloading program Main use Overloading implicit none type(Latvec) :: many(2) = [ Latvec([0,0,1]), Latvec([0,0,2]) ] type(Latvec) :: single = Latvec([0,0,1]) ! these work just fine print *, single == many(1) print *, single == many(2) ! this gives the compilation error: ! Operands of comparison operator '==' at (1) are TYPE(latvec)/TYPE(latvec) print *, any( many == single ) end program Main
[Bug c++/59070] New: Captured object is being moved from the lambda on returning it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59070
Bug ID: 59070
Summary: Captured object is being moved from the lambda on
returning it.
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sir_nawaz959 at yahoo dot com
I'm using GCC 4.8.1
Here is the code which reproduces this bug:
std::vector items {"default"};
auto add = [=](std::string item) mutable
{ items.push_back(item); return items; };
std::cout << add("one") << std::endl;
std::cout << add("two") << std::endl;
std::cout << add("three") << std::endl;
Imagine that operator<< is overloaded for std::vector which all items on ONE
line. The expected out is:
default one
default one two
default one two three
But it actually outputs this:
default one
two
three
So it seems on the first return, the captured vector is moved.
However, if I define the lambda as:
auto add = [=](std::string item) mutable
{ items.push_back(item); auto & x = items; return x; } ;
OR as:
auto add = [=](std::string item) mutable
{ auto & x= items; x.push_back(item); return x; } ;
It prints the expected output.
[Bug middle-end/38318] moving the allocation of temps out of loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 --- Comment #9 from Marc Glisse --- (In reply to Joost VandeVondele from comment #8) > Marc, looks like the fortran FE changed a lot since this bug was filed, and > there is no explicit allocate anymore, in fact the variable is created on > stack by the frontend... Cool, the best optimizations are those you don't need to do ;-) > So now, the proper testcase would be: > > cat PR38318-3.f90 > SUBROUTINE S1(N,A) > REAL :: A(3) > REAL, DIMENSION(:), ALLOCATABLE :: B > DO I=1,N >ALLOCATE(B(3)) >B=-A >CALL S2(B) >DEALLOCATE(B) > ENDDO > END SUBROUTINE > > which really should contain any call to _gfortran_runtime_error_at, > _gfortran_os_error, __builtin_malloc, __builtin_free if all were perfect, > and certainly not in the loop Ok. If you used __builtin_abort instead of _gfortran_os_error, I think my current patch would handle it. It is hard for gcc to guess that _gfortran_os_error is safe. On the other hand, if I special case the test if(VAR==0) as mentioned in a comment in my patch, it won't look at that branch anymore and the optimization should apply. Er, no, I missed the call to s2. I would also need some attribute on s2 so the compiler knows that s2 doesn't do anything too weird. Hopefully, when the compiler has the sources for s2, we could later let it guess those attributes...
[Bug middle-end/38318] moving the allocation of temps out of loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 --- Comment #10 from Joost VandeVondele --- (In reply to Marc Glisse from comment #9) > > Ok. If you used __builtin_abort instead of _gfortran_os_error, I think my > current patch would handle it. It is hard for gcc to guess that > _gfortran_os_error is safe. For the Fortran FE people (not me, I'm a user), but _gfortran_os_error should have an attribute like 'abort' or 'noreturn'. However, the compiler should also be able to figure out this can never be called (if B is 'allocated on the stack') in this subroutine. > Er, no, I missed the call to s2. I would also need some attribute on s2 so > the compiler knows that s2 doesn't do anything too weird. Actually, in Fortran, S2 can't do anything 'weird' with B, in the sense that your optimization should certainly apply. Not so sure about the correct terms here, but in approximate C-speak, B 'as a pointer' is guaranteed to be pointing to exactly the same address, nothing has happened to its target, and no pointer can be pointing to whatever B was pointing to
[Bug c++/59070] Captured object is being moved from the lambda on returning it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59070 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-10 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Sarfaraz Nawaz from comment #0) > Here is the code which reproduces this bug: That code doesn't reproduce anything because it doesn't compile, please provide *complete* testcases instead of expecting other people to fill in the gaps.
[Bug c++/59070] Captured object is being moved from the lambda on returning it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59070
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #2 from Jonathan Wakely ---
This is a valid testcase:
#include
#include
#include
struct VecPrinter {
const std::vector& v;
};
std::ostream& operator<<(std::ostream& out, VecPrinter vp)
{
for (auto& i : vp.v)
out << i << ' ';
return out;
}
int main()
{
std::vector items {"default"};
auto add = [=](std::string item) mutable
{ items.push_back(item); return items; };
std::cout << VecPrinter{ add("one") } << std::endl;
std::cout << VecPrinter{ add("two") } << std::endl;
std::cout << VecPrinter{ add("three") } << std::endl;
}
And it works perfectly with
gcc version 4.8.3 20131029 (prerelease) (GCC)
gcc version 4.9.0 20131002 (experimental) (GCC)
[Bug c++/59070] Captured object is being moved from the lambda on returning it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59070 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > And it works perfectly with > gcc version 4.8.3 20131029 (prerelease) (GCC) > gcc version 4.9.0 20131002 (experimental) (GCC) and gcc version 4.7.4 20131030 (prerelease) (GCC)
[Bug middle-end/38318] moving the allocation of temps out of loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 --- Comment #11 from Marc Glisse --- (In reply to Joost VandeVondele from comment #10) > (In reply to Marc Glisse from comment #9) > > Ok. If you used __builtin_abort instead of _gfortran_os_error, I think my > > current patch would handle it. It is hard for gcc to guess that > > _gfortran_os_error is safe. > > For the Fortran FE people (not me, I'm a user), but _gfortran_os_error > should have an attribute like 'abort' or 'noreturn'. abort doesn't exist, and noreturn is not sufficient, as a function that calls free on the pointer then exits is noreturn but unsafe. > However, the compiler > should also be able to figure out this can never be called (if B is > 'allocated on the stack') in this subroutine. Yes. > > Er, no, I missed the call to s2. I would also need some attribute on s2 so > > the compiler knows that s2 doesn't do anything too weird. > > Actually, in Fortran, S2 can't do anything 'weird' with B, in the sense that > your optimization should certainly apply. Not so sure about the correct > terms here, but in approximate C-speak, B 'as a pointer' is guaranteed to be > pointing to exactly the same address, nothing has happened to its target, > and no pointer can be pointing to whatever B was pointing to So S2 cannot call free (or realloc) on the pointer and then exit or call longjmp or do an infinite loop or anything like that in fortran? Maybe we'll need a flag set by the front-end that says whether (all) functions are safe.
[Bug c++/59070] Captured object is being moved from the lambda on returning it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59070
Sarfaraz Nawaz changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WORKSFORME |---
--- Comment #4 from Sarfaraz Nawaz ---
Here is the complete testcase which compiles fine but gives incorrect output:
#include
#include
#include
std::ostream & operator<<(std::ostream & out, std::vector const &
items)
{
for(auto const & item : items )
out << item << " ";
return out;
}
int main()
{
std::cout << "\nGCC " << __VERSION__ << std::endl;
std::vector items {"default"};
auto add = [=](std::string item) mutable { items.push_back(item); return
items; } ;
std::cout << add("one") << std::endl;
std::cout << add("two") << std::endl;
std::cout << add("three") << std::endl;
}
$ g++-4.8 -std=c++11 -O2 -Wall -pedantic-errors main.cpp && ./a.out
GCC 4.8.1
default one
two
three
which is incorrect output
[Bug middle-end/38318] moving the allocation of temps out of loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 --- Comment #12 from Joost VandeVondele --- (In reply to Marc Glisse from comment #11) > So S2 cannot call free (or realloc) on the pointer and then exit or call > longjmp or do an infinite loop or anything like that in fortran? Maybe we'll > need a flag set by the front-end that says whether (all) functions are safe. well, not free or realloc or longjmp, but infinite loops are allowed in S2. The point is, one is really not passing a pointer to S2 (from a Fortran point of view).
[Bug middle-end/57436] Linux kernel gives file system corruption when built with gcc 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57436 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- (In reply to Andreas Radke from comment #3) > note: we had a similar issue in libdrm. maybe it's related or not. this one > is now fixed: > http://cgit.freedesktop.org/mesa/drm/commit/ > ?id=482abbfafb56cbceaf5355c026434e638cddd0f1 That is undefined behavior. If that happens to be the same issue in XFS then it is a bug in the source of XFS and not GCC. Closing as invalid.
[Bug target/57288] cfi_restore should precede cfi_def_cfa_offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57288 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- So closing as invalid. Next time you can gzip the preprocessed file or even place it on some public web page if it becomes too big.
[Bug c/52862] [4.5/4.6 Regression] ICE convert_to_pointer, at convert.c:50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862 --- Comment #10 from Kai Tietz --- Author: ktietz Date: Sun Nov 10 19:24:43 2013 New Revision: 204650 URL: http://gcc.gnu.org/viewcvs?rev=204650&root=gcc&view=rev Log: PR plugin/52862 * configure.ac: Adding for exported symbols check and for rdynamic-check executable-extension. * configure: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 --- Comment #8 from Kai Tietz --- Author: ktietz Date: Sun Nov 10 19:27:38 2013 New Revision: 204651 URL: http://gcc.gnu.org/viewcvs?rev=204651&root=gcc&view=rev Log: Fixed typo about bug-number ... PR plugin/52872 * configure.ac: Adding for exported symbols check and for rdynamic-check executable-extension. * configure: Regenerated. Modified: trunk/gcc/ChangeLog
[Bug c++/59070] Captured object is being moved from the lambda on returning it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59070 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.4, 4.8.3, 4.9.0 Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- But I already said it works with current releases, and obviously we don't have a time machine to fix 4.8.1 now, so there's no point re-opening the bug. GCC 4.8.2 20131017 (Red Hat 4.8.2-1) default one default one two default one two three
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 --- Comment #9 from Kai Tietz --- Author: ktietz Date: Sun Nov 10 19:29:34 2013 New Revision: 204652 URL: http://gcc.gnu.org/viewcvs?rev=204652&root=gcc&view=rev Log: Merged from trunk PR plugins/52872 * configure.ac: Adding for exported symbols check and for rdynamic-check executable-extension. * configure: Regenerated. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/configure branches/gcc-4_8-branch/gcc/configure.ac
[Bug java/44876] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44876 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- No feedback in over 3 years so closing.
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 --- Comment #10 from Kai Tietz --- Author: ktietz Date: Sun Nov 10 19:32:42 2013 New Revision: 204653 URL: http://gcc.gnu.org/viewcvs?rev=204653&root=gcc&view=rev Log: Merged from trunk PR plugins/52872 * configure.ac: Adding for exported symbols check and for rdynamic-check executable-extension. * configure: Regenerated. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/configure branches/gcc-4_7-branch/gcc/configure.ac
[Bug tree-optimization/42970] Missed unused function return value elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW
[Bug target/46891] Can't build libquadmath for i386-elf target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46891 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- NO feedback in almost 3 years so closing.
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Kai Tietz --- Fixed issue for all open branches ... therefore close issue.
[Bug lto/50338] ICE Linking with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50338 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- No testcase in 2 years so closing as invalid.
[Bug target/47015] gcc/gengtype.c: undefined references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47015 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- This is a broken flex, there is not much we could do here so closing.
[Bug bootstrap/50646] configure detects big endian on little endian system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50646 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- As reported, this is a bug in the original compiler that was being used. This has since been well tested in the 2 years since this was reported and no other reports of this issue so closing.
[Bug debug/51156] build glibc-2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51156 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- No feedback in almost 2 years so closing and I Have built glibc-2.11 on mips64-linux-gnu with no troubles during that time so I know it works.
[Bug tree-optimization/42970] Missed unused function return value elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz --- This testcase seems to be invalid ... The function quantum_gate_counter is visible out-side of the current TU. So nobody can predict that return-type isn't used by external users. So optimization can be done. By adding static to the prototype of quantum_gate_counter for making it visible only to local TU, things getting optimized as desired.
[Bug c/49548] integer comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49548 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- No testcase in over 2 years so closing.
[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #11 from Andrew Pinski --- As mentioned this is because decimal floating point is all soft implementation and that brings in a lot of code.
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 --- Comment #2 from Vittorio Zecca --- g95: complains about deallocated array passed to LBOUND Intel ifort: 1 0 0 1 0 0 1 0 0 1 0 0 NAG nagfor: -220021792 -220021793 0 1 0 0 1 0 0 1 0 0 Lahey Fujitsu lfc: 0 0 0 0 0 0 1 0 0 1 0 0 All of them put SIZE to zero that looks to me better than one as gfortran does. But best behavior is g95's that detects the bug, and displays the correct line number as in the following: rm a.out ; g95 gfbug109.f -ftrace=full -g; ./a.out At line 8 of file gfbug109.f (Unit 6) Traceback: not available, compile with -ftrace=frame or -ftrace=full Fortran runtime error: Deallocated array passed to LBOUND So it would be an enhancement to sensibly handle unallocated/unassociated arrays.
[Bug c/52708] suboptimal code with __builtin_constant_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52708 Andrew Pinski changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- Created attachment 31190 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31190&action=edit Patch which I think fixes this issue I think this is a valid complaint. I attached a patch which is against 4.7.0 which should fix this issue. The problem is PRE tries to pull out the __builtin_constant_p call and then optimizes based on that.
[Bug middle-end/53496] gcc segfaults when compiling glib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53496 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- No feedback in over a year so closing as invalid
[Bug target/53906] Runtime crash on ARM linux when using std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53906 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- No feedback in almost a year so closing as invalid.
[Bug other/48318] Memory access error by "build/genhooks"?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Andrew Pinski --- Closing as invalid as reported updating binutils fixes the issue.
[Bug target/24000] wrong constants allocation for altivec data type on PPC little-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24000 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Andrew Pinski --- Little-endian altivec has been fixed on the trunk (GCC 4.9) so closing as fixed.
[Bug other/25943] Options added to collect2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25943 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- (In reply to Manuel López-Ibáñez from comment #2) > No activity in 6 years, I would close as WONTFIX, but let's leave it at > WAITING. One more year so closing.
[Bug lto/50366] Still got failed assertion in lto_varpool_replace_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50366 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- No testcase in a year so closing.
[Bug c++/59071] New: sse2 intrinsics and constant expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59071
Bug ID: 59071
Summary: sse2 intrinsics and constant expressions
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vermaelen.wouter at gmail dot com
gcc-4.8.2 with -O0 rejects the following code. With -O1 it works fine. Gcc-4.6,
4.7 and clang also work fine. I *believe* the stuff below is a constant
expression, so it should compile (even without optimizations enabled).
---
#include "emmintrin.h"
template __m128i foo(__m128i x) {
return _mm_slli_si128(x, sizeof(__m128i) - N);
}
void bar(__m128i x) { foo<4>(x); }
> g++ test.cc
In file included from test.cc:1:0:
test.cc: In function ‘__m128i foo(__m128i) [with int N = 4; __m128i =
__vector(2) long long int]’:
test.cc:4:9: error: the last argument must be an 8-bit immediate
return _mm_slli_si128(x, sizeof(__m128i) - N);
[Bug target/53649] ICE when using 'C' x86 asm constraint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53649 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Andrew Pinski --- The testcase works for me and others so closing.
[Bug middle-end/50643] Suppress cc1: warnings being treated as errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50643 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Andrew Pinski --- In GCC 4.8.0 and above, it shows what option enabled the error (in most cases) including the warning option that enabled it.
[Bug target/54841] Bad optimization on stack fill before call on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54841 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- No testcase provided in almost a year so closing.
[Bug target/57571] linux kernel function memcpy() execute with low efficiency on Intel Ivybridge platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57571 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- No testcase in 5 months so closing.
[Bug tree-optimization/53966] procmail build deadloop on _autotst & -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53966 --- Comment #4 from Andrew Pinski --- Also we need a self contained testcase to go any further on this problem.
[Bug tree-optimization/54982] false unitialized warning about store_flag in tree-ssa-loop-im.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54982 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- No feed back in over 11 months so closing.
[Bug rtl-optimization/57970] segfault in sched-deps.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57970 Andrew Pinski changed: What|Removed |Added Component|other |rtl-optimization Severity|major |normal --- Comment #1 from Andrew Pinski --- Patches should go to gcc-patches@ .
[Bug c/52862] [4.5/4.6 Regression] ICE convert_to_pointer, at convert.c:50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862 --- Comment #11 from Kai Tietz --- (In reply to Kai Tietz from comment #10) Please ignore commit-message ... wrong bug-number
[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032
--- Comment #4 from vries at gcc dot gnu.org ---
> We already support v=v+1, so it wouldn't be a large extension.
Hmm, indeed. If found some code in cp_builld_binary_op marked with this
comment:
...
/* In case when one of the operands of the binary operation is
a vector and another is a scalar -- convert scalar to vector. */
...
I've tried to do something similar in cp_build_unary_op. Tentative patch:
...
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index bcb8782..0554664 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5746,7 +5746,38 @@ cp_build_unary_op (enum tree_code code, tree xarg, int
noconvert,
else
inc = integer_one_node;
- inc = cp_convert (argtype, inc, complain);
+ /* In case when the operand of the unary operation is a vector --
+ convert scalar inc to vector. */
+ if (TREE_CODE (TREE_TYPE (arg)) == VECTOR_TYPE)
+ {
+ enum stv_conv convert_flag;
+ enum tree_code pm_code = ((code == PREINCREMENT_EXPR
+ || code == POSTINCREMENT_EXPR)
+ ? PLUS_EXPR
+ : MINUS_EXPR);
+
+ convert_flag = scalar_to_vector (input_location, pm_code, arg, inc,
+complain & tf_error);
+
+ switch (convert_flag)
+ {
+ case stv_error:
+ return error_mark_node;
+ case stv_firstarg:
+ gcc_unreachable ();
+ case stv_secondarg:
+ {
+ inc = save_expr (inc);
+ inc = convert (TREE_TYPE (TREE_TYPE (arg)), inc);
+ inc = build_vector_from_val (TREE_TYPE (arg), inc);
+ break;
+ }
+ default:
+ break;
+ }
+ }
+ else
+ inc = cp_convert (argtype, inc, complain);
/* If 'arg' is an Objective-C PROPERTY_REF expression, then we
need to ask Objective-C to build the increment or decrement
...
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-10 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- > Agreed. Detecting bugs is better. But, the best behavior > would be for the programmer not to write invalid code. :-) 'Let anyone among you who is without sin be the first to throw a stone at her. ...' and I love the following sentence: 'When they heard it, they went away, one by one, beginning with the elders' (john 7:53-8:11). I think there is a couple of PR's about invalid use of unallocated arrays or pointers.
[Bug tree-optimization/58028] [4.9 Regression] Several failures in libgomp.graphite after revision 200946
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028 Dominique d'Humieres changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #2 from Dominique d'Humieres --- What is the "fix or revert" policy?
[Bug c++/58990] G++ generates duplicate labels for linux 32-bit when optimization+LFS is enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58990 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- The issue is simple, GCC is generating the correct assembly. The problem is C++ defines extern inline differently from GNU C90 and more like C99's extern inline. We had a way to fix up the header files for this specific issue but it looks like it is not happening for your version of glibc or rather the fixed up headers are not being used as the package installer did not do that which means this is a bug in your distro's binary package and should be reported to them.
[Bug driver/55651] gcc hangs when "-Wp," is passed on the command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55651 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- As reported this is correct behavior.
[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032 --- Comment #5 from Marc Glisse --- (In reply to vries from comment #4) > I've tried to do something similar in cp_build_unary_op. Tentative patch: That seems very complicated. We know the arguments, so we know which has to be converted to what. You could probably make cp_build_unary_op call cp_build_binary_op and cp_build_modify_expr (expand ++v as v=v+1), but I expect something like the 1-liner in comment #3 should be enough, no?
[Bug rtl-optimization/57970] segfault in sched-deps.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57970 --- Comment #2 from Chris King --- If you don't want proposed patches attached to bug reports, then I suggest you remove the text "proposed patch" which is next to the "Add an attachment" link.
