[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99648
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> --- gcc/simplify-rtx.c.jj 2021-04-09 16:18:24.275668496 +0200
> +++ gcc/simplify-rtx.c2021-04-09 19:26:24.963134240 +0200
> @@ -7059,12 +7059,19 @@ simplify_immed_subreg (fixed_size_mode o
>while (buffer.length () < buffer_bytes)
> buffer.quick_push (filler);
> }
> - else
> + else if (!native_encode_rtx (innermode, x, buffer, first_byte,
> inner_bytes))
> +return NULL_RTX;
> + rtx ret = native_decode_rtx (outermode, buffer, 0);
> + if (ret && MODE_COMPOSITE_P (outermode))
> {
> - if (!native_encode_rtx (innermode, x, buffer, first_byte,
> inner_bytes))
> + auto_vec buffer2 (buffer_bytes);
> + if (!native_encode_rtx (outermode, ret, buffer2, 0, buffer_bytes))
> return NULL_RTX;
> - }
> - return native_decode_rtx (outermode, buffer, 0);
> + for (unsigned int i = 0; i < buffer_bytes; ++i)
> + if (buffer[i] != buffer2[i])
> + return NULL_RTX;
> +}
> + return ret;
> }
>
> /* Simplify SUBREG:OUTERMODE(OP:INNERMODE, BYTE)
I think this makes sense from a consistency point of view.
> Makes simplify_subreg fail when trying to subreg a constant into a composite
> floating mode that doesn't decode back.
> Unfortunately, this causes ICE:
> pr71522.c: In function ‘main’:
> pr71522.c:27:1: error: unrecognizable insn:
>27 | }
> | ^
> (insn 5 2 6 2 (set (reg/v:TF 118 [ d ])
> (subreg:TF (const_vector:V16QI [
> (const_int 65 [0x41]) repeated x15
> (const_int 0 [0])
> ]) 0)) "pr71522.c":20:3 -1
> (nil))
> during RTL pass: vregs
>
> store_bit_field_1 calls simplify_gen_subreg and that when
> simplify_immed_subreg fails will happily create the above subreg.
> So I'm quite afraid the above change could break quite a lot and so might be
> better to defer it for GCC12.
Hmm, yeah. I suppose we can force the constant to memory and do the subreg
via a load?
[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target||x86_64-linux-musl Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2021-04-12 Component|c++ |target --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source?
[Bug c++/100041] New: ICE in curr_insn_transform, at lra-constraints.c:4022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041
Bug ID: 100041
Summary: ICE in curr_insn_transform, at lra-constraints.c:4022
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mss at tutanota dot de
Target Milestone: ---
When trying to build LLVM 11.1.0 with GCC 10.3.0 on an x86_64 linux musl
(1.2.1) host, i am getting this ICE:
In file included from
/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/lib/Support/ItaniumManglingCanonicalizer.cpp:13:
/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/include/llvm/Demangle/ItaniumDemangle.h:
In member function 'void
llvm::itanium_demangle::FloatLiteralImpl::printLeft(llvm::itanium_demangle::OutputStream&)
const [with Float = long double]':
/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/include/llvm/Demangle/ItaniumDemangle.h:2144:3:
error: unable to generate reloads for:
2144 | }
| ^
(insn 157 156 158 8 (set (mem:XF (pre_modify:DI (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0]))) [485 S12 A32])
(mem/j/c:XF (reg/f:DI 19 frame) [0 D.132846.value+0 S12 A64]))
"/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/include/llvm/Demangle/ItaniumDemangle.h":2141:23
105 {*pushxf}
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
during RTL pass: reload
/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/include/llvm/Demangle/ItaniumDemangle.h:2144:3:
internal compiler error: in curr_insn_transform, at lra-constraints.c:4022
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/100040] New: Wrong code with intent out assumed-rank allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040 Bug ID: 100040 Summary: Wrong code with intent out assumed-rank allocatable Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50562&action=edit Fortran code showing problem Hi All! With intent out assumed-rank allocatable argument the generated code is missing is missing the descriptor copy out. Seen in: GNU Fortran (GCC) 11.0.1 20210411 (experimental) GNU Fortran (GCC) 10.3.1 20210411 Thank you very much. Best regards, José Rui
[Bug c++/100039] GCC can not bind lvalue to lvalue reference in brace-initialized-temporary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100039 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-04-12 Keywords||rejects-valid Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. Not a regression.
[Bug c++/100039] New: GCC can not bind lvalue to lvalue reference in brace-initialized-temporary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100039
Bug ID: 100039
Summary: GCC can not bind lvalue to lvalue reference in
brace-initialized-temporary expression
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
Consider this program:
typedef int& ref;
int main()
{
int a;
ref{a};
}
This is accepted by clang, msvc and icc. GCC 10.3 rejects this code with a
message:
error: cannot bind non-const lvalue reference of type 'ref' {aka 'int&'} to an
rvalue of type 'int'
I believe the error message is incorrect, because "a" is not an rvalue here. It
is lvalue, therefore it should be allowed to bind to lvalue reference.
https://godbolt.org/z/TWY9GPq3E
[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #12 from Marek Polacek --- Should be fixed, sorry again for the breakage.
[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:1004d3bb5e590a2cc3d22bc9fb11d3bf4978a982 commit r10-9695-g1004d3bb5e590a2cc3d22bc9fb11d3bf4978a982 Author: Marek Polacek Date: Sun Apr 11 16:58:09 2021 -0400 c++: Use FOR_EACH_VEC_ELT instead of range-based for loop. gcc/cp/ChangeLog: PR c++/97966 * pt.c (instantiate_class_template_1): Use FOR_EACH_VEC_ELT instead of range-based for loop.
[Bug middle-end/100038] -Warray-bound triggers false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038 --- Comment #6 from Nicholas Stranchfield --- Created attachment 50561 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50561&action=edit Output for only the SparseBitVector example Here the output for only the SparseBitVector.h test case.
[Bug middle-end/100038] -Warray-bound triggers false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038 --- Comment #5 from Nicholas Stranchfield --- Created attachment 50560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50560&action=edit Output for only the SmallVector example Here the output for only the SmallVector.h test case. P.S.: Sorry for the nose, mistook the attachment text area for the comment field...
[Bug middle-end/100038] -Warray-bound triggers false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038 --- Comment #4 from Nicholas Stranchfield --- Created attachment 50559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50559&action=edit gzipped output for SmallVector example
[Bug middle-end/100038] -Warray-bound triggers false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038 --- Comment #3 from Nicholas Stranchfield --- Created attachment 50558 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50558&action=edit gzipped output for SparseBitVector example
[Bug middle-end/100038] -Warray-bound triggers false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038 --- Comment #2 from Nicholas Stranchfield --- Created attachment 50557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50557&action=edit gzipped output of g++-10.2.0 Sure, here you go.
[Bug middle-end/100038] -Warray-bound triggers false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-04-11 Status|UNCONFIRMED |WAITING Keywords||diagnostic Component|c++ |middle-end --- Comment #1 from Andrew Pinski --- Can you attach the preprocessor source?
[Bug lto/100010] [8/9/10/11 Regression] ICE in lto_output_node, at lto-cgraph.c:447 (-fdevirtualize-at-ltrans) since r6-6384-gceda2c69d5219719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100010 Martin Liška changed: What|Removed |Added Target Milestone|--- |8.5 CC||hubicka at gcc dot gnu.org Summary|ICE in lto_output_node, at |[8/9/10/11 Regression] ICE |lto-cgraph.c:447|in lto_output_node, at |(-fdevirtualize-at-ltrans) |lto-cgraph.c:447 ||(-fdevirtualize-at-ltrans) ||since ||r6-6384-gceda2c69d5219719 Last reconfirmed||2021-04-11 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, started with r6-6384-gceda2c69d5219719.
[Bug c++/100038] New: -Warray-bound triggers false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038
Bug ID: 100038
Summary: -Warray-bound triggers false positives
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nicholas.stranchfi...@you-spam.com
Target Milestone: ---
When compiling LLVM, I noticed that GCC produces some -Warray-bounds warnings,
namely
In file included from mwe.cpp:4:
SparseBitVector.h: In function ‘int main()’:
SparseBitVector.h:129:15: warning: array subscript 2 is above array bounds of
‘const BitWord [2]’ {aka ‘const long unsigned int [2]’} [-Warray-bounds]
129 | if (Bits[i] != 0)
| ^
SparseBitVector.h:54:11: note: while referencing
‘llvm::SparseBitVectorElement<128>::Bits’
54 | BitWord Bits[BITWORDS_PER_ELEMENT];
| ^~~~
SparseBitVector.h:138:15: warning: array subscript 4294967295 is above array
bounds of ‘const BitWord [2]’ {aka ‘const long unsigned int [2]’}
[-Warray-bounds]
138 | if (Bits[Idx] != 0)
| ^
SparseBitVector.h:54:11: note: while referencing
‘llvm::SparseBitVectorElement<128>::Bits’
54 | BitWord Bits[BITWORDS_PER_ELEMENT];
| ^~~~
In file included from mwe.cpp:3:
SmallVector.h:537:7: warning: array subscript 1 is outside array bounds of ‘int
[1]’ [-Warray-bounds]
537 | ++EltPtr;
| ^~
mwe.cpp:21:29: note: while referencing ‘’
21 | VS.insert(VS.begin() + 1, 5);
| ^
In file included from mwe.cpp:3:
SmallVector.h:566:7: warning: array subscript 1 is outside array bounds of ‘int
[1]’ [-Warray-bounds]
566 | ++EltPtr;
| ^~
mwe.cpp:22:6: note: while referencing ‘val’
22 | int val = 6;
| ^~~
On inspection of the source, it seems these are false positives OR some
optimization went havoc (hopefully it did not), e.g. for SparseBitVector.h we
have
struct SparseBitVectorElement {
// ...
BitWord Bits[BITWORDS_PER_ELEMENT]; // line 54
// ...
int find_first() const {
for (unsigned i = 0; i < BITWORDS_PER_ELEMENT; ++i)
if (Bits[i] != 0) // line 129
// ...
}
}
which looks pretty sound to me. Searching around the internet, I'm not the
only one with these warnings, e.g. they show up in Fedora's LLVM build [0,1]
and Debian's [2].
In particular, this case looks very simple and a common theme which should not
trigger such warning.
[0]
https://kojipkgs.fedoraproject.org/packages/llvm/10.0.0/0.6.rc6.fc33/data/logs/ppc64le/build.log
[1]
https://kojipkgs.fedoraproject.org/packages/llvm/11.0.0/0.2.rc3.fc34/data/logs/s390x/build.log
[2]
https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-11&arch=amd64&ver=1%3A11.0.1-2&stamp=1609987721&raw=0
The SmallVector related warning appeared first with GCC 9.x, while the
SparseBitVector related warnings appeared with GCC 10 (tested GCC 10.2.0) and
are absent in GCC-9.3.0.
The warnings trigger with -O2 but not with -O1 and -DNDEBUG is needed for the
SparseBitVector one.
If LLVM headers (version 10 or 11) are installed, then the following minimal
working example triggers the warnings:
g++ -I/usr/lib/llvm/11/include -DNDEBUG -O2 -Warray-bounds -o mwe.cpp.o -c
mwe.cpp
cat mwe.cpp
#include "llvm/ADT/SmallVector.h"
#include "llvm/ADT/SparseBitVector.h"
#include
using namespace llvm;
int main()
{
// Trigger: SparseBitVector (lines 138, 129)
SparseBitVector<> Vec;
Vec.set(5);
// force the vector
printf("%d\n", Vec.find_first());
printf("%d\n", Vec.find_last());
// Trigger: SmallVector (lines 537, 566)
SmallVector VS = {1, 2, 3, 4};
VS.insert(VS.begin() + 1, 5);
int val = 6;
VS.insert(VS.begin() + 2, val);
// force the vector
for (int i : VS) {
printf("%d\n", i);
}
}
[Bug c++/100037] lookup doesn't find class template parameter in default member initializer of forward declared nested class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100037 --- Comment #2 from Marek Polacek --- (Not a regression AFAICT.)
[Bug c++/100037] lookup doesn't find class template parameter in default member initializer of forward declared nested class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100037 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-04-11 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Keywords||rejects-valid Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Interesting. Confirmed, thanks for the report.
[Bug c++/100037] New: lookup doesn't find class template parameter in default member initializer of forward declared nested class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100037
Bug ID: 100037
Summary: lookup doesn't find class template parameter in
default member initializer of forward declared nested
class template
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Issue title is a mouthful, but it's a very narrow case:
template using always_int = int;
struct view {
template struct iterator;
template
struct iterator {
always_int inner = always_int();
};
};
This is rejected with:
:8:46: error: 'Const' was not declared in this scope
8 | always_int inner = always_int();
| ^
:8:51: error: template argument 1 is invalid
8 | always_int inner = always_int();
| ^
This compiles if we also name the template parameter in the forward
declaration. This fails only in the case of a nested class - if you change it
to namespace view from struct view, the example compiles fine.
[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966 --- Comment #10 from Marek Polacek --- Argh! Sorry about that, will fix.
[Bug ipa/100036] New: missed optimization for dead code elimination at -Os, -O2 and -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100036
Bug ID: 100036
Summary: missed optimization for dead code elimination at -Os,
-O2 and -O3 (vs. -O1)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[562] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210411 (experimental) [master revision
1d54b138417:e83b9cf4549:936d500dfc17f58f2507ecd0f7f26e4f197052ee] (GCC)
[563] %
[563] % gcctk -O1 -S -o O1.s small.c
[564] % gcctk -O3 -S -o O3.s small.c
[565] %
[565] % wc O1.s O3.s
27 58 454 O1.s
38 77 665 O3.s
65 135 1119 total
[566] %
[566] % grep foo O1.s
[567] % grep foo O3.s
jmp foo
[568] %
[568] % cat small.c
extern void foo(void);
int a, *b;
static int c, f;
inline int *d() {
int g[100] = {0};
if (a) {
int h = g[0];
foo();
return b;
}
}
int main() {
while (1) {
if (!c)
return f;
d();
}
return 0;
}
[Bug c++/100035] New: Parameter packs not expanded with local variable in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100035
Bug ID: 100035
Summary: Parameter packs not expanded with local variable in
lambda
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/ss9bjYvc1
template
auto f(Ts...) {
([] { Ts x = 0; }, ...);
}
gcc rejects with:
: In function 'auto f(Ts ...)':
:3:4: error: operand of fold expression has no unexpanded parameter
packs
3 | ([] { Ts x = 0; }, ...);
|^~~~
[Bug c++/99961] requires clause rejects mentioning of function parameters too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99961 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug ipa/100034] New: missed optimization for dead code elimination at -O3 (vs. -O1, -Os, -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100034
Bug ID: 100034
Summary: missed optimization for dead code elimination at -O3
(vs. -O1, -Os, -O2)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[641] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210411 (experimental) [master revision
1d54b138417:e83b9cf4549:936d500dfc17f58f2507ecd0f7f26e4f197052ee] (GCC)
[642] %
[642] % gcctk -O1 -S -o O1.s small.c
[643] % gcctk -O3 -S -o O3.s small.c
[644] %
[644] % wc O1.s O3.s
23 45 420 O1.s
41 78 697 O3.s
64 123 1117 total
[645] %
[645] % grep foo O1.s
[646] % grep foo O3.s
callfoo
[647] %
[647] % cat small.c
extern void foo(void);
static int a, b, f, g;
static int d() {
while (g)
f = 0;
while (1)
foo();
}
static void c() { d (); }
void e() {
while (b) {
if (!a)
continue;
c();
}
}
int main() {
e();
return 0;
}
[Bug tree-optimization/100033] New: missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100033
Bug ID: 100033
Summary: missed optimization for dead code elimination at -O3
(vs. -O2)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[583] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210411 (experimental) [master revision
1d54b138417:e83b9cf4549:936d500dfc17f58f2507ecd0f7f26e4f197052ee] (GCC)
[584] %
[584] % gcctk -O2 -S -o O2.s small.c
[585] % gcctk -O3 -S -o O3.s small.c
[586] %
[586] % wc O2.s O3.s
52 112 797 O2.s
56 119 850 O3.s
108 231 1647 total
[587] %
[587] % grep foo O2.s
[588] % grep foo O3.s
callfoo
[589] %
[589] % cat small.c
extern void foo(void);
static volatile int a;
int b, i;
static void c() {
unsigned d = i;
a = d && a;
if (d) {
int e;
while (b) {
int *f, *g = &e, **h = &f;
*h = g;
*f = d;
}
if (!e)
foo();
}
}
int main() {
c();
return 0;
}
[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98088 Hafiz Abid qadeer changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Hafiz Abid qadeer --- Fixed in ac200799acb5cd2fb9e1758f6bf5fff1978daaeb.
[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98088
--- Comment #4 from CVS Commits ---
The master branch has been updated by Hafiz Abid Qadeer :
https://gcc.gnu.org/g:ac200799acb5cd2fb9e1758f6bf5fff1978daaeb
commit r11-8123-gac200799acb5cd2fb9e1758f6bf5fff1978daaeb
Author: Hafiz Abid Qadeer
Date: Thu Apr 8 17:31:30 2021 +0100
[OpenACC] Fix an ICE where a loop with GT condition is collapsed.
We have seen an ICE both on trunk and devel/omp/gcc-10 branches which can
be reprodued with this simple testcase. It occurs if an OpenACC loop has
a collapse clause and any of the loop being collapsed uses GT or GE
condition. This issue is specific to OpenACC.
int main (void)
{
int ix, iy;
int dim_x = 16, dim_y = 16;
{
for (iy = dim_y - 1; iy > 0; --iy)
for (ix = dim_x - 1; ix > 0; --ix)
;
}
}
The problem is caused by a failing assertion in expand_oacc_collapse_init.
It checks that cond_code for fd->loop should be same as cond_code for all
the loops that are being collapsed. As the cond_code for fd->loop is
LT_EXPR with collapse clause (set at the end of omp_extract_for_data),
this assertion forces that all the loop in collapse clause should use
< operator.
There does not seem to be anything in the code which demands this
condition as loop with > condition works ok otherwise. I digged old
mailing list a bit but could not find any discussion on this change.
Looking at the code, expand_oacc_for checks that fd->loop->cond_code is
either LT_EXPR or GT_EXPR. I guess the original intention was to have
similar checks on the loop which are being collapsed. But the way check
was written does not acheive that.
I have fixed it by modifying the check in the assertion to be same as
check on fd->loop->cond_code.
I tested goacc and libgomp (with nvptx offloading) and did not see any
regression. I have added new tests to check collapse with GT/GE condition.
PR middle-end/98088
gcc/
* omp-expand.c (expand_oacc_collapse_init): Update condition in
a gcc_assert.
gcc/testsuite/
* c-c++-common/goacc/collapse-2.c: New.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Add check
for loop with GT/GE condition.
* testsuite/libgomp.oacc-c-c++-common/collapse-3.c: Likewise.
[Bug c++/100032] [8/9/10/11 Regression] renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100032
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |8.5
CC||jason at gcc dot gnu.org
Summary|renaming alias template |[8/9/10/11 Regression]
|that also adds |renaming alias template
|cv-qualifiers is deemed |that also adds
|equivalent to underlying|cv-qualifiers is deemed
|template|equivalent to underlying
||template
--- Comment #1 from Patrick Palka ---
We started accepting the testcase after r208152.
I tried making get_underlying_template look through an alias only if the
underlying type is unqualified:
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6574,6 +6574,8 @@ get_underlying_template (tree tmpl)
/* The underlying type may have been ill-formed. Don't proceed. */
if (!orig_type)
break;
+ if (TYPE_QUALS (orig_type) != TYPE_UNQUALIFIED)
+ break;
tree tinfo = TYPE_TEMPLATE_INFO_MAYBE_ALIAS (orig_type);
if (!tinfo)
break;
but this also makes us (incorrectly?) reject
template class> struct X { };
template struct Y { };
template using Z = const Y;
template using W = Z;
using U = X;
using U = X;
because the underlying type of W for some reason already has the const
qualifier, so get_underlying_template(W) yields W and we deem W not equivalent
to Z.
[Bug target/98348] [10 Regression] GCC 10.2 AVX512 Mask regression from GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #20 from Dávid Bolvanský --- Some small regression (missed opportunity to use vptestnmd): Current trunk compare(unsigned int __vector(16)): vpxor xmm1, xmm1, xmm1 vpcmpd k0, zmm0, zmm1, 0 vpmovm2d zmm0, k0 ret GCC 9.2 compare(unsigned int __vector(16)): vptestnmd k0, zmm0, zmm0 vpmovm2d zmm0, k0 ret https://gcc.godbolt.org/z/5vK68jM3r
[Bug c++/100032] New: renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100032
Bug ID: 100032
Summary: renaming alias template that also adds cv-qualifiers
is deemed equivalent to underlying template
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
DR 1286 allows alias templates to be equivalent to the underlying template if
the alias is just a renaming of the underlying template. In the testcase
below, Z is arguably not equivalent to Y because of the added const qualifier,
but GCC still deems them equivalent, and accepts the testcase.
template class> struct X { };
template struct Y { };
template using Z = const Y;
using T = X;
using T = X;
[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966 Eric Botcazou changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED CC||ebotcazou at gcc dot gnu.org --- Comment #9 from Eric Botcazou --- This breaks the build with older compilers: ../../src/gcc/cp/pt.c: In function 'tree_node* instantiate_class_template_1(tree)': ../../src/gcc/cp/pt.c:12137:17: error: range-based 'for' loops are not allowed in C++98 mode
[Bug c++/100031] New: ICE: in dependent_type_p, at cp/pt.c:26757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100031
Bug ID: 100031
Summary: ICE: in dependent_type_p, at cp/pt.c:26757
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Related to PR 16, PR 100030.
https://godbolt.org/z/TxGMsEv6W
template
auto f(Ts...) {
[]() requires (sizeof(Ts) == 0) {};
}
int main() {
f(0);
}
:3:18: internal compiler error: in dependent_type_p, at cp/pt.c:26757
3 | []() requires (sizeof(Ts) == 0) {};
| ^~
0x1d00ea9 internal_error(char const*, ...)
???:0
0x6bb009 fancy_abort(char const*, int, char const*)
???:0
0x8fa4d8 dependent_type_p(tree_node*)
???:0
0x9c561f cxx_sizeof_or_alignof_type(unsigned int, tree_node*, tree_code, bool,
bool)
???:0
0x73fdba constraints_satisfied_p(tree_node*, tree_node*)
???:0
0x804780 maybe_add_lambda_conv_op(tree_node*)
???:0
0x94addd tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x91d71f instantiate_decl(tree_node*, bool, bool)
???:0
0x7c7a1e maybe_instantiate_decl(tree_node*)
???:0
0x7c9180 mark_used(tree_node*, int)
???:0
0x6de877 build_new_function_call(tree_node*, vec**, int)
???:0
0x981e5c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x8e223d c_parse_file()
???:0
0xa614e2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/100030] ICE: in dependent_type_p, at cp/pt.c:26757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100030 --- Comment #1 from 康桓瑋 --- Related to RP 16.
[Bug c++/100030] New: ICE: in dependent_type_p, at cp/pt.c:26757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100030
Bug ID: 100030
Summary: ICE: in dependent_type_p, at cp/pt.c:26757
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/G3a6Wq5e3
template
auto f(Ts...) {
[] { struct alignas(Ts) S {}; };
}
int main() {
f(0);
}
:3:23: internal compiler error: in dependent_type_p, at cp/pt.c:26757
3 | [] { struct alignas(Ts) S {}; };
| ^~
0x1d00ea9 internal_error(char const*, ...)
???:0
0x6bb009 fancy_abort(char const*, int, char const*)
???:0
0x8fa4d8 dependent_type_p(tree_node*)
???:0
0x9c561f cxx_sizeof_or_alignof_type(unsigned int, tree_node*, tree_code, bool,
bool)
???:0
0x9168ca tsubst_tree_list(tree_node*, tree_node*, int, tree_node*)
???:0
0x95acdc instantiate_class_template(tree_node*)
???:0
0x94ad92 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x91d71f instantiate_decl(tree_node*, bool, bool)
???:0
0x7c7a1e maybe_instantiate_decl(tree_node*)
???:0
0x7c9180 mark_used(tree_node*, int)
???:0
0x6de877 build_new_function_call(tree_node*, vec**, int)
???:0
0x981e5c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x8e223d c_parse_file()
???:0
0xa614e2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug fortran/100029] New: ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 Bug ID: 100029 Summary: ICE on subroutine call with allocatable polymorphic assumed-rank argument Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50556&action=edit Fortran code showing problem Hi All! ICE on subroutine call when passing an allocatable polymorphic assumed-rank intent-out argument. Seen in: GNU Fortran (GCC) 11.0.1 20210411 (experimental) GNU Fortran (GCC) 10.3.1 20210411 GNU Fortran (GCC) 9.3.1 20210411 Thank you very much. Best regards. José Rui
[Bug target/100021] [9/10/11 Regression] std::clamp unprofitable vectorization on -march=nehalem/.../broadwell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100021 --- Comment #2 from Uroš Bizjak --- Also, you are passing -march=sandybridge, but the profiler seems to show Skylake (SKX) target. The STV pass heavily depends on target costs, and when -march=skylake is passed, the conversion is avoided.
[Bug target/100021] [9/10/11 Regression] std::clamp unprofitable vectorization on -march=nehalem/.../broadwell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100021 --- Comment #1 from Uroš Bizjak --- This is not vectorization, but the compiler uses vector registers to perform scalar operations. This is STV (scalar-to-vector) pass in action, you can use -mno-stv to avoid transformation. The transformation is used to avoid CMOV instruction.
