[Bug tree-optimization/101445] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101445 Andrew Pinski changed: What|Removed |Added Summary|wrong code at -O3 on|[11/12 Regression] wrong |x86_64-linux-gnu|code at -O3 on ||x86_64-linux-gnu Target||x86_64-linux-gnu Target Milestone|--- |11.2 Version|unknown |11.1.0 Keywords||wrong-code --- Comment #2 from Andrew Pinski --- (In reply to Qirun Zhang from comment #1) r11-1897
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #231 from The Written Word --- (In reply to John Buddery from comment #228) > These patches are for 11.1.0, but should work on earlier versions too. With > this I have a working gcc which I've tested on several large projects. You don't #undef MAKE_DECL_ONE_ONLY in gcc/config/ia64/hpux.h? If you skip it, do you skip it on earlier GCC builds as well?
[Bug tree-optimization/101445] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101445 --- Comment #1 from Qirun Zhang --- My bisection points to g:f75211822f8d84bb706421d3692e
[Bug tree-optimization/101445] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101445
Bug ID: 101445
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It appears to be a recent regression. Note that -O2 works fine.
$ gcc-trunk -v
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210713 (experimental) [master revision
7670b6633e5:d2f95d2ac56:1583b8bff0be7e41aa721dde79f90ca0763bd4e2] (GCC)
$ gcc-trunk abc.c ; ./a.out
0
0
0
0
0
0
0
$ gcc-trunk -O3 abc.c ; ./a.out
0
0
3
0
0
0
0
$ cat abc.c
int a[35] = {1, 1, 3};
char b = 4;
int c, d;
int main() {
char e;
for (; b >= 0; b--) {
e = 3;
for (; e >= 0; e--)
a[b * 5 + e] = a[b * 5 + e + 1];
}
for (; c < 5; c++)
;
for (; d < 7; d++)
printf("%d\n", a[c * d]);
}
[Bug target/67288] [9/10/11/12 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 Jiu Fu Guo changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED CC||guojiufu at gcc dot gnu.org --- Comment #22 from Jiu Fu Guo --- (In reply to Segher Boessenkool from comment #4) > It's not fixed. On trunk we get: > > === > flush_dcache_range: > rlwinm 3,3,0,0,27 > addi 4,4,15 > subf 4,3,4 > srwi. 9,4,4 > beq 0,.L1 > slwi 9,9,4 > addi 9,9,-16 > srwi 9,9,4 > addi 9,9,1 > mtctr 9 > .p2align 4,,15 > .L3: > dcbf 0, 3 > addi 3,3,16 > bdnz .L3 > sync > .L1: > blr > === > > (-m32, edited a bit). > > The slwi/addi/srwi/addi is unnecessary. With the latest trunk (which contains https://gcc.gnu.org/g:8a15faa730f99100f6f3ed12663563356ec5a2c0) The asm code is: .cfi_startproc rldicr %r3,%r3,0,59 addi %r9,%r4,15 subf %r9,%r3,%r9 srwi %r9,%r9,4 cmpwi %cr0,%r9,0 beqlr %cr0 rldicl %r9,%r9,0,32 mtctr %r9 .p2align 4,,15 .L3: dcbf 0, %r3 addi %r3,%r3,16 bdnz .L3 sync blr
[Bug c++/101435] Bad error with missing template keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101435 --- Comment #3 from Tobias Schlüter --- Thank you! I would certainly have found the other bug had I put the right keyword into the title of the PR myself ...
[Bug c++/16233] unhelpful error message when "template" is omitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16233 Tobias Schlüter changed: What|Removed |Added Last reconfirmed|2015-09-18 00:00:00 |2021-07-14 0:00 CC||tobi at gcc dot gnu.org --- Comment #11 from Tobias Schlüter --- With the current trunk we still get the same message save for the carets (https://godbolt.org/z/sWb7MbTWr) : In member function 'void B::Bar(V*)': :6:16: error: expected primary-expression before 'int' 6 | v->Foo(); |^~~ :6:16: error: expected ';' before 'int' Compiler returned: 1
[Bug c++/101232] Bad error message with stray semicolon in initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101232
--- Comment #2 from Tobias Schlüter ---
Here's another way to trigger this, inspired by my other PR101435
(https://godbolt.org/z/no6aEqvh3):
===
template
class X {
public:
U v;
using Scalar = U;
static constexpr auto Dim = dim;
explicit X(U x) : v(x) {}
template
X cast()
{
return X(T{v});
}
};
void f(int err) {
auto propertyHelper = [err](M&& fallback) -> M {
using FloatM = X;
FloatM v{0};
return err == 0 ? M{ v.template cast(); } :
fallback;
};
}
===
Which gives a comically wrong cascade of errors:
---
: In lambda function:
:23:28: error: expected primary-expression before '{' token
23 | return err == 0 ? M{ v.template cast(); } :
fallback;
|^
:23:28: error: expected ':' before '{' token
23 | return err == 0 ? M{ v.template cast(); } :
fallback;
|^
|:
:23:28: error: expected primary-expression before '{' token
:23:28: error: expected ';' before '{' token
23 | return err == 0 ? M{ v.template cast(); } :
fallback;
|^
|;
:23:71: error: expected primary-expression before ':' token
23 | return err == 0 ? M{ v.template cast(); } :
fallback;
| ^
Compiler returned: 1
-
[Bug libfortran/101305] Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305 --- Comment #3 from sandra at gcc dot gnu.org --- Patches posted: https://gcc.gnu.org/pipermail/fortran/2021-July/056236.html
[Bug target/101384] [9/10/11/12 Regression] wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384 --- Comment #6 from Segher Boessenkool --- I did run on the cfarm. What kind of machine does it need to fail? p8? p9?
[Bug target/101323] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101323 --- Comment #2 from Peter Bergner --- I'll have a look.
[Bug target/101323] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101323 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2021-07-13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Segher Boessenkool --- Confirmed.
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 --- Comment #5 from Bill Schmidt --- Uh, yeah, that is completely unexpected behavior for swaps. I'll try to look at this soon.
[Bug c++/101443] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443 --- Comment #3 from Andrew Pinski --- _93 = MEM[(<<< Unknown tree: nullptr_type >>> &)_84 + 32]; _94 = MEM[(<<< Unknown tree: nullptr_type >>> &)__res$second_88 + 32]; _81 = _93 < _94;
[Bug c++/101443] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443
--- Comment #2 from Rafi Wiener ---
Hey I just found that if I wrap the lines
template
struct pchar2string {
static Tcast(T& t) {return t;}
};
with those pragma to disable optimization it works.
#pragma GCC push_options
#pragma GCC optimize ("O0")
#pragma GCC pop_options
[Bug c++/101443] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-07-13
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
#6 0x0085567e in wide_int_to_tree_1 (type=0x76cd9bd0, pcst=...) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.c:1751
1751 gcc_unreachable ();
(gdb) l
1746
1747case ENUMERAL_TYPE:
1748 break;
1749
1750default:
1751 gcc_unreachable ();
1752}
1753
1754 if (ix >= 0)
1755{
(gdb) p type
$1 = (tree) 0x76cd9bd0
(gdb) p debug_tree(type)
constant 64>
unit-size constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set 46 canonical-type
0x76cd9bd0
pointer_to_this reference_to_this
>
nullptr_type seems a bit off here.
[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100949 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-July/056235.html
[Bug testsuite/101444] New: [12 regression] cc.target/powerpc/pr86731-fwrapv-longlong.c fails after r12-2266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101444 Bug ID: 101444 Summary: [12 regression] cc.target/powerpc/pr86731-fwrapv-longlong.c fails after r12-2266 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:063eba7ca73030139a3bf822ed127cf09b2fc226, r12-2266 make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pr86731-fwrapv-longlong.c" FAIL: gcc.target/powerpc/pr86731-fwrapv-longlong.c scan-assembler-times \\mp?lxv\\M|\\mlxv\\M|\\mlxvd2x\\M 2 # of expected passes3 # of unexpected failures1 This opnly fails on powerpc64 LE on a power 8 system. commit 063eba7ca73030139a3bf822ed127cf09b2fc226 (HEAD, refs/bisect/bad) Author: Michael Meissner Date: Tue Jul 13 00:36:43 2021 -0400 Deal with prefixed loads/stores in tests, PR testsuite/100166
[Bug c++/101443] New: internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443
Bug ID: 101443
Summary: internal compiler error: in wide_int_to_tree_1, at
tree.c:1519
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rawiener at amazon dot com
Target Milestone: ---
Created attachment 51147
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51147=edit
tar containg ss and ii files
Hey,
I use g++ 9.3 and got this error. I checked with godbolt.org and bug exists on
trunk as well.
gcc version:
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 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.
compiled with:
g++ -v -save-temps -O2 -Wno-multichar -Wall -Wextra bug.cpp
when compiling with O0 compilation succeeded.
output
during GIMPLE pass: dom
bug.cpp: In function 'int main()':
bug.cpp:105:5: internal compiler error: in wide_int_to_tree_1, at tree.c:1519
105 | int main() {
attached s and ii files inside the bz2 file.
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129
--- Comment #4 from Jakub Jelinek ---
I think this is a bug in the swaps rs6000 specific pass.
It in particular changes
(insn 20 19 21 2 (set (reg:DI 155)
(mult:DI (reg:DI 224)
-(subreg:DI (reg:V16QI 148) 0))) "pr101129.c":14:8 154 {muldi3}
+(subreg:DI (reg:V16QI 148) 8))) "pr101129.c":14:8 154 {muldi3}
(nil))
(insn 21 20 22 2 (set (reg:DI 156)
(subreg:DI (mult:TI (zero_extend:TI (reg:DI 224))
-(zero_extend:TI (subreg:DI (reg:V16QI 148) 0))) 8))
"pr101129.c":14:8 166 {umuldi3_highpart_le}
+(zero_extend:TI (subreg:DI (reg:V16QI 148) 8))) 0))
"pr101129.c":14:8 166 {umuldi3_highpart_le}
(nil))
The SUBREG_BYTE changes in subregs of pseudo 148 look reasonable as the pass
removed a xxswapd_v16qi that was swapping the value set to that pseudo.
But the 8 to 0 change of SUBREG_BYTE with SUBREG_REG of MULT looks wrong, that
wouldn't even match unless simplified and turns a highpart multiply into
lowpart multiply.
So either the swaps pass needs to be fixed not to do that, or the highpart
multiply instructions should be changed to e.g. use lshiftrt by 64 instead of
highpart subreg of the result.
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 Martin Sebor changed: What|Removed |Added Status|REOPENED|ASSIGNED
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #8 from Martin Sebor --- Another patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575117.html
[Bug tree-optimization/101436] Yet another bogus "array subscript is partly outside array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101436
--- Comment #3 from Cassio Neri ---
Because of the typeid check the unsafe static_cast never happens and I think
the compiler should not be warning about a problem that doesn't exist. Besides,
there's no array involved in this code. I appreciate the attempt to emit a good
warning that might improve my code but the message is completely misleading and
make me scratch my head. Here the code is minimal and obvious to figure out
that there's no array. In a large code base I could spend longtime looking for
an array that doesn't exist or I could find an array that has no issue but the
compiler makes me think it has.
Re using a dynamic_cast: I could surely use a dynamic_cast in real code but
this is a compiler test case. IMHO, it should be minimal, straight to the point
at the expense of neglecting other aspects of the language (e.g. better
practices) that could otherwise divert the attention. As I said the virtual
destructor in A and the typeid check were there to avoid obvious UB that would
happen had I unconditionally performed the static_cast. In that UB case
(provided the message were clearer and not misleading talking about arrays) I'd
be very grateful for getting the warning.
Notice also that I provided a couple of changes that don't make the code any
better w.r.t. an unsafe static_cast (which, again, is never performed). These
changes make the spurious warning to go away (which is good) and this shows
that there's certainly something wrong with the logic that decides to emit the
warning for the code as originally posted.
What about this example which involves no virtual method and where dynamic_cast
cannot help?
struct A {
int type;
};
struct C1 {
int i;
int j;
};
struct C2 {
int i;
};
template
struct B : A {
B() : A{i} {}
T x;
};
using BC1 = B;
using BC2 = B;
void do_something(int);
BC2 get_BC();
void h(A& a) {
if (a.type == 1) {
BC1& b = static_cast(a);
int i = b.x.i;
do_something(i);
}
else if (a.type == 2) {
BC2& b = static_cast(a);
int i = b.x.i;
do_something(i);
}
}
void foo() {
auto x = get_BC();
h(x);
}
Here again, there are changes that make the code no better w.r.t. a potential
unsafe cast but do make the warning to go away:
1) Change the return type of get_BC to BC1.
2) Remove C1::j.
3) Remove the extra level of indirection given by template class B. (See [2].)
[1] Example above: https://godbolt.org/z/Tha3M6xq3
[2] Example with no template: https://godbolt.org/z/nWsPvTrYr
[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100949
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
Tentative patch which regtests ok:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index de406ad2e8f..9e0dcdefd25 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1741,8 +1741,9 @@ gfc_trans_class_init_assign (gfc_code *code)
}
}
- if (code->expr1->symtree->n.sym->attr.optional
- || code->expr1->symtree->n.sym->ns->proc_name->attr.entry_master)
+ if (code->expr1->symtree->n.sym->attr.dummy
+ && (code->expr1->symtree->n.sym->attr.optional
+ || code->expr1->symtree->n.sym->ns->proc_name->attr.entry_master))
{
tree present = gfc_conv_expr_present (code->expr1->symtree->n.sym);
tmp = build3_loc (input_location, COND_EXPR, TREE_TYPE (tmp),
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 --- Comment #11 from H.J. Lu --- The v3 patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575102.html
[Bug c++/101442] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442
--- Comment #1 from Egor ---
Example is provided below. It prints `A()` and nothing else. I expected it to
also pring `~A()`.
```
#include
struct A
{
A() {std::cout << "A()\n";}
A(const A &) = delete;
A =(const A &) = delete;
~A() {std::cout << "~A()\n";}
};
struct B
{
const A
std::string s;
};
B foo()
{
B ret{ A{}, "" };
return ret;
}
int main()
{
B b = foo();
}
```
[Bug c++/101442] New: Destructor not called for a temporary object, if it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442 Bug ID: 101442 Summary: Destructor not called for a temporary object, if it Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iamsupermouse at mail dot ru Target Milestone: ---
[Bug libstdc++/101263] non-propagating-cache::emplace-deref missing constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101263 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Last reconfirmed||2021-07-13 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Patrick Palka --- It looks like emplace-deref was made constexpr in R1 of the paper, but we only implemented R0. Fortunately this added constexpr seems to be the only functional change in R1 vs R0. We might first need to implement P2231 (for constexpr optional) before this function can be properly constexpr.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 101436, which changed state. Bug 101436 Summary: Yet another bogus "array subscript is partly outside array bounds" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101436 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug tree-optimization/101436] Yet another bogus "array subscript is partly outside array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101436
Martin Sebor changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=98266,|
|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=101374|
Resolution|--- |WONTFIX
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Martin Sebor ---
The reports in pr98266 and pr101374 are unrelated. This instance of the
warning is by design: it points out an access to an object of one type (B)
by an lvalue of an unrelated type (B). Such accesses are invalid and can
be unsafe regardless of whether the offset of the accessed member is fully
within the bounds of the accessed object (GCC relies on the requirement to
optimize code).
The problem can be reduced to the following C example:
$ cat a.c && gcc -Wall -S -O2 a.c
struct A { int i; };
struct B { struct A a; int j, k; };
struct C { struct A a; int j; };
int is_B (struct A *); // return nonzero for instances of B
int f (struct C c)
{
struct A *p =
if (is_B (p))
{
struct B *q = (struct B*)p;
return q->a.i; // invalid
}
return 0;
}
a.c: In function ‘f’:
a.c:13:15: warning: array subscript ‘struct B[0]’ is partly outside array
bounds of ‘struct C[1]’ [-Warray-bounds]
13 | return q->a.i;
| ^~
a.c:7:17: note: object ‘c’ of size 8
7 | int f (struct C c)
|~^
The cast that safely converts a pointer/reference down an inheritance hierarchy
is dynamic_cast. Using it avoids the warning. Using typeid and static_cast is
a convoluted way to do the same thing except that it exposes the potential
problem to the warning code: a) because the typeid equality isn't folded and b)
the static_cast is just a straight conversion whereas dynamic_cast is a
function call whose result in the IL is unrelated to its operand.
[Bug target/101384] [9/10/11/12 Regression] wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384 --- Comment #5 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #3) > Created attachment 51146 [details] > gcc12-pr101384.patch Bootstrap/regtest found a bug in the gcc.dg/pr101384.c test, if (y[i] != ((i & 3) ? 0x : 0x8000)) should be if (y[i] != ((i & 1) ? 0x : 0x8000)) Doing bootstrap/regtest now without the patch (just with the new tests) to have base against which to compare and will see if the test fails there. When compiling with cross-compiler, just gcc -O2 -S pr101384.c , copying to GCCFarm and running there reproduces it.
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 --- Comment #2 from Segher Boessenkool --- A good solution would add all those historical targets to rs6000_machine_from_flags.
[Bug d/101441] New: __FUNCTION__ doesn't work in core.stdc.stdio functions without cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101441
Bug ID: 101441
Summary: __FUNCTION__ doesn't work in core.stdc.stdio functions
without cast
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: SztfG at yandex dot ru
Target Milestone: ---
testcase:
import core.stdc.stdio;
extern(C) int main(int argc, char **argv)
{
// works in ldc, dmd, doesnt work in gdc
puts(__FUNCTION__);
puts("test" ~ __FUNCTION__ ~ "test");
// works everywhere
puts(cast(char*)__FUNCTION__);
puts(cast(char*)("test " ~ __FUNCTION__ ~ "test"));
return 0;
}
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- The -many is problematic, that is the whole point of this. As in this example: on different subtargets there are different machine code translations for the same mnemonic!
[Bug target/101384] [9/10/11/12 Regression] wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384 --- Comment #4 from Segher Boessenkool --- The testcase works fine for me? What does it need to fail?
[Bug tree-optimization/100137] [10/11 Regression] -Warray-bounds false positive on varying offset plus negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137 Bug 100137 depends on bug 101374, which changed state. Bug 101374 Summary: [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Martin Sebor --- Fixed by r12-2171; Go fixed by r12-2234.
[Bug d/101440] New: Documentation bug for __attribute__ ((access))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101440 Bug ID: 101440 Summary: Documentation bug for __attribute__ ((access)) Product: gcc Version: 10.1.0 URL: https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Common-F unction-Attributes.html Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: SztfG at yandex dot ru Target Milestone: --- >From documentation: > Examples of the use of the read_only access mode is the argument to the puts > function, or the second and third arguments to the memcpy function. > __attribute__ ((access (read_only, 1, 2))) void* memcpy (void*, const void*, > size_t); There is no reference to "third argument in memcpy function". Or I don't understand something? Maybe there must be __attribute__ ((access (write_only, 1, 3), access (read_only, 2, 3))) void* memcpy (void* restrict, const void* restrict, size_t); so, if we have void *memcpy(void *dest, const void *src, size_t n); then this function can write "size_t n" bytes to "void *dest" and read "size_t n" bytes from "void *src"
[Bug libstdc++/101439] New: std::atomic<__uint128_t>::load() crashes - possible fix with mutable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101439
Bug ID: 101439
Summary: std::atomic<__uint128_t>::load() crashes - possible
fix with mutable
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: doodspav at gmail dot com
Target Milestone: ---
The following code will cause a segfault on x86 from g++4.8 up to g++11.1
(currently the latest non-trunk version on Godbolt):
```
#include
struct S { long i, j; };
const std::atomic x{ {0, 0} };
int f(const std::atomic* p) {
S y = *p;
return y.i;
}
int main() {
return f();
}
```
(demonstrated here: https://godbolt.org/z/eWcTv5fdY for however long the link
remains alive)
Loading the value from `x` causes libatomic to use `lock cmpxchg16b` on
read-only memory, crashing the program (since `lock cmpxchg16b` always performs
a write).
This has been reported in bug report 95722 (and touched upon in 70490), however
those treat it as a libatomic bug (which it technically is), whereas here I
seek to treat it as a libstdc++ bug.
A "simple" workaround for C++ that doesn't involve changing anything in
libatomic would be to mark all members in any 16 byte specialisation of
`std::atomic` as `mutable`, preventing the compiler from placing it in
read-only memory. This is what MSVC does in their implementation (as does
Boost.Atomic I think). This shouldn't break anything as far as I can tell.
This code (using `_Atomic`) also causes a segfault in C. I can't really think
of a similar fix there (maybe just act as if DR459 never happened?).
[Bug libstdc++/101361] Bogus -Wstringop-overread warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361
--- Comment #8 from Martin Sebor ---
The warning depends on the optimizer for eliminating unreachable code but not
all of it can be. For example, the abort below isn't. In theory it could be
but with longer strings that require memory allocation it gets harder. As
discussed in pr98465, some sort of an attribute telling GCC that a and b's data
are disjoint might help.
void g (void)
{
std::string a ("abcd");
std::string b (a);
if (a != b)
__builtin_abort ();
}
In general, code that depends on pointer relationships is not handled optimally
in GCC. Some unreachable code is introduced by GCC itself as a result of
passes like jump threading and that probably could be avoided.
[Bug inline-asm/101438] New: Compiler hang on inline asm with local register and VLA operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101438
Bug ID: 101438
Summary: Compiler hang on inline asm with local register and
VLA operands
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: andrey.vihrov at gmail dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
Compiling this C source:
int main(void)
{
register long long rax __asm__("rax") = 0;
register long long rbx __asm__("rbx") = 0;
register long long rcx __asm__("rcx") = 0;
register long long rdx __asm__("rdx") = 0;
register long long rsi __asm__("rsi") = 0;
register long long rdi __asm__("rdi") = 0;
register long long r8 __asm__("r8") = 0;
register long long r9 __asm__("r9") = 0;
register long long r10 __asm__("r10") = 0;
register long long r11 __asm__("r11") = 0;
register long long r12 __asm__("r12") = 0;
register long long r13 __asm__("r13") = 0;
register long long r14 __asm__("r14") = 0;
register long long r15 __asm__("r15") = 0;
volatile int x = 1;
char arr[x];
__asm__ (""
:
: "r"(rax),
"r"(rbx),
"r"(rcx),
"r"(rdx),
"r"(rsi),
"r"(rdi),
"r"(r8),
"r"(r9),
"r"(r10),
"r"(r11),
"r"(r12),
"r"(r13),
"r"(r14),
"r"(r15),
"m"(arr)
);
}
with "gcc -O1 test.c" causes the compiler to hang in an infinite loop.
Note: This code could possibly be formally incorrect, as [1] warns about
potential clobbering after initialization of local register variables.
[1] https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html
[Bug libstdc++/101361] Bogus -Wstringop-overread warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4d3eaeb4f505b0838c673ee28e7dba8687fc8272 commit r12-2285-g4d3eaeb4f505b0838c673ee28e7dba8687fc8272 Author: Jonathan Wakely Date: Tue Jul 13 12:21:27 2021 +0100 libstdc++: Simplify basic_string_view::ends_with [PR 101361] The use of npos triggers a diagnostic as described in PR c++/101361. This change replaces the use of npos with the exact length, which is already known. We can further simplify it by inlining the effects of compare and substr, avoiding the redundant range checks in the latter. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR c++/101361 * include/std/string_view (ends_with): Use traits_type::compare directly.
[Bug c/101437] New: [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437
Bug ID: 101437
Summary: [12 Regression] ICE: Segmentation fault signal
terminated program cc1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
struct s
{
unsigned int : 1;
};
inline static void foo(int x)
{
struct s this_struct = {.var = x};
*((volatile struct s *) 0x88UL) = this_struct;
}
void bar()
{
foo(0);
}
$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210711 (experimental)
Copyright (C) 2021 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.
$ gcc-sp12 test.c
test.c: In function ‘foo’:
test.c:9:28: error: ‘struct s’ has no member named ‘var’
9 | struct s this_struct = {.var = x};
|^~~
test.c:9:34: warning: excess elements in struct initializer
9 | struct s this_struct = {.var = x};
| ^
test.c:9:34: note: (near initialization for ‘this_struct’)
gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 101181, which changed state. Bug 101181 Summary: [11/12 Regression] ICE when using an alias template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101181 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/101181] [11/12 Regression] ICE when using an alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101181 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for GCC 11.2/12
[Bug c++/101247] ICE when using static constexpr bool defined in parent-class in nested class constructor requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101247 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |11.2 Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed for GCC 11.2/12
[Bug c++/101194] [9/10 Regression] aggregate init requires default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194 Patrick Palka changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10 Regression] aggregate |aggregate init requires |init requires default |default constructor |constructor --- Comment #5 from Patrick Palka --- Fixed for 11.2/12 so far
[Bug c++/98832] CTAD fails for alias template of aggregate with specified undeducible template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98832 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.2 --- Comment #4 from Patrick Palka --- Fixed for 11.2/12
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 101182, which changed state. Bug 101182 Summary: [concepts] ICE with ++ in non-template requires-expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101182 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/101182] [concepts] ICE with ++ in non-template requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101182 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.2 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for 11.2/12
[Bug c++/100918] [9/10 Regression] Naming a destructor as a qualified template-id results in bogus access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918 Patrick Palka changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10 Regression] Naming a |Naming a destructor as a|destructor as a qualified |qualified template-id |template-id results in |results in bogus access |bogus access error |error | --- Comment #4 from Patrick Palka --- Fixed for 11.2/12 so far
[Bug c++/97420] [9/10 Regression] NTTP function reference cannot bind to noexcept function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420 Patrick Palka changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10 Regression] NTTP |NTTP function reference |function reference cannot |cannot bind to noexcept |bind to noexcept function |function| --- Comment #9 from Patrick Palka --- Fixed for 11.2/12 so far
[Bug c++/101181] [11/12 Regression] ICE when using an alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101181 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:63566075309907ca807c1c6cef57bf19f4602825 commit r11-8734-g63566075309907ca807c1c6cef57bf19f4602825 Author: Patrick Palka Date: Fri Jul 9 10:20:25 2021 -0400 c++: requires-expr with dependent extra args [PR101181] Here we're crashing ultimately because the mechanism for delaying substitution into a requires-expression (and constexpr if and pack expansions) doesn't expect to see dependent args. But we end up capturing dependent args here during substitution into the default template argument as part of coerce_template_parms for the dependent specialization p. This patch enables the commented out code in add_extra_args for handling this situation. This isn't needed for pack expansions (as the accompanying comment points out), and it doesn't seem strictly necessary for constexpr if either, but for requires-expressions delaying even dependent substitution is important for ensuring we don't evaluate requirements out of order. It turns out we also need to make a copy of the arguments when capturing them so that coerce_template_parms doesn't later add to them and form an unexpected cycle (REQUIRES_EXPR_EXTRA_ARGS (t) would indirectly point to t). We also need to make tsubst_template_args handle missing template arguments, since the arguments we capture from coerce_template_parms and are incomplete at that point. PR c++/101181 gcc/cp/ChangeLog: * constraint.cc (tsubst_requires_expr): Pass complain/in_decl to add_extra_args. * cp-tree.h (add_extra_args): Add complain/in_decl parameters. * pt.c (build_extra_args): Make a copy of args. (add_extra_args): Add complain/in_decl parameters. Enable the code for handling the case where the extra arguments are dependent. (tsubst_pack_expansion): Pass complain/in_decl to add_extra_args. (tsubst_template_args): Handle missing template arguments. (tsubst_expr) : Pass complain/in_decl to add_extra_args. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires26.C: New test. * g++.dg/cpp2a/lambda-uneval16.C: New test. (cherry picked from commit 2c699fd29829cd6115f78238dab7cab74f0a5009)
[Bug c++/101247] ICE when using static constexpr bool defined in parent-class in nested class constructor requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101247 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6d11dd94e53103641f9826b14e3086399f2a948c commit r11-8733-g6d11dd94e53103641f9826b14e3086399f2a948c Author: Patrick Palka Date: Fri Jul 9 10:20:22 2021 -0400 c++: find_template_parameters and TEMPLATE_DECLs [PR101247] r12-1989 fixed the testcase in the PR, but unfortunately the fix is buggy: it breaks the case where the common template between the TEMPLATE_DECL t and ctx_parms is the innermost template (as in concepts-memtmpl5.C below). This can be fixed by instead passing the TREE_TYPE of ctmpl to common_enclosing_class when ctmpl is a class template. But even after that's fixed, the analogous case where the innermost template is a partial specialization is still broken (as in concepts-memtmpl5a.C below), because ctmpl is always a primary template. So this patch instead takes a diferent approach that doesn't rely on ctx_parms at all: when looking for the template parameters of a TEMPLATE_DECL that are shared with the current template context, just walk its DECL_CONTEXT. As long as the template is not overly general (e.g. we didn't pass it through most_general_template), this should give us exactly what we want, since if a TEMPLATE_DECL can be referred to from some template context then the template parameters it uses must all be in-scope and contained in its DECL_CONTEXT. This effectively makes us treat TEMPLATE_DECLs more similarly to other _DECLs (whose DECL_CONTEXT we also walk). PR c++/101247 gcc/cp/ChangeLog: * pt.c (any_template_parm_r) : Just walk the DECL_CONTEXT. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memtmpl4.C: Uncomment the commented out example, which we now handle correctly. * g++.dg/cpp2a/concepts-memtmpl5.C: New test. * g++.dg/cpp2a/concepts-memtmpl5a.C: New test. (cherry picked from commit f53e66019df819f55d424cc56f8b0ea81c074b55)
[Bug c++/101247] ICE when using static constexpr bool defined in parent-class in nested class constructor requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101247 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2902f2d8424cfa365fec49401fa066e2b6de9ca4 commit r11-8732-g2902f2d8424cfa365fec49401fa066e2b6de9ca4 Author: Patrick Palka Date: Fri Jul 2 13:54:57 2021 -0400 c++: unqualified member template in constraint [PR101247] Here any_template_parm_r is failing to mark the template parameters implicitly used by the unqualified use of 'd' inside the constraint because the code to do so assumes each level of a template parameter list points to the corresponding primary template, but here the parameter level for A in the out-of-line definition of A::B does not (nor do the parameter levels for A and C in the definition of A::C), which causes us to overlook the sharing. So it seems we can't in general depend on the TREE_TYPE of a template parameter level being non-empty here. This patch partially fixes this by rewriting the relevant part of any_template_parm_r to not depend on the TREE_TYPE of outer levels. We still depend on the innermost level to point to the innermost primary template, so we still crash on the commented out line in the below testcase. PR c++/101247 gcc/cp/ChangeLog: * pt.c (any_template_parm_r) : Rewrite to use common_enclosing_class and to not depend on the TREE_TYPE of outer levels pointing to the corresponding primary template. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memtmpl4.C: New test. (cherry picked from commit e3528ce197f8886869f95e8a8f901861a319851c)
[Bug c++/101194] [9/10/11/12 Regression] aggregate init requires default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1b57a9fb90552e52f2a121e2ae12534484b39859 commit r11-8731-g1b57a9fb90552e52f2a121e2ae12534484b39859 Author: Patrick Palka Date: Wed Jun 30 20:44:52 2021 -0400 c++: cxx_eval_array_reference and empty elem type [PR101194] Here the initializer for x is represented as an empty CONSTRUCTOR due to its empty element type. So during constexpr evaluation of the ARRAY_REF x[0], we end up trying to value initialize the omitted element at index 0, which fails because the element type is not default constructible. This patch makes cxx_eval_array_reference specifically handle the case where the element type is an empty type. PR c++/101194 gcc/cp/ChangeLog: * constexpr.c (cxx_eval_array_reference): When the element type is an empty type and the corresponding element is omitted, just return an empty CONSTRUCTOR instead of attempting value initialization. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-empty16.C: New test. (cherry picked from commit a688c284dd3848b6c4ea553035f0f9769fb4fbc9)
[Bug c++/98832] CTAD fails for alias template of aggregate with specified undeducible template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98832 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:660cbbae327fbfa315e26d286b03efffc3c21cb5 commit r11-8730-g660cbbae327fbfa315e26d286b03efffc3c21cb5 Author: Patrick Palka Date: Thu Jun 24 13:11:44 2021 -0400 c++: alias CTAD and aggregate deduction cand [PR98832] During alias CTAD, we're accidentally ignoring the aggregate deduction candidate for the underlying template because this guide is added separately via maybe_aggr_guide (which doesn't yet handle alias templates) instead of via deduction_guides_for (which does). This patch makes maybe_aggr_guide handle alias templates in a manner similar to deduction_guides_for. PR c++/98832 gcc/cp/ChangeLog: * pt.c (maybe_aggr_guide): Handle alias templates appropriately. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/class-deduction-alias9.C: New test. (cherry picked from commit c761be53f6b62e22ac5de18c4aaf88648f64f5b7)
[Bug c++/101182] [concepts] ICE with ++ in non-template requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101182 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0f6c007f3f7e9b6fdd9906ed1e4c791f6b15 commit r11-8729-g0f6c007f3f7e9b6fdd9906ed1e4c791f6b15 Author: Patrick Palka Date: Thu Jun 24 11:29:02 2021 -0400 c++: requires-expression folding [PR101182] Here we're crashing because cp_fold_function walks into the (templated) requirements of a requires-expression outside a template, but the folding routines aren't prepared to handle templated trees. This patch fixes this by making cp_fold use evaluate_requires_expr to fold a requires-expression as a whole, which also means we no longer need to explicitly do so during gimplification. (Note that we delay folding of such requires-expressions for sake of better diagnostics when one is used as the condition of a failed static_assert.) PR c++/101182 gcc/cp/ChangeLog: * constraint.cc (evaluate_requires_expr): Adjust function comment. * cp-gimplify.c (cp_genericize_r) : Move to ... (cp_fold) : ... here. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires25.C: New test. (cherry picked from commit c06493dc30afbf65b14d783c7cd53f20877ef577)
[Bug libstdc++/100387] ranges::minmax compares moved-out value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100387 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:927548b42c4850094eb41c7ae882cbe219b24231 commit r11-8728-g927548b42c4850094eb41c7ae882cbe219b24231 Author: Patrick Palka Date: Fri Jun 18 19:33:39 2021 -0400 libstdc++: Reduce ranges::minmax/minmax_element comparison complexity This rewrites ranges::minmax and ranges::minmax_element so that it performs at most 3*N/2 many comparisons, as required by the standard. In passing, this also fixes PR100387 by avoiding a premature std::move in ranges::minmax and in std::shift_right. PR libstdc++/100387 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__minmax_fn::operator()): Rewrite to limit comparison complexity to 3*N/2. (__minmax_element_fn::operator()): Likewise. (shift_right): Avoid premature std::move of __result. * testsuite/25_algorithms/minmax/constrained.cc (test04, test05): New tests. * testsuite/25_algorithms/minmax_element/constrained.cc (test02): Likewise. (cherry picked from commit cc9c94d43dcfa98436152af9c00f011e9dab25f6)
[Bug c++/100918] [9/10/11/12 Regression] Naming a destructor as a qualified template-id results in bogus access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6530cf0d50ae4c23c8e1ba908d1d0d4472e2966c commit r11-8727-g6530cf0d50ae4c23c8e1ba908d1d0d4472e2966c Author: Patrick Palka Date: Mon Jun 7 12:02:08 2021 -0400 c++: access of dtor named by qualified template-id [PR100918] Here, when resolving the destructor named by Inner::~Inner (which is valid until C++20) we end up in cp_parser_lookup_name called indirectly from cp_parser_template_id to look up the name Inner from the scope Inner. The lookup naturally finds the injected-class-name, and because the flag is_template is true, we adjust this lookup result to the TEMPLATE_DECL Inner. We then check access of this adjusted lookup result. But this access check fails because the lookup scope is Inner and the context_for_name_lookup for the TEMPLATE_DECL is Outer (whereas for the injected-class-name it's also Inner). The simplest fix seems to be to check access of the original lookup result (the injected-class-name) instead of the adjusted result (the TEMPLATE_DECL). So this patch moves the access check in cp_parser_lookup_name to before the injected-class-name adjustment. PR c++/100918 gcc/cp/ChangeLog: * parser.c (cp_parser_lookup_name): Check access of the lookup result before we potentially adjust an injected-class-name to its TEMPLATE_DECL. gcc/testsuite/ChangeLog: * g++.dg/template/access38.C: New test. (cherry picked from commit 6cb35b606c39d5f21f3298c77bfbcaaef3fbc872)
[Bug c++/97420] [9/10/11/12 Regression] NTTP function reference cannot bind to noexcept function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:bbad9d7cfdb8dd8e28589160120546a61adeeedf commit r11-8726-gbbad9d7cfdb8dd8e28589160120546a61adeeedf Author: Patrick Palka Date: Wed May 26 08:35:31 2021 -0400 c++: Fix reference NTTP binding to noexcept fn [PR97420] Here, in C++17 mode, convert_nontype_argument_function is rejecting binding a non-noexcept function reference template parameter to a noexcept function (encoded as the template argument '*(int (&) (int)) '). The first roadblock to making this work is that the argument is wrapped an an implicit INDIRECT_REF, so we need to unwrap it before calling strip_fnptr_conv. The second roadblock is that the NOP_EXPR cast converts from a function pointer type to a reference type while simultaneously removing the noexcept qualification, and fnptr_conv_p doesn't consider this cast to be a function pointer conversion. This patch fixes this by making fnptr_conv_p treat REFERENCE_TYPEs and POINTER_TYPEs interchangeably. Finally, in passing, this patch also simplifies noexcept_conv_p by removing a bunch of redundant checks already performed by its only caller fnptr_conv_p. PR c++/97420 gcc/cp/ChangeLog: * cvt.c (noexcept_conv_p): Remove redundant checks and simplify. (fnptr_conv_p): Don't call non_reference. Use INDIRECT_TYPE_P instead of TYPE_PTR_P. * pt.c (convert_nontype_argument_function): Look through implicit INDIRECT_REFs before calling strip_fnptr_conv. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept68.C: New test. (cherry picked from commit b4329e3dd6fb7c78948fcf9d2f5b9d873deec284)
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 93781, which changed state. Bug 93781 Summary: Optimizer produces suboptimal code related to -ftree-vrp https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/93781] Optimizer produces suboptimal code related to -ftree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Andrew Macleod --- Recomputation now resolves all the tests in the series.
[Bug tree-optimization/93781] Optimizer produces suboptimal code related to -ftree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781 --- Comment #9 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:f75560398af6f1f696c820016f437af4e8b4265c commit r12-2284-gf75560398af6f1f696c820016f437af4e8b4265c Author: Andrew MacLeod Date: Tue Jul 13 09:41:30 2021 -0400 Adjust testcase to test the call is removed. Ranger now handles the test. gcc/testsuite PR tree-optimization/93781 * gcc.dg/tree-ssa/pr93781-1.c: Check that call is removed.
[Bug middle-end/101062] [10 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] wrong |[10 Regression] wrong code |code with "-O2 |with "-O2 |-fno-toplevel-reorder |-fno-toplevel-reorder |-frename-registers" |-frename-registers" --- Comment #19 from Jakub Jelinek --- Fixed for 11.2 and trunk so far.
[Bug inline-asm/100785] [9/10 Regression] ICE: in expand_asm_stmt with "m" and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100785 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10 Regression] ICE: in |ICE: in expand_asm_stmt |expand_asm_stmt with "m" |with "m" and bitfield |and bitfield --- Comment #10 from Jakub Jelinek --- Fixed for 11.2 and trunk so far.
[Bug tree-optimization/101419] [9/10/11 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |collapsing memset() calls |collapsing memset() calls |can break |can break |__builtin_object_size() |__builtin_object_size() --- Comment #22 from Jakub Jelinek --- Fixed on the trunk. Unsure about backports.
[Bug tree-optimization/101434] vector-by-vector left shift expansion for char/short is not optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101434 --- Comment #3 from Uroš Bizjak --- (In reply to Richard Biener from comment #1) > Probably low priority if not doable nicely w/o XOP. -mxop can be substituted with -mavx512bw -mavx512vl for the same effect.
[Bug target/101384] [9/10/11/12 Regression] wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 51146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51146=edit gcc12-pr101384.patch Untested fix. easy_altivec_constant has code to try construct vector constants with different element sizes, perhaps different from CONST_VECTOR's mode. But as written, that works fine for vspltis[bhw] cases, but not for the vspltisw x,-1; vsl[bhw] x,x,x case, because that creates always a V16QImode, V8HImode or V4SImode constant containing broadcasted constant with just the MSB set. Perhaps for backports it would be best to limit the EASY_VECTOR_MSB case matching to step == 1 && copies == 1, because that is the only case the splitter handled correctly, but as can be seen in the gcc.target tests, the patch tries to handle it for all the cases.
[Bug tree-optimization/101434] vector-by-vector left shift expansion for char/short is not optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101434 --- Comment #2 from Richard Biener --- So technically (int)short-var << a -> short-var << (min (a, 15)) we know a is <= 31 because of the int shift (and >= 0) but we cannot simply emit short-var << a because how the target behaves is not well-defined (SHIFT_COUNT_TRUNCATED) but the behavior is well-defined for the int << int shift. Pattern recog has code to deal with this in theory but it gives up here and does not bother to emit a min ().
[Bug libstdc++/101361] Bogus -Wstringop-overread warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361 --- Comment #6 from Jonathan Wakely --- And that change only helps the testcase in comment 1, not the original one in comment 0.
[Bug tree-optimization/101434] vector-by-vector left shift expansion for char/short is not optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101434 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-07-13 Target||x86_64-*-* i?86-*-* Blocks||53947 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||missed-optimization --- Comment #1 from Richard Biener --- Probably low priority if not doable nicely w/o XOP. Note this is mainly due to integer promotion rules (we see shifts of int by int) and fear of introducing undefined behavior (the int by int shift has larger valid ranges for the RHS than a truncated one). There must be a duplicate bugreport. IMHO we might consider to make shifts of smaller than int types with out of bound shift amounts well-defined. I think there's no way to rewrite types to avoid the undefined behavior like we can do with signed arithmetic -> unsigned arithmetic (besides division by -1 where the sign matters). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/101384] [9/10/11/12 Regression] wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Summary|wrong code at -Og and above |[9/10/11/12 Regression] |with vector shift/multiply |wrong code at -Og and above ||with vector shift/multiply Priority|P3 |P2 Last reconfirmed||2021-07-13 Status|UNCONFIRMED |NEW Target Milestone|--- |9.5
[Bug target/101384] wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384 --- Comment #2 from Jakub Jelinek --- r226407 works fine, r23 already fails (even at -O0 or -O2 or -Og).
[Bug c++/101435] Bad error with missing typename keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101435 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-13 Keywords||diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=16233 --- Comment #2 from Jonathan Wakely --- Right, "typename M" would be invalid, you only need "typename" before a nested name like M::Scalar, where M is dependent. This is nothing to do with PR 63392. Confirmed as a diagnostic bug. It would be good to get a fix-it here. Maybe a dup of PR 16233.
[Bug tree-optimization/101436] Yet another bogus "array subscript is partly outside array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101436 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I guess it would be nice if devirt was able to optimize away the typeid comparison. But even when it is not, I'd perhaps understand the warning if b.x.j was accessed (though still warning on dead code), but b.x.i is present in both B and B.
[Bug tree-optimization/101436] New: Yet another bogus "array subscript is partly outside array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101436
Bug ID: 101436
Summary: Yet another bogus "array subscript is partly outside
array bounds"
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Target Milestone: ---
This bogus warning was reported at least twice recently: #98266 and #101374.
Below is a new case that, it seems, hasn't been addressed yet.
#include
struct A {
virtual ~A();
};
template
struct B : A {
T x;
};
struct C1 {
int i;
double j;
};
struct C2 {
int i;
};
void do_something(int);
B get_BC2();
void h(A& a) {
if (typeid(a) == typeid(B)) {
B& b = static_cast&>(a);
int i = b.x.i;
do_something(i);
}
}
void foo() {
B x = get_BC2();
h(x);
}
Compiled with '-O3 -Warray-bounds' yields:
: In function 'void foo()':
:27:9: warning: array subscript 'B[0]' is partly outside array
bounds of 'B [1]' [-Warray-bounds]
27 | int i = b.x.i;
| ^
:33:9: note: while referencing 'x'
33 | B x = get_BC2();
FWIW:
1) This is a regression from GCC 10.3.
2) The warning goes away if any of the following changes are made:
* Remove C1::j.
* Change type of C1::j to any of int, char, bool, unsigned or float. (Perhaps
any type T such that sizeof(T) <= sizeof(int)).
* Compile with '-fPIC' (however, if h is marked inline then the warning comes
back).
3) If b is declared as B (as opposed to B&), then the warning points to
line 'struct B: A {'.
4) The test case could be simplified further by removing A's virtual destructor
and the typeid check. However, this would make the code to invoke UB and I hope
the code above doesn't.
5) #98266 regards virtual inheritance which does not appear here and a test
cases therein issues no warning when compiled with GCC 11.1.
6) IIUC the warning reported by #101374 happens in GCC's own code and was
caused by some recent change that is not part of GCC 11.1. Indeed a test case
reported therein compiles fine with GCC 11.1 whereas the one above doesn't.
See also:
Test case above: https://godbolt.org/z/n4obaohPs
Test case from #98266: https://godbolt.org/z/PEjfhs3T6
Test case from #101374: https://godbolt.org/z/Ebb8YszT5
[Bug libstdc++/101361] Bogus -Wstringop-overread warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361
--- Comment #5 from Jonathan Wakely ---
This would be better, because it avoids the redundant range checking done when
this->compare calls this->substr:
{
const auto __len = this->size();
const auto __xlen = __x.size();
return __len >= __xlen
&& traits_type::compare(end() - __xlen, __x.data(), __xlen) == 0;
}
But there's still a bug if the compiler warns about unreachable code. The npos
is passed to substr as __n which does:
const size_type __rlen = std::min(__n, _M_len - __pos);
So there is no way we ever pass that value to memcmp. From my uninformed point
of view this seems like a problem with jump threading vs VRP and changing
libstdc++ just sweeps it under the rug.
[Bug libstdc++/101361] Bogus -Wstringop-overread warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361 --- Comment #4 from Jonathan Wakely --- It seems acceptable, but isn't the diagnostic bug still there if users write exactly the same code? The use of npos there is valid.
[Bug c++/101430] Passing a lambda as a template argument causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101430 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Ever confirmed|0 |1 Last reconfirmed||2021-07-13 --- Comment #1 from Jonathan Wakely --- Confirmed. Not a regression.
[Bug c++/101435] Bad error with missing typename keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101435
--- Comment #1 from Tobias Schlüter ---
Grrr, I made a mistake in describing the issue with the code: what is missing
is the `template` keyword before `cast`, so it should read
return err == 0 ? M{ v.template cast() } : fallback;
^
Of course GCC gives errors everywhere but there :D
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 Richard Biener changed: What|Removed |Added Known to work||11.1.1 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Priority|P3 |P2 --- Comment #16 from Richard Biener --- Fixed.
[Bug tree-optimization/101291] [10/11 Regression] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:5df86357becfc5c3a676b9f506bf2c1c625306f2 commit r11-8725-g5df86357becfc5c3a676b9f506bf2c1c625306f2 Author: Richard Biener Date: Mon Jul 5 11:53:07 2021 +0200 middle-end/101291 - set loop copy of versioned loop This fixes the vectorizer loop versioning code failing to clear niter related info on the scalar loop as it assumed get_loop_copy would work even for the outermost loop. The patch makes that assumption hold by adjusting the loop versioning code. 2021-07-05 Richard Biener PR middle-end/101291 * cfgloopmanip.c (loop_version): Set the loop copy of the versioned loop to the new loop. (cherry picked from commit 38872c6c0db1b10b17d3913b277c499913208d0b)
[Bug tree-optimization/101394] [9/10/11 Regression] ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:7d060844c0de1ed65da84374cae6fa1598011f4a commit r11-8724-g7d060844c0de1ed65da84374cae6fa1598011f4a Author: Richard Biener Date: Mon Jul 12 10:49:03 2021 +0200 tree-optimization/101394 - fix PRE full redundancy wrt abnormals This avoids adding a copy from an abnormal picked up from PHI translation much like we'd avoid inserting the translated expression on pred edges. 2021-07-12 Richard Biener PR tree-optimization/101394 * tree-ssa-pre.c (do_pre_regular_insertion): Avoid inserting copies from abnormals for a full redundancy. * gcc.dg/torture/pr101394.c: New testcase. (cherry picked from commit 92343e0ba4d47f21ae20ffcb83d736bdbc15dae0)
[Bug tree-optimization/101423] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7113 since r12-1951-ga3aaba68405751ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101423 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:2d90f3ed9c63926cb6f150aa0dcad4d16a4c16c7 commit r11-8723-g2d90f3ed9c63926cb6f150aa0dcad4d16a4c16c7 Author: Richard Biener Date: Mon Jul 12 10:26:25 2021 +0200 middle-end/101423 - internal calls do not trap This adjusts gimple_could_trap_p to not consider internal function calls to trap compared to indirect calls or calls to weak functions. 2021-07-12 Richard Biener PR middle-end/101423 * gimple.c (gimple_could_trap_p_1): Internal function calls do not trap. * tree-eh.c (tree_could_trap_p): Likewise. (cherry picked from commit 123d0a597beb6d9865f808bf15b0d67f2a8fd5b2)
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:f32145c27eec468247353b59ec5f62fcba3ae2c7 commit r11-8722-gf32145c27eec468247353b59ec5f62fcba3ae2c7 Author: Richard Biener Date: Thu Jul 1 10:35:38 2021 +0200 tree-optimization/100778 - fix placement of trapping vectorized ops This avoids placing possibly trapping vectorized operations where the corresponding scalar operation was possibly not executed. 2021-01-07 Richard Biener PR tree-optimization/100778 * tree-vect-slp.c (vect_schedule_slp_node): Do not place trapping vectorized ops ahead of their scalar BB. * gcc.dg/torture/pr100778.c: New testcase. (cherry picked from commit a3aaba68405751bae3f630669515b7ecdf77efa6)
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 --- Comment #14 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:1c2e5ab1468d959200334f2f5039d8d6af01f9fb commit r11-8721-g1c2e5ab1468d959200334f2f5039d8d6af01f9fb Author: Richard Biener Date: Fri May 28 14:26:06 2021 +0200 tree-optimization/100778 - avoid cross-BB vectorization of trapping op This avoids vectorizing a possibly trapping operation when lanes are handled in different BBs. I spotted this when working on the originally reported issue in PR100778. 2021-05-28 Richard Biener PR tree-optimization/100778 * tree-vect-slp.c (vect_build_slp_tree_1): Prevent possibly trapping ops in different BBs. * gcc.dg/vect/bb-slp-pr100778-1.c: New testcase. (cherry picked from commit f7a07f5a5d8065e7f11133dd1f4ad3510ab2195b)
[Bug c++/101435] New: Bad error with missing typename keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101435
Bug ID: 101435
Summary: Bad error with missing typename keyword
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobi at gcc dot gnu.org
Target Milestone: ---
Consider (https://godbolt.org/z/hxnv779Tr):
===
template
class X {
public:
U v;
using Scalar = U;
static constexpr auto Dim = dim;
explicit X(U x) : v(x) {}
template
X cast()
{
return X(T{v});
}
};
void f(int err) {
auto propertyHelper = [err](M&& fallback) -> M {
using FloatM = X;
FloatM v{0};
return err == 0 ? M{ v.cast() } : fallback;
};
}
This gives the fairly confusing error messages:
+++
: In lambda function:
:23:28: error: expected primary-expression before '{' token
23 | return err == 0 ? M{ v.cast() } : fallback;
|^
:23:28: error: expected ':' before '{' token
23 | return err == 0 ? M{ v.cast() } : fallback;
|^
|:
:23:28: error: expected primary-expression before '{' token
:23:28: error: expected ';' before '{' token
23 | return err == 0 ? M{ v.cast() } : fallback;
|^
|;
:23:55: error: expected '(' before '>' token
23 | return err == 0 ? M{ v.cast() } : fallback;
| ^
| (
:23:57: error: expected primary-expression before ')' token
23 | return err == 0 ? M{ v.cast() } : fallback;
| ^
:23:58: error: expected ';' before '}' token
23 | return err == 0 ? M{ v.cast() } : fallback;
| ^~
| ;
:23:61: error: expected primary-expression before ':' token
23 | return err == 0 ? M{ v.cast() } : fallback;
| ^
Compiler returned: 1
+++
The actual cause of the error is the missing typename keyword before M (clang
points this out correctly, MSVC of course accepts the code without error
message). This is similar to #63392 but in that case we at least get a hint as
to what the actual problem is.
[Bug tree-optimization/101434] New: vector-by-vector left shift expansion for char/short is not optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101434
Bug ID: 101434
Summary: vector-by-vector left shift expansion for char/short
is not optimal
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcase:
--cut here--
short r[8], a[8], b[8];
void f1 (void)
{
int i;
for (i = 0; i < 8; i++)
r[i] = a[i] << b[i];
}
--cut here--
compiles with -O2 -ftree-vectorize -mxop to:
vmovdqa a(%rip), %xmm0
vmovdqa b(%rip), %xmm1
vpmovsxwd %xmm0, %xmm2
vpsrldq $8, %xmm0, %xmm0
vpmovsxwd %xmm1, %xmm3
vpsrldq $8, %xmm1, %xmm1
vpshad %xmm3, %xmm2, %xmm2
vpmovsxwd %xmm0, %xmm0
vpmovsxwd %xmm1, %xmm1
vpshad %xmm1, %xmm0, %xmm0
vpperm .LC0(%rip), %xmm0, %xmm2, %xmm2
vmovdqa %xmm2, r(%rip)
ret
SImode vpshad is used together with lots of other instructions, but a HImode
vpshaw should be emitted instead.
Similar testcase:
--cut here--
short r[8], a[8], b[8];
void f2 (void)
{
int i;
for (i = 0; i < 8; i++)
r[i] = a[i] >> b[i];
}
--cut here--
results in expected HImode vect-by-vect shift insn:
vpxor %xmm0, %xmm0, %xmm0
vpsubw b(%rip), %xmm0, %xmm0
vpshaw %xmm0, a(%rip), %xmm0
vmovdqa %xmm0, r(%rip)
ret
(do not bother with vpxor and vpsubw, these are just one of XOP peculiarities.)
[Bug tree-optimization/101390] Expand vector mod as vector div + multiply-subtract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > scalar patterns are the appropriate way to do this There may be parts of the compiler I'm not familiar here, so apologies... By scalar patterns do you mean something in match.pd?
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Then this looks fixed to me...
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431 --- Comment #8 from Eric Botcazou --- > With -gsplit-dwarf (and without -gno-as-loc-support) I can reproduce in 11, > but not on the trunk, where it got fixed with > r12-1777-ga21dc9d1529b8a8071e36b22b6e8492fc2ce7d5a > The .file 0 emission in 11 used to be guarded with asm_outputs_debug_line_str > which is false for split dwarf. r12-1777-ga21dc9d1529b8a8071e36b22b6e8492fc2ce7d5a has been backported onto the 11 branch as r11-8650-gf19b20de1b24d6b53479c6815316a5201b22775d.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #21 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:dddb6ffdc5c25264dd75ad82dad8e48a0718d2d9 commit r12-2270-gdddb6ffdc5c25264dd75ad82dad8e48a0718d2d9 Author: Jakub Jelinek Date: Tue Jul 13 11:04:22 2021 +0200 passes: Fix up subobject __bos [PR101419] The following testcase is miscompiled, because VN during cunrolli changes __bos argument from address of a larger field to address of a smaller field and so __builtin_object_size (, 1) then folds into smaller value than the actually available size. copy_reference_ops_from_ref has a hack for this, but it was using cfun->after_inlining as a check whether the hack can be ignored, and cunrolli is after_inlining. This patch uses a property to make it exact (set at the end of objsz pass that doesn't do insert_min_max_p) and additionally based on discussions in the PR moves the objsz pass earlier after IPA. 2021-07-13 Jakub Jelinek Richard Biener PR tree-optimization/101419 * tree-pass.h (PROP_objsz): Define. (make_pass_early_object_sizes): Declare. * passes.def (pass_all_early_optimizations): Rename pass_object_sizes there to pass_early_object_sizes, drop parameter. (pass_all_optimizations): Move pass_object_sizes right after pass_ccp, drop parameter, move pass_post_ipa_warn right after that. * tree-object-size.c (pass_object_sizes::execute): Rename to... (object_sizes_execute): ... this. Add insert_min_max_p argument. (pass_data_object_sizes): Move after object_sizes_execute. (pass_object_sizes): Likewise. In execute method call object_sizes_execute, drop set_pass_param method and insert_min_max_p non-static data member and its initializer in the ctor. (pass_data_early_object_sizes, pass_early_object_sizes, make_pass_early_object_sizes): New. * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Use (cfun->curr_properties & PROP_objsz) instead of cfun->after_inlining. * gcc.dg/builtin-object-size-10.c: Pass -fdump-tree-early_objsz-details instead of -fdump-tree-objsz1-details in dg-options and adjust names of dump file in scan-tree-dump. * gcc.dg/pr101419.c: New test.
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431 Jakub Jelinek changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- With -gsplit-dwarf (and without -gno-as-loc-support) I can reproduce in 11, but not on the trunk, where it got fixed with r12-1777-ga21dc9d1529b8a8071e36b22b6e8492fc2ce7d5a The .file 0 emission in 11 used to be guarded with asm_outputs_debug_line_str which is false for split dwarf.
[Bug c++/101433] New: [modules] Bad File Data from simple function returning std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101433
Bug ID: 101433
Summary: [modules] Bad File Data from simple function returning
std::vector
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: C.Damerius at gmx dot de
Target Milestone: ---
We have two files, A.cpp, and B.cpp with the contents:
A.cpp:
export module A;
import ;
std::vector ReturnVector() {
std::vector result;
return result;
}
B.cpp:
export module B;
import A;
We execute the following commands:
g++-11 -std=c++20 -fmodules-ts -c -x c++-system-header vector
g++-11 -std=c++20 -fmodules-ts -c -o A.o A.cpp
g++-11 -std=c++20 -fmodules-ts -c -o B.o B.cpp
This produces the following output:
In module imported at B.cpp:3:1:
A: error: failed to read compiled module: Bad file data
A: note: compiled module file is ‘gcm.cache/A.gcm’
A: fatal error: returning to the gate for a mechanical issue
compilation terminated.
Version, System Type and Configuration/Build options as of "g+-11 -v":
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~21.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--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 --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-RPS7jb/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-RPS7jb/gcc-11-11.1.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~21.04)
[Bug tree-optimization/101432] NULL dereferences aren't assumed to be unreachable even with -fdelete-null-pointer-checks -fno-isolate-erroneous-paths-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101432 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-13 --- Comment #1 from Richard Biener --- -fisolate-erroneous-paths-dereference is the only one that "elides" the null dereference but it doesn't currently have a way to optimistically remove it, instead it places a trap at the path entry unconditionally. Thus you get f: .LFB0: .cfi_startproc testb %dil, %dil je .L2 movl0, %eax ud2 .p2align 4,,10 .p2align 3 .L2: movl$42, %eax ret there are duplicate enhancement requests for an option to control this behavior. The current default behavior is on purpose.
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> (In reply to Richard Biener from comment #4)
> > > cat tmp/t.c
> > void foo(int i) {}
> > > gcc-11 -g -o tmp/t.o tmp/t.c -c
> >
> > and the DWARF ends up
> >
> > <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
> >DW_AT_producer: (indirect string, offset: 0x0): GNU C17 11.1.1
> > 20210428 -mtune=generic -march=x86-64 -g
> > <11> DW_AT_language: 29 (C11)
> > <12> DW_AT_name: (indirect line string, offset: 0x0): tmp/t.c
> > <16> DW_AT_comp_dir: (indirect line string, offset: 0x8): /
> > <1a> DW_AT_low_pc : 0x0
> > <22> DW_AT_high_pc : 0xa
> > <2a> DW_AT_stmt_list : 0x0
> >
> > ...
> > The Directory Table (offset 0x22, lines 2, columns 1):
> > Entry Name
> > 0 (indirect line string, offset: 0xa): tmp
> > 1 (indirect line string, offset: 0xe): tmp
> >
> > The File Name Table (offset 0x30, lines 2, columns 2):
> > Entry Dir Name
> > 0 0 (indirect line string, offset: 0x12): tmp/t.c
> > 1 1 (indirect line string, offset: 0x1a): t.c
> >
> > I suspect this is because of how GCC and gas together end up producing
> > .debug_line - we have
> >
> > .file "t.c"
> > .text
> > ...
> > foo:
> > .LFB0:
> > .file 1 "tmp/t.c"
> > ...
> > .section.debug_line,"",@progbits
> > .Ldebug_line0:
> > .file 0 "/" "tmp/t.c"
> >
> > but this .file 0 ends up taking the place of comp-dir and it also
> > ends up duplicating the file entry for t.c unnecessarily. I'm not
> > familiar with how the DWARF5 stuff was set up so I hope somebody
> > else can have a look.
> >
> > Note the referenced testcase in github uses -gsplit-dwarf.
>
> This was with binutils 2.36.1 and GCC configured against that.
But it looks good (apart from duplicated file entry) with -gno-as-loc-support:
The Directory Table (offset 0x22, lines 2, columns 1):
Entry Name
0 (indirect line string, offset: 0x10): /
1 (indirect line string, offset: 0x0): tmp
The File Name Table (offset 0x30, lines 2, columns 2):
Entry Dir Name
0 0 (indirect line string, offset: 0x4): tmp/t.c
1 1 (indirect line string, offset: 0xc): t.c
it looks like some configury doesn't work as expected? The driver
passes --gdwarf-5 to the assembler.
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431
--- Comment #5 from Richard Biener ---
(In reply to Richard Biener from comment #4)
> > cat tmp/t.c
> void foo(int i) {}
> > gcc-11 -g -o tmp/t.o tmp/t.c -c
>
> and the DWARF ends up
>
> <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
>DW_AT_producer: (indirect string, offset: 0x0): GNU C17 11.1.1
> 20210428 -mtune=generic -march=x86-64 -g
> <11> DW_AT_language: 29 (C11)
> <12> DW_AT_name: (indirect line string, offset: 0x0): tmp/t.c
> <16> DW_AT_comp_dir: (indirect line string, offset: 0x8): /
> <1a> DW_AT_low_pc : 0x0
> <22> DW_AT_high_pc : 0xa
> <2a> DW_AT_stmt_list : 0x0
>
> ...
> The Directory Table (offset 0x22, lines 2, columns 1):
> Entry Name
> 0 (indirect line string, offset: 0xa): tmp
> 1 (indirect line string, offset: 0xe): tmp
>
> The File Name Table (offset 0x30, lines 2, columns 2):
> Entry Dir Name
> 0 0 (indirect line string, offset: 0x12): tmp/t.c
> 1 1 (indirect line string, offset: 0x1a): t.c
>
> I suspect this is because of how GCC and gas together end up producing
> .debug_line - we have
>
> .file "t.c"
> .text
> ...
> foo:
> .LFB0:
> .file 1 "tmp/t.c"
> ...
> .section.debug_line,"",@progbits
> .Ldebug_line0:
> .file 0 "/" "tmp/t.c"
>
> but this .file 0 ends up taking the place of comp-dir and it also
> ends up duplicating the file entry for t.c unnecessarily. I'm not
> familiar with how the DWARF5 stuff was set up so I hope somebody
> else can have a look.
>
> Note the referenced testcase in github uses -gsplit-dwarf.
This was with binutils 2.36.1 and GCC configured against that.
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431
--- Comment #4 from Richard Biener ---
> cat tmp/t.c
void foo(int i) {}
> gcc-11 -g -o tmp/t.o tmp/t.c -c
and the DWARF ends up
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_producer: (indirect string, offset: 0x0): GNU C17 11.1.1
20210428 -mtune=generic -march=x86-64 -g
<11> DW_AT_language: 29 (C11)
<12> DW_AT_name: (indirect line string, offset: 0x0): tmp/t.c
<16> DW_AT_comp_dir: (indirect line string, offset: 0x8): /
<1a> DW_AT_low_pc : 0x0
<22> DW_AT_high_pc : 0xa
<2a> DW_AT_stmt_list : 0x0
...
The Directory Table (offset 0x22, lines 2, columns 1):
Entry Name
0 (indirect line string, offset: 0xa): tmp
1 (indirect line string, offset: 0xe): tmp
The File Name Table (offset 0x30, lines 2, columns 2):
Entry Dir Name
0 0 (indirect line string, offset: 0x12): tmp/t.c
1 1 (indirect line string, offset: 0x1a): t.c
I suspect this is because of how GCC and gas together end up producing
.debug_line - we have
.file "t.c"
.text
...
foo:
.LFB0:
.file 1 "tmp/t.c"
...
.section.debug_line,"",@progbits
.Ldebug_line0:
.file 0 "/" "tmp/t.c"
but this .file 0 ends up taking the place of comp-dir and it also
ends up duplicating the file entry for t.c unnecessarily. I'm not
familiar with how the DWARF5 stuff was set up so I hope somebody
else can have a look.
Note the referenced testcase in github uses -gsplit-dwarf.
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431 --- Comment #3 from roc at ocallahan dot org --- This is the Fedora 34 package. $ gcc --version gcc (GCC) 11.1.1 20210531 (Red Hat 11.1.1-3) $ rpm -qa|grep ^gcc-11 gcc-11.1.1-3.fc34.x86_64 $ rpm -qa|grep binutils-2 binutils-2.35.1-41.fc34.x86_64
