[Bug c++/67270] internal compiler error: in unify, at cp/pt.c:18178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67270 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- It is not a regression for 4.9.3, because it ICEed before.
[Bug c++/67274] Inconsistent `this-` required when calling member function in a lambda capturing `this` through another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67274
--- Comment #1 from Vittorio Romeo vittorio.romeo at outlook dot com ---
More test cases, using minor variations to the code posted above:
With bar() = call([this](auto x){ foo(x); });
clang++ 3.6+ compiles.
g++ 5.2+ does not compile.
With bar() = call([this](auto x){ this-foo(x); });
clang++ 3.6+ compiles.
g++ 5.2+ compiles.
With bar() = call([this](int x){ foo(x); });
clang++ 3.6+ compiles.
g++ 5.2+ compiles.
With bar() = [this](auto x){ foo(x); }(1);
clang++ 3.6+ compiles.
g++ 5.2+ compiles.
[Bug c++/67274] New: Inconsistent `this-` required when calling member function in a lambda capturing `this` through another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67274
Bug ID: 67274
Summary: Inconsistent `this-` required when calling member
function in a lambda capturing `this` through another
function
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Passing a `this`-capturing generic lambda (to a template function) that calls a
member function of `this` without an explicit `this-` results in an error:
error: cannot call member function 'void Example::foo(int)' without object
call([this](auto x){ foo(x); });`
If the lambda is not generic, or if the lambda is not passed to any other
function but called in place, it compiles without an explicit `this-`.
For reference, clang 3.6+ is cool with the code in all situations.
---
Minimal example:
http://melpon.org/wandbox/permlink/M2eH3FUOentPfieM
templatetypename TF
void call(TF f)
{
f(1);
}
struct Example
{
void foo(int){ }
void bar()
{
call([this](auto x){ foo(x); });
}
};
int main()
{
Example{}.bar();
return 0;
}
---
StackOverflow question with more examples:
http://stackoverflow.com/questions/32097759
[Bug c++/67273] New: Incorrect -Wshadow warning with generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67273
Bug ID: 67273
Summary: Incorrect -Wshadow warning with generic lambdas
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
The `-Wshadow` flag fires an incorrect warning using generic lambdas with
`auto` type deduction.
Minimal example:
http://melpon.org/wandbox/permlink/ynGNXTYN8rY40BgY
---
Code (copy-pasted from example):
// `auto i` - incorrect warning
auto autol0()
{
return [](auto i){ std::cout i; };
}
auto autol1()
{
return [](auto i){ autol0()(i); };
}
// `int i` - no warnings
auto intl0()
{
return [](int i){ std::cout i; };
}
auto intl1()
{
return [](int i){ intl0()(i); };
}
---
Warning (copy-pasted from example):
prog.cc:5:21: warning: declaration of 'int i' shadows a parameter [-Wshadow]
return [](auto i){ std::cout i; };
^
prog.cc:10:20: note: shadowed declaration is here
return [](auto i){ autol0()(i); };
^
[Bug other/67042] gcc/hwint.h:250:19: runtime error: left shift of 8589934588 by 32 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67042 --- Comment #1 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Wed Aug 19 13:42:36 2015 New Revision: 227008 URL: https://gcc.gnu.org/viewcvs?rev=227008root=gccview=rev Log: Avoid signed left shift undefined behaviour in sext_hwi gcc/ PR other/67042 * hwint.h (sext_hwi): Switch to unsigned for the left shift, and conditionalize the whole on __GNUC__. Add fallback code depending neither on undefined nor implementation-defined behaviour. Modified: trunk/gcc/ChangeLog trunk/gcc/hwint.h
[Bug tree-optimization/63602] [5/6 Regression] Wrong code w/ -O2 -ftree-loop-linear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63602 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- BTW: same results for gcc-5.1.0 with isl-0.12.2: gcc -floop-block -O2 pr63602.c gcc -floop-interchange -O2 pr63602.c gcc -floop-parallelize-all -O2 pr63602.c gcc -floop-strip-mine -O2 pr63602.c even worse: gcc -floop-unroll-and-jam -O2 pr63602.c ../../gcc-5.1.0/isl/isl_ctx.c:172: isl_ctx freed, but some objects still reference it pr63602.c: In function 'main': pr63602.c:7:1: internal compiler error: Aborted main(void) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jeff Hammond from comment #13) This is all fair. I try very hard to fix my own bugs and submit patches, but in this case I am wholly unqualified. I don't know the first thing about implementing a production compiler, or any compiler for that matter. To work on GCC, you mostly need to know C/C++, how to use GDB and be able to setup the bootstrap and regression test environment. Most tasks are not hard or require any special knowledge, just tedious (run the testsuite, follow-up on patches, trace code through the debugger and figure out why it is not working as it should). In fact, GCC is not lacking patches, there are many unapplied patches in bugzilla and the mailing lists. It lacks people motivated enough to do all the red-tape work necessary to get a patch applied to the repository.
[Bug other/67042] gcc/hwint.h:250:19: runtime error: left shift of 8589934588 by 32 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67042 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- fixed.
[Bug target/65491] [aarch64] ICE: in emit_move_insn, at expr.c:3609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65491 Andrey Tarasevich tarasevich at cs dot uni-saarland.de changed: What|Removed |Added CC||tarasevich at cs dot uni-saarland. ||de --- Comment #5 from Andrey Tarasevich tarasevich at cs dot uni-saarland.de --- Test pr65491.c fails on on darwin14.5 x86_64 GCC was compiled from SVN trunk revision 226781 gcc -v -save-temps /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c Using built-in specs. COLLECT_GCC=/Users/sevich/work/build_normal/bin/gcc COLLECT_LTO_WRAPPER=/Users/sevich/work/build_normal/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/lto-wrapper Target: x86_64-apple-darwin14.5.0 Configured with: /Users/sevich/work/source/gcc_trunk_git/configure --disable-bootstrap --enable-languages=c,c++ --prefix=/Users/sevich/work/build_normal/ Thread model: posix gcc version 6.0.0 20150811 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.5' '-v' '-save-temps' '-mtune=core2' /Users/sevich/work/build_normal/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/cc1 -E -quiet -v -D__DYNAMIC__ /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c -fPIC -mmacosx-version-min=10.10.5 -mtune=core2 -fpch-preprocess -o pr65491_1.i ignoring nonexistent directory /Users/sevich/work/build_normal/lib/gcc/x86_64-apple-darwin14.5.0/6.0.0/../../../../x86_64-apple-darwin14.5.0/include #include ... search starts here: #include ... search starts here: /Users/sevich/work/build_normal/lib/gcc/x86_64-apple-darwin14.5.0/6.0.0/include /usr/local/include /Users/sevich/work/build_normal/include /Users/sevich/work/build_normal/lib/gcc/x86_64-apple-darwin14.5.0/6.0.0/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.5' '-v' '-save-temps' '-mtune=core2' /Users/sevich/work/build_normal/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/cc1 -fpreprocessed pr65491_1.i -fPIC -quiet -dumpbase pr65491_1.c -mmacosx-version-min=10.10.5 -mtune=core2 -auxbase pr65491_1 -version -o pr65491_1.s GNU C11 (GCC) version 6.0.0 20150811 (experimental) (x86_64-apple-darwin14.5.0) compiled by GNU C version 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C11 (GCC) version 6.0.0 20150811 (experimental) (x86_64-apple-darwin14.5.0) compiled by GNU C version 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 700dea0ce5ef3b798edb9c9160a43b26 /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c: In function ‘sum’: /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:7:1: error: mode precision of non-integral result does not match field size of BIT_FIELD_REF sum (a first, a second) ^ BIT_FIELD_REF first_1(D), 128, 0 /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:9:16: note: in statement return first + second; ^ _6 = BIT_FIELD_REF first_1(D), 128, 0; /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:7:1: error: mode precision of non-integral result does not match field size of BIT_FIELD_REF sum (a first, a second) ^ BIT_FIELD_REF second_2(D), 128, 0 /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:9:16: note: in statement return first + second; ^ _7 = BIT_FIELD_REF second_2(D), 128, 0; /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:7:1: internal compiler error: verify_gimple failed sum (a first, a second) ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/67272] [HSA] register allocator expects that every register must be assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67272 --- Comment #1 from Michael Matz matz at gcc dot gnu.org --- Which options and which svn revision are you using? I can't reproduce.
[Bug fortran/66929] [6 regression] ICE with iso_varying_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66929 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Mikael Morin mikael at gcc dot gnu.org --- I posted a follow-up test inspired by generic_31.f90 as PR67277. The rest here is FIXED, closing.
[Bug target/67272] [HSA] register allocator expects that every register must be assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67272 --- Comment #3 from Michael Matz matz at gcc dot gnu.org --- Author: matz Date: Wed Aug 19 15:55:19 2015 New Revision: 227014 URL: https://gcc.gnu.org/viewcvs?rev=227014root=gccview=rev Log: PR target/67272 * hsa-regalloc.c (naive_process_phi): Don't emit code into the entry block. Modified: branches/hsa/gcc/ChangeLog.hsa branches/hsa/gcc/hsa-regalloc.c
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Marek Polacek mpolacek at gcc dot gnu.org --- Ok, should be fixed now.
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #30 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Aug 19 14:22:26 2015 New Revision: 227009 URL: https://gcc.gnu.org/viewcvs?rev=227009root=gccview=rev Log: PR middle-end/67133 * gimple-ssa-isolate-paths.c (insert_trap_and_remove_trailing_statements): Rename to ... (insert_trap): ... this. Don't remove trailing statements; split block instead. (find_explicit_erroneous_behaviour): Don't remove all outgoing edges. * g++.dg/torture/pr67133.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr67133.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-isolate-paths.c trunk/gcc/testsuite/ChangeLog
[Bug target/67272] [HSA] register allocator expects that every register must be assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67272 --- Comment #2 from Michael Matz matz at gcc dot gnu.org --- Ah, with -O0, can reproduce now.
[Bug c/67276] New: duplicated missing terminating character diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67276 Bug ID: 67276 Summary: duplicated missing terminating character diagnostic Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org Target Milestone: --- From gcc.dg/pragma-message.c: #pragma message /home/manuel/test.c:1:17: warning: missing terminating character #pragma message ^ /home/manuel/test.c:1:9: error: missing terminating character #pragma message ^ It doesn't make sense to give a warning if we are going to give an error anyway. Moreover, this is a pedwarn, so with -pedantic-errors we get two errors.
[Bug preprocessor/67276] duplicated missing terminating character diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67276 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Component|c |preprocessor --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- This affects also C++ and it seems more like a preprocessor issue.
[Bug fortran/67277] segfault when passing a missing optional argument to an elemental intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67277 --- Comment #2 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Mikael Morin from comment #1) I hope it works that way. Nope, it doesn't. :-(
[Bug middle-end/67271] [5/6 Regression] ICE with -O1,2,3 on darwin14.5 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67271 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug c++/53184] Unnecessary anonymous namespace warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||blue.dragan+gcc at gmail dot com --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 51440 has been marked as a duplicate of this bug. ***
[Bug c++/51440] Improve message and add an option for warning for an unnamed struct member: TYPE has a field FIELD whose type uses the anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51440 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 53184 ***
[Bug fortran/67277] New: segfault when passing a missing optional argument to an elemental intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67277 Bug ID: 67277 Summary: segfault when passing a missing optional argument to an elemental intrinsic Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- Created attachment 36214 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36214action=edit test case The testcase is the intrinsic variant of generic_31.f90 from pr66929. It leads to a null pointer dereference at runtime when trying to evaluate the absent optional argument. The problem is the same as pr66929, we don't have a procedure interface symbol for the call, so we don't know that the dummy argument of the intrinsic procedure is optional, and thus assume that it is always present.
[Bug regression/67278] New: ICE: verify_gimple failed on darwin 14.5 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67278 Bug ID: 67278 Summary: ICE: verify_gimple failed on darwin 14.5 x86_64 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: tarasevich at cs dot uni-saarland.de Target Milestone: --- Created attachment 36216 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36216action=edit test case Test pr65491.c fails on on darwin14.5 x86_64 GCC was compiled from SVN trunk revision 226781 gcc -v -save-temps /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c Using built-in specs. COLLECT_GCC=/Users/sevich/work/build_normal/bin/gcc COLLECT_LTO_WRAPPER=/Users/sevich/work/build_normal/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/lto-wrapper Target: x86_64-apple-darwin14.5.0 Configured with: /Users/sevich/work/source/gcc_trunk_git/configure --disable-bootstrap --enable-languages=c,c++ --prefix=/Users/sevich/work/build_normal/ Thread model: posix gcc version 6.0.0 20150811 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.5' '-v' '-save-temps' '-mtune=core2' /Users/sevich/work/build_normal/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/cc1 -E -quiet -v -D__DYNAMIC__ /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c -fPIC -mmacosx-version-min=10.10.5 -mtune=core2 -fpch-preprocess -o pr65491_1.i ignoring nonexistent directory /Users/sevich/work/build_normal/lib/gcc/x86_64-apple-darwin14.5.0/6.0.0/../../../../x86_64-apple-darwin14.5.0/include #include ... search starts here: #include ... search starts here: /Users/sevich/work/build_normal/lib/gcc/x86_64-apple-darwin14.5.0/6.0.0/include /usr/local/include /Users/sevich/work/build_normal/include /Users/sevich/work/build_normal/lib/gcc/x86_64-apple-darwin14.5.0/6.0.0/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.5' '-v' '-save-temps' '-mtune=core2' /Users/sevich/work/build_normal/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/cc1 -fpreprocessed pr65491_1.i -fPIC -quiet -dumpbase pr65491_1.c -mmacosx-version-min=10.10.5 -mtune=core2 -auxbase pr65491_1 -version -o pr65491_1.s GNU C11 (GCC) version 6.0.0 20150811 (experimental) (x86_64-apple-darwin14.5.0) compiled by GNU C version 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C11 (GCC) version 6.0.0 20150811 (experimental) (x86_64-apple-darwin14.5.0) compiled by GNU C version 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 700dea0ce5ef3b798edb9c9160a43b26 /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c: In function ‘sum’: /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:7:1: error: mode precision of non-integral result does not match field size of BIT_FIELD_REF sum (a first, a second) ^ BIT_FIELD_REF first_1(D), 128, 0 /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:9:16: note: in statement return first + second; ^ _6 = BIT_FIELD_REF first_1(D), 128, 0; /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:7:1: error: mode precision of non-integral result does not match field size of BIT_FIELD_REF sum (a first, a second) ^ BIT_FIELD_REF second_2(D), 128, 0 /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:9:16: note: in statement return first + second; ^ _7 = BIT_FIELD_REF second_2(D), 128, 0; /Users/sevich/work/source/gcc_trunk_git/gcc/testsuite//gcc.target//aarch64//pr65491_1.c:7:1: internal compiler error: verify_gimple failed sum (a first, a second) ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/67277] segfault when passing a missing optional argument to an elemental intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67277 --- Comment #3 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Mikael Morin from comment #2) (In reply to Mikael Morin from comment #1) I hope it works that way. Nope, it doesn't. :-( The symbol is left uninitialized, it seems. And reverting the symbol.c part doesn't work either, because then the vptr is cleared.
[Bug tree-optimization/67227] [6 regression] comparison failure in ada/par.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67227 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Summary|[6 regression] stage2 ada |[6 regression] comparison |compiler miscompiled|failure in ada/par.o --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- It is only a comparison failure due to scheduling differences. --- x1 2015-08-19 15:26:41.0 +0200 +++ x2 2015-08-19 15:26:46.0 +0200 @@ -1,5 +1,5 @@ -stage2-gcc/ada/par.o: file format elf64-ia64-little +stage3-gcc/ada/par.o: file format elf64-ia64-little Disassembly of section .text: @@ -29467,25 +29467,25 @@ 214b2: PCREL21B atree__new_node 214b6: 00 00 00 02 00 00 nop.i 0x0 214bc: 08 00 00 50 br.call.sptk.many b0=214b0 par__ch6__p_formal_part.2186+0xa30 - 214c0: 08 78 e0 01 80 24 [MMI] mov r15=16504 - 214c6: e0 80 03 00 49 20 mov r14=16496 - 214cc: 00 06 04 92 mov r1=16608 - 214d0: 0a 80 23 00 08 20 [MMI] addp4 r112=r8,r0;; - 214d6: f0 78 30 00 40 c0 add r15=r15,r12 - 214dc: e1 60 00 80 add r14=r14,r12 - 214e0: 0a 08 04 18 00 20 [MMI] add r1=r1,r12;; - 214e6: f0 00 3c 20 20 00 ld4 r15=[r15] - 214ec: 00 00 04 00 nop.i 0x0 + 214c0: 08 70 c0 01 80 24 [MMI] mov r14=16496 + 214c6: 00 00 00 02 00 e0 nop.m 0x0 + 214cc: 81 07 00 92 mov r15=16504 + 214d0: 09 08 80 01 81 24 [MMI] mov r1=16608 + 214d6: 00 00 00 02 00 00 nop.m 0x0 + 214dc: 8e 00 20 80 addp4 r112=r8,r0;; + 214e0: 09 70 38 18 00 20 [MMI] add r14=r14,r12 + 214e6: f0 78 30 00 40 20 add r15=r15,r12 + 214ec: 10 60 00 80 add r1=r1,r12;; 214f0: 09 00 20 1c 90 11 [MMI] st4 [r14]=r8 214f6: 10 00 04 30 20 00 ld8 r1=[r1] 214fc: 00 00 04 00 nop.i 0x0;; - 21500: 01 00 00 00 01 00 [MII] nop.m 0x0 - 21506: e0 00 3c 2c 00 e0 sxt4 r14=r15 - 2150c: 01 61 00 84 adds r15=16,r12;; - 21510: 0b 70 38 00 11 20 [MMI] shladd r14=r14,2,r0;; - 21516: e0 78 38 00 40 00 add r14=r15,r14 + 21500: 02 78 00 1e 10 10 [MII] ld4 r15=[r15] + 21506: 00 00 00 02 00 c0 nop.i 0x0;; + 2150c: 01 78 58 00 sxt4 r14=r15 + 21510: 0b 78 40 18 00 21 [MMI] adds r15=16,r12;; + 21516: e0 70 00 22 40 00 shladd r14=r14,2,r0 2151c: 00 00 04 00 nop.i 0x0;; - 21520: 09 00 00 00 01 00 [MMI] nop.m 0x0 + 21520: 0b 70 3c 1c 00 20 [MMI] add r14=r15,r14;; 21526: e0 e0 3b 7e 46 00 adds r14=-4,r14 2152c: 00 00 04 00 nop.i 0x0;; 21530: 10 88 03 1c 10 10 [MIB] ld4 r113=[r14]
[Bug fortran/66929] [6 regression] ICE with iso_varying_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66929 --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Wed Aug 19 14:47:23 2015 New Revision: 227010 URL: https://gcc.gnu.org/viewcvs?rev=227010root=gccview=rev Log: Forward-port test generic_31.f90 from the 5 branch. gcc/testsuite/ PR fortran/66929 * gfortran.dg/generic_31.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/generic_31.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/65491] [aarch64] ICE: in emit_move_insn, at expr.c:3609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65491 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrey Tarasevich from comment #5) Test pr65491.c fails on on darwin14.5 x86_64 GCC was compiled from SVN trunk revision 226781 Please file this as a separate bug.
[Bug target/67272] [HSA] register allocator expects that every register must be assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67272 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Matz matz at gcc dot gnu.org --- Fixed in r227014. Code was emitted to the entry block, which isn't supported.
[Bug bootstrap/67275] New: *** No rule to make target '../build-x86_64-w64-mingw32/libiberty/pic/libiberty.a', needed by 'build/genmddeps.exe'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67275 Bug ID: 67275 Summary: *** No rule to make target '../build-x86_64-w64-mingw32/libiberty/pic/libiberty.a ', needed by 'build/genmddeps.exe'. Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rai...@emrich-ebersheim.de Target Milestone: --- When configured using --enabled-host-shared for x86_64-w64-mingw32 the linking of genmddeps expects a pic version of libiberty.a in build-x86_64-w64-mingw32/libiberty/pic/ which isn't build beforehand. ../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-6.0.0-test/configure --prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test --with-gnu-as --with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/bin/as --with-gnu-ld --with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/bin/ld --build=x86_64-w64-mingw32 --enable-threads=posix --enable-languages=c,ada,c++,fortran,java,lto,objc,obj-c++ --with-gmp-include=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/include --with-gmp-lib=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/lib64 --with-mpfr-include=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/include --with-mpfr-lib=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/lib64 --with-mpc-include=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/include --with-mpc-lib=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/lib64 --with-isl-include=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/include --with-isl-lib=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test/lib64 --with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-6.0.0-test --enable-libgomp --enable-fully-dynamic-string --disable-multilib --enable-checking=release --disable-werror --enable-host-shared --with-sysroot=/x86_64-w64-trunk g++ -std=gnu++98 -c -g -DIN_GCC -fPIC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-6.0.0-test/gcc -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-6.0.0-test/gcc/build -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-6.0.0-test/gcc/../include -I./../intl -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-6.0.0-test/gcc/../libcpp/include \ -o build/genmddeps.o ../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-6.0.0-test/gcc/genmddeps.c make[3]: *** No rule to make target '../build-x86_64-w64-mingw32/libiberty/pic/libiberty.a', needed by 'build/genmddeps.exe'. Stop. IMHO this is an issue in the configuration machinery. x86_64-w64-mingw32 is always position independent. Rainer
[Bug fortran/67277] segfault when passing a missing optional argument to an elemental intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67277 --- Comment #1 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 36215 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36215action=edit Draft patch, untested, currently bootstrapping This patch adds a gfc_abstract_symbol class to abstract away the differences between gfc_symbol and gfc_intrinsic_symbol. Then the procedure symbol can be abstracted to a gfc_abstract_symbol, even if it is intrinsic. The change in symbol.c is necessary, otherwise the vptr is not set. I hope it works that way.
[Bug target/67280] New: [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280
Bug ID: 67280
Summary: [5 Regression] wrong C++11 code generated on
arm-linux-gnueabihf
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with the 5 branch svn r226731 on arm-linux-gnueabihf, works with -O1,
fails with -O2. works on x86_64 and aarch64.
$ cat foo.cc
#include iostream
#include exception
#include functional
namespace
{
void run(std::functionvoid() const f)
{
try
{
f();
}
catch (std::exception const e)
{
std::cerr ignored exception: e.what() std::endl;
}
}
}
int main()
{
run([]{ throw std::runtime_error(some error); });
run([]{ throw std::runtime_error(some error); });
}
$ g++ -O1 -std=c++11 foo.cc ./a.out
ignored exception: some error
ignored exception: some error
$ g++ -O2 -std=c++11 foo.cc ./a.out
terminate called after throwing an instance of 'std::runtime_error'
what(): some error
Aborted
$ g++ -Os -std=c++11 foo.cc ./a.out
terminate called after throwing an instance of 'std::runtime_error'
what(): some error
Aborted
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-15ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--disable-werror --enable-multilib --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 5.2.1 20150808 (Ubuntu 5.2.1-15ubuntu1)
[Bug target/67281] HTM builtins aren't treated as compiler barriers on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67281 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- There is no memory access in your testcase at all. Since the variables are all local variables and nothing takes the address, it can be moved out of the loop as no other thread can cause that to fail.
[Bug target/55307] libgcc's __cpu_indicator_init does not check for avx correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55307 Jeffrey Walton noloader at gmail dot com changed: What|Removed |Added CC||noloader at gmail dot com --- Comment #4 from Jeffrey Walton noloader at gmail dot com --- Forgive my ignorance... Is __builtin_cpu_supports really __builtin_os_supports? If we want to test CPU support (rather than OS support), then can it be done with the built-ins? Also, the documentation at https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/X86-Built-in-Functions.html does not mention that this is in fact OS support, and not CPU support.
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #52 from Alexandre Oliva aoliva at gcc dot gnu.org --- Author: aoliva Date: Wed Aug 19 17:00:32 2015 New Revision: 227015 URL: https://gcc.gnu.org/viewcvs?rev=227015root=gccview=rev Log: [PR64164] fix regressions reported on m68k and armeb Defer stack slot address assignment for all parms that can't live in pseudos, and accept pseudos assignments in assign_param_setup_block. for gcc/ChangeLog PR rtl-optimization/64164 * cfgexpand.c (parm_maybe_byref_p): Renamed to... (parm_in_stack_slot_p): ... this. Disregard mode, what matters is whether the parm will live in a pseudo or a stack slot. (expand_one_ssa_partition): Deal with params without a default def. Disregard mode. * cfgexpand.h: Renamed function declaration. * tree-ssa-coalesce.c: Adjust. * function.c (split_complex_args): Allocate stack slot for unassigned parms before splitting. (parm_in_unassigned_mem_p): New. Use it instead of parm_maybe_byref_p throughout this file. (assign_parm_setup_block): Use it. Accept pseudos in the expand-assigned rtl. (assign_parm_setup_reg): Drop BLKmode requirement. (assign_parm_setup_stack): Allocate and fill in the address of unassigned MEM parms. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/cfgexpand.h trunk/gcc/function.c trunk/gcc/tree-ssa-coalesce.c
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Yes, because 1 31 is UB in C99/C11.
[Bug tree-optimization/67282] New: Wrong code with -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67282
Bug ID: 67282
Summary: Wrong code with -floop-nest-optimize
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
I think that we're generating a wrong code when using -O2 -floop-nest-optimize:
double A[64][64];
double C[64][64];
int
main ()
{
int i, j, k;
for (i = 0; i 64; i++)
for (j = 0; j 64; j++)
for (k = 0; k 64; k++)
C[i][j] = A[i][k];
}
$ ./a.out
Segmentation fault (core dumped)
It doesn't segv if I use -frapv/-fsanitize=undefined/...
Might be related to PR66980.
[Bug c/67279] New: -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279
Bug ID: 67279
Summary: -fsanitize=undefined spurious error: initializer
element is not constant
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
/* gcc -fsanitize=undefined issues spurious error message */
/* OK without sanitizer */
/* Target: x86_64-unknown-linux-gnu */
void test(void)
{
int dec_good = 1 31; /* good */
static int dec_BAD = 1 31; /* error: initializer element is not constant*/
}
[Bug target/67211] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67211 --- Comment #8 from Michael Meissner meissner at gcc dot gnu.org --- A preliminary analysis is -mefficient-unaligned-vector is set in rs6000_option_override_internal if -mtune=power8 is used. Note, this code uses a variable 'rs6000_cpu' to indicate the tuning cpu, not the target cpu. Now, long term we probably should audit the uses of rs6000_cpu to see if they are related to tuning or arch, and possibly add rs6000_tune for those conditions. Setting efficient unaligned vector is wrong for a tuning option. I believe the best approach is to make -mefficient-unaligned-vector a normal masked option in rs6000_isa. This will allow future processors to specify this option, rather than going through the code to find (rs6000_cpu == PROCESSOR_POWER8) and adjust it. The reason unaligned fast vector support enables the bug is it enables the option to convert adjacent DImode structure mode members into V2DImode. The code builds V2DImode vectors in the VSX registers to copy the structure. At the end of the function, there is a reference to one of the elements, and reload is trying to combine this with the previous load. But it doesn't have a move direct operation on a power7 cpu. The code for power8 looks like: lfd 31,320(1) ... mtvsrd 12,9 ... xxpermdi 63,12,31,0 stxvd2x 63,1,26 ... mfvsrd 9,31 addi 9,9,8 ld 10,0(9) .LVL14: mtvsrd 31,9 .LVL15: .loc 1 24 0 add 9,10,21 In this case, it probably doesn't win to aggregate the structure members as V2DImode, since it involves a lot of moves and xxpermdi's. I haven't tracked down why it doesn't fail on trunk compared to the GCC 5 branch.
[Bug target/67211] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67211 --- Comment #9 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 36217 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36217action=edit Proposed patch to fix the problem This patch makes -mefficient-unaligned-vsx set on -mcpu=power8 instead of -mtune=power8.
[Bug target/67281] New: HTM builtins aren't treated as compiler barriers on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67281
Bug ID: 67281
Summary: HTM builtins aren't treated as compiler barriers on
powerpc
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tuliom at linux dot vnet.ibm.com
Target Milestone: ---
Depending on the level of optimization, GCC moves a memory access outside a
transaction which breaks the atomicity of the transaction.
This is a small testcase that reproduces this behavior:
$ cat tbegin-barrier.c
long
foo (long dest, long src0, long src1, long tries)
{
long i;
for (i = 0; i tries; i++)
{
__builtin_tbegin (0);
dest = src0 + src1;
__builtin_tend (0);
}
return dest;
}
compiling using: -O2 -S -mcpu=power8 tbegin-barrier.c
gives
foo:
cmpdi 0,6,0
blelr 0
mtctr 6
add 3,4,5
.p2align 4,,15
.L3:
tbegin. 0
tend. 0
bdnz .L3
blr
[Bug target/67211] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67211 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Attachment #36217|0 |1 is obsolete|| --- Comment #10 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 36218 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36218action=edit Proposed patch to fix the problem (#2) Bill convinced me that we need setting ALLOW_MOVMISALIGN to 1 if power8. This patch fixes that.
[Bug target/67281] HTM builtins aren't treated as compiler barriers on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67281 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Since there are no stores, the load seems like it can be pulled out of the loop too.
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279 --- Comment #2 from Vittorio Zecca zeccav at gmail dot com --- UB = undefined behaviour? Why then it is only signaled if static attribute is requested? This is accepted:int dec_1 = 1 31; Isn't UB as well if it is not static? I believe gcc should deliver a warning, and then a runtime error message at runtime. In other words codes that compile with gcc should still compile with -fsanitize=undefined This example comes from wine and it is annoying to recompile the codes that exhibit this error message. Also, the message is misleading, it should say that the initializer is undefined.
[Bug target/67281] HTM builtins aren't treated as compiler barriers on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67281
--- Comment #4 from Tulio Magno Quites Machado Filho tuliom at linux dot
vnet.ibm.com ---
(In reply to Andrew Pinski from comment #3)
Since there are no stores, the load seems like it can be pulled out of the
loop too.
I disagree with you.
If I use the value of dest to take a decision inside the transaction, I need
the memory barrier before the access to *src0.
Here's an example:
long
foo (long dest, long *src0, long src1, long tries)
{
long i;
for (i = 0; i tries; i++)
{
__builtin_tbegin (0);
dest = *src0 + src1;
if (dest == 13)
__builtin_tabort(0);
__builtin_tend (0);
}
return dest;
}
In other words, if you access *src0 before the memory barrier, its value may
change when the memory barrier is created. This is particularly useful if dest
says if a lock has been acquired by another thread or not.
For the reference, this has been found in glibc source code:
https://sourceware.org/ml/libc-alpha/2015-07/msg00986.html
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-19 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- The reason for the error is that -fsanitize=undefined replaces 131 with a call to a sanitizer function __ubsan_handle_shift_out_of_bounds(), however, this function call is not constant and it cannot be the initializer of a static variable. A possible solution could be to give a warning enabled by default (about 1 31 being undefined) and to NOT sanitize expressions that are required to be constants (since anyway the compiler will not accept them). In any case, it makes sense that -fsanitize=undefined does not affect whether the code is compiled or not.
[Bug c++/67268] demangler does not elide empty argument pack in operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67268 --- Comment #1 from Ian Lance Taylor ian at airs dot com --- This symbol shows a similar, though perhaps not identical, issue: _ZNSt11_Tuple_implILm0EJN12stats_census7tracing2OpEEEC2IRS2_JEvEEOT_DpOT0_ The demangler turns this into std::_Tuple_impl0ul, stats_census::tracing::Op::_Tuple_implstats_census::tracing::Op, , void(stats_census::tracing::Op) It should be std::_Tuple_impl0ul, stats_census::tracing::Op::_Tuple_implstats_census::tracing::Op, void(stats_census::tracing::Op)
[Bug target/67281] HTM builtins aren't treated as compiler barriers on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67281
Peter Bergner bergner at gcc dot gnu.org changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #5 from Peter Bergner bergner at gcc dot gnu.org ---
(In reply to Tulio Magno Quites Machado Filho from comment #4)
I disagree with you.
I agree with Tulio.
Here's an example:
long
foo (long dest, long *src0, long src1, long tries)
{
long i;
for (i = 0; i tries; i++)
{
__builtin_tbegin (0);
dest = *src0 + src1;
if (dest == 13)
__builtin_tabort(0);
__builtin_tend (0);
}
return dest;
}
Even better is to change src1 to a pointer too and dereference that within the
transaction. If *src0 and *src1 are two memory locations that should be
updated together and atomically, then allowing them to move past the tbegin.
could break that requirement.
[Bug c++/66606] missing diagnostic on using function main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66606 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-19 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug c/67283] New: GCC regression over inlining of returned structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283
Bug ID: 67283
Summary: GCC regression over inlining of returned structures
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roche at httrack dot com
Target Milestone: ---
Created attachment 36219
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36219action=edit
Sample test case (gcc -S -O3 -W -Wall)
An optimization bug regression appears to exist when dealing with structures
returned by inlined functions. This was working totally fine with GCC 4.4.7.
(see below)
A typical example is:
struct foo {
int flags;
/* Let it be enough NOT to be packed in registers */
void *opaque[2];
};
static __inline__ struct foo add_flag(struct foo foo, int flag) {
foo.flags |= flag;
return foo;
}
Calls to add_flag are inlined, but the stack usage increases with latest GCC
versions (the code should be almost identical, except the flag in place in the
stack).
Tested the following GCC versions: (grep addq.*%rsp to get stack usage for
each function) ; tested architecture: x86-64
GCC 4.4.7: OK
addq$72, %rsp # demo_1
addq$72, %rsp
addq$72, %rsp
addq$72, %rsp
addq$72, %rsp # demo_5
GCC 4.5.3 to 4.6.4: NOK (UNTESTED between 4.4.8 to 4.5.2)
addq$72, %rsp # demo_1
addq$136, %rsp
addq$168, %rsp
addq$200, %rsp
addq$232, %rsp # demo_5
GCC 4.7.3 to 5.2.0: NOK (UNTESTED between 4.6.5 to 4.7.2)
addq$72, %rsp # demo_1
addq$136, %rsp
addq$200, %rsp
addq$264, %rsp
addq$328, %rsp # demo_5
Therefore, the test case was fine in GCC 4.4.7, first degraded between 4.4.8
and 4.5.3, and then again between 4.6.5 and 4.7.3
Note: code produced with http://gcc.godbolt.org/ with -O3 -W -Wall flags.
(same results with -01)
[Bug c/67283] GCC regression over inlining of returned structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283 --- Comment #2 from Xavier Roche roche at httrack dot com --- Created attachment 36221 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36221action=edit Produced assembly code with GCC 4.6.4 on x86_64 Produced assembly code with GCC 4.6.4 on x86_64
[Bug c/67283] GCC regression over inlining of returned structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283 --- Comment #3 from Xavier Roche roche at httrack dot com --- Created attachment 36222 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36222action=edit Produced assembly code with GCC 5.2.0 on x86_64 Produced assembly code with GCC 5.2.0 on x86_64
[Bug target/67281] HTM builtins aren't treated as compiler barriers on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67281
--- Comment #2 from Tulio Magno Quites Machado Filho tuliom at linux dot
vnet.ibm.com ---
Oooops. My bad.
What about this one?
$ cat tbegin-barrier.c
long
foo (long dest, long *src0, long src1, long tries)
{
long i;
for (i = 0; i tries; i++)
{
__builtin_tbegin (0);
dest = *src0 + src1;
__builtin_tend (0);
}
return dest;
}
If we compile it the same way:
foo:
cmpdi 0,6,0
blelr 0
mtctr 6
ld 3,0(4)
.p2align 4,,15
.L3:
tbegin. 0
tend. 0
bdnz .L3
add 3,3,5
blr
[Bug c/67283] GCC regression over inlining of returned structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283 --- Comment #1 from Xavier Roche roche at httrack dot com --- Created attachment 36220 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36220action=edit Produced assembly code with GCC 4.4.7 on x86_64 Produced assembly code with GCC 4.4.7 on x86_64
[Bug c++/67269] demangler does not handle constructor of substituted name correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67269
--- Comment #1 from Ian Lance Taylor ian at airs dot com ---
Here is a similar, though different, case involving a constructor:
_ZZN1C1D1E1F1G1HEvENUlvE_C2EOS4_
The demangler currently turns this into:
C::D::E::F::G::H()::{lambda()#1}::H({lambda()#1})
That is clearly wrong: H is part of the local name. It's not the constructor.
The correct demangling would probably be
C::D::E::F::G::H()::{lambda()#1}::{lambda()#1}({lambda()#1})
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279
--- Comment #3 from Vittorio Zecca zeccav at gmail dot com ---
The following code has UB at lines 4 and 5 but compiles with
-fsanitize=undefined
int main()
{
int test[1],t;
t=test[1];
return test[1];
}
Its execution it delivers four runtime errors from the sanitizer and I
am happy with that
ps.c:4:7: runtime error: index 1 out of bounds for type 'int [1]'
ps.c:4:2: runtime error: load of address 0x7ffcb21195f4 with
insufficient space for an object of type 'int'
0x7ffcb21195f4: note: pointer points here
e0 96 11 b2 fc 7f 00 00 00 00 00 00 00 00 00 00 70 07 40 00 00 00
00 00 e0 ff a1 0d 39 00 00 00
^
ps.c:5:12: runtime error: index 1 out of bounds for type 'int [1]'
ps.c:5:8: runtime error: load of address 0x7ffcb21195f4 with
insufficient space for an object of type 'int'
0x7ffcb21195f4: note: pointer points here
e0 96 11 b2 fc 7f 00 00 00 00 00 00 fc 7f 00 00 70 07 40 00 00 00
00 00 e0 ff a1 0d 39 00 00 00
In short: I like to see gcc -fsanitize=undefined to compile codes it
compiles without sanitation
[Bug go/67284] New: libgo fails to build on trunk r227015 / *-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67284
Bug ID: 67284
Summary: libgo fails to build on trunk r227015 / *-linux-gnu
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: doko at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
libgo ftbfs on the trunk r227015
powerpc64le-linux-gnu:
../../../src/libgo/go/encoding/gob/decode.go: In function
'gob.decIgnoreOpFor.pN20_encoding_gob.Decoder':
../../../src/libgo/go/encoding/gob/decode.go:843:1: internal compiler error: in
operator[], at vec.h:714
func (dec *Decoder) decIgnoreOpFor(wireId typeId) decOp {
^
x86_64-linux-gnu (32bit multilib), aarch64-linux-gnu, i686-linux-gnu,
powerpc-linux-gnu:
../../../../src/libgo/go/encoding/gob/decode.go: In function
'gob.decIgnoreOpFor.pN20_encoding_gob.Decoder':
../../../../src/libgo/go/encoding/gob/decode.go:843:1: internal compiler error:
in operator[], at vec.h:714
func (dec *Decoder) decIgnoreOpFor(wireId typeId) decOp {
^
0xacea17 vecedge_def*, va_gc, vl_embed::operator[](unsigned int)
../../src/gcc/vec.h:714
0xacea17 extract_true_false_edges_from_block(basic_block_def*, edge_def**,
edge_def**)
../../src/gcc/tree-cfg.c:8456
0xad71b1 gimple_verify_flow_info
../../src/gcc/tree-cfg.c:5260
0x6f2a35 verify_flow_info()
../../src/gcc/cfghooks.c:260
0xae7141 cleanup_tree_cfg_noloop
../../src/gcc/tree-cfgcleanup.c:739
0xae7141 cleanup_tree_cfg()
../../src/gcc/tree-cfgcleanup.c:788
0x9db3f4 execute_function_todo
../../src/gcc/passes.c:1900
0x9dbd03 execute_todo
../../src/gcc/passes.c:2005
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions.
Makefile:5201: recipe for target 'encoding/gob.lo' failed
make[10]: *** [encoding/gob.lo] Error 1
make[10]: Leaving directory '/«PKGBUILDDIR»/build/x86_64-linux-gnu/32/libgo'
Makefile:4058: recipe for target 'all-recursive' failed
make[9]: *** [all-recursive] Error 1
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #4) A possible solution could be to give a warning enabled by default (about 1 31 being undefined) and to NOT sanitize expressions that are required to be constants (since anyway the compiler will not accept them). Indeed, Clang doesn't instrument static initializers. This is a bug on the C/C++ FEs instrumentation. I wonder what happens with global static and static const? They do not seem to be instrumented by the sanitizer.
[Bug c++/67065] [DR 1886] Missing diagnostics for ill-formed program with main variable instead of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|Missing diagnostics for |[DR 1886] Missing |ill-formed program with |diagnostics for ill-formed |main variable instead of|program with main variable |function|instead of function --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Anders Granlund from comment #0) The program is ill-formed by following sentence in [basic.start.main]p3 (http://eel.is/c++draft/basic.start.main#3): A program that declares a variable main at global scope or that declares the name main with C language linkage (in any namespace) is ill-formed. This sentence only exists in the most recent draft, so I'm not surprised it isn't widely implemented yet. :)
[Bug c++/66957] [4.9/5/6 Regression] incorrect is protected within this context error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66957 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.9.4 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.9.4, 5.3, 6.0.
[Bug c++/38579] [4.2/4.3/4.4 Regression] Template: Wrong inherited copy-ctor visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38579 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Known to fail|| --- Comment #10 from Jason Merrill jason at gcc dot gnu.org --- Note that this will be broken again in 4.9.4 and 5.3, because the fix caused the worse bug 66957 and so I reverted it on those branches. 6.0 will have a proper fix.
[Bug c++/66957] [4.9/5/6 Regression] incorrect is protected within this context error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66957 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 20 01:45:49 2015 New Revision: 227023 URL: https://gcc.gnu.org/viewcvs?rev=227023root=gccview=rev Log: PR c++/66957 * search.c (protected_accessible_p): Remove redundant access_in_type. Add otype parm instead of walking binfo. (friend_accessible_p): Check SCOPE itself. Handle class templates. Pass through otype. (dfs_accessible_post): Handle all accessibility cases. (dfs_accessible_pre): New. (accessible_p): Use it. Don't check protected access here. Pass decl and otype to dfs_walk. (member_declared_in_type, dfs_access_in_type_pre): New. (access_in_type): Use dfs_access_in_type_pre. * friend.c (add_friend): Fix multiple friends with the same name. Added: trunk/gcc/testsuite/g++.dg/inherit/access9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/friend.c trunk/gcc/cp/search.c
[Bug middle-end/67271] [5/6 Regression] ICE with -O1,2,3 on darwin14.5 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67271 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Seems like native_encode_string should deal with nonsensical offset: (gdb) p off $4 = -1352770792
[Bug c++/67270] internal compiler error: in unify, at cp/pt.c:18178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67270 --- Comment #2 from radventure at yandex dot ru --- (In reply to Marek Polacek from comment #1) This was fixed in r219557 and is fixed in 5/trunk. I know about absence of problem in 5.1.
[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #19 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
I'm not sure why bug 59535 was closed, same problem might still exist, quote:
Zhenqiang Chen 2014-09-03 06:17:44 UTC
Here is a small case to show lra introduces one more register copy (tested
with trunk and 4.9).
int isascii (int c)
{
return c = 0 c 128;
}
With options: -Os -mthumb -mcpu=cortex-m0, I got
isascii:
mov r3, #0
mov r2, #127
mov r1, r3 //???
cmp r2, r0
adc r1, r1, r3
mov r0, r1
bx lr
With options: -Os -mthumb -mcpu=cortex-m0 -mno-lra, I got
isascii:
mov r2, #127
mov r3, #0
cmp r2, r0
adc r3, r3, r3
mov r0, r3
bx lr
Testing 4.8.5 and 5.2.0 still still produces same bigger code in GCC 5.2.
So something adds a register copy in this small case.
/Fredrik
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #21 from rusty at rustcorp dot com.au --- jengelh at inai dot de gcc-bugzi...@gcc.gnu.org writes: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #20 from Jan Engelhardt jengelh at inai dot de --- Seems like the short route is to add a new attribute ((warn_unused_result_with_void_cancelling)) that exhibits the desired behavior of (void) cancelling the warning, and then make glibc use that. Simple, no? Indeed! I'll produce the patch if anyone thinks it's worthwhile? It'll only take another 10 years to switch everyone :) Thanks, Rusty.
[Bug c++/67269] New: demangler does not handle constructor of substituted name correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67269
Bug ID: 67269
Summary: demangler does not handle constructor of substituted
name correctly
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
CC: gbenson at redhat dot com
Target Milestone: ---
The demangler picks the constructor name based on the last name that it sees.
It does not do this correctly when the last name is actually substituted.
Here is a test case, which I concede is fairly insane.
_ZNSt10_HashtableI12basic_stringIcSt11char_traitsIcESaIcEESt4pairIKS4_N1C1D1EEESaISA_ENSt8__detail10_Select1stESt8equal_toIS4_ESt4hashIS4_ENSC_18_Mod_range_hashingENSC_20_Default_ranged_hashENSC_20_Prime_rehash_policyENSC_17_Hashtable_traitsILb1ELb0ELb19_M_assignIZNSN_C1ERKSN_EUlPKNSC_10_Hash_nodeISA_Lb1_EEvSQ_RKT_
The demangler turns this into
void std::_Hashtablebasic_stringchar, std::char_traitschar,
std::allocatorchar , std::pairbasic_stringchar, std::char_traitschar,
std::allocatorchar const, C::D::E,
std::allocatorstd::pairbasic_stringchar, std::char_traitschar,
std::allocatorchar const, C::D::E , std::__detail::_Select1st,
std::equal_tobasic_stringchar, std::char_traitschar, std::allocatorchar
, std::hashbasic_stringchar, std::char_traitschar, std::allocatorchar
, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traitstrue,
false, true ::_M_assignstd::_Hashtablebasic_stringchar,
std::char_traitschar, std::allocatorchar , std::pairbasic_stringchar,
std::char_traitschar, std::allocatorchar const, C::D::E,
std::allocatorstd::pairbasic_stringchar, std::char_traitschar,
std::allocatorchar const, C::D::E , std::__detail::_Select1st,
std::equal_tobasic_stringchar, std::char_traitschar, std::allocatorchar
, std::hashbasic_stringchar, std::char_traitschar, std::allocatorchar
, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traitstrue,
false, true ::_M_assign(std::_Hashtablebasic_stringchar,
std::char_traitschar, std::allocatorchar , std::pairbasic_stringchar,
std::char_traitschar, std::allocatorchar const, C::D::E,
std::allocatorstd::pairbasic_stringchar, std::char_traitschar,
std::allocatorchar const, C::D::E , std::__detail::_Select1st,
std::equal_tobasic_stringchar, std::char_traitschar, std::allocatorchar
, std::hashbasic_stringchar, std::char_traitschar, std::allocatorchar
, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traitstrue,
false, true
const)::{lambda(std::__detail::_Hash_nodestd::pairbasic_stringchar,
std::char_traitschar, std::allocatorchar const, C::D::E, true
const*)#1}(std::_Hashtablebasic_stringchar, std::char_traitschar,
std::allocatorchar , std::pairbasic_stringchar, std::char_traitschar,
std::allocatorchar const, C::D::E,
std::allocatorstd::pairbasic_stringchar, std::char_traitschar,
std::allocatorchar const, C::D::E , std::__detail::_Select1st,
std::equal_tobasic_stringchar, std::char_traitschar, std::allocatorchar
, std::hashbasic_stringchar, std::char_traitschar, std::allocatorchar
, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traitstrue,
false, true const, std::_Hashtablebasic_stringchar,
std::char_traitschar, std::allocatorchar , std::pairbasic_stringchar,
std::char_traitschar, std::allocatorchar const, C::D::E,
std::allocatorstd::pairbasic_stringchar, std::char_traitschar,
std::allocatorchar const, C::D::E , std::__detail::_Select1st,
std::equal_tobasic_stringchar, std::char_traitschar, std::allocatorchar
, std::hashbasic_stringchar, std::char_traitschar, std::allocatorchar
, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traitstrue,
false, true ::_M_assign(std::_Hashtablebasic_stringchar,
std::char_traitschar, std::allocatorchar , std::pairbasic_stringchar,
std::char_traitschar, std::allocatorchar const, C::D::E,
std::allocatorstd::pairbasic_stringchar, std::char_traitschar,
std::allocatorchar const, C::D::E , std::__detail::_Select1st,
std::equal_tobasic_stringchar, std::char_traitschar, std::allocatorchar
, std::hashbasic_stringchar, std::char_traitschar, std::allocatorchar
, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traitstrue,
false, true
const)::{lambda(std::__detail::_Hash_nodestd::pairbasic_stringchar,
std::char_traitschar, std::allocatorchar const, C::D::E, true
const*)#1} const)
I'm fairly sure that the
[Bug c++/67100] ICE(in type_dependent_expression_p) on macro function + user defined literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67100 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed in r220656.
[Bug c/67271] New: ICE with -O1,2,3 on darwin14.5 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67271 Bug ID: 67271 Summary: ICE with -O1,2,3 on darwin14.5 x86_64 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tarasevich at cs dot uni-saarland.de Target Milestone: --- Created attachment 36212 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36212action=edit preprocessed test case Although test case has out of bounds read, it still yield ICE. GCC was compiled from SVN trunk revision 226781 gcc -v -save-temps -O1 test_case_38.c Using built-in specs. COLLECT_GCC=/Users/sevich/work/build_normal/bin/gcc COLLECT_LTO_WRAPPER=/Users/sevich/work/build_normal/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/lto-wrapper Target: x86_64-apple-darwin14.5.0 Configured with: /Users/sevich/work/source/gcc_trunk_git/configure --disable-bootstrap --enable-languages=c,c++ --prefix=/Users/sevich/work/build_normal/ Thread model: posix gcc version 6.0.0 20150811 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.5' '-v' '-save-temps' '-O1' '-mtune=core2' /Users/sevich/work/build_normal/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/cc1 -E -quiet -v -D__DYNAMIC__ test_case_38.c -fPIC -mmacosx-version-min=10.10.5 -mtune=core2 -O1 -fpch-preprocess -o test_case_38.i ignoring nonexistent directory /Users/sevich/work/build_normal/lib/gcc/x86_64-apple-darwin14.5.0/6.0.0/../../../../x86_64-apple-darwin14.5.0/include #include ... search starts here: #include ... search starts here: /Users/sevich/work/build_normal/lib/gcc/x86_64-apple-darwin14.5.0/6.0.0/include /usr/local/include /Users/sevich/work/build_normal/include /Users/sevich/work/build_normal/lib/gcc/x86_64-apple-darwin14.5.0/6.0.0/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.5' '-v' '-save-temps' '-O1' '-mtune=core2' /Users/sevich/work/build_normal/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/cc1 -fpreprocessed test_case_38.i -fPIC -quiet -dumpbase test_case_38.c -mmacosx-version-min=10.10.5 -mtune=core2 -auxbase test_case_38 -O1 -version -o test_case_38.s GNU C11 (GCC) version 6.0.0 20150811 (experimental) (x86_64-apple-darwin14.5.0) compiled by GNU C version 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C11 (GCC) version 6.0.0 20150811 (experimental) (x86_64-apple-darwin14.5.0) compiled by GNU C version 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 700dea0ce5ef3b798edb9c9160a43b26 test_case_38.c: In function ‘main’: test_case_38.c:5:15: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] long *a = empty; ^ test_case_38.c:7:12: warning: implicit declaration of function ‘labs’ [-Wimplicit-function-declaration] a[i] = labs(a[i]); ^ test_case_38.c:7:12: warning: incompatible implicit declaration of built-in function ‘labs’ test_case_38.c:7:12: note: include ‘stdlib.h’ or provide a declaration of ‘labs’ test_case_38.c:9:1: internal compiler error: Segmentation fault: 11 } ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/67050] [C++14] ICE when calling a template member function from a lambda with implicit this capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67050 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- With -std=c++1y an ICE started with r200948.
[Bug c++/67050] [C++14] ICE when calling a template member function from a lambda with implicit this capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67050 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- (But it's a different ICE than the one in the Description.)
[Bug middle-end/67271] [5/6 Regression] ICE with -O1,2,3 on darwin14.5 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67271 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-19 Ever confirmed|0 |1
[Bug middle-end/67271] [5/6 Regression] ICE with -O1,2,3 on darwin14.5 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67271 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Component|c |middle-end Target Milestone|--- |5.3 Summary|ICE with -O1,2,3 on |[5/6 Regression] ICE with |darwin14.5 x86_64 |-O1,2,3 on darwin14.5 ||x86_64 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, started with r213045. Not Darwin-specific.
[Bug target/67272] New: [HSA] register allocator expects that every register must be assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67272 Bug ID: 67272 Summary: [HSA] register allocator expects that every register must be assigned Product: gcc Version: hsa Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 36213 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36213action=edit Test case Hi Michael. Current HSA RA produces SEGFAULT in case of we have a register that is never assigned. ICE: /tmp/test2.c:3:1: internal compiler error: Segmentation fault bar () ^ 0xed3dd4 crash_signal ../../gcc/toplev.c:353 0xc5fc9d cmp_begin ../../gcc/hsa-regalloc.c:448 0xc613e3 vechsa_op_reg*, va_heap, vl_embed::qsort(int (*)(void const*, void const*)) ../../gcc/vec.h:938 0xc610a5 vechsa_op_reg*, va_heap, vl_ptr::qsort(int (*)(void const*, void const*)) ../../gcc/vec.h:1666 0xc6087b linear_scan_regalloc ../../gcc/hsa-regalloc.c:682 0xc60e4e regalloc ../../gcc/hsa-regalloc.c:786 0xc60f07 hsa_regalloc() ../../gcc/hsa-regalloc.c:806 0xc5a63a generate_hsa ../../gcc/hsa-gen.c:3240 0xc5b254 execute ../../gcc/hsa-gen.c:3485 Thanks, Martin
[Bug middle-end/67271] [5/6 Regression] ICE with -O1,2,3 on darwin14.5 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67271
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
long int labs (long int j);
int
main ()
{
long *a = empty;
int i = 1441516387;
a[i] = labs (a[i]);
return 0;
}
$ ./cc1 -quiet q.c -O
q.c: In function ‘main’:
q.c:5:13: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
long *a = empty;
^
q.c:9:1: internal compiler error: Segmentation fault
}
^
0xd5be56 crash_signal
/home/marek/src/gcc/gcc/toplev.c:352
0xa11ecf native_encode_string
/home/marek/src/gcc/gcc/fold-const.c:7095
0xa11fb8 native_encode_expr(tree_node const*, unsigned char*, int, int)
/home/marek/src/gcc/gcc/fold-const.c:7127
0xa83bac fold_ctor_reference(tree_node*, tree_node*, unsigned long, unsigned
long, tree_node*)
/home/marek/src/gcc/gcc/gimple-fold.c:5441
0xa841ce fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*))
/home/marek/src/gcc/gcc/gimple-fold.c:5558
0xa81d11 gimple_fold_stmt_to_constant_1(gimple_statement_base*, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/home/marek/src/gcc/gcc/gimple-fold.c:5000
0xe9a2af ccp_fold
/home/marek/src/gcc/gcc/tree-ssa-ccp.c:1218
0xe9cf26 evaluate_stmt
/home/marek/src/gcc/gcc/tree-ssa-ccp.c:1738
0xe9f241 visit_assignment
/home/marek/src/gcc/gcc/tree-ssa-ccp.c:2294
0xe9f487 ccp_visit_stmt
/home/marek/src/gcc/gcc/tree-ssa-ccp.c:2367
0xf47f24 simulate_stmt
/home/marek/src/gcc/gcc/tree-ssa-propagate.c:339
0xf485cf simulate_block
/home/marek/src/gcc/gcc/tree-ssa-propagate.c:517
0xf497c6 ssa_propagate(ssa_prop_result (*)(gimple_statement_base*, edge_def**,
tree_node**), ssa_prop_result (*)(gphi*))
/home/marek/src/gcc/gcc/tree-ssa-propagate.c:934
0xe9f58b do_ssa_ccp
/home/marek/src/gcc/gcc/tree-ssa-ccp.c:2410
0xe9f646 execute
/home/marek/src/gcc/gcc/tree-ssa-ccp.c:2443
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 c++/67247] ICE on std::forward args inside nested lambda function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67247 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Testcase in Comment 2 started ICEing with r211084.
[Bug c++/67270] New: internal compiler error: in unify, at cp/pt.c:18178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67270
Bug ID: 67270
Summary: internal compiler error: in unify, at cp/pt.c:18178
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: radventure at yandex dot ru
Target Milestone: ---
Code listed below crashes compiler
I compile it with g++ -std=c++11 test.cpp
#include initializer_list
template templatetypename... class C, typename... T void g(const CT...
a)
{
}
int main()
{
gstd::initializer_list, int({1, 2, 3});
}
[Bug c++/67270] internal compiler error: in unify, at cp/pt.c:18178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67270 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- This was fixed in r219557 and is fixed in 5/trunk.
[Bug c++/67257] [5/6 regression] Internal compiler error in retrieve_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67257 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- ICE started with r214396.
[Bug c++/67259] list-initialization of a reference fails to initialize char array from string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67259 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I think not a regression, even 4.7 rejects this.
[Bug middle-end/67285] New: ICE with (rdiv (POW:s @0 REAL_CST@1) @0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67285
Bug ID: 67285
Summary: ICE with (rdiv (POW:s @0 REAL_CST@1) @0)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hs.naveen2u at gmail dot com
Target Milestone: ---
The following pattern should work as expected:-
+ /* Simplify pow(x,c) / x - pow(x,c-1). */
+ (simplify
+ (rdiv (POW:s @0 REAL_CST@1) @0)
+ (if (!TREE_OVERFLOW (@1))
+ (POW @0 (minus @1 { build_one_cst (type); }
However, it generates the following error:-
internal compiler error: tree check: expected ssa_name, have var_decl in
simplify_builtin_call, at tree-ssa-forwprop.c:1259
Its due to REAL_CST@1
