[Bug middle-end/63184] [9/10/11/12 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-Septemb ||er/578859.html --- Comment #28 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578859.html
[Bug target/88473] AVX512: constant folding on mask does not remove unnecessary instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88473
--- Comment #9 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > The UNSPEC_MASKOP ones are still there.
> >
> > PR 93885 is the same issue.
>
> void test(void* data, void* data2)
> {
> __m128i v = _mm_load_si128((__m128i const*)data);
> __mmask8 m = _mm_testn_epi16_mask(v, v);
> m = m | 0x0f;
> m = m | 0xf0;
> v = _mm_maskz_add_epi16(m, v, v);
> _mm_store_si128((__m128i*)data2, v);
> }
>
> Should be ok.
>
> Currently we rely on RA to choose whether to use mask register or gpr for
> bitwise operation, which means that if we remove UNSPEC_MASKOP, _kor_mask8
> will only generate gpr orb, to ensure the correspondence between intrinsic
> and instruction, UNSPEC_MASKOP is necessary, if the user wants GCC to
> optimize bitwise operation, it is recommended to use bitwise operator
> instead of intrinsic.
Similar for 88476
[Bug target/88473] AVX512: constant folding on mask does not remove unnecessary instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88473
--- Comment #8 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #7)
> The UNSPEC_MASKOP ones are still there.
>
> PR 93885 is the same issue.
void test(void* data, void* data2)
{
__m128i v = _mm_load_si128((__m128i const*)data);
__mmask8 m = _mm_testn_epi16_mask(v, v);
m = m | 0x0f;
m = m | 0xf0;
v = _mm_maskz_add_epi16(m, v, v);
_mm_store_si128((__m128i*)data2, v);
}
Should be ok.
Currently we rely on RA to choose whether to use mask register or gpr for
bitwise operation, which means that if we remove UNSPEC_MASKOP, _kor_mask8 will
only generate gpr orb, to ensure the correspondence between intrinsic and
instruction, UNSPEC_MASKOP is necessary, if the user wants GCC to optimize
bitwise operation, it is recommended to use bitwise operator instead of
intrinsic.
[Bug target/102211] ICE introduced by r12-3277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211 --- Comment #2 from Hongtao.liu --- According to *movsi_internal and *movdi_64bit, SImode, and DImode can be placed into FP_REGS, but in riscv_hard_regno_mode_ok, SImode/DImode is not allowed to be allocated as FP_REGS, the mismatch here caues the ICE. Simple hack as modified gcc/config/riscv/riscv.c @@ -4553,7 +4553,9 @@ riscv_hard_regno_mode_ok (unsigned int regno, machine_mode mode) return false; if (GET_MODE_CLASS (mode) != MODE_FLOAT - && GET_MODE_CLASS (mode) != MODE_COMPLEX_FLOAT) + && GET_MODE_CLASS (mode) != MODE_COMPLEX_FLOAT + && mode != E_SImode + && mode != E_DImode) return false; /* Only use callee-saved registers if a potential callee is guaranteed Solved the issue. foo: fmv.d.x fa5,a0 fmul.s fa0,fa0,fa5
[Bug target/102211] ICE introduced by r12-3277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
--- Comment #1 from Hongtao.liu ---
But it's ok for
float
foo (float a, long b)
{
union{float a[2];
long b;}c;
c.b = b;
return c.a[0];
}
foo:
fmv.w.x fa0,a0
ret
Which means movement between gpr and float reg is allowed.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after 94e24187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #1 from Greg Turner --- (In reply to Greg Turner from comment #0) > this bug report will be long and confusing tldr: as of 94e24187 host-optimized gcc exhibits ICEs while building complex C++ projects on AMD zen hosts. The problem manifests during gimplification, usually nondeterministically. Reverting 94e24187 resolves the problem, however the ultimate cause is as of yet undiagnosed. Full details in my original long and confusing post :)
[Bug target/102211] New: ICE introduced by r12-3277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
Bug ID: 102211
Summary: ICE introduced by r12-3277
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: sch...@linux-m68k.org
Target Milestone: ---
Target: risv64
cat test.c
float
foo (float a, long b)
{
union{float a[2];
long b;}c;
c.b = b;
return c.a[0] * a;
}
gcc test.c -O2 -S
test.c:8:1: error: this is the insn:
(insn 12 19 13 2 (set (reg/i:SF 42 fa0)
(mult:SF (reg:SF 77)
(subreg:SF (reg:DI 80 [78]) 0))) "test.c":8:1 17 {mulsf3}
(expr_list:REG_DEAD (reg:DI 80 [78])
(expr_list:REG_DEAD (reg:SF 77)
(nil
during RTL pass: reload
[Bug tree-optimization/84794] memcpy/memmove between a struct and its first member not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84794 --- Comment #5 from Andrew Pinski --- One simple way of doing this is seeing if ptr_difference_const returns true and the difference is 0. I have not checked if this works but it just might.
[Bug bootstrap/89140] libiberty/pex-unix.c fails to compile in aarch64-to-x86_64 cross build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89140 Brett Neumeier changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Brett Neumeier --- (In reply to Andrew Pinski from comment #1) > >the configure script for libiberty finds that getrusage is not available but > >wait4 is. > > Both should be there. Hello Andrew Pinski! Thank you for looking at this. I experimentally removed the patch from my build process and find that the issue no longer occurs with current versions of the GNU toolchain components (binutils 2.37, glibc 2.34, gcc 11.2.0). So there is probably no point in leaving this bug open. I'm marking it as resolved.
[Bug middle-end/63184] [9/10/11/12 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184 --- Comment #27 from Andrew Pinski --- Created attachment 51411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51411=edit patch which I am testing
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660 --- Comment #13 from Andrew Pinski --- This has been fixed at r12-2039-gcd48e550d1dc583, if we use the C++ front-end. Using the C front-end we still have a casting issue.
[Bug middle-end/63184] [9/10/11/12 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184
Andrew Pinski changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #26 from Andrew Pinski ---
So what is interesting is for aarch64, GCC is able to figure out the two values
are equal but only after register allocation (note LLVM has a similar issue
too).
Anyways at forwprop4 we have:
_5 = [1] + _4;
_13 = _3 + 8;
_7 = + _13;
if (_5 != _7)
I think I have a patch (I need to format it correctly though):
(for neeq (ne eq)
(simplify
(neeq (pointer_plus ADDR_EXPR@0 @1) (pointer_plus ADDR_EXPR@2 @3))
(with { poly_int64 diff; }
(if (ptr_difference_const (@0, @2, ))
(neeq (plus { build_int_cst_type (type, diff); }
(convert (minus @1 @3)))
{build_zero_cst (type); })
I also added this one too as I saw that was not being folded either:
(simplify
(pointer_diff (pointer_plus ADDR_EXPR@0 @1) (pointer_plus ADDR_EXPR@2 @3))
(with { poly_int64 diff; }
(if (ptr_difference_const (@0, @2, ))
(plus { build_int_cst_type (type, diff); } (convert (minus @1 @3))
[Bug middle-end/46555] [9/10/11/12 Regression] PHI RTL expansion leads to CSiBE regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46555
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2016-01-05 00:00:00 |2021-9-5
--- Comment #14 from Andrew Pinski ---
Still happening on the trunk:
(code_label 164 163 165 24 2 (nil) [5 uses])
(note 165 164 11 24 [bb 24] NOTE_INSN_BASIC_BLOCK)
(insn 11 165 180 24 (set (reg:HI 110 [ ])
(const_int -1 [0x]))
"/home/jan/Downloads/CSiBE/src/./OpenTCP-1.0.4/icmp.c":112:9 -1
(nil))
(jump_insn 180 11 181 24 (set (pc)
(label_ref:SI 170)) 842 {jump}
(nil)
-> 170)
(barrier 181 180 183)
(code_label 183 181 182 25 14 (nil) [1 uses])
(note 182 183 12 25 [bb 25] NOTE_INSN_BASIC_BLOCK)
(insn 12 182 170 25 (set (reg:HI 110 [ ])
(const_int -1 [0x]))
"/home/jan/Downloads/CSiBE/src/./OpenTCP-1.0.4/icmp.c":155:2 -1
(nil))
[Bug c/102210] New: Invalid assembly generated while building OpenSSH on hppa64-hp-hpux11.23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102210
Bug ID: 102210
Summary: Invalid assembly generated while building OpenSSH on
hppa64-hp-hpux11.23
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: me at larbob dot org
Target Milestone: ---
Created attachment 51410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51410=edit
bsd-closefrom.i from -save-temps
I am running GCC 11.1.0 on hppa64-hp-hpux11.23.
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/util/gcc64/gcc-11.1.0/libexec/gcc/hppa64-hp-hpux11.23/11.1.0/lto-wrapper
Target: hppa64-hp-hpux11.23
Configured with: ../../sources/gcc-11.1.0/configure
--prefix=/usr/util/gcc64/gcc-11.1.0 --disable-nls --disable-libgomp
--enable-languages=c,c++ --with-gmp=/usr/util/gcc64/gmp-6.1.0
--with-mpfr=/usr/util/gcc64/mpfr-3.1.6 --with-mpc=/usr/util/gcc64/mpc-1.0.3
--without-gnu-ld --with-gnu-as --with-as=/usr/util/gcc64/binutils-2.25/bin/as
CONFIG_SHELL=/usr/util/bin/bash AWK=/usr/util/bin/awk SED=/usr/util/bin/sed
CC=/usr/util/gcc64/gcc-7.2.0/bin/gcc CXX=/usr/util/gcc64/gcc-7.2.0/bin/g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.0 (GCC)
While building OpenSSH 8.7p1 (or older versions, tested some 7.x versions):
gcc -g -O2 -pipe -Wno-error=format-truncation -Wall -Wextra -Wpointer-arith
-Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess
-Wno-pointer-sign -Wno-unused-parameter -Wno-unused-result
-Wimplicit-fallthrough -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv
-fno-builtin-memset -fPIC -I. -I.. -I. -I./.. -I/usr/util/openssl/include
-I/usr/util/include -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1
-DHAVE_CONFIG_H -c bsd-closefrom.c
{standard input}: Assembler messages:
{standard input}:79: Error: Invalid Add Condition: tsv
{standard input}:79: Error: Invalid operands
make[1]: *** [Makefile:104: bsd-closefrom.o] Error 1
This only seems to happen when GCC is compiled for the hppa64-hp-hpux11.*
target, not hppa2.0w-hp-hpux11.* or other 32-bit PA-RISC targets. I have tested
this with a much different version of binutils (2.25 vs. 2.37) and have run
into the same issue. Furthermore, I've also tested with GCC 4.7.1 and run into
the same issue.
[Bug tree-optimization/80511] [9/10/11/12 Regression] gcc.dg/Wstrict-overflow-18.c gcc.dg/Wstrict-overflow-7.c gcc.dg/pragma-diag-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80511 Andrew Pinski changed: What|Removed |Added CC||david at westcontrol dot com --- Comment #10 from Andrew Pinski --- *** Bug 100702 has been marked as a duplicate of this bug. ***
[Bug middle-end/100702] Strict overflow warning regression in gcc 8 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- So this is a dup of bug 80511. *** This bug has been marked as a duplicate of bug 80511 ***
[Bug middle-end/100702] Strict overflow warning regression in gcc 8 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702 --- Comment #4 from Andrew Pinski --- gcc.dg/Wstrict-overflow-7.c is the testcase for this.
[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and backported to 11-branch. Closing. Thanks for the report!
[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:71013e5fb844cab1865a65373fdc32aa5b87a525 commit r11-8962-g71013e5fb844cab1865a65373fdc32aa5b87a525 Author: Harald Anlauf Date: Tue Aug 31 21:00:53 2021 +0200 Fortran - extend set of substring expressions handled in length simplification gcc/fortran/ChangeLog: PR fortran/100950 * simplify.c (substring_has_constant_len): Minimize checks for substring expressions being allowed. gcc/testsuite/ChangeLog: PR fortran/100950 * gfortran.dg/pr100950.f90: Extend coverage. (cherry picked from commit e4cb3bb9ac11b4126ffa718287dd509a4b10a658)
[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c94755c7734c6aac9e114fb69ca23aed524e2450 commit r11-8961-gc94755c7734c6aac9e114fb69ca23aed524e2450 Author: Harald Anlauf Date: Thu Aug 19 21:00:45 2021 +0200 Fortran - simplify length of substring with constant bounds gcc/fortran/ChangeLog: PR fortran/100950 * simplify.c (substring_has_constant_len): New. (gfc_simplify_len): Handle case of substrings with constant bounds. gcc/testsuite/ChangeLog: PR fortran/100950 * gfortran.dg/pr100950.f90: New test. (cherry picked from commit d881460deb1f0bdfc3e8fa2d391a03a9763cbff4)
[Bug c++/102209] New: NRVO for function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102209
Bug ID: 102209
Summary: NRVO for function parameters
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
I believe this is a missed optimization opportunity.
Given following class and functions:
struct s{
s();
s(const s&);
s(s&&);
void doit();
};
s bar0(){
s v = s();
v.doit();
return v;
}
s bar1(s v = s()){
v.doit();
return v;
}
void foo0(){ auto v = bar0(); }
void foo1(){ auto v = bar1(); }
I can see that in bar0, the returned s is copy (and move) elided.
But for bar1, this is not the case.
I've tried different things, like changing function signature, adding
std::forward, change optimization level, disable exceptions, but I was never
able to obtain the desired result.
As in bar1 `v` is actually built a level higher on the stack, for this
code-snippet I would even have expected GCC to have less issue optimizing the
copy/move away.
For reference: https://godbolt.org/z/oe7W3nvcP
foo0():
sub rsp, 24
callconstruct()
lea rdi, [rsp+15]
calls::doit()
calldestroy()
add rsp, 24
ret
foo1():
sub rsp, 24
callconstruct()
lea rdi, [rsp+15]
calls::doit()
callmove()
calldestroy()
add rsp, 24
jmp destroy()
In both cases, bar* has been inlined.
It can be easily verified that in the case of bar0 everything is inlined, and
no copies are made.
In the case of foo1, a temporary is created, passed to bar without moving or
copying, but when bar1 returns, a move is made.
As s is passed by value, I do not think the move is necessary.
So either my assumption is wrong, or GCC is playing safe.
I would like to know if it is a missed optimization opportunity on the side of
the programmer or compiler (for those classes where even an unnecessary move
might be costly).
[Bug c/91038] ICE with VLA type and statement expression (gimplify_var_or_parm_decl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91038 --- Comment #3 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578844.html
[Bug c/29970] mixing ({...}) with VLA leads to massive breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970 --- Comment #14 from Martin Uecker --- Another version of the patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578844.html
[Bug tree-optimization/102200] [12 Regression] ice in put_ref, at pointer-query.cc:1351 since r12-3300-gece28da924ddda8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102200 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Summary|[12 Regression] ice in |[12 Regression] ice in |put_ref, at |put_ref, at |pointer-query.cc:1351 |pointer-query.cc:1351 since ||r12-3300-gece28da924ddda8b --- Comment #2 from Martin Liška --- Started really with r12-3300-gece28da924ddda8b.
[Bug ipa/98265] [10 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265 Andrew Pinski changed: What|Removed |Added CC||tobi at gcc dot gnu.org --- Comment #13 from Andrew Pinski --- *** Bug 95859 has been marked as a duplicate of this bug. ***
[Bug ipa/95859] [10/11/12 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|10.4|10.3 Resolution|--- |DUPLICATE --- Comment #16 from Andrew Pinski --- This is an exact dup of bug 98265. *** This bug has been marked as a duplicate of bug 98265 ***
[Bug ipa/94762] [9/10/11/12 Regression] ICE: Segmentation fault (in is_tm_irrevocable) since r7-1710-g849a76a5a20db383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94762 --- Comment #4 from Andrew Pinski --- trans-mem.c does not handle any internal functions.
[Bug ipa/80277] ipa-icf overlooking functions with identical assemble and semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80277 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Target Milestone|9.5 |--- --- Comment #6 from Andrew Pinski --- Right the issue here is unsigned vs signed . To be able to ICF these two functions, GCC would take undefined code to be being defined (signed integer overflow vs unsigned wrapping).
[Bug ipa/57218] [9/10/11/12 Regression] Excessive inlining even at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57218 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Last reconfirmed|2018-02-03 00:00:00 |2021-9-5 --- Comment #18 from Andrew Pinski --- So looking at LLVM, at -Oz, the inlining is not done but at -Os it is.
[Bug middle-end/90408] >= -O2 suddenly generates code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90408 --- Comment #5 from Oliver Stoeneberg --- Alright. Just wanted to make sure it's intentional since it just happened on trunk.
[Bug middle-end/90408] >= -O2 suddenly generates code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90408 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.3 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- (In reply to Oliver Stoeneberg from comment #3) > Thanks - I checked with godbolt and it looks fine for -O1 and -O2 now. > > -Os on trunk generates an additional instruction compared to previous > versions > > xor eax, eax Yes that is on purpose as it reduces the overall size. X86 you cannot just look at the # of instructions to figure out if it is a size win. So closing as fixed.
[Bug c++/102208] New: Acceptance of invalid decltype(auto) in the default operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102208
Bug ID: 102208
Summary: Acceptance of invalid decltype(auto) in the default
operator <=>
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
GCC accepts invalid:
```
struct A { decltype(auto) operator <=>(const A &) const = default; };
```
https://gcc.godbolt.org/z/h1xxboGa9
The correct program must have simply `auto`:
```
struct A { auto operator <=>(const A &) const = default; };
```
[Bug middle-end/90408] >= -O2 suddenly generates code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90408 --- Comment #3 from Oliver Stoeneberg --- Thanks - I checked with godbolt and it looks fine for -O1 and -O2 now. -Os on trunk generates an additional instruction compared to previous versions xor eax, eax
[Bug c++/94501] arrays are not decaying to pointers in variadic function template for conversion to a function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94501
qingzhe huang changed:
What|Removed |Added
CC||nickhuang99 at hotmail dot com
--- Comment #2 from qingzhe huang ---
I believe this case of no specialization matching error is related with this
bug(clang passed, MSVC++ failed like GCC https://godbolt.org/z/KTahxj868).
Possibly it is a duplicate case. However, I can see even though the root cause
are all from template substitution, the "implicit_convert" and
"determine_specialization" are two different path. Should we dup this or create
a new, considering the fix might be quite different in these two cases? Do we
force developper to fix both cases when submitting a patch?
template
void foo(Ts...);
template<>
void foo(int*){}
:3:19: error: no matches converting function 'foo' to type 'void
(*)(int*)'
3 | void (*f)(int*) = foo;
| ^~
:2:6: note: candidate is: 'template void foo(Ts ...)'
2 | void foo(Ts...);
| ^~~
:5:6: error: template-id 'foo' for 'void foo(int*)' does not
match any template declaration
5 | void foo(int*){}
| ^~~
:2:6: note: candidate is: 'template void foo(Ts ...)'
2 | void foo(Ts...);
| ^~~
[Bug demangler/102132] [nm] Stack overflow in demangler_path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102132 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||amodra at gmail dot com Ever confirmed|0 |1 Version|unknown |12.0 Last reconfirmed||2021-09-05 --- Comment #4 from Alan Modra --- Yes, gcc's libiberty is still considered upstream of binutils' copy.
[Bug demangler/102130] [c++filt] Stack overflow in demangle_path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102130 Alan Modra changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2021-09-05 Resolution|MOVED |--- Ever confirmed|0 |1 Version|7.5.0 |12.0 CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- Even though c++filt is binutils, the problem occurs in a libiberty file and in rust-demangle.c as of 2021-08-30 in gcc master. Moved back here.
[Bug tree-optimization/102207] [12 Regression] wrong code with __builtin_sub_overflow() at -O1 and above with uint128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102207 --- Comment #2 from Jakub Jelinek --- Created attachment 51409 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51409=edit gcc12-pr102207.patch Untested fix.
[Bug tree-optimization/102207] [12 Regression] wrong code with __builtin_sub_overflow() at -O1 and above with uint128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102207 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |12.0 CC||jakub at gcc dot gnu.org Last reconfirmed||2021-09-05 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Started with my r12-3312-g2af6dd77ea742d4ee911f466878624972929508a
[Bug tree-optimization/102207] New: [12 Regression] wrong code with __builtin_sub_overflow() at -O1 and above with uint128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102207 Bug ID: 102207 Summary: [12 Regression] wrong code with __builtin_sub_overflow() at -O1 and above with uint128 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 51408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51408=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc testcase.c -O $ ./a.out Aborted The value is 128bit 0xfffe instead of 0xfffe. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-3354-20210904001638-g7b7395409c7-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-3354-20210904001638-g7b7395409c7-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210904 (experimental) (GCC)
[Bug middle-end/90408] >= -O2 suddenly generates code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90408 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98265 --- Comment #2 from Andrew Pinski --- So now -O1, -O2 and -O3 produce the same code, most likely after r10-9646/r11-7940 . -Os just does not inline the constructor ( std::__cxx11::basic_string, std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator >&&) [complete object constructor]). So I think this is fixed in GCC 10.3 and GCC 11+.
[Bug tree-optimization/90625] fold strcmp(a, b) == 0 to zero for strings of unequal but non-const lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90625 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2019-05-27 00:00:00 |2021-9-5
[Bug tree-optimization/90768] better range analysis for converting bit tests into less-than greater-than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90768
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #6 from Andrew Pinski ---
Just to make things clean these two functions should produce the same code:
#include
#include
int bcmp_1(char *a, char *b, size_t s) {
if (s < 16) {
if (s >= 8)
if (*(uint64_t *)a != *(uint64_t *)b)
return 1;
}
return 0;
}
int bcmp_2(char *a, char *b, size_t s) {
if (s < 16) {
if (s & 8)
if (*(uint64_t *)a != *(uint64_t *)b)
return 1;
}
return 0;
}
[Bug tree-optimization/81772] Compile-time snprintf optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81772 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/68211] Free __m128d subreg of double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68211 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #9 from Andrew Pinski --- I thought I saw this bug like this recently too.
[Bug middle-end/87595] __tls_get_addr should be __attribute__((__noplt__))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87595 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81501 Component|target |middle-end Severity|normal |enhancement
[Bug tree-optimization/84794] memcpy/memmove between a struct and its first member not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84794 Andrew Pinski changed: What|Removed |Added Keywords||TREE Last reconfirmed|2018-03-12 00:00:00 |2021-9-5 Severity|normal |enhancement --- Comment #4 from Andrew Pinski --- In GCC 11+ (due to r11-2647-g299c9857); expand (with ter turned on), is able to remove the memcpy call in h .
[Bug middle-end/102206] New: amd zen hosts running zen-optimized gcc: gimplification ICE after 94e24187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206
Bug ID: 102206
Summary: amd zen hosts running zen-optimized gcc:
gimplification ICE after 94e24187
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: g...@be-evil.net
Target Milestone: ---
The bad news: why this bug report will be long and confusing
There some things in this bug report that will probably make folks think "This
is a hardware or software stability problem and not gcc's fault."
Strictly speaking, I can't entirely disprove this hypothesis, but I will
present evidence below which has led me to believe it's probably a legit gcc
bug.
AFAICT, due to the nature of binary distributions, this bug manifests
exclusively on Gentoo. I imagine there are like 50 Gentoo users on Zen and 25
of them have experienced the bug, half of whom filed bug reports, and the rest
of whom shrugged it off and decided it must have been a cosmic ray or something
:)
So, Gentoo-only. "Rice" is an arguably racially-insensitive term Gentoo people
use to describe excessive customization of Gentoo systems resulting in various
breakage and non-reproducible problems. Initially I thought this was probably
a "rice"-related problem, but I have taken considerable pains to rule this out.
It's not rice-related.
But wait, there's more! It's also non-deterministically non-deterministic!
That is, almost everyone experiences this bug non-deterministically. But, for
reasons not yet understood, some users (I was once one of them) have found
configurations in which this bug manifests fully
repeatably and deterministically. Sadly, AFAICT none of these users have
managed to preserve these fully deterministic software configurations.
OK, enough prefacing. I just want to prepare the reader: the nature of this
bug/issue will raise some doubts, which will likely need to be overcome before
this bug looks "legit". I also wish to encourage the reader not to jump to
easy "not-a-bug" conclusions without careful consideration of the circumstances
presented below.
Scope/Domain of the bug
===
On Gentoo, there are several AMD Zen hardware users who report that they must
either
A) avoid building gcc with
-m{arch,tune}=znver?
and their
-m{arch,tune}=native
equivalents, or
B) must downgrade to gcc-9 or earlier.
If they fail to do so, the bug will occur, eventually. The compile which seems
to most reliably reproduce the bug is boost (any recent version will do the
trick). But it appears in other builds.
Zen (1xxx) and Zen+ (2xxx) hosts seem most susceptible. But Zen-2 and Zen 3
hosts (3xxx/4xxx(?) and 5xxx, respectively) also appear to be at least
occasionally affected.
Note that once an optimized gcc is built, optimizing the target build with
similar -m{arch,tune} options is not a requirement. But, such target
optimizations do seem to reproduce the problem with a considerably greater
probability.
Bug Manifestation
=
The bug itself appears as an ICE, stack smash, or zero-pointer-deference fault
during c++ compiles. The problem seems to always manifest during
gimplification and to produce distinctive stack-dumps, ie:
Thread 2.1 "cc1plus" received signal SIGABRT, Aborted.
[Switching to process 15911]
0x77bc3f71 in raise () from /lib64/libc.so.6
#0 0x77bc3f71 in raise () from /lib64/libc.so.6
#1 0x77bad537 in abort () from /lib64/libc.so.6
#2 0x77c08207 in ?? () from /lib64/libc.so.6
#3 0x77c99892 in __fortify_fail () from /lib64/libc.so.6
#4 0x77c99870 in __stack_chk_fail () from /lib64/libc.so.6
#5 0x0065a1f2 in cp_gimplify_expr(tree_node**, gimple**, gimple**) ()
#6 0x009f4ffc in gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) ()
#7 0x009faeb1 in ?? ()
#8 0x009f6304 in gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) ()
#9 0x009f6196 in gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) ()
#10 0x009f5d42 in gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) ()
#11 0x009f6196 in gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) ()
#12 0x009fd5b9 in ?? ()
#13 0x009f638d in gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) ()
#14 0x009f6196 in gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) ()
#15 0x009f9ed9 in gimplify_body(tree_node*, bool) ()
#16 0x009fa316 in gimplify_function_tree(tree_node*) ()
#17 0x00885f58 in cgraph_node::analyze() ()
#18 0x0078 in ?? ()
#19 0x008894c3 in
[Bug target/89954] missed optimization for signed extension for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #3 from Andrew Pinski ---
So at combine we have:
(insn 5 2 6 2 (set (reg:QI 87 [ c ])
(mem/c:QI (symbol_ref:DI ("c") [flags 0x2] ) [0 c+0 S1 A8])) "/app/example.cpp":5:14 77 {*movqi_internal}
(nil))
(insn 6 5 7 2 (parallel [
(set (reg:QI 86)
(xor:QI (reg:QI 87 [ c ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":5:14 546 {*xorqi_1}
(expr_list:REG_DEAD (reg:QI 87 [ c ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (xor:QI (mem/c:QI (symbol_ref:DI ("c") [flags
0x2] ) [0 c+0 S1 A8])
(const_int 1 [0x1]))
(nil)
(insn 7 6 12 2 (set (reg:SI 85)
(sign_extend:SI (reg:QI 86))) "/app/example.cpp":5:14 154 {extendqisi2}
(expr_list:REG_DEAD (reg:QI 86)
(nil)))
The load is not loaded into the full SI/DI register yet. The change to SI mode
for xor happens after reload in split2.
So yes it is a target issue.
[Bug middle-end/82170] gcc optimizes int range-checking poorly on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2017-09-14 00:00:00 |2021-9-4 Severity|normal |enhancement Component|target |middle-end
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 86708, which changed state. Bug 86708 Summary: strlen of an empty aggregate element or member string not folded https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86708 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/86708] strlen of an empty aggregate element or member string not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86708 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Andrew Pinski --- Fixed by r10-2769. Specifically this part of the patch: * gimple-fold.c (fold_nonarray_ctor_reference): Return a STRING_CST for missing initializers.
[Bug ipa/88971] Branch optimization inconsistency (missed optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-05
Status|UNCONFIRMED |NEW
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
Component|middle-end |ipa
--- Comment #9 from Andrew Pinski ---
This is just an inlining problem:
#include
#include
struct Data {
int i;
int j;
};
class Test {
public:
template
void CheckAndPrint(const T );
};
template
inline void Test::CheckAndPrint(const T ) {
asm volatile ("mfence" ::: "memory");
if (t.j > 0) {
std::string a = "<";
std::string b = "<";
}
asm volatile ("mfence" ::: "memory");
}
int main() {
Data data;
std::cin >> data.i;
std::cin >> data.j;
Test t;
t.CheckAndPrint(data);
return 0;
}
--- CUT
If we get rid of one of the std::string in Test::CheckAndPrint, we are able to
inline the constructor (std::__cxx11::basic_string::basic_string<> ) and
everything goes away.
One thing I noticed is:
[local count: 1073612976]:
_24 = __builtin_strlen (__s_7(D));
...
if (_24 > 15)
I wonder if we could have an IPA pass which clones this function based on the
strlen that gets pass to the second argument and such.
