[Bug tree-optimization/96665] [11 regression] new FAILs for gcc.dg/strlenopt-55.c after r11-2709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96665 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-08-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #1 from Martin Liška --- @seurer: Please add author of the revision to CC next time.
[Bug tree-optimization/96058] ICE in c_getstr at gcc/fold-const.c:15475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96058 --- Comment #18 from Martin Liška --- *thanks for reminder
[Bug lto/45375] [meta-bug] Issues with building Mozilla (i.e. Firefox) with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Bug 45375 depends on bug 96058, which changed state. Bug 96058 Summary: ICE in c_getstr at gcc/fold-const.c:15475 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96058 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96058] ICE in c_getstr at gcc/fold-const.c:15475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96058 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Martin Liška --- (In reply to Arseny Solokha from comment #16) > Is there any work pending? No, that's for reminder.
[Bug tree-optimization/96669] New: Failure to optimize left shift+and to test for 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96669
Bug ID: 96669
Summary: Failure to optimize left shift+and to test for 0
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x)
{
return (1 << x) & 1;
}
This can be converted to `return x == 0;`. This transformation is done by LLVM,
but not by GCC.
[Bug tree-optimization/96669] Failure to optimize shift by variable+and by 1 to test for 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96669 --- Comment #1 from Gabriel Ravier --- PS: This can also be done when the shift is a right shift instead of a left shift (i.e. `1 >> x` is used instead of `1 << x`)
[Bug tree-optimization/96670] New: [11 Regression] ICE in tree_to_uhwi, at tree.c:7361 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96670
Bug ID: 96670
Summary: [11 Regression] ICE in tree_to_uhwi, at tree.c:7361
since r11-2709-g866626efd749ed3e
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
The following is causing ICE:
$ cat memchr.c
struct {
int n;
short a;
} const sx = {};
void
test_not_find() {
int nb = (char *)&sx.a - (char *)&sx;
char *p = (char *)&sx;
__builtin_memchr(p, 5, nb);
}
$ gcc memchr.c -Os -fno-tree-ccp -c
during GIMPLE pass: forwprop
memchr.c: In function ‘test_not_find’:
memchr.c:12:1: internal compiler error: in tree_to_uhwi, at tree.c:7361
12 | }
| ^
0x72c3b3 tree_to_uhwi(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.c:7361
0x72c3b3 tree_to_uhwi(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.c:7359
0xacad32 gimple_fold_builtin_memchr
/home/marxin/Programming/gcc/gcc/gimple-fold.c:2678
0xad7f8b gimple_fold_builtin
/home/marxin/Programming/gcc/gcc/gimple-fold.c:4018
0xad7f8b gimple_fold_call
/home/marxin/Programming/gcc/gcc/gimple-fold.c:4531
0xad8d03 fold_stmt_1
/home/marxin/Programming/gcc/gcc/gimple-fold.c:5232
0xea600c execute
/home/marxin/Programming/gcc/gcc/tree-ssa-forwprop.c:3103
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/96671] New: Failure to optimize a 3 xor+and pattern to xor + andnot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96671 Bug ID: 96671 Summary: Failure to optimize a 3 xor+and pattern to xor + andnot Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: gabravier at gmail dot com Target Milestone: ---
[Bug tree-optimization/96671] Failure to optimize a 3 xor+and pattern to xor+andnot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96671
Gabriel Ravier changed:
What|Removed |Added
Keywords||missed-optimization
Summary|Failure to optimize a 3 |Failure to optimize a 3
|xor+and pattern to xor +|xor+and pattern to
|andnot |xor+andnot
--- Comment #1 from Gabriel Ravier ---
Oops, I accidentally pressed enter and filed this with no details. Here are the
details :
int f(int a, int b, int c)
{
return (a ^ b) & ((b ^ c) ^ a);
}
This can be optimized to `return (a ^ b) & ~c`. This transformation is done by
LLVM, but not by GCC.
[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 --- Comment #11 from Iain Sandoe --- (In reply to Thomas Koenig from comment #10) > Since there is no other viable Fortran compiler on iOS, AFAIK, iOS has not been supported by GCC since Apple gcc-4.2.1 and the Apple releases didn't have gfortran. this applies to the shift of macOS to arm64. (although, ironically, supporting arm64 GCC on macOS would bring support to iOS too). > this means that packages like R, numpy and anything else will not > work on the new hardware. > > I guess the advice will just have to be: Do not buy any new-style > Macs if you plan to do any scientific work at all until this has > been resolved. https://github.com/iains/gcc-darwin-arm64#readme .. but a volunteer effort and vying for time with every other bug / enhancement.
[Bug c++/96645] [9/10/11 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #5 from Sergey --- (In reply to Jonathan Wakely from comment #4) > And libc++'s std::variant is still affected by the same issue, but instead > of the default constructor being deleted it just has the wrong exception > specification: > Should I report the issue in clang bugtracker?
[Bug d/96301] d: internal compiler error: Segmentation fault during RTL pass: expand on armhf/armel/s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96301 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:6bebbc033d8bf2246745ffef7186b0424e08ba6b commit r11-2734-g6bebbc033d8bf2246745ffef7186b0424e08ba6b Author: Iain Buclaw Date: Fri Jul 24 13:49:37 2020 +0200 d: Fix ICE Segmentation fault during RTL pass: expand on armhf/armel/s390x gcc/d/ChangeLog: PR d/96301 * decl.cc (DeclVisitor::visit (FuncDeclaration *)): Only return non-trivial structs by invisible reference. gcc/testsuite/ChangeLog: PR d/96301 * gdc.dg/pr96301a.d: New test. * gdc.dg/pr96301b.d: New test. * gdc.dg/pr96301c.d: New test.
[Bug d/96301] d: internal compiler error: Segmentation fault during RTL pass: expand on armhf/armel/s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96301 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:412068819b463751ef476183077638b3429213de commit r10-8637-g412068819b463751ef476183077638b3429213de Author: Iain Buclaw Date: Fri Jul 24 13:49:37 2020 +0200 d: Fix ICE Segmentation fault during RTL pass: expand on armhf/armel/s390x gcc/d/ChangeLog: PR d/96301 * decl.cc (DeclVisitor::visit (FuncDeclaration *)): Only return non-trivial structs by invisible reference. gcc/testsuite/ChangeLog: PR d/96301 * gdc.dg/pr96301a.d: New test. * gdc.dg/pr96301b.d: New test. * gdc.dg/pr96301c.d: New test. (cherry picked from commit 6bebbc033d8bf2246745ffef7186b0424e08ba6b)
[Bug d/96301] d: internal compiler error: Segmentation fault during RTL pass: expand on armhf/armel/s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96301 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Buclaw --- Done.
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 --- Comment #7 from Hongtao.liu --- (In reply to Hongtao.liu from comment #5) > (In reply to Uroš Bizjak from comment #4) > > Created attachment 49060 [details] > > Proposed patch > > > > Attached patch completely rewrites restore_stack_nonlocal expander. > > > > Can someone please test the patch on a CET enabled target? > > I can help with this, we have CET enabled tigerlake. Bootstrap is ok, regression test for i386/x86-64 backend is ok. (our cet-enabled tigerlake is pre-alpha version, test ran very slowly.)
[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668 Tobias Burnus changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- (In reply to Tobias Burnus from comment #0) > ! pointer: allegedly target is automatically mapped > ! without requiring an explicit mapping or even the always modifier > !$omp target !! map(always, tofrom: p1, p2, q1, q2) Namely: "If a list item in a map clause is an associated pointer and the pointer is not the base pointer of another list item in a map clause on the same construct, then it is treated as if its pointer target is implicitly mapped in the same clause. For the purposes of the map clause, the mapped pointer target is treated as if its base pointer is the associated pointer."
[Bug tree-optimization/96672] New: Missing -Wclobbered diagnostic, or: __attribute__((returns_twice)) does not inhibit constant folding across call site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96672 Bug ID: 96672 Summary: Missing -Wclobbered diagnostic, or: __attribute__((returns_twice)) does not inhibit constant folding across call site Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: felix.von.s at posteo dot de Target Milestone: --- Created attachment 49072 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49072&action=edit Sample program The attached sample, compiled with -O3 -DVOLATILE= outputs 5; without either flag it outputs 6. I expected at least one of the following: - that the compiler warn about the clobbered x variable at the return statement; - that the program output 6 whether or not x is declared volatile. Currently neither is the case; compiling with -Wall -Wextra -Wclobbered emits no warnings. While the standard mandates that the variable be declared volatile, GCC seems to make some effort to preserve the expected semantics even when this requirement is not met; this would seem like a missed case.
[Bug c++/83445] conversion function has too high priority in overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83445 --- Comment #2 from Jonathan Wakely --- Invoking Target(Source const&) is a user-defined conversion too. The conversion sequence requires binding a reference to the Source object and then converting it to a Target. In C++17 there is no call to Target(Target const&) or Target(Target&&) because the temporary returned by Source::operator Target() is materialized directly into an object of type Target. Clang agrees with GCC that Source::operator Target() is a better conversion, but I can't find the wording specifying that.
[Bug c++/96673] New: Friend class with templates and default constructor not recognized in C++14 or later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96673
Bug ID: 96673
Summary: Friend class with templates and default constructor
not recognized in C++14 or later
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andebjor at gmail dot com
Target Milestone: ---
This code fails when compiled as C++14 or C++17 with the error message "error:
'C::C(A&) [with T = int]' is private within this context".
---8<---
template
class A {};
template
class B;
template
class C {
private:
friend class B;
explicit C(A&) {};
};
template
class B {
public:
B() = default;
//B() {}; // << This implementation of the constructor makes it work
A a = {};
C c = C{a};
};
int main() {
auto b = B{};
auto &c = b.c;
}
--->8---
Compiler explorer link: https://godbolt.org/z/4ofMdM
This code builds with `clang` but fails with most versions of GCC.
* Version 4.9 works
* Version 5.x: internal compiler error
* Version 6.x up until trunk version: "C::C(A&) [with T = int]' is
private within this context"
There are several ways to make the code build:
* Removing templating. Without templates the error about the constructor being
private does not appear.
* Changing the constructor of `B` from `B() = default;` to `B() {};`
* Building with C++11.
[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668 --- Comment #2 from Chung-Lin Tang --- Note that what I'm working on at the moment does not include the Fortran parts, and this particular feature appears to be more suitable to be implemented within the Fortran FE, I think.
[Bug tree-optimization/96674] New: Failure to optimize combination of comparisons to dec+compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
Bug ID: 96674
Summary: Failure to optimize combination of comparisons to
dec+compare
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(unsigned a, unsigned b)
{
return (b == 0) | (a < b);
}
This can be optimized to `return a <= (b - 1);`. This transformation is done by
LLVM, but not by GCC.
[Bug c++/96675] New: tautological-compare warning emitted for NTTP bitwise comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96675
Bug ID: 96675
Summary: tautological-compare warning emitted for NTTP bitwise
comparison
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
template
constexpr bool f(char d) {
return 'a' <= c && c <= 'z' ? (d | 0x20) == c :
'A' <= c && c <= 'Z' ? (d & ~0x20) == c :
d == c;
}
static_assert(f<'p'>('P'));
In instantiation of 'constexpr bool f(char) [with char c = 'p']':
:7:21: required from here
:4:44: warning: bitwise comparison always evaluates to false
[-Wtautological-compare]
4 | 'A' <= c && c <= 'Z' ? (d & ~0x20) == c :
|^~~~
Per godbolt, this happened somewhere between 10.1.0 and 10.2.0.
Motivation is
https://github.com/capnproto/capnproto/commit/c38629e5a4b8ce9561b81cb23ea5fc39cbd93eb7
[Bug c++/96676] New: Segmentation fault on parsing simple variadic template function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96676
Bug ID: 96676
Summary: Segmentation fault on parsing simple variadic template
function call
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ivan.leonov.d at yandex dot ru
Target Milestone: ---
Sample code:
template < typename T, typename... TYPES >
struct A {
template < TYPES... types >
void Get() { }
};
void f() {}
int main() {
A a;
a.Get<&f>();
}
Error and Backtrace:
prog.cc: In function 'int main()':
prog.cc:13:15: internal compiler error: Segmentation fault
13 | a.Get<&f>();
| ^
0xc026af crash_signal
../../source/gcc/toplev.c:327
0x73a995 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:12871
0x7356d1 coerce_template_parameter_pack
../../source/gcc/cp/pt.c:8538
0x7356d1 coerce_template_parms
../../source/gcc/cp/pt.c:8830
0x747bc8 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../source/gcc/cp/pt.c:21078
0x619282 add_template_candidate_real
../../source/gcc/cp/call.c:3417
0x6199bc add_template_candidate
../../source/gcc/cp/call.c:3502
0x6199bc add_candidates
../../source/gcc/cp/call.c:5883
0x61a9cc add_candidates
../../source/gcc/cp/call.c:5798
0x61a9cc build_new_method_call_1
../../source/gcc/cp/call.c:10271
0x61b6ff build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../source/gcc/cp/call.c:10478
0x6fcdd7 cp_parser_postfix_expression
../../source/gcc/cp/parser.c:7513
0x6dfa9a cp_parser_binary_expression
../../source/gcc/cp/parser.c:9641
0x6e13de cp_parser_assignment_expression
../../source/gcc/cp/parser.c:9946
0x6e16e2 cp_parser_expression
../../source/gcc/cp/parser.c:10114
0x6e41b8 cp_parser_expression_statement
../../source/gcc/cp/parser.c:11774
0x6eef10 cp_parser_statement
../../source/gcc/cp/parser.c:11570
0x6f076d cp_parser_statement_seq_opt
../../source/gcc/cp/parser.c:11921
0x6f0820 cp_parser_compound_statement
../../source/gcc/cp/parser.c:11871
0x7078da cp_parser_function_body
../../source/gcc/cp/parser.c:23170
[Bug c++/96676] Segmentation fault on parsing simple variadic template function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96676 --- Comment #1 from Ivan Leonov --- Output of gcc -v: Using built-in specs. COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++ COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head --enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls --enable-lto LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32 Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20200816 (experimental) (GCC) COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-I' '/opt/wandbox/boost-sml/include' '-I' '/opt/wandbox/boost-di/include' '-I' '/opt/wandbox/range-v3/include' '-I' '/opt/wandbox/nlohmann-json/include' '-I' '/opt/wandbox/cmcstl2/include' '-I' '/opt/wandbox/te/include' '-std=gnu++20' '-Wall' '-Wextra' '-I' '/opt/wandbox/boost-1.68.0/gcc-head/include' '-L/opt/wandbox/boost-1.68.0/gcc-head/lib' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus -quiet -v -I /opt/wandbox/boost-sml/include -I /opt/wandbox/boost-di/include -I /opt/wandbox/range-v3/include -I /opt/wandbox/nlohmann-json/include -I /opt/wandbox/cmcstl2/include -I /opt/wandbox/te/include -I /opt/wandbox/boost-1.68.0/gcc-head/include -imultiarch x86_64-linux-gnu -D_GNU_SOURCE prog.cc -quiet -dumpbase prog.cc -dumpbase-ext .cc -mtune=generic -march=x86-64 -Wall -Wextra -std=gnu++20 -version -o /tmp/ccDLpOFA.s GNU C++20 (GCC) version 11.0.0 20200816 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 11.0.0 20200816 (experimental), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/wandbox/boost-sml/include /opt/wandbox/boost-di/include /opt/wandbox/range-v3/include /opt/wandbox/nlohmann-json/include /opt/wandbox/cmcstl2/include /opt/wandbox/te/include /opt/wandbox/boost-1.68.0/gcc-head/include /opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0 /opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-pc-linux-gnu /opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward /opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include /opt/wandbox/gcc-head/include /opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++20 (GCC) version 11.0.0 20200816 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 11.0.0 20200816 (experimental), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3d112d3862b6c6b3c098fd9068684321
[Bug c++/96677] New: Compile error on valid code with variadic template function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96677
Bug ID: 96677
Summary: Compile error on valid code with variadic template
function call
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ivan.leonov.d at yandex dot ru
Target Milestone: ---
Sample code:
template < typename... TYPES >
struct A {
template < TYPES... types >
void Get() { }
};
void f() {}
int main() {
A a;
a.Get<&f>();
}
Error:
prog.cc: In function 'int main()':
prog.cc:13:15: error: no matching function for call to 'A::Get()'
13 | a.Get<&f>();
| ^
prog.cc:6:10: note: candidate: 'template void A::Get()
[with TYPES ...types = {types ...}; TYPES = {void (*)()}]'
6 | void Get() { }
| ^~~
Output of gcc -v:
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200816 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-I' '/opt/wandbox/boost-sml/include' '-I'
'/opt/wandbox/boost-di/include' '-I' '/opt/wandbox/range-v3/include' '-I'
'/opt/wandbox/nlohmann-json/include' '-I' '/opt/wandbox/cmcstl2/include' '-I'
'/opt/wandbox/te/include' '-std=gnu++20' '-Wall' '-Wextra' '-I'
'/opt/wandbox/boost-1.68.0/gcc-head/include'
'-L/opt/wandbox/boost-1.68.0/gcc-head/lib' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus -quiet -v
-I /opt/wandbox/boost-sml/include -I /opt/wandbox/boost-di/include -I
/opt/wandbox/range-v3/include -I /opt/wandbox/nlohmann-json/include -I
/opt/wandbox/cmcstl2/include -I /opt/wandbox/te/include -I
/opt/wandbox/boost-1.68.0/gcc-head/include -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE prog.cc -quiet -dumpbase prog.cc -dumpbase-ext .cc -mtune=generic
-march=x86-64 -Wall -Wextra -std=gnu++20 -version -o /tmp/ccDLpOFA.s
GNU C++20 (GCC) version 11.0.0 20200816 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20200816 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/wandbox/boost-sml/include
/opt/wandbox/boost-di/include
/opt/wandbox/range-v3/include
/opt/wandbox/nlohmann-json/include
/opt/wandbox/cmcstl2/include
/opt/wandbox/te/include
/opt/wandbox/boost-1.68.0/gcc-head/include
/opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0
/opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-pc-linux-gnu
/opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward
/opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include
/opt/wandbox/gcc-head/include
/opt/wandbox/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++20 (GCC) version 11.0.0 20200816 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20200816 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3d112d3862b6c6b3c098fd9068684321
[Bug tree-optimization/96672] Missing -Wclobbered diagnostic, or: __attribute__((returns_twice)) does not inhibit constant folding across call site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96672 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- Looking at dumps, after expanding to RTL we do not have the abnormal edge from the longjmp BB. So while on GIMPLE we preserve modifications of 'x', on RTL we see the 'x = 6' write as dead, and the 'x = 5' write is propagated to the use. (the -Wclobbered warning happens after all the propagation is done) I am surprised the abnormal dispatcher block is not preserved on RTL.
[Bug c++/83445] conversion function has too high priority in overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83445 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- I think this is a desired effect of r269667. The wording isn't in the standard yet, though.
[Bug c/96678] New: [OpenMP] Rejects map(var[:]) of known size with "for pointer type length expression must be specified"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96678
Bug ID: 96678
Summary: [OpenMP] Rejects map(var[:]) of known size with "for
pointer type length expression must be specified"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The following seems to work with many OpenMP compilers and seems to valid. With
GCC 11:
# g++ -fopenmp -c -DEXPLICIT_SIZE test.c
# g++ -fopenmp -c -UEXPLICIT_SIZE test.c
test6.c: In function ‘void test(double*)’:
test6.c:9:34: error: for pointer type length expression must be specified
9 | #pragma omp target map(alloc:src[:])
| ^~~
// --- test.c --
#define SIZE (100)
typedef double Grid[SIZE];
void test (Grid src)
{
#ifdef EXPLICIT_SIZE
#pragma omp target map(alloc:src[0:SIZE])
#else
#pragma omp target map(alloc:src[:])
#endif
{
src[0] = 5;
}
}
[Bug tree-optimization/96671] Failure to optimize a 3 xor+and pattern to xor+andnot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96671
--- Comment #2 from Gabriel Ravier ---
There is also a very similar pattern with this function :
int f(int a, int b, int c)
{
return (a ^ b) | ((b ^ c) ^ a);
}
Which can be optimized to `return (a ^ b) | c;`.
[Bug libstdc++/69724] Unnecessary temporary object during std::thread construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69724 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bb1b7f087bdd028000fd8f84e74b20adccc9d5bb commit r11-2736-gbb1b7f087bdd028000fd8f84e74b20adccc9d5bb Author: Jonathan Wakely Date: Tue Aug 18 14:23:19 2020 +0100 libstdc++: Remove redundant copying of std::async arguments [PR 69724] As was previously done for std::thread, this removes an unnecessary copy of an rvalue of type thread::_Invoker. Instead of creating the rvalue and then moving that into the shared state, the member of the shared state is initialized directly from the forwarded callable and bound arguments. This also slightly simplifies std::thread creation to remove the _S_make_state helper function. libstdc++-v3/ChangeLog: PR libstdc++/69724 * include/std/future (__future_base::_S_make_deferred_state) (__future_base::_S_make_async_state): Remove. (__future_base::_Deferred_state): Change constructor to accept a parameter pack of arguments and forward them to the call wrapper. (__future_base::_Async_state_impl): Likewise. Replace lambda expression with a named member function. (async): Construct state object directly from the arguments, instead of using thread::__make_invoker, _S_make_deferred_state and _S_make_async_state. Move shared state into the returned future. * include/std/thread (thread::_Call_wrapper): New alias template for use by constructor and std::async. (thread::thread(Callable&&, Args&&...)): Create state object directly instead of using _S_make_state. (thread::__make_invoker, thread::__decayed_tuple) (thread::_S_make_state): Remove. * testsuite/30_threads/async/69724.cc: New test.
[Bug c++/96656] Segmentation fault with make_friend_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96656 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Last reconfirmed||2020-08-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Patrick Palka --- Confirmed, not a regression.
[Bug libstdc++/69724] Unnecessary temporary object during std::thread construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69724 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jonathan Wakely --- std::thread was fixed for GCC 10.1 and std::async is fixed for GCC 11.
[Bug c++/96652] Segmentation fault with instantiate_class_template_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96652 Patrick Palka changed: What|Removed |Added Last reconfirmed||2020-08-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed, not a regression either.
[Bug c++/94162] ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162 Marek Polacek changed: What|Removed |Added CC||poul250 at yandex dot ru --- Comment #3 from Marek Polacek --- *** Bug 96627 has been marked as a duplicate of this bug. ***
[Bug c++/96627] gcc raises compile-time segmentation fault on <=> = default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96627 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Marek Polacek --- Looks like a dup. *** This bug has been marked as a duplicate of bug 94162 ***
[Bug c++/96060] ICE with spaceship default operator returning int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96060 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Marek Polacek --- Also a dup. Bug 94162 has more information. *** This bug has been marked as a duplicate of bug 94162 ***
[Bug tree-optimization/96679] New: Failure to optimize or+and+or pattern to and+or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96679
Bug ID: 96679
Summary: Failure to optimize or+and+or pattern to and+or
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int a, int b, int c)
{
return ((b | c) & a) | b;
}
This can be optimized to `return (a & c) | b;`. This transformation is done by
LLVM, but not by GCC.
[Bug c++/94162] ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162 Marek Polacek changed: What|Removed |Added CC||nunoplopes at sapo dot pt --- Comment #4 from Marek Polacek --- *** Bug 96060 has been marked as a duplicate of this bug. ***
[Bug c++/94162] ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #5 from Marek Polacek ---
Test from bug 96060:
#include
struct xx {
int a;
int operator<=>(const xx&) const = default;
};
int f(std::set &x) {
x.emplace(0);
return 0;
}
[Bug c++/94162] ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2020-08-18
--- Comment #6 from Marek Polacek ---
Test from Bug 96627:
#include
struct Float {
float value;
constexpr Float(float value) : value (value) {}
constexpr bool operator == (Float other) const noexcept {
return abs(value - other.value) < 0.5;
}
constexpr bool operator != (Float other) const noexcept {
return !(*this == other);
}
constexpr bool operator <=> (const Float& other) const noexcept = default;
};
[Bug c++/96636] ICE in build_value_init_noctor, at cp/init.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96636 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-08-18 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/96637] ICE in tree check: expected tree_list, have error_mark in cp_check_const_attributes, at cp/decl2.c:1423
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96637 Marek Polacek changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-08-18 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/96638] [8/9/10/11 Regression] ICE in chainon, at tree.c:3169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96638 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[8/9/10/11 Regression] ICE |chainon, at tree.c:3169 |in chainon, at tree.c:3169 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |8.5 Priority|P3 |P4 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-08-18 --- Comment #1 from Marek Polacek --- Even GCC 6 ICEs.
[Bug rtl-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96298 --- Comment #9 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:d850dec9b7bd02ef925def138894402038cca78d commit r11-2737-gd850dec9b7bd02ef925def138894402038cca78d Author: Roger Sayle Date: Tue Aug 18 14:45:52 2020 +0100 New tests for PR rtl-optimization/96298. Tests to confirm PR rtl-optimization is now fixed, remains so. 2020-08-18 Roger Sayle Zdenek Sojka gcc/testsuite/ChangeLog PR rtl-optimization/96298 * gcc.dg/pr96298.c: New test. * gcc.target/i386/pr96298.c: New test.
[Bug rtl-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96298 Roger Sayle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Roger Sayle --- Fixed. Thanks for everyone's help. Sorry again.
[Bug target/96558] [11 Regression] ICE in extract_constrain_insn, at recog.c:2195 (error: insn does not satisfy its constraints)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96558 Roger Sayle changed: What|Removed |Added Status|NEW |RESOLVED CC||roger at nextmovesoftware dot com Resolution|--- |FIXED --- Comment #6 from Roger Sayle --- Fixed. Thanks for everyone's help. Sorry again.
[Bug c++/61372] Add warning to detect noexcept functions that might throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372 --- Comment #3 from David Crocker --- (In reply to Jonathan Wakely from comment #2) > extern "C" functions can throw, so it would be wrong to unconditionally > assume they can't. True, you can write an extern "C" function that throws. But does it ever make sense to? I don't think so. Functions written in C and then declared extern "C" in a C++ program so that they can be called from C++ won't throw or propagate exceptions, even if they end up calling functions written in C++ that throw. The only reason to write a function in C++ and declare it extern "C" is so that it call be called from C, in which case it had better not throw.
[Bug rtl-optimization/60473] optimization after shift sub-optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60473 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED CC||roger at nextmovesoftware dot com Status|UNCONFIRMED |RESOLVED --- Comment #3 from Roger Sayle --- Fixed, and a test case added to ensure this doesn't happen again.
[Bug c++/96623] [11 Regression] ICE in inject_parm_decls, at cp/parser.c:23893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[11 Regression] ICE in |inject_parm_decls, at |inject_parm_decls, at |cp/parser.c:23893 |cp/parser.c:23893 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |11.0 Last reconfirmed||2020-08-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- 11 Regression, started with r11-289.
[Bug c++/96623] [11 Regression] ICE in inject_parm_decls, at cp/parser.c:23893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623 --- Comment #2 from Marek Polacek --- We should have rejected "noexcept()".
[Bug c++/61372] Add warning to detect noexcept functions that might throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372 --- Comment #4 from Jonathan Wakely --- (In reply to David Crocker from comment #3) > (In reply to Jonathan Wakely from comment #2) > > extern "C" functions can throw, so it would be wrong to unconditionally > > assume they can't. > > True, you can write an extern "C" function that throws. But does it ever > make sense to? I don't think so. Functions written in C and then declared > extern "C" in a C++ program so that they can be called from C++ won't throw > or propagate exceptions, That's not true. std::bsearch and std::qsort are counterexamples. You don't know what the user-provided function does, and you can't assume it doesn't throw. > even if they end up calling functions written in > C++ that throw. The only reason to write a function in C++ and declare it > extern "C" is so that it call be called from C, in which case it had better > not throw. That's an incorrect assumption. Not all extern "C" functions are written in C++. Even if they are, you can't assume they don't throw because they could use callbacks that can throw, or they might throw even in C programs (which works fine for some targets, unwinding the stack exactly as a C++ program wants it to). It would be OK to optionally assume functions with C language linkage don't throw, but it must be optional.
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 --- Comment #8 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:f8104bb9dc2365d268ca93e43a24f42e8314fcc1 commit r11-2739-gf8104bb9dc2365d268ca93e43a24f42e8314fcc1 Author: Uros Bizjak Date: Tue Aug 18 17:31:49 2020 +0200 i386: Rewrite restore_stack_nonlocal expander [PR96536]. -fcf-protection code in restore_stack_nonlocal uses a branch based on a clobber result. The patch adds missing compare and completely rewrites the expander to use high-level functions in RTL construction. 2020-08-18 Uroš Bizjak gcc/ChangeLog: PR target/96536 * config/i386/i386.md (restore_stack_nonlocal): Add missing compare RTX. Rewrite expander to use high-level functions in RTL construction.
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:6342cee8801f191466b71116d004e8ccb812caaa commit r10-8638-g6342cee8801f191466b71116d004e8ccb812caaa Author: Uros Bizjak Date: Tue Aug 18 17:34:37 2020 +0200 i386: Fix restore_stack_nonlocal expander [PR96536]. -fcf-protection code in restore_stack_nonlocal uses a branch based on a clobber result. The patch adds missing compare. 2020-08-18 Uroš Bizjak gcc/ChangeLog: PR target/96536 * config/i386/i386.md (restore_stack_nonlocal): Add missing compare RTX.
[Bug analyzer/96666] [11 Regression] Analyzer creates too many regions for a particular program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #1 from Arseny Solokha --- Created attachment 49073 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49073&action=edit Testcase 2 I've managed to come up w/ a smaller testcase, partially reduced from test/std/utilities/any/any.nonmembers/swap.pass.cpp. % g++-11.0.0 -O1 -fanalyzer -c gboytagp.cpp g++-11.0.0: internal compiler error: Segmentation fault signal terminated program cc1plus
[Bug middle-end/88780] [8/9/10/11 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780 Marietto changed: What|Removed |Added CC||marietto2008 at gmail dot com --- Comment #6 from Marietto --- Hello. I'm a xen user. I'm trying to Build Qemu & Xen for XenGT on Ubuntu 20.04 following this tutorial : https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide#332-build-qemu--xen-for-xengt because I want to share the integrated GPU with a xen VM. The main hardware components of my PC are the following : CPU I9-9900k Intel Corporation UHD Graphics 630 (Desktop 9 Series) (rev 02) IVIDIA Corporation TU102 [GeForce RTX 2080 Ti] (rev a1) The compilation gave no errors until this point : root@ziomario-z390aoruspro:/etc/xen/igvtg-xen# make install-tools .. make libs make[5]: ingresso nella directory «/etc/xen/igvtg-xen/tools/libxc» rm -f _paths.h.tmp; echo "#define sbindir "/usr/sbin"" >>_paths.h.tmp; echo "#define bindir "/usr/bin"" >>_paths.h.tmp; echo "#define LIBEXEC "/usr/lib/xen"" >>_paths.h.tmp; echo "#define LIBEXEC_BIN "/usr/lib/xen/bin"" >>_paths.h.tmp; echo "#define libdir "/usr/lib"" >>_paths.h.tmp; echo "#define SHAREDIR "/usr/share"" >>_paths.h.tmp; echo "#define XENFIRMWAREDIR "/usr/lib/xen/boot"" >>_paths.h.tmp; echo "#define XEN_CONFIG_DIR "/etc/xen"" >>_paths.h.tmp; echo "#define XEN_SCRIPT_DIR "/etc/xen/scripts"" >>_paths.h.tmp; echo "#define XEN_LOCK_DIR "/var/lock"" >>_paths.h.tmp; echo "#define XEN_RUN_DIR "/var/run/xen"" >>_paths.h.tmp; echo "#define XEN_PAGING_DIR "/var/lib/xen/xenpaging"" >>_paths.h.tmp; echo "#define XEN_DUMP_DIR "/var/lib/xen/dump"" >>_paths.h.tmp; echo "#define XEN_LOG_DIR "/var/log/xen"" >>_paths.h.tmp; echo "#define XEN_LIB_DIR "/var/lib/xen"" >>_paths.h.tmp; echo "#define XEN_RUN_STORED "/var/run/xenstored"" >>_paths.h.tmp; if ! cmp -s _paths.h.tmp paths.h; then mv -f paths.h.tmp paths.h; else rm -f paths.h.tmp; fi gcc -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION=XEN_LATEST_INTERFACE_VERSION -MMD -MF .xc_pm.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -I../../xen/common/libelf -Werror -Wmissing-prototypes -I. -I./include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/include -D__XEN_TOOLS -pthread -I/etc/xen/igvtg-xen/tools/libxc/../../tools/libs/toollog/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/libs/evtchn/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/libs/devicemodel/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/include -include /etc/xen/igvtg-xen/tools/libxc/../../tools/config.h -I/etc/xen/igvtg-xen/tools/libxc/../../tools/libs/call/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/libs/foreignmemory/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/libs/gnttab/include -I/etc/xen/igvtg-xen/tools/libxc/../../tools/include -c -o xc_pm.o xc_pm.c In file included from /usr/include/string.h:495, from xc_private.h:24, from xc_pm.c:22: In function ‘strncpy’, inlined from ‘xc_set_cpufreq_gov’ at xc_pm.c:308:5: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound 16 equals destination size [-Werror=stringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~ cc1: all warnings being treated as errors make[5]: *** [/etc/xen/igvtg-xen/tools/libxc/../../tools/Rules.mk:222: xc_pm.o] Errore 1 make[5]: uscita dalla directory «/etc/xen/igvtg-xen/tools/libxc» make[4]: *** [Makefile:184: build] Errore 2 make[4]: uscita dalla directory «/etc/xen/igvtg-xen/tools/libxc» make[3]: *** [/etc/xen/igvtg-xen/tools/../tools/Rules.mk:246: subdir-install-libxc] Errore 2 make[3]: uscita dalla directory «/etc/xen/igvtg-xen/tools» make[2]: *** [/etc/xen/igvtg-xen/tools/../tools/Rules.mk:241: subdirs-install] Errore 2 make[2]: uscita dalla directory «/etc/xen/igvtg-xen/tools» make[1]: *** [Makefile:74: install] Errore 2 make[1]: uscita dalla directory «/etc/xen/igvtg-xen/tools» make: *** [Makefile:127: install-tools] Errore 2 how can I fix it ?
[Bug rtl-optimization/61494] -fsignaling-nans not taken into account for x - 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61494 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Roger Sayle --- Fixed. Thanks Vincent.
[Bug c++/96673] [8/9/10/11 Regression] Friend class with templates and default constructor not recognized in C++14 or later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96673 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |8.5 Last reconfirmed||2020-08-18 Keywords||rejects-valid Summary|Friend class with templates |[8/9/10/11 Regression] |and default constructor not |Friend class with templates |recognized in C++14 or |and default constructor not |later |recognized in C++14 or ||later --- Comment #1 from Marek Polacek --- Confirmed. GCC 5 actualled ICEd on this. GCC 4.9 compiled it even with -std=c++14.
[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) > The exact behaviour is not well specified in OpenMP 4.5 or 5.0 but at least > with 'always' the following is expected to map. > (See OpenMP Issue 2152 + upcoming OpenMP TR9 – which require the always > modifier. There is code which expects that implicit mapping and mapping > without always modifier also works.) > > For pointers, at least OpenMP 5.0 seems to require that the POINTER target > is automatically mapped: > > module m > implicit none > integer, pointer :: p1 => null() > integer, pointer :: p1 => null() > integer, allocatable :: a1, a2(:) > !$omp declare target(p1, p2, a1, a2) > end module m > Module m looks wrong. Should the 2nd p1 be p2?
[Bug c++/96673] [8/9/10/11 Regression] Friend class with templates and default constructor not recognized in C++14 or later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96673 --- Comment #2 from Marek Polacek --- The ICE with -std=c++14 started with r216750. It was fixed by r234442, but the error appeared.
[Bug c++/96675] [10/11 Regression] tautological-compare warning emitted for NTTP bitwise comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96675 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Last reconfirmed||2020-08-18 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.3 Summary|tautological-compare|[10/11 Regression] |warning emitted for NTTP|tautological-compare |bitwise comparison |warning emitted for NTTP ||bitwise comparison Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Keywords||diagnostic --- Comment #1 from Marek Polacek --- Started with my r11-155.
[Bug middle-end/96680] New: [11 Regression][OpenMP][LTO] Declare variant + ICE in lto_fixup_prevailing_decls, at lto/lto-common.c:2595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96680 Bug ID: 96680 Summary: [11 Regression][OpenMP][LTO] Declare variant + ICE in lto_fixup_prevailing_decls, at lto/lto-common.c:2595 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, openmp Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- This now fails with offloading in the device lto1 of both AMDGCN and nvptx. The testcase is tests/5.0/declare_variant/test_declare_variant.c of https://github.com/SOLLVE/sollve_vv compile, e.g., as gcc -fopenmp -I ompvv ./tests/5.0/declare_variant/test_declare_variant.c lto1: internal compiler error: in lto_fixup_prevailing_decls, at lto/lto-common.c:2595 0x6536a0 lto_fixup_prevailing_decls gcc-mainline/gcc/lto/lto-common.c:2595 0x65f9a1 lto_fixup_decls gcc-mainline/gcc/lto/lto-common.c:2645 0x65f9a1 read_cgraph_and_symbols(unsigned int, char const**) src/gcc-mainline/gcc/lto/lto-common.c:2897 0x63fd42 lto_main() gcc-mainline/gcc/lto/lto.c:625
[Bug tree-optimization/96665] [11 regression] new FAILs for gcc.dg/strlenopt-55.c after r11-2709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96665 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization, patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Patch I plan to commit: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552161.html
[Bug tree-optimization/96681] New: Failure to optimize xor of comparisons with specific constants to comparison of xor-ed of compared variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96681
Bug ID: 96681
Summary: Failure to optimize xor of comparisons with specific
constants to comparison of xor-ed of compared
variables
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x, int y)
{
return (x < 0) ^ (y < 0);
}
This can be optimized to `return (x ^ y) < 0;`. LLVM does this transformation,
but GCC does not. This transformation can also be done with `return (x > -1) ^
(y > -1);`. There is also a similar transformation with `return (x > -1) ^ (y <
0);`, which can be optimized to `return ~(x ^ y) < 0;`.
[Bug middle-end/96680] [11 Regression][OpenMP][LTO] Declare variant + ICE in lto_fixup_prevailing_decls, at lto/lto-common.c:2595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96680 --- Comment #1 from Tobias Burnus --- In the debugger, the first call to lto_fixup_prevailing_decls is for main._omp_fn.0 and the second - and failing - one is for (gdb) p debug_tree(t)
[Bug c/96682] Arm: Wrong code generated for MVE with -O1 and above optimization options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96682 SRINATH PARVATHANENI changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-08-18
[Bug c/96682] New: Arm: Wrong code generated for MVE with -O1 and above optimization options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96682
Bug ID: 96682
Summary: Arm: Wrong code generated for MVE with -O1 and above
optimization options.
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sripar01 at gcc dot gnu.org
Target Milestone: ---
Target: arm
Created attachment 49074
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49074&action=edit
test case
$ arm-none-eabi -v
Using built-in specs.
COLLECT_GCC=../MVE_PUBLIC/gcc-arm-none-eabi-10-2020-q2-preview/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/media/sripar01/2tb_work/MVE_PUBLIC/gcc-arm-none-eabi-10-2020-q2-preview/bin/../lib/gcc/arm-none-eabi/10.1.1/lto-wrapper
Target: arm-none-eabi
Configured with:
/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/src/gcc/configure
--target=arm-none-eabi
--prefix=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/install-native
--libexecdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/install-native/lib
--infodir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/install-native/share/doc/gcc-arm-none-eabi/info
--mandir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/install-native/share/doc/gcc-arm-none-eabi/man
--htmldir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/install-native/share/doc/gcc-arm-none-eabi/html
--pdfdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/install-native/share/doc/gcc-arm-none-eabi/pdf
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib
--with-headers=yes --with-python-dir=share/gcc-arm-none-eabi
--with-sysroot=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/install-native/arm-none-eabi
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--with-gmp=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/build-native/host-libs/usr
--with-mpfr=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/build-native/host-libs/usr
--with-mpc=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/build-native/host-libs/usr
--with-isl=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/build-native/host-libs/usr
--with-libelf=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-13_20200625_1593044217/build-native/host-libs/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='GNU Arm Embedded Toolchain 10-2020-q2-preview'
--with-multilib-list=rmprofile,aprofile
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.1.1 20200529 (release) (GNU Arm Embedded Toolchain
10-2020-q2-preview)
$ arm-none-eabi-gcc bug.c -mfloat-abi=hard -march=armv8.1-m.main+mve.fp -O3 -c
x.i:65:1: warning: return type defaults to 'int' [-Wimplicit-int]
65 | fn1(__fp16 *pSrc) {
| ^~~
/tmp/ccOTL3zZ.s: Assembler messages:
/tmp/ccOTL3zZ.s:40: Error: instruction does not support writeback -- `vldr.16
s15,[r0]!'
vldr.16 and vstr.16 does not support write back for MVE, wrong code-gen for the
attached test case bug.c.
[Bug c++/96676] Segmentation fault on parsing simple variadic template function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96676 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Thanks for the report. I think it's a dup. *** This bug has been marked as a duplicate of bug 84796 ***
[Bug c++/84796] ICE in a template parameter pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84796 Marek Polacek changed: What|Removed |Added CC||ivan.leonov.d at yandex dot ru --- Comment #2 from Marek Polacek --- *** Bug 96676 has been marked as a duplicate of this bug. ***
[Bug middle-end/96680] [11 Regression][OpenMP][LTO] Declare variant + ICE in lto_fixup_prevailing_decls, at lto/lto-common.c:2595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96680 --- Comment #2 from Tobias Burnus --- Created attachment 49075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49075&action=edit C testcase - de-macro-fied version sollve_vv's 5.0/declare_variant/test_declare_variant.c
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:65f460db575eb004172e75b88f5a76724f04e255 commit r9-8813-g65f460db575eb004172e75b88f5a76724f04e255 Author: Uros Bizjak Date: Tue Aug 18 18:47:47 2020 +0200 i386: Fix restore_stack_nonlocal expander [PR96536]. -fcf-protection code in restore_stack_nonlocal uses a branch based on a clobber result. The patch adds missing compare. 2020-08-18 Uroš Bizjak gcc/ChangeLog: PR target/96536 * config/i386/i386.md (restore_stack_nonlocal): Add missing compare RTX.
[Bug c++/84796] ICE in a template parameter pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84796
--- Comment #3 from Marek Polacek ---
Test from bug 96676.
template < typename T, typename... TYPES >
struct A {
template < TYPES... types >
void Get() { }
};
void f() {}
int main() {
A a;
a.Get<&f>();
}
But even r150013 ICEs, so perhaps they're not dups as I thought.
[Bug c++/96676] Segmentation fault on parsing simple variadic template function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96676 Marek Polacek changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2020-08-18 Ever confirmed|0 |1 Resolution|DUPLICATE |--- --- Comment #3 from Marek Polacek --- Actually, it probably isn't.
[Bug c/96683] New: Arm: MVE ACLE intrinsics vst1q_{s8|u8|s16|u16} is not supported by GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96683
Bug ID: 96683
Summary: Arm: MVE ACLE intrinsics vst1q_{s8|u8|s16|u16} is not
supported by GCC.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sripar01 at gcc dot gnu.org
Target Milestone: ---
Target: arm
Created attachment 49076
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49076&action=edit
test case
$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/work/gnu-work/Release/build-arm-none-eabi/install/libexec/gcc/arm-none-eabi/10.2.1/lto-wrapper
Target: arm-none-eabi
Configured with: /work/gnu-work/Release/src/gcc/configure
--target=arm-none-eabi
--prefix=/work/gnu-work/Release/build-arm-none-eabi/install//
--with-gmp=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--with-mpfr=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--with-mpc=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--with-isl=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
--with-multilib-list=rmprofile --with-pkgversion=unknown : (reconfigured)
/work/gnu-work/Release/src/gcc/configure --target=arm-none-eabi
--prefix=/work/gnu-work/Release/build-arm-none-eabi/install//
--with-gmp=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--with-mpfr=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--with-mpc=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--with-isl=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --with-newlib --with-multilib-list=rmprofile
--with-pkgversion=unknown target_alias=arm-none-eabi CFLAGS='-O0 -g3'
CXXFLAGS='-O0 -g3' --enable-languages=c,c++,fortran,lto --no-create
--no-recursion
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20200803 (unknown)
$ arm-none-eabi-gcc bug.c -mfloat-abi=hard -march=armv8.1-m.main+mve.fp -O3
bug.c: In function 'foo':
bug.c:9358:3: error: this builtin is not supported for this target
9358 | __builtin_mve_vst1q_sv8hi ((__builtin_neon_hi *) __addr, __value);
| ^
gcc for arm-none-eabi target fails to compile MVE ACLE intrinsics
vst1q(_s8|_s16|_u8|_u16).
[Bug c++/84796] ICE in a template parameter pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84796 --- Comment #4 from Marek Polacek --- *** Bug 96677 has been marked as a duplicate of this bug. ***
[Bug c++/96677] Compile error on valid code with variadic template function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96677 Marek Polacek changed: What|Removed |Added Resolution|--- |DUPLICATE CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Marek Polacek --- OK, this one is actually a dup of bug 84796, started with the same rev. *** This bug has been marked as a duplicate of bug 84796 ***
[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668 --- Comment #4 from Tobias Burnus --- (In reply to kargl from comment #3) > > integer, pointer :: p1 => null() > > integer, pointer :: p1 => null() > Module m looks wrong. Should the 2nd p1 be p2? It should be "p2(:)" (Thanks. I wrote it in the browser without cross checking – and as I planed to do it, the VMware had disk access issues. Thus, I just hit 'submit' while the browser was still running. Hence, there might be additional issues. I also planned to enumerate the 'stop 1'.)
[Bug c/96684] New: arm: MVE intrinsics / __ARM_undef presence in f16 vector max routine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96684 Bug ID: 96684 Summary: arm: MVE intrinsics / __ARM_undef presence in f16 vector max routine Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sripar01 at gcc dot gnu.org Target Milestone: --- Target: arm Created attachment 49077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49077&action=edit test case $ arm-none-eabi-gcc -v Using built-in specs. COLLECT_GCC=arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/work/gnu-work/Release/build-arm-none-eabi/install/libexec/gcc/arm-none-eabi/10.2.1/lto-wrapper Target: arm-none-eabi Configured with: /work/gnu-work/Release/src/gcc/configure --target=arm-none-eabi --prefix=/work/gnu-work/Release/build-arm-none-eabi/install// --with-gmp=/work/gnu-work/Release/build-arm-none-eabi/host-tools --with-mpfr=/work/gnu-work/Release/build-arm-none-eabi/host-tools --with-mpc=/work/gnu-work/Release/build-arm-none-eabi/host-tools --with-isl=/work/gnu-work/Release/build-arm-none-eabi/host-tools --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran --with-newlib --with-multilib-list=rmprofile --with-pkgversion=unknown : (reconfigured) /work/gnu-work/Release/src/gcc/configure --target=arm-none-eabi --prefix=/work/gnu-work/Release/build-arm-none-eabi/install// --with-gmp=/work/gnu-work/Release/build-arm-none-eabi/host-tools --with-mpfr=/work/gnu-work/Release/build-arm-none-eabi/host-tools --with-mpc=/work/gnu-work/Release/build-arm-none-eabi/host-tools --with-isl=/work/gnu-work/Release/build-arm-none-eabi/host-tools --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --with-newlib --with-multilib-list=rmprofile --with-pkgversion=unknown target_alias=arm-none-eabi CFLAGS='-O0 -g3' CXXFLAGS='-O0 -g3' --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: single Supported LTO compression algorithms: zlib gcc version 10.2.1 20200803 (unknown) $ arm-none-eabi-gcc bug.c -mfloat-abi=hard -march=armv8.1-m.main+mve.fp -O3 --specs=rdimon.specs /work/gnu-work/Release/build-arm-none-eabi/install/lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: /tmp/ccQXZj1p.o: in function `main': bug.c:(.text.startup+0x30): undefined reference to `__ARM_undef' collect2: error: ld returned 1 exit status
[Bug c/96684] arm: MVE intrinsics / __ARM_undef presence in f16 vector max routine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96684 SRINATH PARVATHANENI changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-08-18 Ever confirmed|0 |1 --- Comment #1 from SRINATH PARVATHANENI --- __ARM_undef undefined reference generated from the test cases for the compiler. Need to fix this.
[Bug c/96683] Arm: MVE ACLE intrinsics vst1q_{s8|u8|s16|u16} is not supported by GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96683 SRINATH PARVATHANENI changed: What|Removed |Added Last reconfirmed||2020-08-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/96602] Partial ordering is ambiguous with default function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96602 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-08-18 --- Comment #1 from Marek Polacek --- Sounds legit. Not a regression.
[Bug fortran/94958] gcc/fortran/trans-array.c:9797: possible typo ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94958
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from vehre at gcc dot gnu.org ---
Further research showed, that the conseQuences of the mistake are not impacting
gfortran in any kind, because the errmsg and errmsg_len are never used. The
code here is jumped to only when a derived type containing an allocatable
component is broadcasted and then only in caf-lib-mode, e.g.:
! { dg-do compile }
!
! PR fortran/94958
!
implicit none
type struct
integer, allocatable :: comp
end type
type(struct) :: a
character(kind=1, len=20) :: err
integer :: stat
call co_broadcast(a, this_image(), stat, err)
end
gfortran -fcoarray=lib bcast_1.f90 -lcaf_single
During traversal of the derived type for bcast, the function call to
CO_BROADCAST() for the type 'a' and it's allocatable component 'comp' is never
augmented with the nodes for stat, errmsg and errmsg_len. For this small
example the code already has two calls to co_broadcast. Which indicates the
necessity of having some way to aggregate the stat and errmsg over all these
calls. Unfortunately does the Fortran-standard (2015, 2018) not state how to
aggregate the stat and/or errmsg for multiple broadcasts.
I therefore propose a fix:
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 7a1b2fc74c9..73a45cd2dcf 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9732,7 +9732,7 @@ gfc_bcast_alloc_comp (gfc_symbol *derived, gfc_expr
*expr, int rank,
args.image_index = image_index;
args.stat = stat;
args.errmsg = errmsg;
- args.errmsg = errmsg_len;
+ args.errmsg_len = errmsg_len;
if (rank == 0)
{
as obvious and get done with this pr.
[Bug c++/96593] No "declaration changes meaning" diagnostic for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96593 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-08-18 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Like you say, this might be mandatory in C++23: https://wg21.link/p1697r0. So confirmed.
[Bug tree-optimization/96685] New: Failure to optimize not+sub to add+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96685
Bug ID: 96685
Summary: Failure to optimize not+sub to add+not
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x, int y)
{
return ~(x - y);
}
This can be optimized to `~x + y`. While this isn't necessarily faster on most
platforms, it is at least equivalent and on x86 the addition can be optimized
to `lea` whereas the subtraction can't. This transformation is done by LLVM,
but not by GCC.
[Bug middle-end/88780] [8/9/10/11 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780 --- Comment #7 from Martin Sebor --- (In reply to Marietto from comment #6) ... > In function ‘strncpy’, > inlined from ‘xc_set_cpufreq_gov’ at xc_pm.c:308:5: > /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: > ‘__builtin_strncpy’ specified bound 16 equals destination size > [-Werror=stringop-truncation] > 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); > | ^~ This instance of the warning is most likely unrelated to the one reported in comment #0 (to tell for sure we'd need a test case to reproduce it). It indicates that strncpy is being called with the third argument set to the size of the destination array, which leaves the destination unterminated unless the source string is shorter. The following articles describe the problem and the suggested solutions in detail: https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ https://us-cert.cisa.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 --- Comment #11 from CVS Commits --- The releases/gcc-8 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:bf7b9330982165e051de0962c5bc231e2d1242d9 commit r8-10410-gbf7b9330982165e051de0962c5bc231e2d1242d9 Author: Uros Bizjak Date: Tue Aug 18 19:48:51 2020 +0200 i386: Fix restore_stack_nonlocal expander [PR96536]. -fcf-protection code in restore_stack_nonlocal uses a branch based on a clobber result. The patch adds missing compare. 2020-08-18 Uroš Bizjak gcc/ChangeLog: PR target/96536 * config/i386/i386.md (restore_stack_nonlocal): Add missing compare RTX.
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |8.5 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Uroš Bizjak --- Fixed everywhere.
[Bug fortran/96686] New: MIN/MAX should reject character arguments of different kind rather than ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96686 Bug ID: 96686 Summary: MIN/MAX should reject character arguments of different kind rather than ICE Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- We current fail on this: program p implicit none character(kind=1) :: c1 = "1" character(kind=4) :: c4 = 4_"4" print *, min (c1, c4) end program p min_max_char.f90:5:16: 5 | print *, min (c1, c4) |1 internal compiler error: Cannot convert 'CHARACTER(1)' to 'CHARACTER(0,4)' at (1) 0x69ee19 gfc_report_diagnostic ../../gcc-trunk/gcc/fortran/error.c:782 0x6a0592 gfc_internal_error(char const*, ...) ../../gcc-trunk/gcc/fortran/error.c:1402 0x6bfb68 gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int, bool) ../../gcc-trunk/gcc/fortran/intrinsic.c:5350 0x6c8385 gfc_resolve_minmax ../../gcc-trunk/gcc/fortran/iresolve.c:1621 0x6b4391 resolve_intrinsic ../../gcc-trunk/gcc/fortran/intrinsic.c:4501 0x6b4391 do_simplify ../../gcc-trunk/gcc/fortran/intrinsic.c:4671 0x6bedda gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc-trunk/gcc/fortran/intrinsic.c:5013 0x70e17b resolve_unknown_f ../../gcc-trunk/gcc/fortran/resolve.c:2919 0x70e17b resolve_function ../../gcc-trunk/gcc/fortran/resolve.c:3277 0x70e17b gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:7094 0x714e84 gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:7061 0x714e84 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11799 0x71e09f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:10826 0x713c58 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11789 0x71650d resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:17334 0x7165de gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:17369 0x6fe4b5 resolve_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:6286 0x6fe4b5 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6538 0x74b3af gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:212 Proposed solution: since MIN/MAX with character arguments are not legacy stuff, there is no good reason to provide a GNU extension. We should simply reject this always, as in: gfc-11 min_max_char.f90 -std=f2018 min_max_char.f90:5:20: 5 | print *, min (c1, c4) |1 Error: GNU Extension: Different type kinds at (1) although it should simply say: Different type kinds. No reference to any GNU Extension.
[Bug fortran/96686] MIN/MAX should reject character arguments of different kind rather than ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96686 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-08-18 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Yep, I agree that this should simply be rejected. I looked at your other patch for min/max, and think it can be committed. If you want to update that patch to include the fix for this PR consider it pre-approved (provided regression testing passes).
[Bug c++/96687] New: new char[4]{"foo"} doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96687
Bug ID: 96687
Summary: new char[4]{"foo"} doesn't work
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
We should accept the following:
char *p = new char[4]{"foo"};
but we reject with:
error: invalid conversion from ‘const char*’ to ‘char’ [-fpermissive]
[Bug c++/96687] new char[4]{"foo"} doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96687 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Last reconfirmed||2020-08-18 Keywords||rejects-valid Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug tree-optimization/96670] [11 Regression] ICE in tree_to_uhwi, at tree.c:7361 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96670 --- Comment #1 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:bb04901d14f7749eb949092fd3dfcb6ca1958701 commit r11-2742-gbb04901d14f7749eb949092fd3dfcb6ca1958701 Author: Martin Sebor Date: Tue Aug 18 12:49:35 2020 -0600 Fix PR tree-optimization/96670 - ICE on memchr with an empty initializer. gcc/ChangeLog: PR tree-optimization/96670 PR middle-end/78257 * gimple-fold.c (gimple_fold_builtin_memchr): Call byte_representation to get it, not string_constant. gcc/testsuite/ChangeLog: PR tree-optimization/96670 * gcc.dg/memchr-2.c: New test. * gcc.dg/memcmp-6.c: New test.
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257 --- Comment #11 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:bb04901d14f7749eb949092fd3dfcb6ca1958701 commit r11-2742-gbb04901d14f7749eb949092fd3dfcb6ca1958701 Author: Martin Sebor Date: Tue Aug 18 12:49:35 2020 -0600 Fix PR tree-optimization/96670 - ICE on memchr with an empty initializer. gcc/ChangeLog: PR tree-optimization/96670 PR middle-end/78257 * gimple-fold.c (gimple_fold_builtin_memchr): Call byte_representation to get it, not string_constant. gcc/testsuite/ChangeLog: PR tree-optimization/96670 * gcc.dg/memchr-2.c: New test. * gcc.dg/memcmp-6.c: New test.
[Bug tree-optimization/96670] [11 Regression] ICE in tree_to_uhwi, at tree.c:7361 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96670 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-08-18 --- Comment #2 from Martin Sebor --- Confirmed. Reproducible with just -O alone.
[Bug tree-optimization/96670] [11 Regression] ICE in tree_to_uhwi, at tree.c:7361 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96670 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- Fixed in r11-2742.
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257 --- Comment #12 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:d367f5fcb579d21c3093cf5c464f5787fe584a1d commit r11-2743-gd367f5fcb579d21c3093cf5c464f5787fe584a1d Author: Martin Sebor Date: Tue Aug 18 12:57:18 2020 -0600 PR middle-end/96665 - memcmp of a constant string not folded Related: PR middle-end/78257 - missing memcmp optimization with constant arrays gcc/ChangeLog: PR middle-end/96665 PR middle-end/78257 * expr.c (convert_to_bytes): Replace statically allocated buffer with a dynamically allocated one of sufficient size. gcc/testsuite/ChangeLog: PR middle-end/96665 PR middle-end/78257 * gcc.dg/memcmp-5.c: New test.
[Bug tree-optimization/96665] [11 regression] new FAILs for gcc.dg/strlenopt-55.c after r11-2709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96665 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:d367f5fcb579d21c3093cf5c464f5787fe584a1d commit r11-2743-gd367f5fcb579d21c3093cf5c464f5787fe584a1d Author: Martin Sebor Date: Tue Aug 18 12:57:18 2020 -0600 PR middle-end/96665 - memcmp of a constant string not folded Related: PR middle-end/78257 - missing memcmp optimization with constant arrays gcc/ChangeLog: PR middle-end/96665 PR middle-end/78257 * expr.c (convert_to_bytes): Replace statically allocated buffer with a dynamically allocated one of sufficient size. gcc/testsuite/ChangeLog: PR middle-end/96665 PR middle-end/78257 * gcc.dg/memcmp-5.c: New test.
[Bug tree-optimization/96665] [11 regression] memcmp of a constant string not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96665 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Summary|[11 regression] new FAILs |[11 regression] memcmp of a |for gcc.dg/strlenopt-55.c |constant string not folded |after r11-2709 | Target Milestone|--- |11.0 --- Comment #4 from Martin Sebor --- Fixed in r11-2743.
[Bug tree-optimization/96688] New: Failure to optimize shift-right+not of constant to avoid not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96688
Bug ID: 96688
Summary: Failure to optimize shift-right+not of constant to
avoid not
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x)
{
return ~(123 >> x);
}
This return in this code can be optimized to `return ~123 >> x;`, and the same
optimization is possible where 123 is replaced by essentially any constant.
This transformation is done by LLVM, but not by GCC.
[Bug fortran/96686] MIN/MAX should reject character arguments of different kind rather than ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96686
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Yep, I agree that this should simply be rejected. I looked at your other
> patch for min/max, and think it can be committed. If you want to update
> that patch to include the fix for this PR consider it pre-approved (provided
> regression testing passes).
The addition:
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 74e5e448760..65b46cd3f85 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3693,6 +3693,11 @@ check_rest (bt type, int kind, gfc_actual_arglist
*arglist)
{
if (x->ts.type == type)
{
+ if (x->ts.type == BT_CHARACTER)
+ {
+ gfc_error ("Different character kinds at %L", &x->where);
+ return false;
+ }
if (!gfc_notify_std (GFC_STD_GNU, "Different type "
"kinds at %L", &x->where))
return false;
does the job and regtests fine.
Will commit together with the other PR, and with a new testcase for this one.
[Bug fortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613 --- Comment #9 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3c04bd60e56da399a441f73ebb687b5039b9cf3f commit r11-2746-g3c04bd60e56da399a441f73ebb687b5039b9cf3f Author: Harald Anlauf Date: Tue Aug 18 21:48:56 2020 +0200 PR fortran/96613,96686 - Fix type/kind issues, temporaries evaluating MIN/MAX When evaluating functions of the MIN/MAX variety inline, use a temporary of appropriate type and kind, and convert to the result type at the end. In the case of allowing for the GNU extensions to MIN/MAX, derive the result kind consistently during simplificaton. Furthermore, the Fortran standard requires type and kind of arguments to the MIN/MAX intrinsics to all have the same type and kind. While a GNU extension accepts kind differences for integer and real arguments which seems to have been used in legacy code, there is no reason to allow different character kinds. We now reject the latter unconditionally. gcc/fortran/ChangeLog: * check.c (check_rest): Reject MIN/MAX character arguments of different kind. * simplify.c (min_max_choose): The simplification result shall have the highest kind value of the arguments. * trans-intrinsic.c (gfc_conv_intrinsic_minmax): Choose type and kind of intermediate by looking at all arguments, not the result. gcc/testsuite/ChangeLog: * gfortran.dg/minmax_char_3.f90: New test. * gfortran.dg/min_max_kind.f90: New test. * gfortran.dg/pr96613.f90: New test.
