[Bug middle-end/86940] False positive with -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86940
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC||msebor at gcc dot gnu.org
--- Comment #5 from Martin Sebor ---
(In reply to Aritz Erkiaga from comment #4)
GCC does have knowledge about many libc functions but rand() isn't one of them
(yet). It would be possible to add rand() to the list but it would only solve
this one test case (i.e., involving rand()). I don't think adding a built-in
just to avoid a -Wuninitialized in this case is worth it. There may be other
reasons to add it, such as constraining its return value to [0, RAND_MAX]. If
you can make a more compelling case for it there's a decent chance that it will
be added.
Barring that, the test case reduces to:
$ cat pr86940.c && gcc -O2 -S -Wall pr86940.c
int f (void);
void g (void)
{
void *p;
if (f ())
p = __builtin_malloc (8);
if (f ())
__builtin_free (p);
}
pr86940.c: In function ‘g’:
pr86940.c:10:5: warning: ‘p’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
__builtin_free (p);
^~
[Bug lto/50676] Partitioning may fail with presence of static variables referring to function labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676 --- Comment #7 from Eric Gallager --- (In reply to Andi Kleen from comment #6) > The patch doesn't seem to be checked in yet. Is there a reason for that? Maybe people just forgot about it?
[Bug c++/86943] New: [8 Regression] Wrong code when converting stateless generic lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
Bug ID: 86943
Summary: [8 Regression] Wrong code when converting stateless
generic lambda to function pointer
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oremanj at mit dot edu
Target Milestone: ---
When creating a function pointer from a stateless generic lambda that accepts
the argument of generic type by value, gcc 8+ on x86_64 generates wrong code,
invoking a move constructor on a pointer-to-pointer to the moved-from object
rather than just a pointer to it. This occurs regardless of optimizations as
far as I can tell.
$ cat t.cc
extern "C" int printf(const char *fmt, ...);
struct nontrivial
{
nontrivial() { printf("default-construct %p\n", this); }
nontrivial(const nontrivial& other)
{ printf("copy-construct %p from %p\n", this, &other); }
nontrivial(nontrivial&& other) noexcept
{ printf("move-construct %p from %p\n", this, &other); }
~nontrivial()
{ printf("destroy %p\n", this); }
};
using cb_t = void(*)(nontrivial);
cb_t test()
{
return [](auto val) { printf("called %p\n", &val); };
}
int main()
{
volatile cb_t cb = test();
cb({});
return 0;
}
$ g++-7 -o t.ok t.cc -std=c++14
$ ./t.ok
default-construct 0x7ffc6cf08b0f
move-construct 0x7ffc6cf08adf from 0x7ffc6cf08b0f
called 0x7ffc6cf08adf
destroy 0x7ffc6cf08adf
destroy 0x7ffc6cf08b0f
$ g++-8 -o t.fail t.cc -std=c++14
$ ./t.fail
default-construct 0x7fffd8a636ff
move-construct 0x7fffd8a636c7 from 0x7fffd8a636c8
called 0x7fffd8a636c7
destroy 0x7fffd8a636c7
destroy 0x7fffd8a636ff
In the second example, the object is move-constructed from an address at which
no object has been constructed. Examining in a debugger, 0x7fffd8a636c8
contains the address 0x7fffd8a636ff, i.e., there is one level of indirection
too many.
Tested with godbolt.org, bug is absent on 7.1.0, 7.2.0, 7.3.0, and present on
8.1.0, 8.2.0, and 9.0.0 20180812.
[Bug c++/86942] New: A trailing-return-type is allowed when the return type is not 'auto' for using declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86942
Bug ID: 86942
Summary: A trailing-return-type is allowed when the return type
is not 'auto' for using declarations
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
void test() -> void; // fail => ok
using function = void() -> int; // allowed?!?
int f();
int main() {
function *Boo = f; // not ok; trailing return type is ignored
}
The above code fails to compile on the latest gcc trunk. It is invalid as a
trailing-return-type can only appear if the return type of the function is
'auto'.
No arguments to g++ necessary. Online demo: https://godbolt.org/g/XtSw6T
[Bug c++/65043] Expected narrowing conversion during list initialization of bool from double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65043 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57891 Marek Polacek changed: What|Removed |Added Keywords||accepts-invalid Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Marek Polacek --- Fixed for GCC 9.
[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57891
--- Comment #11 from Marek Polacek ---
Author: mpolacek
Date: Mon Aug 13 23:12:11 2018
New Revision: 263523
URL: https://gcc.gnu.org/viewcvs?rev=263523&root=gcc&view=rev
Log:
PR c++/57891
* call.c (struct conversion): Add check_narrowing_const_only.
(build_converted_constant_expr): Set check_narrowing and
check_narrowing_const_only. Give error if expr is error node.
(convert_like_real): Pass it to check_narrowing.
* cp-tree.h (check_narrowing): Add a default parameter.
* decl.c (compute_array_index_type): Use input_location instead of
location_of.
* pt.c (convert_nontype_argument): Return NULL_TREE if tf_error.
* typeck2.c (check_narrowing): Don't warn for instantiation-dependent
expressions. Call maybe_constant_value instead of
fold_non_dependent_expr. Don't mention { } in diagnostic. Only check
narrowing for constants if CONST_ONLY.
* g++.dg/cpp0x/Wnarrowing6.C: New test.
* g++.dg/cpp0x/Wnarrowing7.C: New test.
* g++.dg/cpp0x/Wnarrowing8.C: New test.
* g++.dg/cpp0x/Wnarrowing9.C: New test.
* g++.dg/cpp0x/Wnarrowing10.C: New test.
* g++.dg/cpp0x/constexpr-47969.C: Adjust dg-error.
* g++.dg/cpp0x/constexpr-ex2.C: Likewise.
* g++.dg/cpp0x/constexpr-targ.C: Likewise.
* g++.dg/cpp0x/scoped_enum2.C: Likewise.
* g++.dg/ext/stmtexpr15.C: Likewise.
* g++.dg/gomp/pr47963.C: Likewise.
* g++.dg/init/new37.C: Likewise.
* g++.dg/init/new43.C: Likewise.
* g++.dg/other/fold1.C: Likewise.
* g++.dg/parse/array-size2.C: Likewise.
* g++.dg/template/dependent-name3.C: Likewise.
* g++.dg/cpp0x/constexpr-data2.C: Add dg-error.
* g++.dg/other/vrp1.C: Likewise.
* g++.dg/template/char1.C: Likewise.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing10.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing6.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing7.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing8.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-47969.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-data2.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ex2.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-targ.C
trunk/gcc/testsuite/g++.dg/cpp0x/scoped_enum2.C
trunk/gcc/testsuite/g++.dg/ext/stmtexpr15.C
trunk/gcc/testsuite/g++.dg/gomp/pr47963.C
trunk/gcc/testsuite/g++.dg/init/new37.C
trunk/gcc/testsuite/g++.dg/init/new43.C
trunk/gcc/testsuite/g++.dg/other/fold1.C
trunk/gcc/testsuite/g++.dg/other/vrp1.C
trunk/gcc/testsuite/g++.dg/parse/array-size2.C
trunk/gcc/testsuite/g++.dg/template/char1.C
trunk/gcc/testsuite/g++.dg/template/dependent-name3.C
[Bug debug/86941] New: ICE in i386/winnt.c:1258 in i386_pe_seh_unwind_emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86941
Bug ID: 86941
Summary: ICE in i386/winnt.c:1258 in i386_pe_seh_unwind_emit
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
The following code from the stack-trace-7.c testsuite case causes an ICE on
x86_64-w64-mingw32:
/* { dg-do run } */
/* { dg-options "-O2 -fstack-clash-protection -fno-optimize-sibling-calls
--param stack-clash-protection-probe-interval=12 --param
stack-clash-protection-guard-size=12" } */
/* { dg-require-effective-target supports_stack_clash_protection } */
/* For further testing, this can be run under valgrind where it's crashed
on aarch64 and ppc64le with -fstack-check=specific. */
__attribute__((noinline, noclone)) void
foo (char *p)
{
asm volatile ("" : : "r" (p) : "memory");
}
__attribute__((noinline, noclone)) void
bar (void)
{
char buf[131072];
foo (buf);
}
__attribute__((noinline, noclone)) void
baz (void)
{
char buf[12000];
foo (buf);
}
int
main ()
{
bar ();
baz ();
return 0;
}
stack-check-7.c:20:1: internal compiler error: in i386_pe_seh_unwind_emit, at
config/i386/winnt.c:1258
0x71157e i386_pe_seh_unwind_emit(_IO_FILE*, rtx_insn*)
../../../gccsvn/gcc/config/i386/winnt.c:1258
0x9e174a final_scan_insn_1
../../../gccsvn/gcc/final.c:3110
0x9e1c3b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../../gccsvn/gcc/final.c:3146
0x9e1f04 final_1
../../../gccsvn/gcc/final.c:2019
0x9e2c64 rest_of_handle_final
../../../gccsvn/gcc/final.c:4657
0x9e2c64 execute
../../../gccsvn/gcc/final.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/86940] False positive with -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86940 --- Comment #4 from Aritz Erkiaga --- Ok, then this is not a bug. Maybe a feature request? Well, actually I think it would be safe for the compiler to assume that libc (and possibly other external libraries) don't have access to variables defined in the source file being compiled. Of course, they could do whatever they like, but the possibility is not worth a warning, as I see it.
[Bug middle-end/86940] False positive with -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86940 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- (In reply to Aritz Erkiaga from comment #2) > I don't know. Somehow it does know it when the testcase is compiled without > any -O flags, but it not something trivial, and so I would not be surprised > if GCC were not able to get that information. Because without any -O option (aka -O0) GCC does not enable any flow based uninitilization checking.
[Bug middle-end/86940] False positive with -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86940 --- Comment #2 from Aritz Erkiaga --- I don't know. Somehow it does know it when the testcase is compiled without any -O flags, but it not something trivial, and so I would not be surprised if GCC were not able to get that information.
[Bug middle-end/86940] False positive with -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86940 --- Comment #1 from Andrew Pinski --- How does GCC know that rand does not change the global variable initialize? Or something else before main has changed it from 1 to 0?
[Bug middle-end/86940] New: False positive with -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86940 Bug ID: 86940 Summary: False positive with -Wuninitialized Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: aerkiaga6 at gmail dot com Target Milestone: --- Created attachment 44532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44532&action=edit Preprocessed source Compiling the code with the following command: gcc -v -save-temps -Wall -O test.c Gives this output: gcc -v -save-temps -Wall -O test.c Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-8.2.0/configure --enable-languages=c,c++ Thread model: posix gcc version 8.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-O' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu test.c -mtune=generic -march=x86-64 -Wall -O -fpch-preprocess -o test.i ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include /usr/local/include /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-O' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/cc1 -fpreprocessed test.i -quiet -dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -O -Wall -version -o test.s GNU C17 (GCC) version 8.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C17 (GCC) version 8.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 82490e2e2080530dcab0165c2e5082fa test.c: In function ‘main’: test.c:15:20: warning: ‘str’ may be used uninitialized in this function [-Wmaybe-uninitialized] if(initialize) free(str); ^ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-O' '-mtune=generic' '-march=x86-64' /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/as -v --64 -o test.o test.s GNU assembler version 2.31.1 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.31.1 COMPILER_PATH=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-O' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/collect2 -plugin /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/liblto_plugin.so -plugin-opt=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper -plugin-opt=-fresolution=test.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtbegin.o -L/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0 -L/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../.. test.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-O' '-mtune=generic' '-march=x86-64' GCC complains that 'str' may be uninitialized, which is not possible. Requirements for tri
[Bug sanitizer/86755] [ASAN] Libasan failed to be build for arm with -mthumb and -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86755 chefmax at gcc dot gnu.org changed: What|Removed |Added CC||chefmax at gcc dot gnu.org --- Comment #1 from chefmax at gcc dot gnu.org --- Upstream review: https://reviews.llvm.org/D50180
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 --- Comment #42 from Iain Sandoe --- (In reply to Elliot Saba from comment #41) > Has there been any progress on this? We are running into this while trying > to cross-compile GCC for Darwin. Has this been fixed in 8.3.0? I will be posting two patches (one just posted today) that are my proposed solution - basically, v2 above plus removing a target hook.
[Bug target/85904] [7/8 Regression] configure issue cross compiling on netbsd, with patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85904 --- Comment #13 from Jonathan Wakely --- Author: redi Date: Mon Aug 13 19:15:40 2018 New Revision: 263517 URL: https://gcc.gnu.org/viewcvs?rev=263517&root=gcc&view=rev Log: Revert "libstdc++-v3: Have aligned_alloc() on Newlib" This reverts commit r263462 / 61b760a78fdf9f5d87b0b626a61a3216bd1411fc because aligned_alloc is not defined for baremetal newlib targets, see https://gcc.gnu.org/ml/libstdc++/2018-08/msg00065.html Revert 2018-08-10 Sebastian Huber PR target/85904 * configure.ac: Define HAVE_ALIGNED_ALLOC if building for Newlib. * configure: Regenerate. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/configure branches/gcc-8-branch/libstdc++-v3/configure.ac
[Bug target/85904] [7/8 Regression] configure issue cross compiling on netbsd, with patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85904 --- Comment #14 from Jonathan Wakely --- Author: redi Date: Mon Aug 13 19:16:02 2018 New Revision: 263518 URL: https://gcc.gnu.org/viewcvs?rev=263518&root=gcc&view=rev Log: Revert "libstdc++-v3: Have aligned_alloc() on Newlib" This reverts commit r263463 / b7edd52337828cc46e469bca12f58288795b78d5 because aligned_alloc is not defined for baremetal newlib targets, see https://gcc.gnu.org/ml/libstdc++/2018-08/msg00065.html Revert 2018-08-10 Sebastian Huber PR target/85904 * configure.ac: Define HAVE_ALIGNED_ALLOC if building for Newlib. * configure: Regenerate. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/configure branches/gcc-7-branch/libstdc++-v3/configure.ac
[Bug rtl-optimization/86939] IRA incorrectly creates an interference between a pseudo register and a hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86939 Peter Bergner changed: What|Removed |Added CC||law at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #1 from Peter Bergner --- CC'ing Vlad and Jeff to make them aware of the issue, but I'll have a look at fixing this.
[Bug libstdc++/45093] Different definitions of _Rb_tree::{erase,_M_destroy_node} between C++98 and C++0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45093 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Mon Aug 13 18:54:43 2018 New Revision: 263516 URL: https://gcc.gnu.org/viewcvs?rev=263516&root=gcc&view=rev Log: PR libstdc++/45093 avoid warnings for _M_destroy_node PR libstdc++/45093 * include/bits/stl_tree.h (_Rb_tree::_M_destroy_node(_Link_type)): Combine definitions to avoid --detect-odr-violations warning. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_tree.h
[Bug target/85904] [7/8 Regression] configure issue cross compiling on netbsd, with patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85904 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Mon Aug 13 18:54:21 2018 New Revision: 263513 URL: https://gcc.gnu.org/viewcvs?rev=263513&root=gcc&view=rev Log: Revert "libstdc++-v3: Have aligned_alloc() on Newlib" This reverts commit r263461 / 2e920cd849b3cf0a72df4f172e27676a3e70b73f because aligned_alloc is not defined for baremetal newlib targets, see https://gcc.gnu.org/ml/libstdc++/2018-08/msg00065.html Revert 2018-08-10 Sebastian Huber PR target/85904 * configure.ac: Define HAVE_ALIGNED_ALLOC if building for Newlib. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac
[Bug rtl-optimization/86939] New: IRA incorrectly creates an interference between a pseudo register and a hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86939
Bug ID: 86939
Summary: IRA incorrectly creates an interference between a
pseudo register and a hard register
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
IRA incorrectly creates an interference between a pseudo register and a hard
register that should not interfere, leading to an extra register copy that is
not needed:
bergner@pike:~/gcc/BUGS$ cat bug.i
typedef long (*fptr_t) (void);
long
func (fptr_t *p)
{
if (p)
return (*p) ();
return 0;
}
bergner@pike:~/gcc/BUGS$
/home/bergner/gcc/build/gcc-fsf-mainline-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-debug/gcc -O2 -S bug.i
bergner@pike:~/gcc/BUGS$ cat bug.s
[snip]
ld 9,0(9)
std 2,24(1)
mtctr 9
mr 12,9
bctrl
The indirect call above requires r12 to be set before the bctrl, but we should
have just loaded its value directly into r12 instead of into r9. Looking at
the RTL during IRA, we have:
(insn 10 34 11 3 (set (reg/f:DI 125 [ *p_4(D) ])
(mem/f:DI (reg/v/f:DI 127 [orig:123 pD.2807 ] [123]) [1 *p_4(D)+0 S8
A64])) "bug.i":6 608 {*movdi_internal64}
(expr_list:REG_DEAD (reg/v/f:DI 127 [orig:123 pD.2807 ] [123])
(nil)))
(insn 11 10 12 3 (set (reg:DI 12 12)
(reg/f:DI 125 [ *p_4(D) ])) "bug.i":6 608 {*movdi_internal64}
(nil))
(call_insn 12 11 13 3 (parallel [
(set (reg:DI 3 3)
(call (mem:SI (reg/f:DI 125 [ *p_4(D) ]) [0 *_1 S4 A8])
(const_int 0 [0])))
(set (reg:DI 2 2)
(unspec:DI [
(const_int 24 [0x18])
] UNSPEC_TOCSLOT))
(clobber (reg:DI 65 lr))
]) "bug.i":6 691 {*call_value_indirect_elfv2di}
(expr_list:REG_DEAD (reg/f:DI 125 [ *p_4(D) ])
(expr_list:REG_DEAD (reg:DI 12 12)
(expr_list:REG_CALL_DECL (nil)
(nil
(expr_list (use (reg:DI 12 12))
(nil)))
(insn 13 12 31 3 (set (reg:DI 122 [ ])
(reg:DI 3 3)) "bug.i":6 608 {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 3 3)
(nil)))
(jump_insn 31 13 32 3 (set (pc)
(label_ref 18)) "bug.i":6 780 {jump}
(nil)
-> 18)
and:
Allocno a1r125 of GENERAL_REGS(29) has 28 avail. regs 0 3-11 14-31,
node: 0 3-11 14-31 (confl regs = 1 2 12 13 32-113)
Now pseudo 125 is live when r12 is defined, which is normally enough to make
two regs/pseudos interfere, but since they have the same value, an interference
should not be created between them. If we can stop the interference from being
generated, then we should get the allocation and code generated that we want.
[Bug tree-optimization/86829] Missing sin(atan(x)) and cos(atan(x)) optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86829 --- Comment #5 from Giuliano Belinassi --- I filed the copyright assignment request and sent it to the assign at gnu dot org. The patch itself I sent to the patch e-mail listing with the subject "patch to bug #86829".
[Bug tree-optimization/71625] missing strlen optimization on different array initialization style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625 --- Comment #17 from Martin Sebor --- Author: msebor Date: Mon Aug 13 17:57:51 2018 New Revision: 263511 URL: https://gcc.gnu.org/viewcvs?rev=263511&root=gcc&view=rev Log: PR tree-optimization/71625 - missing strlen optimization on different array initialization style gcc/c/ChangeLog: PR tree-optimization/71625 * c-parser.c (c_parser_declaration_or_fndef): Call braced_list_to_string. gcc/c-family/ChangeLog: PR tree-optimization/71625 * c-common.c (braced_list_to_string): New function. * c-common.h (braced_list_to_string): Declare it. gcc/cp/ChangeLog: PR tree-optimization/71625 * decl.c (check_initializer): Call braced_list_to_string. (eval_check_narrowing): New function. * gcc/cp/typeck2.c (digest_init_r): Accept strings literals as initilizers for all narrow character types. gcc/testsuite/ChangeLog: PR tree-optimization/71625 * g++.dg/init/string2.C: New test. * g++.dg/init/string3.C: New test. * g++.dg/init/string4.C: New test. * gcc.dg/init-string-3.c: New test. * gcc.dg/strlenopt-55.c: New test. * gcc.dg/strlenopt-56.c: New test. Added: trunk/gcc/testsuite/g++.dg/init/string2.C trunk/gcc/testsuite/g++.dg/init/string3.C trunk/gcc/testsuite/g++.dg/init/string4.C trunk/gcc/testsuite/gcc.dg/init-string-3.c trunk/gcc/testsuite/gcc.dg/strlenopt-55.c trunk/gcc/testsuite/gcc.dg/strlenopt-56.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c
[Bug rtl-optimization/85645] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645 --- Comment #18 from Segher Boessenkool --- Yes, and don't change resolution because something "seems".
[Bug target/86324] testsuite test divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86324 --- Comment #9 from Peter Bergner --- Author: bergner Date: Mon Aug 13 17:34:38 2018 New Revision: 263510 URL: https://gcc.gnu.org/viewcvs?rev=263510&root=gcc&view=rev Log: gcc/ Backport from mainline 2018-07-06 Peter Bergner PR target/86324 * target.def (translate_mode_attribute): New hook. * targhooks.h (default_translate_mode_attribute): Declare. * targhooks.c (default_translate_mode_attribute): New function. * doc/tm.texi.in (TARGET_TRANSLATE_MODE_ATTRIBUTE): New hook. * doc/tm.texi: Regenerate. * config/rs6000/rs6000.c (TARGET_TRANSLATE_MODE_ATTRIBUTE): Define. (rs6000_translate_mode_attribute): New function. gcc/c-family/ Backport from mainline 2018-07-06 Peter Bergner PR target/86324 * c-attribs.c (handle_mode_attribute): Call new translate_mode_attribute target hook. gcc/testsuite/ Backport from mainline 2018-07-06 Peter Bergner PR target/86324 gcc.target/powerpc/pr86324-1.c: New test. gcc.target/powerpc/pr86324-2.c: Likewise. Added: branches/ibm/gcc-8-branch/gcc/testsuite/ChangeLog.ibm branches/ibm/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86324-1.c branches/ibm/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr86324-2.c Modified: branches/ibm/gcc-8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-8-branch/gcc/c-family/ChangeLog.ibm branches/ibm/gcc-8-branch/gcc/c-family/c-attribs.c branches/ibm/gcc-8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-8-branch/gcc/doc/tm.texi branches/ibm/gcc-8-branch/gcc/doc/tm.texi.in branches/ibm/gcc-8-branch/gcc/target.def branches/ibm/gcc-8-branch/gcc/targhooks.c branches/ibm/gcc-8-branch/gcc/targhooks.h
[Bug rtl-optimization/85645] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645 Arseny Solokha changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Arseny Solokha --- Seems to be finally fixed for all active branches by the recent Segher's backport.
[Bug middle-end/65855] SCEV / SCCP missing optimization: triangular numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855 Andrew Pinski changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 86923 has been marked as a duplicate of this bug. ***
[Bug c/86923] Missed optimization performing consecutive integer sum, loop not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86923 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- (In reply to jos...@codesourcery.com from comment #1) > Isn't this bug 65855? Yes *** This bug has been marked as a duplicate of bug 65855 ***
[Bug middle-end/86757] [og8,nvptx] gangprivate related regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86757 jules at gcc dot gnu.org changed: What|Removed |Added CC||jules at gcc dot gnu.org --- Comment #1 from jules at gcc dot gnu.org --- I believe this is fixed in the patch posted upstream: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00749.html
[Bug c/86923] Missed optimization performing consecutive integer sum, loop not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86923 --- Comment #1 from joseph at codesourcery dot com --- Isn't this bug 65855?
[Bug target/85644] [8/9 Regression] -fstack-protector generates invalid read to %fs:0x0 on mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85644 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- Some of the dups of this mentioned thread-local storage (TLS), in which case bug 29838 and bug 52268 might be related
[Bug rtl-optimization/85645] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645 --- Comment #16 from Segher Boessenkool --- Author: segher Date: Mon Aug 13 17:05:48 2018 New Revision: 263509 URL: https://gcc.gnu.org/viewcvs?rev=263509&root=gcc&view=rev Log: Backport from mainline 2018-05-09 Segher Boessenkool PR rtl-optimization/85645 * regrename.c (build_def_use): Also kill the chains that include the destination of a REG_CFA_REGISTER note. PR rtl-optimization/85645 * regcprop.c (copyprop_hardreg_forward_1): Don't propagate into an insn that has a REG_CFA_REGISTER note. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/regcprop.c branches/gcc-7-branch/gcc/regrename.c
[Bug target/86938] Invalid register name for r8w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86938 --- Comment #1 from Andrew Pinski --- The rNd, rNw, and rNb aliases for rN (r8-r15) are not currently supported as far as I can tell. Use r8 instead.
[Bug c/86938] New: Invalid register name for r8w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86938
Bug ID: 86938
Summary: Invalid register name for r8w
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: quasicoherent at protonmail dot com
Target Milestone: ---
Created attachment 44531
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44531&action=edit
-save-temps output
When compiling the following code:
#include
int main() {
register unsigned short var __asm__("r8w") = 0;
__asm__ volatile (
"mov $123, %[var]\t\n"
: [var] "+rm" (var)
);
printf("%d\n", var);
return 0;
}
with
gcc -Wall -Wextra bug.c
I get the error:
bug.c: In function ‘main’:
bug.c:4:26: error: invalid register name for ‘var’
register unsigned short var __asm__("r8w") = 0;
^~~
If "r8w" is replaced by, for example, "ax" the compilation works and the
resulting program outputs "123\n", as desired.
gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-16ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --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-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
[Bug c++/86931] constexpr variable initialization: internal compiler error: in reshape_init_r, at cp/decl.c:6042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86931 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #2 from Marek Polacek --- commit cf72f34dc248e4dea971f08dc370b07c9d7601e5 Author: jason Date: Mon Oct 27 17:42:12 2014 + Implement N3653 (Member initializers and aggregates) and fix references to 'this' in constexpr constructors. * class.c (check_field_decls): In C++14 an NSDMI does not make the class non-aggregate. * constexpr.c (struct constexpr_ctx): New. (cxx_bind_parameters_in_call): Handle 'this'. (cxx_eval_call_expression): Create new constexpr_ctx. (cxx_eval_component_reference): Check CONSTRUCTOR_NO_IMPLICIT_ZERO. (initialized_type, init_subob_ctx, verify_ctor_sanity): New. (cxx_eval_bare_aggregate): Use them. Build CONSTRUCTOR early. (cxx_eval_vec_init_1): Likewise. (cxx_eval_constant_expression) [PARM_DECL]: Allow 'this'. [TARGET_EXPR]: Build new constexpr_ctx. [PLACEHOLDER_EXPR]: New. (cxx_eval_outermost_constant_expr): Build new constexpr_ctx. Add object parameter. (is_sub_constant_expr): Build new constexpr_ctx. (potential_constant_expression_1): Handle PLACEHOLDER_EXPR. Allow 'this'. * cp-gimplify.c (cp_gimplify_init_expr): Call replace_placeholders. * cp-tree.h (CONSTRUCTOR_NO_IMPLICIT_ZERO): New. * error.c (dump_expr): Handle PLACEHOLDER_EXPR. * init.c (get_nsdmi): Generate PLACEHOLDER_EXPR. * tree.c (lvalue_kind): Handle PLACEHOLDER_EXPR. (build_ctor_subob_ref, replace_placeholders): New. * typeck2.c (store_init_value): Use replace_placeholders. (process_init_constructor_record): Make zero-init before NSDMI explicit. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216750 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/86324] testsuite test divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86324 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.3 |9.0 --- Comment #8 from Peter Bergner --- Ok, so we seemed to have missed the window for getting IEEE128 into GCC 8, so unless some distro decides later on, that they want IEEE128 in GCC 8, I'm going to skip backporting this and just leave it on trunk. I will backport this to the IBM GCC 8 branch though.
[Bug c++/86931] constexpr variable initialization: internal compiler error: in reshape_init_r, at cp/decl.c:6042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86931 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-13 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/86745] [9 regression] gcc.target/i386/avx-cvt-2.c etc. FAIL on 64-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86745 Andrey Guskov changed: What|Removed |Added CC||andrey.y.guskov at intel dot com --- Comment #2 from Andrey Guskov --- Confirmed on Haswell. The guilty revision is r263067.
[Bug c++/86915] Segmentation fault for an array of auto in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86915 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/86915] Segmentation fault for an array of auto in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86915 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Mon Aug 13 15:36:30 2018 New Revision: 263507 URL: https://gcc.gnu.org/viewcvs?rev=263507&root=gcc&view=rev Log: PR c++/86915 * decl.c (create_array_type_for_decl): Handle null name. * g++.dg/diagnostic/auto1.C: New test. Added: trunk/gcc/testsuite/g++.dg/diagnostic/auto1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/86937] strnlen() of a conditional expression with constant operands not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86937 Martin Sebor changed: What|Removed |Added Keywords||diagnostic, ||missed-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86936 Blocks||83819 --- Comment #1 from Martin Sebor --- See also pr86936 for a similar issue. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/86937] New: strnlen() of a conditional expression with constant operands not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86937
Bug ID: 86937
Summary: strnlen() of a conditional expression with constant
operands not folded
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC folds the strlen() call below with a conditional expression involving
constant operands but it fails to do the same for the equivalent strnlen()
call.
Besides missing this optimization opportunity it also prevents it from
diagnosing strnlen() calls with unterminated character arrays where the bound
is greater than the size of the array.
$ cat f.c && gcc -O2 -S -Wall -Wextra -Wnull-dereference
-fdump-tree-optimized=/dev/stdout f.c
const char a[4] = "123";
int f (int i)
{
return __builtin_strlen (i ? a : "");
}
int g (int i)
{
return __builtin_strnlen (i ? a : "", 4);
}
;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=1)
Removing basic block 3
f (int i)
{
int prephitmp_7;
[local count: 1073741825]:
if (i_3(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
[local count: 1073741825]:
# prephitmp_7 = PHI <3(2), i_3(D)(3)>
return prephitmp_7;
}
;; Function g (g, funcdef_no=1, decl_uid=1909, cgraph_uid=2, symbol_order=2)
Removing basic block 3
g (int i)
{
long unsigned int _1;
const char * iftmp.1_2;
int _5;
[local count: 1073741825]:
if (i_3(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
[local count: 1073741825]:
# iftmp.1_2 = PHI <&a(2), ""(3)>
_1 = __builtin_strnlen (iftmp.1_2, 4);
_5 = (int) _1;
return _5;
}
[Bug tree-optimization/86936] strnlen() of a constant not folded due to laddress transformation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86936 Martin Sebor changed: What|Removed |Added Summary|strlen() of a constant not |strnlen() of a constant not |folded due to laddress |folded due to laddress |transformation |transformation --- Comment #2 from Martin Sebor --- This is about strnlen (strlen is folded early on).
[Bug tree-optimization/86936] strlen() of a constant not folded due to laddress transformation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86936
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic,
||missed-optimization
--- Comment #1 from Martin Sebor ---
Besides missing out on an optimization opportunity the transformation also
prevents diagnosing strlen() calls with such arguments where the second
argument is greater than the upper bound of the array. (Issuing the diagnostic
regardless would result in false positives if the referenced element was, in
fact, nul-terminated, as would be the case if a were defined like so: const
char a[][4] = { "12", "123", "1234" };)
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #9 from Andrey Guskov --- OK.
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #8 from Segher Boessenkool --- So is it worse code, better code, is the testcase broken / suboptimal? The haswell problem seems to be completely unrelated, so open a separate PR please.
[Bug tree-optimization/86936] New: strlen() of a constant not folded due to laddress transformation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86936
Bug ID: 86936
Summary: strlen() of a constant not folded due to laddress
transformation
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Despite the argument being a constant string, as a result of the laddress
transformation the call to strnlen() in the function below is not folded into a
constant because it loses the knowledge about which element of the array the
strnlen argument refers to.
$ cat f.c && gcc -O2 -S -Wall -Wextra -Wnull-dereference
-fdump-tree-bswap=/dev/stdout -fdump-tree-laddress=/dev/stdout f.c
const char a[][4] = { "123", "1234" };
int f (int i)
{
return __builtin_strnlen (&a[1][i], 4);
}
;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=1)
f (int i)
{
const char * _1;
long unsigned int _2;
int _5;
[local count: 1073741825]:
_1 = &a[1][i_3(D)];
_2 = __builtin_strnlen (_1, 4);
_5 = (int) _2;
return _5;
}
;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=1)
f (int i)
{
const char * _1;
long unsigned int _2;
int _5;
sizetype _6;
sizetype _7;
[local count: 1073741825]:
_6 = (sizetype) i_3(D);
_7 = _6 + 4;
_1 = &a + _7;
_2 = __builtin_strnlen (_1, 4);
_5 = (int) _2;
return _5;
}
[Bug target/85640] [8/9 Regression] Code size regression vs 7.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85640 --- Comment #3 from Alexander Monakov --- (first paragraph of previous comment had 'before'/'after' swapped, sorry) Also note that adjusting the testcase to use size_t rather than unsigned int for the 'len' variable (as production code probably should) avoids the issue: final value replacement doesn't need to special case len==0 then.
[Bug fortran/86935] Bad locus in ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86935
--- Comment #1 from janus at gcc dot gnu.org ---
The following is sufficient to tip the locus to the next line:
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 263503)
+++ gcc/fortran/match.c (working copy)
@@ -1888,6 +1888,8 @@ gfc_match_associate (void)
gfc_association_list* newAssoc = gfc_get_association_list ();
gfc_association_list* a;
+ gfc_gobble_whitespace ();
+
/* Match the next association. */
if (gfc_match (" %n => %e", newAssoc->name, &newAssoc->target)
!= MATCH_YES)
[Bug fortran/86935] New: Bad locus in ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86935 Bug ID: 86935 Summary: Bad locus in ASSOCIATE statement Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Test case (invalid code): implicit none type :: t real :: r = 0.5 integer :: i = 3 end type type(t) :: x associate (r => x%r, & i => x%ii) print *, r ,i end associate end gfortran says: associate (r => x%r, & 1 Error: Expected association at (1) The error message points to the wrong line (the first association is fine, but the second one is wrong).
[Bug c++/86499] lambda-expressions with capture-default are allowed at namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86499 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug libstdc++/86934] Feature test macros in should respect _GLIBCXX_HOSTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86934 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-13 Ever confirmed|0 |1
[Bug tree-optimization/86927] [8/9 Regression] Gcc miscompiles at -O3 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86927 --- Comment #3 from Martin Liška --- Then it ends in Richi's revision r249553. Sounds like culprit.
[Bug libstdc++/45093] Different definitions of _Rb_tree::{erase,_M_destroy_node} between C++98 and C++0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45093 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Jonathan Wakely --- The different definitions of erase have been mangled differently since GCC 4.8, by using the abi-tag. Gold still warns about _M_destroy_node, but that's harmless.
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 Andrey Guskov changed: What|Removed |Added CC||andrey.y.guskov at intel dot com --- Comment #7 from Andrey Guskov --- On Haswell, r263067 is also responsible for that: spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.target/i386/avx-cvt-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -mavx -mno-avx2 -mtune=generic -fdump-tree-vect-details -ffat-lto-objects -S -o avx-cvt-2.s PASS: gcc.target/i386/avx-cvt-2.c (test for excess errors) PASS: gcc.target/i386/avx-cvt-2.c scan-tree-dump-times vect "vectorized 1 loops in function" 6 PASS: gcc.target/i386/avx-cvt-2.c scan-assembler vcvttpd2dq(y[^\n\r]*%xmm|[^\n\r]*xmm[^\n\r]*YMMWORD PTR) PASS: gcc.target/i386/avx-cvt-2.c scan-assembler vcvtdq2ps[^\n\r]*ymm FAIL: gcc.target/i386/avx-cvt-2.c scan-assembler vcvtps2pd[^\n\r]*(%xmm[^\n\r]*%ymm|ymm[^\n\r]*xmm) Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=haswell --with-cpu=haswell
[Bug libstdc++/86934] New: Feature test macros in should respect _GLIBCXX_HOSTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86934 Bug ID: 86934 Summary: Feature test macros in should respect _GLIBCXX_HOSTED Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- The current header doesn't account for the fact that many features are not defined for freestanding builds. Also, the --enable-libstdcxx-filesystem-ts configure option means that isn't always present, even for hsoted builds (but that should change for GCC 9 anyway). I'm not sure how to do this cleanly so that is always consistent with the real values in other headers. We could generate from a script that processes the headers (separately for freestanding and hosted headers) and just extracts the __cpp_lib_* macros and the preprocessor conditions they depend on. Also, in https://gcc.gnu.org/ml/libstdc++/2018-07/msg00128.html I said: It would be nice if we had tests to check that every macro in matches the other definition of it (i.e. either both are defined to the same value, or neither is defined).
[Bug c++/86933] GCC fails to recognize specialization of variadic non-type template parameter declared with `auto`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86933 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-13 Ever confirmed|0 |1
[Bug target/85590] [nvptx, libgomp, openacc] Use cuda runtime fns to determine launch configuration in nvptx plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85590 --- Comment #1 from Tom de Vries --- Author: vries Date: Mon Aug 13 12:04:24 2018 New Revision: 263505 URL: https://gcc.gnu.org/viewcvs?rev=263505&root=gcc&view=rev Log: [nvptx] Use CUDA driver API to select default runtime launch geometry The CUDA driver API starting version 6.5 offers a set of runtime functions to calculate several occupancy-related measures, as a replacement for the occupancy calculator spreadsheet. This patch adds a heuristic for default runtime launch geometry, based on the new runtime function cuOccupancyMaxPotentialBlockSize. Build on x86_64 with nvptx accelerator and ran libgomp testsuite. 2018-08-13 Cesar Philippidis Tom de Vries PR target/85590 * plugin/cuda/cuda.h (CUoccupancyB2DSize): New typedef. (cuOccupancyMaxPotentialBlockSize): Declare. * plugin/cuda-lib.def (cuOccupancyMaxPotentialBlockSize): New CUDA_ONE_CALL_MAYBE_NULL. * plugin/plugin-nvptx.c (CUDA_VERSION < 6050): Define CUoccupancyB2DSize and declare cuOccupancyMaxPotentialBlockSize. (nvptx_exec): Use cuOccupancyMaxPotentialBlockSize to set the default num_gangs and num_workers when the driver supports it. Modified: trunk/libgomp/ChangeLog trunk/libgomp/plugin/cuda-lib.def trunk/libgomp/plugin/cuda/cuda.h trunk/libgomp/plugin/plugin-nvptx.c
[Bug c++/86933] New: GCC fails to recognize specialization of variadic non-type template parameter declared with `auto`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86933
Bug ID: 86933
Summary: GCC fails to recognize specialization of variadic
non-type template parameter declared with `auto`
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d25fe0be at outlook dot com
Target Milestone: ---
The following code fails to compile, saying `TT<&X::x, &X::y>` is not defined.
template struct TT;
template struct TT {};
struct X {
int x;
double y;
};
TT<&X::x, &X::y> t;
```
Not sure if related, the following code (reduced version) is rejected as well:
```
template struct TT;
template struct TT {};
int x;
double y;
TT<&x, &y> t;
```
clang (5.0 or higher) accepts both.
Live example: https://wandbox.org/permlink/ObPM2S5s0bsczNfk
[Bug tree-optimization/86927] [8/9 Regression] Gcc miscompiles at -O3 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86927 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- Martin, can you try bisecting with -fvect-cost-model=unlimited ? May be caused by vectorization, reduction created for 'c' looks wrong. gcc-7 did not try to vectorize this.
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846
--- Comment #7 from Jonathan Wakely ---
Ah, that patch assumes this is defined:
#ifdef __GTHREAD_MUTEX_INIT
__native_type _M_mutex = __GTHREAD_MUTEX_INIT;
constexpr __mutex_base() noexcept = default;
i.e. PTHREAD_MUTEX_INITIALIZER.
If that's not available we might just need to use a global mutex, without the
constant_init<> wrapper that makes the object immortal. In that case it will be
risky to use the default memory resource functions after static destructors
start (which is bad practice anyway).
So this would be a bit more robust:
--- a/libstdc++-v3/src/c++17/memory_resource.cc
+++ b/libstdc++-v3/src/c++17/memory_resource.cc
@@ -25,6 +25,10 @@
#include
#include
#include
+#if ATOMIC_POINTER_LOCK_FREE != 2
+# include // std::mutex, std::lock_guard
+# include // std::exchange
+#endif
namespace std _GLIBCXX_VISIBILITY(default)
{
@@ -81,7 +85,39 @@ namespace pmr
constant_init newdel_res{};
constant_init null_res{};
+#if ATOMIC_POINTER_LOCK_FREE == 2
constant_init> default_res{&newdel_res.obj};
+#else
+struct locking_atomic
+{
+#ifdef __GTHREAD_MUTEX_INIT
+ // std::mutex has constexpr constructor
+ constexpr
+#endif
+ locking_atomic(memory_resource* r) : val(r) { }
+ mutex mx;
+ memory_resource* val;
+
+ memory_resource* load()
+ {
+ lock_guard lock(mx);
+ return val;
+ }
+
+ memory_resource* exchange(memory_resource* r)
+ {
+ lock_guard lock(mx);
+ return std::exchange(val, r);
+ }
+};
+#ifdef __GTHREAD_MUTEX_INIT
+constant_init default_res{&newdel_res.obj};
+#else
+struct {
+ locking_atomic obj = &newdel_res.obj;
+} default_res __attribute__ ((init_priority (100)));
+#endif
+#endif
} // namespace
memory_resource*
Unfortunately this produces a warning for targets without pointer-width atomics
and without PTHREAD_MUTEX_INITIALIZER:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/memory_resource.cc:119:55:
warning: requested init_priority is reserved for internal use
} default_res __attribute__ ((init_priority (100)));
^
[Bug c++/86870] Declaration disambiguation is too greedy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86870 --- Comment #1 from Nicolas Lesser --- Oops, I missed to define a default constructor for `X`. This however, does not change the bug report and gcc still incorrectly parses the second statement as a declaration.
[Bug c++/86932] [8/9 Regression] Empty non-type template parameter pack not considered for SFINAE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86932
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||7.3.0
Keywords||accepts-invalid
Last reconfirmed||2018-08-13
CC||jason at gcc dot gnu.org
Ever confirmed|0 |1
Summary|[8 Regression] Empty|[8/9 Regression] Empty
|non-type template parameter |non-type template parameter
|pack not considered for |pack not considered for
|SFINAE. |SFINAE.
Known to fail||8.2.0, 9.0
--- Comment #2 from Jonathan Wakely ---
You've got a stray 'typename' there.
Reduced:
template struct enable_if { using type = T; };
template struct enable_if { };
template struct is_foo { static constexpr bool value = false; };
template::value, int>::type...>
void f() {}
int main()
{
f();
}
Started to be accepted with r247842
PR c++/79549 - C++17 ICE with non-type auto template parameter pack
* pt.c (convert_template_argument): Just return an argument pack.
(coerce_template_parameter_pack, template_parm_to_arg)
(extract_fnparm_pack, make_argument_pack, tsubst_template_args)
(tsubst_decl, tsubst, type_unification_real, unify_pack_expansion):
Don't set the type of a NONTYPE_ARGUMENT_PACK.
* parser.c (make_char_string_pack, make_string_pack): Likewise.
[Bug tree-optimization/86889] s390x gcc build fails when configured with --disable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86889 Ilya Leoshkevich changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Ilya Leoshkevich --- Bisect points to: commit d19574debc50ff915c5d39c22a51cb0bc750e75d (HEAD, refs/bisect/bad) Author: rguenth Date: Fri May 18 11:54:37 2018 + 2018-05-18 Richard Biener * gimple-ssa-evrp.c (class evrp_folder): Add simplify_stmt_using_ranges method. (evrp_dom_walker::before_dom_children): Call it. * gcc.dg/tree-ssa/pr21559.c: Adjust. * gcc.dg/tree-ssa/pr45397.c: Likewise. * gcc.dg/tree-ssa/pr61839_1.c: Likewise. * gcc.dg/tree-ssa/pr61839_2.c: Likewise. * gcc.dg/tree-ssa/pr61839_4.c: Likewise. * gcc.dg/tree-ssa/vrp17.c: Likewise. * gcc.dg/tree-ssa/vrp18.c: Likewise. * gcc.dg/tree-ssa/vrp23.c: Likewise. * gcc.dg/tree-ssa/vrp24.c: Likewise. * gcc.dg/tree-ssa/vrp58.c: Likewise. * gcc.dg/vrp-min-max-1.c: Likewise. * gcc.dg/vrp-min-max-3.c: New testcase. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@260357 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/86932] [8 Regression] Empty non-type template parameter pack not considered for SFINAE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86932
--- Comment #1 from zennehoy ---
Sorry, I included the problematic void non-type template parameter pack.
The type of std::enable_if_t should be specified as something other than void,
e.g., int:
#include
template, int>...>
void f() {}
int main()
{
f();
}
[Bug c++/86921] do not remove input in bash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86921 --- Comment #2 from Jonathan Wakely --- If you're saying that data read from the terminal by std::cin cannot be "un-read" by typing backspace, that's correct. That is not a GCC bug, it's just how the OS works. In the default line-buffered mode, when you hit Enter the line is sent to the application. Typing backspace cannot undo that, the program has already read the data, and doesn't receive the backspace characters.
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
David Binderman changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #1 from David Binderman ---
Still going wrong. Here is another test case:
$ ~/gcc/results.263471.ubsan/bin/gcc -c -O2 bug456.c
../../trunk/gcc/poly-int.h:1941:12: runtime error: negation of
-9223372036854775808 cannot be represented in type 'long int'; cast to an
unsigned type to negate this value to itself
$ more bug456.c
int a;
long b;
void c() { b = -9223372036854775807L - 1 - a; }
$
[Bug c++/86932] New: [8 Regression] Empty non-type template parameter pack not considered for SFINAE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86932
Bug ID: 86932
Summary: [8 Regression] Empty non-type template parameter pack
not considered for SFINAE.
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zennehoy at gmail dot com
Target Milestone: ---
The following code incorrectly compiles under GCC 8.1/8.2, but fails (as
expected) with GCC 7.3 and other compilers:
#include
template>...>
void f() {}
int main()
{
f();
}
The originating stackoverflow discussion about this issue can be found here:
https://stackoverflow.com/q/51787713/694509
A working example can be found on godbolt:
https://godbolt.org/g/Rb46qQ
[Bug c++/86922] Invoking templated PTMF on subclass gives false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86922 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-13 Ever confirmed|0 |1
[Bug c++/86930] g++ incorrectly complains about incomplete type in structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86930 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-13 Ever confirmed|0 |1
[Bug c++/86931] New: constexpr variable initialization: internal compiler error: in reshape_init_r, at cp/decl.c:6042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86931
Bug ID: 86931
Summary: constexpr variable initialization: internal compiler
error: in reshape_init_r, at cp/decl.c:6042
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janniksilvanus at gmail dot com
Target Milestone: ---
: g++ --version
g++ (SUSE Linux) 8.1.1 20180719 [gcc-8-branch revision 262874]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
: cat internal_compiler_error.ii
template
struct Array {
T data[2];
};
template
void test(
Applier const &)
{
auto constexpr data = Array{0, 0};
}
void instantiate()
{
test([](){});
}
: g++ --std=c++1z internal_compiler_error.ii -c
internal_compiler_error.ii: In instantiation of ‘void test(const Applier&)
[with Applier = instantiate()::]’:
internal_compiler_error.ii:15:15: required from here
internal_compiler_error.ii:10:19: internal compiler error: in reshape_init_r,
at cp/decl.c:6152
auto constexpr data = Array{0, 0};
^~~~
Note the similarity with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86930,
may be related.
[Bug c++/86930] New: g++ incorrectly complains about incomplete type in structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86930
Bug ID: 86930
Summary: g++ incorrectly complains about incomplete type in
structured binding
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janniksilvanus at gmail dot com
Target Milestone: ---
: g++ --version
g++ (SUSE Linux) 8.1.1 20180719 [gcc-8-branch revision 262874]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
: cat incomplete_type.ii
template
struct IndexPair {
Index first;
Index second;
};
using UsedIndexPair = IndexPair;
template
void call_applier(
UsedIndexPair const & indices,
Applier && applier)
{
auto const [a, b] = indices;
applier(a, b);
}
void instantiate()
{
call_applier(
{0, 1},
[&](int, int){});
}
: g++ --std=c++1z incomplete_type.ii -c
incomplete_type.ii: In function ‘void call_applier(const UsedIndexPair&,
Applier&&)’:
incomplete_type.ii:14:15: warning: structured binding refers to incomplete
class type ‘const IndexPair’
auto const [a, b] = indices;
gcc-7.3.1 even crashes on this input:
/opt/rh/devtoolset-7/root/usr/bin/g++ --std=c++1z incomplete_type.ii -c
incomplete_type.ii: In function ‘void call_applier(const UsedIndexPair&,
Applier&&)’:
incomplete_type.ii:14:24: internal compiler error: Segmentation fault
auto const [a, b] = indices;
^~~
[Bug tree-optimization/86925] ice in get_predictor_value, at predict.c:2551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86925 Martin Liška changed: What|Removed |Added Component|c |tree-optimization Version|8.0 |9.0 Target Milestone|--- |9.0
[Bug tree-optimization/86927] [8/9 Regression] Gcc miscompiles at -O3 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86927 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||7.3.0 Version|unknown |8.2.0 Keywords||wrong-code Last reconfirmed||2018-08-13 CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|Gcc miscompiles at -O3 on |[8/9 Regression] Gcc |valid code |miscompiles at -O3 on valid ||code Target Milestone|--- |8.3 Known to fail||8.2.0, 9.0 --- Comment #1 from Martin Liška --- I see it starting from r255268, but it's probably a latent issue.
