[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #25 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Jun 18 06:09:28 2014 New Revision: 211766 URL: https://gcc.gnu.org/viewcvs?rev=211766root=gccview=rev Log: 2014-06-18 Manuel López-Ibáñez m...@gcc.gnu.org PR fortran/61126 * options.c (gfc_handle_option): Remove call to handle_generated_option. 2014-06-18 Dominique d'Humieres domi...@lps.ens.fr PR fortran/61126 * gfortran.dg/wextra_1.f: Add -Wall to dg-options. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/wextra_1.f
[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #26 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Jun 18 06:22:11 2014 New Revision: 211767 URL: https://gcc.gnu.org/viewcvs?rev=211767root=gccview=rev Log: 2014-06-18 Tobias Burnus bur...@net-b.de PR fortran/61126 * invoke.texi (-Wunused-parameter): Make clearer when -Wextra implies this option. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi
[Bug driver/61106] [4.8/4.9/4.10 Regression] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 Bug 61106 depends on bug 61126, which changed state. Bug 61126 Summary: [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Tobias Burnus burnus at gcc dot gnu.org --- Should be FIXED. The first commit contains the patches from comment 10 and 23, the second (cf. comment 22) mentions -Wextra -Wunused in the manual; I kept the -Wextra -Wall in line with gcc/doc/invoke.texi, even though -Wall is only indirectly affecting this option.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Excellent, that version is very safe. Are you willing to commit it? Otherwise, I don't know when I can do it, maybe only Sunday. If you do that, you may want to also add, after the first comment: // By default follow the old inline rules to avoid ABI changes. something like: // (logic copied from libsupc++/typeinfo (libstdc++/61536)). otherwise the patch is ready to go in.
[Bug tree-optimization/61515] [4.9/4.10 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 17 Jun 2014, law at redhat dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #12 from Jeffrey A. Law law at redhat dot com --- Fundamentally we don't have a way to know what equivalences we need to invalidate. Invalidation is, umm, painful. The question in my mind is why are we getting so many invalidations to start with. That's the first thing to look at. Well, it's easy to avoid the quadraticness - you can always create testcases that need a lot of invalidates. But the current algorithm really does not scale. Honestly though, I really wonder if handling backedges is worth the effort, even though it's important for one benchmark. Not sure about that, but trivial improvements to the scalability are possible here. Walking all SSA names is O(number of stmts) - if you do that O(number of stmts) time (as you do) that's clearly the bug.
[Bug tree-optimization/52252] An opportunity for x86 gcc vectorizer (gain up to 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52252 --- Comment #7 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Wed Jun 18 07:46:18 2014 New Revision: 211769 URL: https://gcc.gnu.org/viewcvs?rev=211769root=gccview=rev Log: gcc/ * config/i386/i386.c (ix86_reassociation_width): Add alternative for vector case. * config/i386/i386.h (TARGET_VECTOR_PARALLEL_EXECUTION): New. * config/i386/x86-tune.def (X86_TUNE_VECTOR_PARALLEL_EXECUTION): New. * tree-vect-data-refs.c (vect_shift_permute_load_chain): New. Introduces alternative way of loads group permutaions. (vect_transform_grouped_load): Try alternative way of permutations. gcc/testsuite/ PR tree-optimization/52252 * gcc.target/i386/pr52252-atom.c: Test on loads group of size 3. * gcc.target/i386/pr52252-core.c: Ditto. PR tree-optimization/61403 * gcc.target/i386/pr61403.c: Test on loads and stores group of size 3. Added: trunk/gcc/testsuite/gcc.target/i386/pr52252-atom.c trunk/gcc/testsuite/gcc.target/i386/pr52252-core.c trunk/gcc/testsuite/gcc.target/i386/pr61403.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/x86-tune.def trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/61403] An opportunity for x86 gcc vectorizer (~40% gain)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61403 --- Comment #1 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Wed Jun 18 07:46:18 2014 New Revision: 211769 URL: https://gcc.gnu.org/viewcvs?rev=211769root=gccview=rev Log: gcc/ * config/i386/i386.c (ix86_reassociation_width): Add alternative for vector case. * config/i386/i386.h (TARGET_VECTOR_PARALLEL_EXECUTION): New. * config/i386/x86-tune.def (X86_TUNE_VECTOR_PARALLEL_EXECUTION): New. * tree-vect-data-refs.c (vect_shift_permute_load_chain): New. Introduces alternative way of loads group permutaions. (vect_transform_grouped_load): Try alternative way of permutations. gcc/testsuite/ PR tree-optimization/52252 * gcc.target/i386/pr52252-atom.c: Test on loads group of size 3. * gcc.target/i386/pr52252-core.c: Ditto. PR tree-optimization/61403 * gcc.target/i386/pr61403.c: Test on loads and stores group of size 3. Added: trunk/gcc/testsuite/gcc.target/i386/pr52252-atom.c trunk/gcc/testsuite/gcc.target/i386/pr52252-core.c trunk/gcc/testsuite/gcc.target/i386/pr61403.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/x86-tune.def trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug libgcc/61546] MINGW : __int64 is #define'd as 'long long'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61546 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Well, long long(123456789012345678); isn't valid C++. Either use cast syntax or provide a typedef.
[Bug ipa/61540] internal compiler error in try_make_edge_direct_virtual_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61540 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-18 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug libgcc/61546] MINGW : __int64 is #define'd as 'long long'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61546 --- Comment #2 from Anton Baskanov baskanov at gmail dot com --- (In reply to Richard Biener from comment #1) Well, long long(123456789012345678); isn't valid C++. Either use cast syntax or provide a typedef. Yes, you are right, but why libgcc uses #define for __int64 instead of typedef? This is confusing.
[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #5 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Created attachment 32962 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32962action=edit Proposed patch This was caused by some invalid rtl sharing between DECL_INCOMING_RTL and the insn stream. I think the right fix is (a) to copy stack_parm and entry_parm before using them in the rtl stream and (b) as compensation, to allow validize_mem to modify its argument in-place. As well as fixing the bug, this seems to reduce the total amount of rtl copying required. Of course, the problem with (b) is that this could in turn expose other invalid sharing bugs, so it's a bit frying-pan-to-fire. I've tried to look through all calls to validize_mem to see which might be affected. The patch passed bootstrap on x86_64-linux-gnu but could you test it for sparc too?
[Bug libgcc/61546] MINGW : __int64 is #define'd as 'long long'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61546 Ozkan Sezer sezeroz at gmail dot com changed: What|Removed |Added CC||sezeroz at gmail dot com --- Comment #3 from Ozkan Sezer sezeroz at gmail dot com --- (In reply to Anton Baskanov from comment #2) why libgcc uses #define for __int64 instead of typedef? MinGW and MinGW-w64 use #define instead of a typedef, because that allows for uses like 'signed __int64' and 'unsigned __int64', i.e. __int64 isn't native to gcc.
[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #5 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- [...] The patch passed bootstrap on x86_64-linux-gnu but could you test it for sparc too? Sure: sparc-sun-solaris2.11 bootstrap in progress. I'll be leaving for a short vacation before that finishes, so don't expect a result before tuesday next week. Thanks. Rainer
[Bug libgcc/61546] MINGW : __int64 is #define'd as 'long long'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61546 --- Comment #4 from Anton Baskanov baskanov at gmail dot com --- (In reply to Ozkan Sezer from comment #3) (In reply to Anton Baskanov from comment #2) why libgcc uses #define for __int64 instead of typedef? MinGW and MinGW-w64 use #define instead of a typedef, because that allows for uses like 'signed __int64' and 'unsigned __int64', i.e. __int64 isn't native to gcc. OK, got it. Thanks for the answer!
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #14 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Wed Jun 18 09:44:15 2014 New Revision: 211774 URL: https://gcc.gnu.org/viewcvs?rev=211774root=gccview=rev Log: Fix libstdc++/61536 - Export out of line typeinfo comparison operators 2014-06-18 Paolo Carlini paolo.carl...@oracle.com Ramana Radhakrishnan ramana.radhakrish...@arm.com PR libstdc++/61536 * config/abi/pre/gnu.ver: Adjust for out of line comparisons. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed now.
[Bug driver/61106] [4.8/4.9/4.10 Regression] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #18 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Richard, Jakub, Now that the fortran issued was fixed, can Matthias commit the patch again? in all branches? I think this issue may affect other options, not just -Wunused-parameter.
[Bug sanitizer/61547] New: Invalid sanitization of trailing byte in __builtin_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547 Bug ID: 61547 Summary: Invalid sanitization of trailing byte in __builtin_strlen Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: y.gribov at samsung dot com 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 Created attachment 32963 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32963action=edit Reprocase The attached testcase performs an overflow in strlen call. Current GCC fails to detect it because of invalid instrumentation of trailing byte: $ gcc repro.c -fsanitize=address -O1 -static-libasan $ ./a.out $ echo $? 0
[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547 --- Comment #1 from Yury Gribov y.gribov at samsung dot com --- Created attachment 32964 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32964action=edit Proposed patch Adding draft patch. I only ran Asan regression tests though (leaving for long vacation today). Perhaps someone will have time to have a look at this.
[Bug target/61544] ICE due to thumb1_reorg function mishandles label type insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544 --- Comment #1 from xuepeng guo xguo at gcc dot gnu.org --- Author: xguo Date: Wed Jun 18 10:11:08 2014 New Revision: 211775 URL: https://gcc.gnu.org/viewcvs?rev=211775root=gccview=rev Log: 2014-06-18 Terry Guo terry@arm.com PR target/61544 * config/arm/arm.c (thumb1_reorg): Move to next basic block if we reach the head. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug target/61544] ICE due to thumb1_reorg function mishandles label type insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544 Terry Guo terry.guo at arm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Terry Guo terry.guo at arm dot com --- The fix is submitted.
[Bug sanitizer/61530] [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 --- Comment #6 from Yury Gribov y.gribov at samsung dot com --- Created attachment 32965 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32965action=edit Alternative patch Draft patch to illustrate the last proposal. Bootstrap pending.
[Bug regression/61548] New: FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Bug ID: 61548 Summary: FAIL: gcc.dg/tls/alias-1.c (internal compiler error) Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org On arm and aarch64 I see ICEs in the aforementioned test: $TOP/gcc/testsuite/gcc.dg/tls/alias-1.c:24:3: internal compiler error: Segmentation fault 0x9f71d5 crash_signal $TOP/gcc/toplev.c:337 0x6b1f7e symtab_alias_target $TOP/gcc/cgraph.h:1534 0x6b1f7e verify_symtab_base(symtab_node*) $TOP/gcc/symtab.c:830 0x6b21e9 verify_symtab_node(symtab_node*) $TOP/gcc/symtab.c:863 0x6b3684 verify_symtab() $TOP/gcc/symtab.c:881 0x8917d5 symtab_remove_unreachable_nodes(bool, _IO_FILE*) $TOP/gcc/ipa.c:592 0x6c0c74 ipa_passes $TOP/gcc/cgraphunit.c:2065 0x6c0c74 compile() $TOP/gcc/cgraphunit.c:2187 0x6c1909 finalize_compilation_unit() $TOP/gcc/cgraphunit.c:2342 0x56a5ac c_write_global_declarations() $TOP/gcc/c/c-decl.c:10452 I'm using an arm-none-eabi cross configured with --with-fpu=neon-fp-armv8 --with-arch=armv8-a at r211767. Trying to go back to find a good revision is not easy because arm builds have been broken by other things recently.
[Bug other/61549] New: Error when linking with shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61549
Bug ID: 61549
Summary: Error when linking with shared libraries
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: isak50 at mail dot ru
// os - linux debian
//-- /usr/local/lib/1.cpp
#include iostream
struct S
{
int val;
S() {val=1; std::cout 1::constr\n;}
~S() {std::cout 1::destr\n;}
}s;
extern int f1() {return s.val;}
//-- /usr/local/lib/2.cpp
#include iostream
struct S
{
int val;
S() {val=2; std::cout 2::constr\n;}
~S() {std::cout 2::destr\n;}
}s;
extern int f2() {return s.val;}
//-- /usr/local/lib/ex.cpp
#include iostream
extern int f1();
extern int f2();
int main()
{
std::cout ex::main\n;
std::cout f1 = f1() \n;
std::cout f2 = f2() \n;
return 0;
}
//-- buid
/usr/local/lib $ g++ 1.cpp -fPIC -shared -o lib1.so
/usr/local/lib $ g++ 2.cpp -fPIC -shared -o lib2.so
/usr/local/lib $ g++ ex.cpp lib1.so lib2.so -o ex
/usr/local/lib $ ldconfig
//-- run
./ex
//-- output
1::constr
1::constr // Why 1::constr? should be 2::constr
ex::main
f1 = 1
f2 = 1
1::destr// Why 1::destr? should be 2::destr
1::destr
[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547 --- Comment #2 from Kostya Serebryany kcc at gcc dot gnu.org --- Note that in clang we chose not to instrument any builtins in compiler, but instead fully rely on interceptors.
[Bug rtl-optimization/54555] (set (REGX) (CONST_INT B)) - (set (STRICT_LOW_PART (REGX)) (CONST_INT B)) is pessimising
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54555 --- Comment #2 from Andreas Schwab schwab at gcc dot gnu.org --- Author: schwab Date: Wed Jun 18 10:37:14 2014 New Revision: 211777 URL: https://gcc.gnu.org/viewcvs?rev=211777root=gccview=rev Log: Use strict_low_part for loading a constant only if it is cheaper PR rtl-optimization/54555 * postreload.c (move2add_use_add2_insn): Substitute STRICT_LOW_PART only if it is cheaper. testsuite/: PR rtl-optimization/54555 * gcc.target/m68k/pr54555.c: New test. Added: trunk/gcc/testsuite/gcc.target/m68k/pr54555.c Modified: trunk/gcc/ChangeLog trunk/gcc/postreload.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/54555] (set (REGX) (CONST_INT B)) - (set (STRICT_LOW_PART (REGX)) (CONST_INT B)) is pessimising
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54555 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org --- Fixed for 4.10.
[Bug tree-optimization/61517] [4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61517 --- Comment #3 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Wed Jun 18 10:43:50 2014 New Revision: 211778 URL: https://gcc.gnu.org/viewcvs?rev=211778root=gccview=rev Log: 2014-06-18 Thomas Preud'homme thomas.preudho...@arm.com gcc/ PR tree-optimization/61517 * tree-ssa-math-opts.c (find_bswap_or_nop_1): Adapt to return a stmt whose rhs's first tree is the source expression instead of the expression itself. (find_bswap_or_nop): Likewise. (bsap_replace): Rename stmt in cur_stmt. Pass gsi by value and src as a gimple stmt whose rhs's first tree is the source. In the memory source case, move the stmt to be replaced close to one of the original load to avoid the problem of a store between the load and the stmt's original location. (pass_optimize_bswap::execute): Adapt to change in bswap_replace's signature. gcc/testsuite/ * gcc.c-torture/execute/bswap-2.c (incorrect_read_le32): New. (incorrect_read_be32): Likewise. (main): Call incorrect_read_* to test stmt replacement is made by bswap at the right place. * gcc.c-torture/execute/pr61517.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr61517.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/bswap-2.c trunk/gcc/tree-ssa-math-opts.c
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #40 from thopre01 at gcc dot gnu.org --- Alright, change commited (r211778). Can you try another bootstrap with trunk to see if your Bus error was this bug or another one still? Thanks a lot.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #41 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #40 from thopre01 at gcc dot gnu.org --- Alright, change commited (r211778). Can you try another bootstrap with trunk to see if your Bus error was this bug or another one still? One bootstrap is already running, but I'm about to leave for a short vacation. I'll get back to you when I've returned next tuesday. Rainer
[Bug other/61549] Error when linking with shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61549 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You are violating the one-definition-rule (ODR) of C++. It's undefined if two same classes have different implementations. Put them in anonymous namespaces and it'll work.
[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Kostya Serebryany from comment #2) Note that in clang we chose not to instrument any builtins in compiler, but instead fully rely on interceptors. So you never expand such builtins inline?
[Bug target/61550] New: [4.10 Regression] [SH] build failure with ICE in gen_reg_rtx, at emit-rtl.c:943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61550 Bug ID: 61550 Summary: [4.10 Regression] [SH] build failure with ICE in gen_reg_rtx, at emit-rtl.c:943 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kkojima at gcc dot gnu.org Target: sh*-*-* Created attachment 32966 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32966action=edit A reduced test case The trunk fails to build on sh4-unknown-linux-gnu with an ICE during compiling libgomp. A reduced case attached fails with: gomp.c: In function 'gomp_thread_start': gomp.c:59:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:943 } ^ 0x8332ab1 gen_reg_rtx(machine_mode) ../../ORIG/trunk/gcc/emit-rtl.c:943 0x8343ad2 force_reg ../../ORIG/trunk/gcc/explow.c:659 0x890f5fe prepare_move_operands(rtx_def**, machine_mode) ../../ORIG/trunk/gcc/config/sh/sh.c:1832 0x896fb3d gen_movsi(rtx_def*, rtx_def*) ../../ORIG/trunk/gcc/config/sh/sh.md:6878 0x8367a60 insn_gen_fn::operator()(rtx_def*, rtx_def*) const ../../ORIG/trunk/gcc/recog.h:308 0x8367a60 emit_move_insn_1(rtx_def*, rtx_def*) ../../ORIG/trunk/gcc/expr.c:3521 0x8556a9c gen_move_insn(rtx_def*, rtx_def*) ../../ORIG/trunk/gcc/optabs.c:4874 0x85bc683 gen_reload ../../ORIG/trunk/gcc/reload1.c:8797
[Bug target/61550] [4.10 Regression] [SH] build failure with ICE in gen_reg_rtx, at emit-rtl.c:943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61550
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
sh.c:prepare_move_operands has the code for TLS addresses which
shouldn't be run when reload in progress in the first place.
I'm testing the patch below.
--- ORIG/trunk/gcc/config/sh/sh.c2014-06-17 21:21:32.043445314 +0900
+++ trunk/gcc/config/sh/sh.c2014-06-18 08:26:27.846157153 +0900
@@ -1758,7 +1758,8 @@ prepare_move_operands (rtx operands[], e
else
opc = NULL_RTX;
- if ((tls_kind = tls_symbolic_operand (op1, Pmode)) != TLS_MODEL_NONE)
+ if (! reload_in_progress ! reload_completed
+ (tls_kind = tls_symbolic_operand (op1, Pmode)) != TLS_MODEL_NONE)
{
rtx tga_op1, tga_ret, tmp, tmp2;
[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547 --- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) (In reply to Kostya Serebryany from comment #2) Note that in clang we chose not to instrument any builtins in compiler, but instead fully rely on interceptors. So you never expand such builtins inline? Not that I know of. LLVM has only 3 builtins like this (memset/memcpy/memmove): http://llvm.org/docs/LangRef.html#standard-c-library-intrinsics And asan replaces these builtins with asan's own call (e.g. __asan_memset)
[Bug tree-optimization/61518] [4.10 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61518 --- Comment #3 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Wed Jun 18 11:40:59 2014 New Revision: 211780 URL: https://gcc.gnu.org/viewcvs?rev=211780root=gccview=rev Log: PR tree-optimization/61518 gcc/ * tree-if-conv.c (is_cond_scalar_reduction): Add missed check that reduction var is used in reduction stmt or phi-function only. gcc/testsuite/ * gcc.dg/torture/pr61518.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61518.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug ipa/61540] internal compiler error in try_make_edge_direct_virtual_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61540 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- I've proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01430.html
[Bug c++/61539] [4.8/4.9/4.10 Regression] ICE: in unify_one_argument, at cp/pt.c:15465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61539 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||jason at redhat dot com --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r179436.
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- IIRC with libc++ tuple is not an empty type, so has more overhead than ours in other edge cases. Maybe you should recommend users stay away from that too.
[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 Bill Pringlemeir bpringlemeir at gmail dot com changed: What|Removed |Added CC||bpringlemeir at gmail dot com --- Comment #22 from Bill Pringlemeir bpringlemeir at gmail dot com --- The good ARM assembler uses the 'mla' instruction which is a 'multiply and accumulate'. Since this is not recognized, the multiply result needs a temporary register to do the add with and I think this cause the extra registers. I believe you should look to see why the 'mla' is not matched. I don't know if the x86 has an op-code like this.
[Bug target/61551] New: [NEON] alter costs to allow use of post-indexed addressing modes for VLD{2..4}/VST{2..4}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61551
Bug ID: 61551
Summary: [NEON] alter costs to allow use of post-indexed
addressing modes for VLD{2..4}/VST{2..4}
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cbaylis at gcc dot gnu.org
CC: ramana.radhakrishnan at arm dot com
Target: arm-unknown-linux-gnueabi
Created attachment 32967
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32967action=edit
test for NEON addressing modes
The attached test case demonstrates that GCC does not exploit the post-indexed
addressing mode for NEON structure loads and stores: VLDn, VSTn where n=2.
Generated code for VLD1/VST1 (using desired post-indexed addressing)
test_ld1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vld1.8 {d16}, [r0], r1
vst1.8 {d16}, [r0], r1
vld1.8 {d16}, [r0], r1
vst1.8 {d16}, [r0], r1
vld1.8 {d16}, [r0], r1
vst1.8 {d16}, [r0]
bx lr
Generated code for VLD2:
test_ld2:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
addsr3, r0, r1
vld2.8 {d16-d17}, [r0]
addsr0, r3, r1
addsr2, r0, r1
vst2.8 {d16-d17}, [r3]
addsr3, r2, r1
vld2.8 {d16-d17}, [r0]
add r1, r1, r3
vst2.8 {d16-d17}, [r2]
vld2.8 {d16-d17}, [r3]
vst2.8 {d16-d17}, [r1]
bx lr
A proof of concept patch is posted at:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01361.html
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #8 from Eelis gcc-bugzilla at contacts dot eelis.net ---
With Clang 3.5, given
struct X: std::tuple { char c; };
I get sizeof(X)==1. Is that not what you mean?
[Bug target/61545] Miscompilation in libcap-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61545 --- Comment #2 from Richard Henderson rth at gcc dot gnu.org --- Author: rth Date: Wed Jun 18 14:27:55 2014 New Revision: 211785 URL: https://gcc.gnu.org/viewcvs?rev=211785root=gccview=rev Log: PR target/61545 * config/aarch64/aarch64.md (tlsdesc_small_PTR): Clobber CC_REGNUM. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md
[Bug target/61545] Miscompilation in libcap-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61545 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org --- Author: rth Date: Wed Jun 18 14:37:04 2014 New Revision: 211786 URL: https://gcc.gnu.org/viewcvs?rev=211786root=gccview=rev Log: PR target/61545 * config/aarch64/aarch64.md (tlsdesc_small): Clobber CC_REGNUM. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/aarch64/aarch64.md
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org ---
Try:
struct X: std::tupleEmpty { double d; };
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 --- Comment #10 from Eelis gcc-bugzilla at contacts dot eelis.net --- I see what you mean! And while stuff with empty types and EBO is IMHO not nearly as serious as random superfluous bytes that are inserted when you use tuples of a bread and butter type like char, I agree it would be good to file a ticket in http://llvm.org/bugs/ if there isn't one already. :)
[Bug target/61545] Miscompilation in libcap-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61545 --- Comment #4 from Richard Henderson rth at gcc dot gnu.org --- Author: rth Date: Wed Jun 18 14:38:56 2014 New Revision: 211787 URL: https://gcc.gnu.org/viewcvs?rev=211787root=gccview=rev Log: PR target/61545 * config/aarch64/aarch64.md (tlsdesc_small): Clobber CC_REGNUM. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/aarch64/aarch64.md
[Bug target/58692] aarch64 arm_neon.h functions are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58692 Tejas Belagod belagod at gcc dot gnu.org changed: What|Removed |Added CC||belagod at gcc dot gnu.org --- Comment #1 from Tejas Belagod belagod at gcc dot gnu.org --- The ARM NEON intrinsics are documented in ACLE available here: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf and specifically the detailed list of NEON Intrinsics here: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073a/IHI0073A_arm_neon_intrinsics_ref.pdf
[Bug target/58692] aarch64 arm_neon.h functions are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58692 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-18 Ever confirmed|0 |1
[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #23 from Bill Pringlemeir bpringlemeir at gmail dot com --- (In reply to Bill Pringlemeir from comment #22) The good ARM assembler uses the 'mla' instruction which is a 'multiply and accumulate'. Since this is not recognized, the multiply result needs a temporary register to do the add with and I think this cause the extra registers. I believe you should look to see why the 'mla' is not matched. I don't know if the x86 has an op-code like this. Er, I see. The 'mla' comes as a result of seeing that the array index calculations can be reused. Sorry for the noise.
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Can you provide a stack trace to show which constructor/destructor it's hanging in?
[Bug c++/61537] [4.9/4.10 Regression] template parameter lists wrongly detected on struct or class keyword on parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61537
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-06-18
Summary|template parameter lists|[4.9/4.10 Regression]
|wrongly detected on |template parameter lists
|struct or class keyword |wrongly detected on
|on parameters |struct or class keyword
||on parameters
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
struct Dummy
{};
template typename T
class Base
{
public: template typename S
void do_sth(S param, struct Dummy dummy);
};
template typename T
template typename S
//void BaseT::do_sth(S param, Dummy)// working
void BaseT::do_sth(S param, struct Dummy) // not working
{
}
[Bug c/51840] asm goto enhancement request
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-18 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- So original issue is caused by two issues. For initial expand we produce the following rtl for the first code-switch: (jump_insn 32 31 34 2 (parallel [ (asm_operands/v (jmp *%0) () 0 [ (mem/v/f/j:DI (plus:DI (mult:DI (reg:DI 136) (const_int 8 [0x8])) (reg/f:DI 135)) [0 vm_dispatch S8 A64]) ] [ (asm_input:DI (m) t_asmgoto.c:65) ] [ (label_ref:DI 36) (label_ref:DI 56) (label_ref:DI 114) (label_ref:DI 120) ] t_asmgoto.c:65) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) (clobber (mem:BLK (scratch) [0 A8])) ]) t_asmgoto.c:65 -1 (insn_list:REG_LABEL_TARGET 36 (insn_list:REG_LABEL_TARGET 56 (insn_list:REG_LABEL_TARGET 114 (nil - 120) (note 34 32 33 4 [bb 4] NOTE_INSN_BASIC_BLOCK) (note/s 33 34 35 4 (atop__a_dec) NOTE_INSN_DELETED_LABEL 2) (barrier 35 33 36) (code_label 36 35 37 5 8 [3 uses]) ... Of interest is here the '(note/s 33 34 35 4 (atop__a_dec) NOTE_INSN_DELETED_LABEL 2)'. As long as code_label 36 (which is implementation of atop__a_dec code) follows directly that note, we are fine. That's true for -Os, -O0, and -O1. For -O2 we exectute additional the basic-block-reorder pass, and that moves label 36 away. Nevertheless the semi-deleted label-note remains and cause the wrong code-path.
[Bug java/61552] New: Unneeded check for libart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61552 Bug ID: 61552 Summary: Unneeded check for libart Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: Arfrever.FTA at GMail dot Com According to my grepping, libart was actually used only in GCC 3.4.* and 4.0.* (e.g. libart headers were included in GCC's libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkImagePainter.c). libjava/configure.ac in GCC trunk still contains: PKG_CHECK_MODULES(LIBART, libart-2.0 = 2.1) AC_SUBST(LIBART_CFLAGS) AC_SUBST(LIBART_LIBS) No Makefile.am file uses LIBART_CFLAGS or LIBART_LIBS. 4 generated Makefile.in files contain useless assignments of LIBART_CFLAGS and LIBART_LIBS. $ grep -E LIBART_(CFLAGS|LIBS) **/Makefile.am $ grep -E LIBART_(CFLAGS|LIBS) **/Makefile.in libjava/gcj/Makefile.in:LIBART_CFLAGS = @LIBART_CFLAGS@ libjava/gcj/Makefile.in:LIBART_LIBS = @LIBART_LIBS@ libjava/include/Makefile.in:LIBART_CFLAGS = @LIBART_CFLAGS@ libjava/include/Makefile.in:LIBART_LIBS = @LIBART_LIBS@ libjava/Makefile.in:LIBART_CFLAGS = @LIBART_CFLAGS@ libjava/Makefile.in:LIBART_LIBS = @LIBART_LIBS@ libjava/testsuite/Makefile.in:LIBART_CFLAGS = @LIBART_CFLAGS@ libjava/testsuite/Makefile.in:LIBART_LIBS = @LIBART_LIBS@ I suggest to delete check for libart in libjava/configure.ac and regenerate appropriate Makefile.in files.
[Bug c/61553] New: __atomic_store with non-pointer arg ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61553 Bug ID: 61553 Summary: __atomic_store with non-pointer arg ICE Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bstarynk at gcc dot gnu.org Created attachment 32968 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32968action=edit faulty source code (On Debian/Sid/AMD64) The attached file (with an incorrect __atomic_store) gives an ICE. badatomicstore.c: In function ‘clear_s1’: badatomicstore.c:9:6: internal compiler error: in tree_to_uhwi, at tree.h:3660 __atomic_store(s-i_name, NULL, __ATOMIC_SEQ_CST); ^ Please submit a full bug report, Of course, the instruction is incorrect; it should be __atomic_store_n(s-i_name, NULL, __ATOMIC_SEQ_CST);
[Bug c++/61554] New: ice in bb_seq_addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61554 Bug ID: 61554 Summary: ice in bb_seq_addr Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 32969 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32969action=edit gzipped C++ source code The attached source code, when compiled by trunk dated today, 20140618, does this when compiled with -O2 ../results/bin/gcc -c -O2 bug149.cc /home/dcb/rpmbuild/BUILD/stdair-1.00.1/stdair/bom/SegmentSnapshotTable.cpp: In member function ‘boost::multi_arrayT, NumDims, Allocator boost::multi_arrayT, NumDims, Allocator::resize(const boost::detail::multi_array::extent_genNumDims) [with T = double; long unsigned int NumDims = 2ul; Allocator = std::allocatordouble]’: /home/dcb/rpmbuild/BUILD/stdair-1.00.1/stdair/bom/SegmentSnapshotTable.cpp:469:1: internal compiler error: Segmentation fault } ^ 0xa9697f crash_signal ../../src/trunk/gcc/toplev.c:337 0x890bbc bb_seq_addr ../../src/trunk/gcc/gimple.h:1389 0x890bbc gsi_start_bb ../../src/trunk/gcc/gimple-iterator.h:118 0x890bbc gsi_for_stmt(gimple_statement_base*) ../../src/trunk/gcc/gimple-iterator.c:620 0xbc031c substitute_and_fold(tree_node* (*)(tree_node*), bool (*)(gimple_stmt_iterator*), bool) ../../src/trunk/gcc/tree-ssa-propagate.c:1225 0xb45aea ccp_finalize ../../src/trunk/gcc/tree-ssa-ccp.c:926 0xb45aea do_ssa_ccp ../../src/trunk/gcc/tree-ssa-ccp.c:2341 0xb45aea execute ../../src/trunk/gcc/tree-ssa-ccp.c:2374 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug inline-asm/29357] inline asm %c0 template form not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29357 Gerald Pfeifer gerald at pfeifer dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gerald at pfeifer dot com Resolution|--- |FIXED Known to fail||4.10.0 --- Comment #3 from Gerald Pfeifer gerald at pfeifer dot com --- Hi Avi, I am sorry nobody looked into this earlier. David indicated this actually is covered in https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#i386Operandmodifiers Can you please advise if there is anything you see missing or there are changes you'd still like to see?
[Bug inline-asm/37621] Missing documentation for x86 inline assembler modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37621 Gerald Pfeifer gerald at pfeifer dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gerald at pfeifer dot com Resolution|--- |FIXED --- Comment #4 from Gerald Pfeifer gerald at pfeifer dot com --- I checked, and https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#i386Operandmodifiers now covers this as part of the general documentation so I am closing this report as fixed. Please advise if I missed anything.
[Bug inline-asm/43319] Lack of documentation on asm extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43319 Gerald Pfeifer gerald at pfeifer dot com changed: What|Removed |Added CC||gerald at pfeifer dot com --- Comment #2 from Gerald Pfeifer gerald at pfeifer dot com --- Nan, https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#i386Operandmodifiers covers these in general now, though I did not see %P covered.
[Bug target/61423] Incorrect conversion from unsigned int to floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423 --- Comment #13 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jun 18 20:01:37 2014 New Revision: 211803 URL: https://gcc.gnu.org/viewcvs?rev=211803root=gccview=rev Log: Backport from mainline 2014-06-06 Uros Bizjak ubiz...@gmail.com PR target/61423 * config/i386/i386.md (*floatunssimode2_i387_with_xmm): New define_insn_and_split pattern, merged from *floatunssimode2_1 and corresponding splitters. Zero extend general register or memory input operand to XMM temporary. Enable for TARGET_SSE2 and TARGET_INTER_UNIT_MOVES_TO_VEC only. (floatunssimode2): Update expander predicate. testsuite/ChangeLog: Backport from mainline 2014-06-13 Ilya Enkovich ilya.enkov...@intel.com PR rtl-optimization/61094 PR rtl-optimization/61446 * gcc.target/i386/pr61446.c : New. Backport from mainline 2014-06-06 Uros Bizjak ubiz...@gmail.com PR target/61423 * gcc.target/i386/pr61423.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61423.c branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61446.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 --- Comment #20 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jun 18 20:01:37 2014 New Revision: 211803 URL: https://gcc.gnu.org/viewcvs?rev=211803root=gccview=rev Log: Backport from mainline 2014-06-06 Uros Bizjak ubiz...@gmail.com PR target/61423 * config/i386/i386.md (*floatunssimode2_i387_with_xmm): New define_insn_and_split pattern, merged from *floatunssimode2_1 and corresponding splitters. Zero extend general register or memory input operand to XMM temporary. Enable for TARGET_SSE2 and TARGET_INTER_UNIT_MOVES_TO_VEC only. (floatunssimode2): Update expander predicate. testsuite/ChangeLog: Backport from mainline 2014-06-13 Ilya Enkovich ilya.enkov...@intel.com PR rtl-optimization/61094 PR rtl-optimization/61446 * gcc.target/i386/pr61446.c : New. Backport from mainline 2014-06-06 Uros Bizjak ubiz...@gmail.com PR target/61423 * gcc.target/i386/pr61423.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61423.c branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61446.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446 --- Comment #10 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jun 18 20:01:37 2014 New Revision: 211803 URL: https://gcc.gnu.org/viewcvs?rev=211803root=gccview=rev Log: Backport from mainline 2014-06-06 Uros Bizjak ubiz...@gmail.com PR target/61423 * config/i386/i386.md (*floatunssimode2_i387_with_xmm): New define_insn_and_split pattern, merged from *floatunssimode2_1 and corresponding splitters. Zero extend general register or memory input operand to XMM temporary. Enable for TARGET_SSE2 and TARGET_INTER_UNIT_MOVES_TO_VEC only. (floatunssimode2): Update expander predicate. testsuite/ChangeLog: Backport from mainline 2014-06-13 Ilya Enkovich ilya.enkov...@intel.com PR rtl-optimization/61094 PR rtl-optimization/61446 * gcc.target/i386/pr61446.c : New. Backport from mainline 2014-06-06 Uros Bizjak ubiz...@gmail.com PR target/61423 * gcc.target/i386/pr61423.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61423.c branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61446.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/61423] Incorrect conversion from unsigned int to floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.4 --- Comment #14 from Uroš Bizjak ubizjak at gmail dot com --- Fixed in all release branches.
[Bug ipa/61555] New: [4.9/4.10 Regression] LLVM build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555
Bug ID: 61555
Summary: [4.9/4.10 Regression] LLVM build failure
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
LLVM trunk fails to build with 4.9 and 4.10:
[1299/1853] Linking CXX executable bin/bugpoint
FAILED: : /usr/bin/g++ -fPIC -fvisibility-inlines-hidden -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wno-maybe-uninitialized -Wnon-virtual-dtor -Wno-comment
-std=c++11 -ffunction-sections -fdata-sections -O2 -DNDEBUG -pipe
-march=native
-Wl,-O1,--hash-style=gnu,--gc-sections,--icf=all,--icf-iterations=3
-Wl,--export-dynamic tools/bugpoint/CMakeFiles/bugpoint.dir/BugDriver.cpp.o
tools/bugpoint/CMakeFiles/bugpoint.dir/CrashDebugger.cpp.o
tools/bugpoint/CMakeFiles/bugpoint.dir/ExecutionDriver.cpp.o
tools/bugpoint/CMakeFiles/bugpoint.dir/ExtractFunction.cpp.o
tools/bugpoint/CMakeFiles/bugpoint.dir/FindBugs.cpp.o
tools/bugpoint/CMakeFiles/bugpoint.dir/Miscompilation.cpp.o
tools/bugpoint/CMakeFiles/bugpoint.dir/OptimizerDriver.cpp.o
tools/bugpoint/CMakeFiles/bugpoint.dir/ToolRunner.cpp.o
tools/bugpoint/CMakeFiles/bugpoint.dir/bugpoint.cpp.o -o bin/bugpoint
lib/libLLVMAnalysis.so lib/libLLVMBitWriter.so lib/libLLVMCodeGen.so
lib/libLLVMCore.so lib/libLLVMipa.so lib/libLLVMipo.so lib/libLLVMIRReader.so
lib/libLLVMInstCombine.so lib/libLLVMInstrumentation.so lib/libLLVMLinker.so
lib/libLLVMObjCARCOpts.so lib/libLLVMScalarOpts.so lib/libLLVMSupport.so
lib/libLLVMTarget.so lib/libLLVMTransformUtils.so lib/libLLVMVectorize.so
lib/libLLVMInstCombine.so lib/libLLVMAsmParser.so lib/libLLVMTransformUtils.so
lib/libLLVMipa.so lib/libLLVMAnalysis.so lib/libLLVMTarget.so lib/libLLVMMC.so
lib/libLLVMObject.so lib/libLLVMBitReader.so lib/libLLVMCore.so
lib/libLLVMSupport.so -lrt -ldl -lcurses -lpthread -lz
-Wl,-rpath,\$ORIGIN/../lib :
tools/bugpoint/CMakeFiles/bugpoint.dir/bugpoint.cpp.o:bugpoint.cpp:function
llvm::cl::listllvm::PassInfo const*, bool,
llvm::PassNameParser::getExtraOptionNames(llvm::SmallVectorImplchar
const*): error: undefined reference to 'llvm::cl::parserllvm::PassInfo
const*::getOption(unsigned int) const'
collect2: error: ld returned 1 exit status
[1299/1853] Building CXX object
tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/Targets.cpp.o
ninja: build stopped: subcommand failed.
Reduced:
markus@x4 llvm_build % cat bugpoint.ii
namespace llvm
{
namespace cl
{
enum NumOccurrencesFlag
{
ZeroOrMore
};
enum OptionHidden
{
NotHidden
};
class A
{
protected:
A (NumOccurrencesFlag, OptionHidden);
virtual void getExtraOptionNames (int );
};
class B
{
public:
virtual char *getOption (unsigned) const;
void getExtraOptionNames (int) { getOption (0); }
};
template class class parser : public B
{
char *getOption (unsigned) const;
};
template class ParserClass = parserint class C : A
{
ParserClass Parser;
void getExtraOptionNames (int p1) { Parser.getExtraOptionNames (0); }
public:
template class M0t, class M1t C (M0t, M1t) : A (ZeroOrMore, NotHidden) {}
};
}
class PassInfo;
class D : public cl::parserconst PassInfo *
{
public:
D ();
};
}
using namespace llvm;
cl::CD a (0, cl::ZeroOrMore);
markus@x4 llvm_build % g++ -c -O2 -std=c++11 bugpoint.ii
markus@x4 llvm_build % nm bugpoint.o | grep
_ZNK4llvm2cl6parserIPKNS_8PassInfoEE9getOptionEj
U _ZNK4llvm2cl6parserIPKNS_8PassInfoEE9getOptionEj
(4.8.3 is fine)
markus@x4 llvm_build % /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3/g++ -c -O2
-std=c++11 bugpoint.ii
markus@x4 llvm_build % nm bugpoint.o | grep
_ZNK4llvm2cl6parserIPKNS_8PassInfoEE9getOptionEj
markus@x4 llvm_build %
[Bug tree-optimization/61554] [4.10 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61554 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.8.3, 4.9.0 Version|4.9.0 |4.10.0 Last reconfirmed||2014-06-18 Component|c++ |tree-optimization CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 Summary|ice in bb_seq_addr |[4.10 Regression] ICE: ||Segmentation fault Target Milestone|--- |4.10.0 Known to fail||4.10.0 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Confirmed. Program received signal SIGSEGV, Segmentation fault. [Switching to process 20379] gsi_for_stmt (stmt=stmt@entry=0x75a91910) at ../../gcc/gcc/gimple-iterator.c:620 620 i = gsi_start_bb (bb); (gdb) bt #0 gsi_for_stmt (stmt=stmt@entry=0x75a91910) at ../../gcc/gcc/gimple-iterator.c:620 #1 0x00ce55c0 in substitute_and_fold (get_value_fn=get_value_fn@entry=0xc59eb0 get_constant_value(tree), fold_fn=fold_fn@entry=0xc61d60 ccp_fold_stmt(gimple_stmt_iterator*), do_dce=do_dce@entry=true) at ../../gcc/gcc/tree-ssa-propagate.c:1227 #2 0x00c5bd44 in ccp_finalize () at ../../gcc/gcc/tree-ssa-ccp.c:926 #3 do_ssa_ccp () at ../../gcc/gcc/tree-ssa-ccp.c:2341 #4 (anonymous namespace)::pass_ccp::execute (this=optimized out) at ../../gcc/gcc/tree-ssa-ccp.c:2374 #5 0x00ad0be2 in execute_one_pass (pass=pass@entry=0x1831ad0) at ../../gcc/gcc/passes.c:2179 #6 0x00ad0ed6 in execute_pass_list_1 (pass=0x1831ad0) at ../../gcc/gcc/passes.c:2232 #7 0x00ad0ee8 in execute_pass_list_1 (pass=0x18319b0, pass@entry=0x18316b0) at ../../gcc/gcc/passes.c:2233 #8 0x00ad0f29 in execute_pass_list (fn=0x712a87e0, pass=0x18316b0) at ../../gcc/gcc/passes.c:2243 #9 0x00acf725 in do_per_function_toporder (callback=callback@entry=0xad0f10 execute_pass_list(function*, opt_pass*), data=0x18316b0) at ../../gcc/gcc/passes.c:1547 #10 0x00ad14d7 in execute_ipa_pass_list (pass=0x1831650) at ../../gcc/gcc/passes.c:2577 #11 0x0084ce47 in ipa_passes () at ../../gcc/gcc/cgraphunit.c:2056 #12 compile () at ../../gcc/gcc/cgraphunit.c:2187 #13 0x0084d8e5 in finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:2342 #14 0x0063b2af in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:4647 #15 0x00b85c2d in compile_file () at ../../gcc/gcc/toplev.c:562 #16 0x00b87c75 in do_compile () at ../../gcc/gcc/toplev.c:1918 #17 toplev_main (argc=16, argv=0x7fffde58) at ../../gcc/gcc/toplev.c:1994 #18 0x775fbfb0 in __libc_start_main () from /lib/libc.so.6 #19 0x0054b841 in _start ()
[Bug ipa/61555] [4.9/4.10 Regression] LLVM build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Are you sure this is not a LLVM source issue? llvm::cl::parserllvm::PassInfo const*::getOption(unsigned int) const is called by llvm::cl::Cllvm::D::getExtraOptionNames(int). llvm::cl::Cllvm::D::getExtraOptionNames(int) is part of vtable for llvm::cl::Cllvm::D. I don't see anything wrong here really as the type of Parser can found at compile time and it is D inherits from cl::parserconst PassInfo *. So getExtraOptionNames calls Parser.getExtraOptionNames which in turns calls this-getOption (0) which is a virtual function call. Since we know the type of *this here, we call directly llvm::cl::parserllvm::PassInfo const*::getOption(unsigned int) const. So the devirtuatization seems correct and it is just a LLVM source problem.
[Bug ipa/61555] [4.9/4.10 Regression] LLVM build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) Are you sure this is not a LLVM source issue? llvm::cl::parserllvm::PassInfo const*::getOption(unsigned int) const is called by llvm::cl::Cllvm::D::getExtraOptionNames(int). llvm::cl::Cllvm::D::getExtraOptionNames(int) is part of vtable for llvm::cl::Cllvm::D. I don't see anything wrong here really as the type of Parser can found at compile time and it is D inherits from cl::parserconst PassInfo *. So getExtraOptionNames calls Parser.getExtraOptionNames which in turns calls this-getOption (0) which is a virtual function call. Since we know the type of *this here, we call directly llvm::cl::parserllvm::PassInfo const*::getOption(unsigned int) const. So the devirtuatization seems correct and it is just a LLVM source problem. Thanks. I just wasn't 100% sure. LLVM bug: http://llvm.org/bugs/show_bug.cgi?id=20067
[Bug tree-optimization/61554] [4.10 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61554
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat bug.ii
struct A
{
A ();
};
const unsigned long min (const unsigned long , const unsigned long ) {}
template typename _InputIterator1, typename _InputIterator2,
typename _OutputIterator, typename _BinaryOperation
void transform (_InputIterator1 p1, _InputIterator2, _OutputIterator,
_BinaryOperation p4)
{
for (; p1;)
p4 (0, 0);
}
class multi_array
{
public:
multi_array (int , int );
int resize_ranges;
int resize___trans_tmp_1;
void m_fn1 ()
{
multi_array a (resize_ranges, this-m_fn2 ());
const unsigned long (*b)(const unsigned long , const unsigned long )
= min;
transform (resize___trans_tmp_1, 0, 0, b);
A c;
}
~multi_array ()
{
for (int i; base_;)
;
}
int base_;
int m_fn2 ();
};
class B
{
void m_fn3 (const int , const int );
multi_array _bookingSnapshotBlock;
};
void B::m_fn3 (const int , const int ) { _bookingSnapshotBlock.m_fn1 (); }
[Bug c++/59296] [c++11] ref-qualified member function is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59296 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org, ||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #3 from Joshua Kinard kumba at gentoo dot org ---
(In reply to Jonathan Wakely from comment #2)
Can you provide a stack trace to show which constructor/destructor it's
hanging in?
Hopefully you mean a backtrace from gdb. Not finding a lot of info on doing a
C++ stacktrace (I haven't messed with C++ in years).
The testcase isn't stripped and has debugging info, but glibc-2.19, and
gcc-4.8.2 are stripped and built w/o debugging, so the backtrace doesn't
provide a lot of info. I might be able to rebuild them w/ debugging, but gcc
takes almost 13+ hours on the Octane to build, while glibc takes another 3-4.
First, here is what strace shows:
set_tid_address(0x7797f2e8) = 2532
set_robust_list(0x7797f2f0, 12) = 0
futex(0x7fb06690, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fb06690, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 0) =
-1 EINVAL (Invalid argument)
rt_sigaction(SIGRT_0, {0x8, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_NOCLDWAIT|0x7921a94}, NULL, 16) = 0
rt_sigaction(SIGRT_1, {0x1008, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|SA_NOCLDWAIT|0x7921940}, NULL,
16) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 16) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=2147483647}) = 0
syscall(0x108e, 0x77929500, 0, 0, 0, 0, 0x77929160) = -1 EAGAIN (Resource
temporarily unavailable)
syscall(0x108e, 0x77929500, 0, 0x10100, 0, 0, 0x77929160
That last line is where you see it hanging until I send ctrl+c, with the first
argument to both being 0x108e (4238 in decimal, I typoed it as '4328' in my
original post), which is a futex call, per mips-o32-linux.xml in GDB:
syscall name=futex number=4238/
Running in GDB, setting a catchpoint on syscall 4238 and upping the
heuristic-fence-post limit a fair bit to quiet some warnings down:
This first catchpoint doesn't hang:
¦0x77f9dc1c __pthread_initialize_minimal_internal+148 addiu a0,s8,32
¦0x77f9dc20 __pthread_initialize_minimal_internal+152 li a1,129
¦0x77f9dc24 __pthread_initialize_minimal_internal+156 li a2,1
¦0x77f9dc28 __pthread_initialize_minimal_internal+160 li v0,4238
¦0x77f9dc2c __pthread_initialize_minimal_internal+164 syscall
¦0x77f9dc30 __pthread_initialize_minimal_internal+168 bnez a3,0x77f9df9c
__pthread_initialize_minimal_internal+1044
Catchpoint 1 (call to syscall 4238), 0x77f9dc30 in
__pthread_initialize_minimal_internal () from /lib/libpthread.so.0
(gdb) thread apply all bt
Thread 1 (process 2584):
#0 0x77f9dc30 in __pthread_initialize_minimal_internal () from
/lib/libpthread.so.0
#1 0x77f9c5a4 in _init () from /lib/libpthread.so.0
Cannot access memory at address 0x77fc3ffe
Here's the second catchpoint for syscall #4238:
¦0x77f9dc64 __pthread_initialize_minimal_internal+220 addiu sp,sp,-32
¦0x77f9dc68 __pthread_initialize_minimal_internal+224 sw v0,16(sp)
¦0x77f9dc6c __pthread_initialize_minimal_internal+228 li v0,4238
¦0x77f9dc70 __pthread_initialize_minimal_internal+232 syscall
¦0x77f9dc74 __pthread_initialize_minimal_internal+236 addiu sp,sp,32
Catchpoint 1 (call to syscall 4238), 0x77f9dc74 in
__pthread_initialize_minimal_internal () from /lib/libpthread.so.0
(gdb) thread apply all bt
Thread 1 (process 2584):
#0 0x77f9dc74 in __pthread_initialize_minimal_internal () from
/lib/libpthread.so.0
#1 0x77f9c5a4 in _init () from /lib/libpthread.so.0
Cannot access memory at address 0x77fc3ffe
After I type continue again, it hangs until interrupted:
(gdb) c
Continuing.
HANGS HERE
Program received signal SIGINT, Interrupt.
0x77d50864 in syscall () from /lib/libc.so.6
(gdb) thread apply all bt
Thread 1 (Thread 0x77feb000 (LWP 2591)):
#0 0x77d50864 in syscall () from /lib/libc.so.6
#1 0x77ed9160 in __cxa_guard_acquire () from
/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6
#2 0x77f4325c in std::future_category() () from
/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6
#3 0x77ed406c in ?? () from
/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6
Cannot access memory at address 0x77fc3ffe
(gdb)
[Bug target/61550] [4.10 Regression] [SH] build failure with ICE in gen_reg_rtx, at emit-rtl.c:943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61550 --- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Wed Jun 18 22:11:55 2014 New Revision: 211807 URL: https://gcc.gnu.org/viewcvs?rev=211807root=gccview=rev Log: PR target/61550 * config/sh/sh.c (prepare_move_operands): Don't process TLS addresses here if reload in progress or completed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug c++/61507] GCC does not compile function with parameter pack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61507 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jun 18 22:13:40 2014 New Revision: 211808 URL: https://gcc.gnu.org/viewcvs?rev=211808root=gccview=rev Log: PR c++/61507 * pt.c (resolve_overloaded_unification): Preserve ARGUMENT_PACK_EXPLICIT_ARGS. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic159.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/59296] [c++11] ref-qualified member function is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59296 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jun 18 22:13:51 2014 New Revision: 211809 URL: https://gcc.gnu.org/viewcvs?rev=211809root=gccview=rev Log: PR c++/59296 * call.c (add_function_candidate): Set LOOKUP_NO_RVAL_BIND for ref-qualifier handling. Added: trunk/gcc/testsuite/g++.dg/cpp0x/ref-qual15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/61556] New: [c++11][regression] ‘*(const ValueType*)this’ is not a constant expression with valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61556
Bug ID: 61556
Summary: [c++11][regression] ‘*(const ValueType*)this’ is not a
constant expression with valid code
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: l.jirkovsky at gmail dot com
When used in a certain way, a template class cannot be instantiated in another
template class using a static constexpr. I tracked the regression down to the
following commit:
commit 18619da58c77461642c36cee9f0463c968877f75
Author: jason jason@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Mon Apr 1 19:05:12 2013 +
* call.c (add_function_candidate): Take the address of 'this' here.
(build_over_call): And here.
(build_new_method_call_1, build_op_call_1): Not here.
(build_user_type_conversion_1): Or here.
(add_candidates): Adjust.
Reverting this commit fixes the problem on the current gcc.
The problematic code that should be compilable is attached after the CODE
section.
When compiled with gcc 4.9.0, the
ValueTypeInfoValueTypeEnum::doubleval v; in the FillFunctor
constructor gives an error:
bug2.cpp: In constructor ‘FillFunctorFormat::FillFunctor()’:
bug2.cpp:24:41: in constexpr expansion of ‘const
ValueType{1}-ValueType::operator int()’
bug2.cpp:24:41: error: ‘*(const ValueType*)this’ is not a constant
expression
ValueTypeInfoValueTypeEnum::doubleval v;
^
bug2.cpp:24:41: note: in template argument for type ‘int’
bug2.cpp:24:44: error: invalid type in declaration before ‘;’ token
ValueTypeInfoValueTypeEnum::doubleval v;
However, the same expression compiles just fine if its used in a
function, such as main(). Removing m_ID makes the code compile, too.
Also, the compilation works after replacing:
ValueTypeInfoValueTypeEnum::doubleval v;
with a:
constexpr ValueType doubleval = ValueType(1);
ValueTypeInfodoubleval v;
CODE
#
class ValueType {
public:
constexpr operator int() const {return m_ID;};
constexpr ValueType(const int v)
: m_ID(v) {}
private:
int m_ID;
};
class ValueTypeEnum {
public:
static constexpr ValueType doubleval = ValueType(1);
};
template int format
class ValueTypeInfo {
};
template typename Format
class FillFunctor {
public:
FillFunctor() {
ValueTypeInfoValueTypeEnum::doubleval v;
}
};
int main() {
ValueTypeInfoValueTypeEnum::doubleval v;
}
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #4 from Joshua Kinard kumba at gentoo dot org --- It looks like the bug might be somewhere in __cxa_guard_acquire() in libstdc++-v3/lubsupc++/guard.cc, as that references glibc and futexes. strace indicates that the same syscall was invoked twice in a row -- could this be a double-locking bug? This is what I traced out in gdb: ¦0x77ed91cc __cxa_guard_acquire+336sw zero,32(sp) B+¦0x77ed91d0 __cxa_guard_acquire+340b 0x77ed9144 __cxa_guard_acquire+200 | |-¦0x77ed9144 __cxa_guard_acquire+200lw t9,-28620(gp) ¦0x77ed9148 __cxa_guard_acquire+204li a0,4238 ¦0x77ed914c __cxa_guard_acquire+208move a1,s0 ¦0x77ed9150 __cxa_guard_acquire+212move a2,zero ¦0x77ed9154 __cxa_guard_acquire+216lw a3,32(sp) ¦0x77ed9158 __cxa_guard_acquire+220jalr t9 | |-¦0x77d50850 syscallluigp,0x9 ¦0x77d50854 syscall+4 addiu gp,gp,-2624 ¦0x77d50858 syscall+8 addu gp,gp,t9 ¦0x77d5085c syscall+12 li v0,4000 ¦0x77d50860 syscall+16 syscall HANGS HERE ¦0x77d50864 syscall+20 bnez a3,0x77d50840 ¦0x77d50868 syscall+24 nop ¦0x77d5086c syscall+28 jr ra ¦0x77d50870 syscall+32 nop ¦0x77d50874 syscall+36 nop ¦0x77d50878 nop ¦0x77d5087c nop I can see the first futex syscall (li a0,4238), and I think it looks like inside that syscall, it's doing some loads and adds, then makes a generic syscall (#4000), probably passing the computed 0x108e value as the first argument, which would translate into another futex syscall, which jives with what strace says. Is taking a futex inside of a futex a good thing? It's obvious that something with the R1x000 CPU is coming into play as well, but I don't know what exactly.
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839#c12
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org ---
This is the patch which I used for glibc to fix some libstdc++ issues:
From 2788414e4e6a548766aa7e732fc096f9f572302e Mon Sep 17 00:00:00 2001
From: Andrew Pinski apin...@cavium.com
Date: Thu, 1 Nov 2012 23:07:22 -0700
Subject: [PATCH] 2012-11-01 Andrew Pinski apin...@cavium.com
Bug #5086
* ports/sysdeps/unix/sysv/linux/mips/nptl/pthread_once.c
(__pthread_once):
Add release barrier before setting once_control to say
initialisation is done.
(clear_once_control): Add release barrier.
---
ChangeLog.CAVIUM |8
.../unix/sysv/linux/mips/nptl/pthread_once.c |2 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/ChangeLog.CAVIUM b/ChangeLog.CAVIUM
index 8ed42ea..5975430 100644
--- a/ChangeLog.CAVIUM
+++ b/ChangeLog.CAVIUM
@@ -1,3 +1,11 @@
+2012-11-01 Andrew Pinski apin...@cavium.com
+
+Bug #5086
+* ports/sysdeps/unix/sysv/linux/mips/nptl/pthread_once.c (__pthread_once):
+Add release barrier before setting once_control to say
+initialisation is done.
+(clear_once_control): Add release barrier.
+
2012-10-28 Andrew Pinski apin...@cavium.com
Bug #5059
diff --git a/ports/sysdeps/unix/sysv/linux/mips/nptl/pthread_once.c
b/ports/sysdeps/unix/sysv/linux/mips/nptl/pthread_once.c
index 308da8b..c2ef264 100644
--- a/ports/sysdeps/unix/sysv/linux/mips/nptl/pthread_once.c
+++ b/ports/sysdeps/unix/sysv/linux/mips/nptl/pthread_once.c
@@ -28,6 +28,7 @@ clear_once_control (void *arg)
{
pthread_once_t *once_control = (pthread_once_t *) arg;
+ atomic_full_barrier ();
*once_control = 0;
lll_futex_wake (once_control, INT_MAX, LLL_PRIVATE);
}
@@ -80,6 +81,7 @@ __pthread_once (once_control, init_routine)
/* Add one to *once_control. */
+ atomic_full_barrier ();
atomic_increment (once_control);
/* Wake up all other threads. */
--
1.7.4.1
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #7 from Joshua Kinard kumba at gentoo dot org --- (In reply to Andrew Pinski from comment #6) This is the patch which I used for glibc to fix some libstdc++ issues: Okay, so it's in glibc. Is your patch in glibc yet? It applies cleanly to 2.19, but carries a 2012 date stamp. I'll rebuild and see if this solves the bug. Thanks!
[Bug lto/61557] New: [4.9 Regression] LTO ICE: verify_flow_info failed (error: control flow in the middle of basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61557 Bug ID: 61557 Summary: [4.9 Regression] LTO ICE: verify_flow_info failed (error: control flow in the middle of basic block) Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com Target: i686-pc-linux-gnu Created attachment 32970 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32970action=edit $ gcc -flto main.c foo.c foo.c: In function 'foo': foo.c:4:6: error: control flow in the middle of basic block 2 void foo(void) ^ foo.c:4:6: internal compiler error: verify_flow_info failed 0x88f5d24 verify_flow_info() ../../gcc-4.10/gcc/cfghooks.c:260 0x81efebb execute_function_todo ../../gcc-4.10/gcc/passes.c:1789 0x81f10bc do_per_function ../../gcc-4.10/gcc/passes.c:1504 0x81f10bc execute_todo ../../gcc-4.10/gcc/passes.c:1834 Please submit a full bug report, with preprocessed source if appropriate. Happens with GCC 4.10.0 20140615, GCC 4.9.1 20140521 (when configured with extra diagnostic checks). Appeared in rev. (197291, 199345].
[Bug target/60481] `g++ -Q --help=c++' falsely reports -fms-extensions as [disabled] when in fact it is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60481 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Known to work|4.8.3 |4.8.4 Resolution|WONTFIX |--- Summary|[4.9 Regression] Missing|`g++ -Q --help=c++' falsely |diagnostic ISO C++ forbids |reports -fms-extensions as |declaration of 'foo' with |[disabled] when in fact it |no type|is enabled Known to fail||4.10.0 --- Comment #4 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- The bug is still here in GCC vers. 4.9.1 and 4.10.0. Changing the summary to reflect the actual problem.
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #8 from Joshua Kinard kumba at gentoo dot org --- (In reply to Joshua Kinard from comment #7) (In reply to Andrew Pinski from comment #6) This is the patch which I used for glibc to fix some libstdc++ issues: Okay, so it's in glibc. Is your patch in glibc yet? It applies cleanly to 2.19, but carries a 2012 date stamp. I'll rebuild and see if this solves the bug. Thanks! Still hangs on the second syscall. I can trace the asm and see where it's taking a different route due to those atomic_full_barrier() calls, but I'll have to rebuild gcc next just to be completely sure.
[Bug target/48127] Program crashes reading a non-aligned variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48127 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.4 Resolution|--- |FIXED --- Comment #5 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- GCC 4.8.4 (and recent 4.9, 4.10) do not generate SSE instructions for this testcase.
[Bug rtl-optimization/48128] Excessive code generated for vectorized loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48128 --- Comment #4 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- (In reply to comment #2) When marking baz as static an compiling with -mno-sse, the result is even more strange... Still true for GCC 4.9.1 and 4.10.0.
