[Bug ipa/109445] r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |ipa CC||marxin at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- This just seems like bad luck. Maybe look at the inline dumps see what the cost difference is.
[Bug libstdc++/109445] New: r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445 Bug ID: 109445 Summary: r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3% Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: zhangjungcc at gmail dot com Target Milestone: --- r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3% Follow is the inline dump, left dump is before the commit, right dump is after the commit. [local count: 210861628]:[local count: 210861628]: # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT _466 = s_rng;_466 = s_rng; -- _607 = _466;<> _561 = _466; _118 = _607; _118 = _561; -- _35 = this_72(D)->board.D.5191.m_empty_cnt; =_35 = this_72(D)->board.D.5191.m_empty_cnt; _5 = _35 & 65535;_5 = _35 & 65535; # DEBUG this => _118 # DEBUG this => _118 max_458 = (const uint16) _5; max_458 = (const uint16) _5; # DEBUG max => max_458 # DEBUG max => max_458 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT -- # DEBUG this => _118<> # DEBUG BEGIN_STMT # DEBUG mask => 4294967295 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT _467 = _118->s1; _468 = _467 << 13; _469 = _467 ^ _468; b_470 = _469 >> 19; # DEBUG b => b_470 # DEBUG BEGIN_STMT _471 = _467 << 12; _472 = _471 & 4294959104; _473 = b_470 ^ _472; _118->s1 = _473; # DEBUG BEGIN_STMT _474 = _118->s2; _475 = _474 << 2; _476 = _474 ^ _475; b_477 = _476 >> 25; # DEBUG b => b_477 # DEBUG BEGIN_STMT _478 = _474 << 4; _479 = _478 & 4294967168; _480 = b_477 ^ _479; _118->s2 = _480; # DEBUG BEGIN_STMT _481 = _118->s3; _482 = _481 << 3; _483 = _481 ^ _482; b_484 = _483 >> 11; # DEBUG b => b_484 # DEBUG BEGIN_STMT _485 = _481 << 17; _486 = _485 & 4292870144; _487 = b_484 ^ _486; _118->s3 = _487; # DEBUG BEGIN_STMT _488 = _473 ^ _480; _489 = _487 ^ _488; _611 = _489; _459 = random (_118); # DEBUG this => NULL # DEBUG b => NULL _459 = _611; -- _460 = _459 >> 16; =_460 = _459 >> 16; _461 = (unsigned int) max_458; _461 = (unsigned int) max_458; _462 = _460 * _461; _462 = _460 * _461; _463 = _462 >> 16; _463 = _462 >> 16; -- _612 = _463;<> _563 = _463; -- # DEBUG this => NULL=# DEBUG this => NULL # DEBUG max => NULL # DEBUG max => NULL -- _120 = _612;<> _120 = _563; -- vidx_121 = (int) _120; =vidx_121 = (int) _120; # DEBUG vidx => vidx_121 # DEBUG vidx => vidx_121 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT _37 = this_72(D)->board.D.5191.m_tomove; _37 = this_72(D)->board.D.5191.m_tomove; -- # DEBUG D#1845 => 1 <> # DEBUG D#1824 => 1 -- # DEBUG this => this_72(D) =# DEBUG this => this_72(D) # DEBUG color => _37 # DEBUG color => _37 # DEBUG vidx => vidx_121 # DEBUG vidx => vidx_121 # DEBUG allow_sa => 1# DEBUG allow_sa => 1 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT --
[Bug sanitizer/109444] Possible array overflow without diagnosis in memcpy if called within a virtual method scenario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109444 --- Comment #1 from Andrew Pinski --- There is padding bytes for Foo because the alignment of Foo needs to be the same alignment as a pointer.
[Bug sanitizer/109444] New: Possible array overflow without diagnosis in memcpy if called within a virtual method scenario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109444
Bug ID: 109444
Summary: Possible array overflow without diagnosis in memcpy if
called within a virtual method scenario
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mohamed.selim at dxc dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
It's possible to overflow the destination array size in std::memcpy, this
behavior doesn't trigger the expected sanitizer diagnosis when using memcpy in
a virtual method scenario (scenario 1).
While in (scenario 2) when the std::memcpy is called from a normal method, the
overflow is diagnosed as expected.
#include
#include
#include
// zero terminated 8 characters string literal
const char txt[] = "1234567";
class Bar
{
public:
constexpr Bar() : dst{}
{
}
std::int8_t dst[6];
};
void test(Bar& b)
{
std::cout << "staring memcpy.\n";
std::cout << "size of bytes to be copied: " << sizeof(txt) <<"\n";
std::cout << "dst array size: " << sizeof(b.dst) << "\n";
std::memcpy(b.dst, txt, sizeof(txt));
}
class Base
{
public:
virtual ~Base() = default;
virtual void func() = 0;
};
// 1 - Foo inherits Base, virtual method implementation
class Foo: public Base
{
public:
void func() override
{
test(b);
}
private:
Bar b{};
};
// 2 - no inheritance
class Foo2
{
public:
void func()
{
test(b);
}
private:
Bar b{};
};
//-std=c++14 -fsanitize=address -fsanitize=undefined -static-libasan
-static-libubsan
int main()
{
Foo c{}; // scenario 1, no sanitizer diagnosis
//Foo2 c{}; // scenario 2, triggers sanitizer diagnosis
c.func();
return 0;
}
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #5 from Jonny Grant --- I see it is more complicated than I imagined. Thank you for looking into it.
[Bug tree-optimization/35269] missed optimization of std::vector access.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #2 from AK --- I posted a revised version of this bug here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
[Bug tree-optimization/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 --- Comment #1 from AK --- Link to issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269 where I derived the testcase from.
[Bug tree-optimization/109443] New: missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Bug ID: 109443
Summary: missed optimization of std::vector access (Related to
issue 35269)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
here is slightly modified code example from issue #35269. Both accesses are
similar bug different code is generated. the function `h` has better codegen
than `g` for some reason.
$ g++ -O3 -std=c++20 -fno-exceptions
void f(int);
void g(std::vector v)
{
for (std::vector::size_type i = 0; i < v.size(); i++)
f( v[ i ] );
}
void h(std::vector v)
{
for (std::vector::const_iterator i = v.begin(); i != v.end(); ++i)
f( *i );
}
g(std::vector >):
mov rdx, QWORD PTR [rdi]
cmp QWORD PTR [rdi+8], rdx
je .L6
pushrbp
mov rbp, rdi
pushrbx
xor ebx, ebx
sub rsp, 8
.L3:
mov edi, DWORD PTR [rdx+rbx*4]
add rbx, 1
callf(int)
mov rdx, QWORD PTR [rbp+0]
mov rax, QWORD PTR [rbp+8]
sub rax, rdx
sar rax, 2
cmp rbx, rax
jb .L3
add rsp, 8
pop rbx
pop rbp
ret
.L6:
ret
h(std::vector >):
pushrbp
pushrbx
sub rsp, 8
mov rbx, QWORD PTR [rdi]
cmp rbx, QWORD PTR [rdi+8]
je .L10
mov rbp, rdi
.L12:
mov edi, DWORD PTR [rbx]
add rbx, 4
callf(int)
cmp QWORD PTR [rbp+8], rbx
jne .L12
.L10:
add rsp, 8
pop rbx
pop rbp
ret
[Bug c++/109433] [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433 --- Comment #2 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > With -std=c++11, started to ICE with r12-6326-ge948436eab818c527dd6. > With -std=c++14, started to ICE with r9-1483-g307193b82cecb8ab79cf. Yes that is exactly the same where PR 109431 started to ICE too.
[Bug target/109435] overaligned structs are not passed correctly for mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88469 --- Comment #2 from Andrew Pinski --- The aarch64 and arm backends had a similar issue which was fixed too.
[Bug tree-optimization/109442] New: Dead local copy of std::vector not removed from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
Bug ID: 109442
Summary: Dead local copy of std::vector not removed from
function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
T vat1(std::vector v1) {
auto v = v1;
return 10;
}
g++ -O3 -std=c++20 -fno-exceptions
vat1(std::vector >):
mov rax, QWORD PTR [rdi+8]
sub rax, QWORD PTR [rdi]
je .L11
pushrbp
mov rbp, rax
movabs rax, 9223372036854775804
pushrbx
sub rsp, 8
cmp rax, rbp
jb .L15
mov rbx, rdi
mov rdi, rbp
calloperator new(unsigned long)
mov rsi, QWORD PTR [rbx]
mov rdx, QWORD PTR [rbx+8]
mov rdi, rax
sub rdx, rsi
cmp rdx, 4
jle .L16
callmemmove
mov rdi, rax
.L6:
mov rsi, rbp
calloperator delete(void*, unsigned long)
add rsp, 8
mov eax, 10
pop rbx
pop rbp
ret
.L11:
mov eax, 10
ret
.L15:
callstd::__throw_bad_array_new_length()
.L16:
jne .L6
mov eax, DWORD PTR [rsi]
mov DWORD PTR [rdi], eax
jmp .L6
[Bug c/86584] Incorrect -Wsequence-point warning on structure member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584 --- Comment #2 from Andrew Pinski --- I think there is just a missing warning for the plain decl case and the structure member case is not a spurious warning.
[Bug c/86584] Incorrect -Wsequence-point warning on structure member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584 oliver at futaura dot co.uk changed: What|Removed |Added CC||oliver at futaura dot co.uk --- Comment #1 from oliver at futaura dot co.uk --- Confirmed here. Still happens with gcc (adtools build 11.2.0) 11.2.0: test.c: In function 'main': test.c:13:24: warning: operation on 's.f' may be undefined [-Wsequence-point] 13 | func(, s.f = 1); |^~~ It really doesn't make much sense for gcc to think this a problem. Going to have to disable the warning here as I can't seem to figure a way around it with unnecessarily rewriting huge chunks of code.
[Bug tree-optimization/109441] missed optimization when all elements of vector are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441
--- Comment #1 from AK ---
I guess a better test case is this:
#include
using namespace std;
using T = int;
T v(std::vector v) {
T s;
std::fill(v.begin(), v.end(), T());
for (auto i = 0; i < v.size(); ++i) {
s += v[i];
}
return s;
}
which has similar effect.
$ g++ -O3 -std=c++17
v(std::vector >):
pushrbp
pushrbx
sub rsp, 8
mov rbp, QWORD PTR [rdi+8]
mov rcx, QWORD PTR [rdi]
cmp rcx, rbp
je .L7
sub rbp, rcx
mov rdi, rcx
xor esi, esi
mov rbx, rcx
mov rdx, rbp
callmemset
mov rdi, rbp
mov edx, 1
mov rcx, rbx
sar rdi, 2
testrbp, rbp
cmovne rdx, rdi
cmp rbp, 12
jbe .L8
mov rax, rdx
pxorxmm0, xmm0
shr rax, 2
sal rax, 4
add rax, rbx
.L4:
movdqu xmm2, XMMWORD PTR [rbx]
add rbx, 16
paddd xmm0, xmm2
cmp rbx, rax
jne .L4
movdqa xmm1, xmm0
psrldq xmm1, 8
paddd xmm0, xmm1
movdqa xmm1, xmm0
psrldq xmm1, 4
paddd xmm0, xmm1
movdeax, xmm0
testdl, 3
je .L1
and rdx, -4
mov esi, edx
.L3:
add eax, DWORD PTR [rcx+rdx*4]
lea edx, [rsi+1]
movsx rdx, edx
cmp rdx, rdi
jnb .L1
add esi, 2
lea r8, [0+rdx*4]
add eax, DWORD PTR [rcx+rdx*4]
movsx rsi, esi
cmp rsi, rdi
jnb .L1
add eax, DWORD PTR [rcx+4+r8]
.L1:
add rsp, 8
pop rbx
pop rbp
ret
.L7:
add rsp, 8
xor eax, eax
pop rbx
pop rbp
ret
.L8:
xor eax, eax
xor esi, esi
xor edx, edx
jmp .L3
[Bug tree-optimization/109441] missed optimization when all elements of vector are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/109440] Missed optimization of vector::at when a function is called inside the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440 Andrew Pinski changed: What|Removed |Added Keywords||alias --- Comment #1 from Andrew Pinski --- There are a few things, the most obvious thing is the middle-end thinks the content of v can change via the call to foo. If you make a local copy, then there is a missing VRP which can be fixed by changing the type of i to size_t.
[Bug tree-optimization/109441] New: missed optimization when all elements of vector are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441
Bug ID: 109441
Summary: missed optimization when all elements of vector are
known
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
Reference: https://godbolt.org/z/af4x6zhz9
When all elements of vector are 0, then the compiler should be able to remove
the loop and just return 0.
Testcase:
#include
using namespace std;
using T = int;
T v() {
T s;
std::vector v;
v.resize(1000, 0);
for (auto i = 0; i < v.size(); ++i) {
s += v[i];
}
return s;
}
$ g++ -O3 -std=c++17
.LC0:
.string "vector::_M_fill_insert"
v():
push rbx
pxor xmm0, xmm0
mov edx, 1000
xor esi, esi
sub rsp, 48
lea rcx, [rsp+12]
lea rdi, [rsp+16]
mov QWORD PTR [rsp+32], 0
mov DWORD PTR [rsp+12], 0
movaps XMMWORD PTR [rsp+16], xmm0
call std::vector
>::_M_fill_insert(__gnu_cxx::__normal_iterator > >, unsigned long, int const&)
mov rdx, QWORD PTR [rsp+24]
mov rdi, QWORD PTR [rsp+16]
mov rax, rdx
sub rax, rdi
mov rsi, rax
sar rsi, 2
cmp rdx, rdi
je .L99
test rax, rax
mov ecx, 1
cmovne rcx, rsi
cmp rax, 12
jbe .L107
mov rdx, rcx
pxor xmm0, xmm0
mov rax, rdi
shr rdx, 2
sal rdx, 4
add rdx, rdi
.L101:
movdqu xmm2, XMMWORD PTR [rax]
add rax, 16
paddd xmm0, xmm2
cmp rdx, rax
jne .L101
movdqa xmm1, xmm0
psrldq xmm1, 8
paddd xmm0, xmm1
movdqa xmm1, xmm0
psrldq xmm1, 4
paddd xmm0, xmm1
movd ebx, xmm0
test cl, 3
je .L99
and rcx, -4
mov eax, ecx
.L100:
lea edx, [rax+1]
add ebx, DWORD PTR [rdi+rcx*4]
movsx rdx, edx
cmp rdx, rsi
jnb .L99
add eax, 2
lea rcx, [0+rdx*4]
add ebx, DWORD PTR [rdi+rdx*4]
cdqe
cmp rax, rsi
jnb .L99
add ebx, DWORD PTR [rdi+4+rcx]
.L99:
test rdi, rdi
je .L98
mov rsi, QWORD PTR [rsp+32]
sub rsi, rdi
call operator delete(void*, unsigned long)
.L98:
add rsp, 48
mov eax, ebx
pop rbx
ret
.L107:
xor eax, eax
xor ecx, ecx
jmp .L100
mov rbx, rax
jmp .L105
v() [clone .cold]:
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW Priority|P3 |P1 --- Comment #6 from Segher Boessenkool --- We should not use any VMX insn unless explicitly asked for it, since those do not work as expected if VSCR[NJ]=1, which unfortunately is the default on Linux (but not on powerpc64le-linux; that is a separate (kernel) bug). Rounding mode does not matter too much, if we have some subset of fast-math anyway; the only rounding mode in VMX is round-to-nearest-ties-to-even, which is the default for most everything else). But NJ=1 makes arithmetic behave completely unexpectedly, and it isn't actually faster than NJ=0 on modern hardware anyway. We cannot change the default for setting NJ because some code might rely on it, unfortunately. Luckily disabling generating all VMX insns automatically (i.e. without it being explicitly asked for) isn't all that expensive, just ends up as a few more move instructions here and there. This isn't a regression, but we should have this in GCC 13.
[Bug tree-optimization/109440] New: Missed optimization of vector::at when a function is called inside the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440
Bug ID: 109440
Summary: Missed optimization of vector::at when a function is
called inside the loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
#include
using namespace std;
bool bar();
using T = int;
T vat(std::vector v) {
T s;
for (auto i = 0; i < v.size(); ++i) {
if (bar())
s += v.at(i);
}
return s;
}
$ gcc -O2 -fexceptions -fno-unroll-loops
.LC0:
.string "vector::_M_range_check: __n (which is %zu) >= this->size()
(which is %zu)"
vat(std::vector >):
mov rax, QWORD PTR [rdi]
cmp QWORD PTR [rdi+8], rax
je .L9
pushr12
pushrbp
mov rbp, rdi
pushrbx
xor ebx, ebx
jmp .L6
.L14:
mov rax, QWORD PTR [rbp+8]
sub rax, QWORD PTR [rbp+0]
add rbx, 1
sar rax, 2
cmp rbx, rax
jnb .L13
.L6:
callbar()
testal, al
je .L14
mov rcx, QWORD PTR [rbp+0]
mov rdx, QWORD PTR [rbp+8]
sub rdx, rcx
sar rdx, 2
mov rax, rdx
cmp rbx, rdx
jnb .L15
add r12d, DWORD PTR [rcx+rbx*4]
add rbx, 1
cmp rbx, rax
jb .L6
.L13:
mov eax, r12d
pop rbx
pop rbp
pop r12
ret
.L9:
mov eax, r12d
ret
.L15:
mov rsi, rbx
mov edi, OFFSET FLAT:.LC0
xor eax, eax
callstd::__throw_out_of_range_fmt(char const*, ...)
[Bug target/108177] MVE predicated stores to same address get optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177
--- Comment #5 from Stam Markianos-Wright ---
With the fix to MVE auto_inc having gone in as
ddc9b5ee13cd686c8674f92d46045563c06a23ea I have found that this fix keeps the
auto-inc on these predicated stores broken.
It seems to fail in auto_inc_dec at this condition:
```
/* Make sure this reg appears only once in this insn. */
if (count_occurrences (PATTERN (mem_insn.insn), mem_insn.reg0, 1) != 1)
{
if (dump_file)
fprintf (dump_file, "mem count failure\n");
return false;
}
```
(which makes sense with the pattern now having the MEM appear twice)
I guess this is not urgent since this is only a performance impact on one
instruction. Also if the change needs to be in the auto-inc pass instead of the
backend, then likely something for GCC14, but I thought this would be a good
place to record this ;)
Does anyone have any ideas on this? Or I wonder what the AVX case does for this
[Bug analyzer/109439] New: RFE: Spurious -Wanalyzer-use-of-uninitialized-value tagging along -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439
Bug ID: 109439
Summary: RFE: Spurious -Wanalyzer-use-of-uninitialized-value
tagging along -Wanalyzer-out-of-bounds
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: priour.be at gmail dot com
CC: priour.be at gmail dot com
Target Milestone: ---
Build: 13.0.1 20230328 (experimental)
For every -Wanalyzer-out-of-bounds, a corresponding
-Wanalyzer-use-of-initialized-value seemingly tags along.
As most likely fixing the former would also fix the latter, it would make sense
to only have a OOB diagnosed.
Tested on trunk.
int would_like_only_oob ()
{
int arr[] = {1,2,3,4,5,6,7};
int y1 = arr[9]; // 2 warnings instead of only OOB warning are emitted here
return y1;
}
In the mail list, David suggested that
"Maybe we could fix this by having region_model::check_region_bounds
return a bool that signifies if the access is valid, and propagating
that value up through callers so that we can return a non-
poisoned_svalue at the point where we'd normally return an
"uninitialized" poisoned_svalue.
Alternatively, we could simply terminate any analysis path in which an
OOB access is detected (by implementing the
pending_diagnostic::terminate_path_p virtual function for class
out_of_bounds)."
[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318 --- Comment #10 from Martin Jambor --- The problem is actually slightly different, I have just attached a possible fix to both to PR 107769.
[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769 --- Comment #7 from Martin Jambor --- Created attachment 54817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54817=edit potential patch I am testing the attached patch. I'd like to think about the whole situation a bit more next week, but this seems like a way to fix this and PR 109318.
[Bug analyzer/109438] New: Excessive Duplication of -Wanalyzer-out-of-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109438
Bug ID: 109438
Summary: Excessive Duplication of -Wanalyzer-out-of-bounds
warnings
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: priour.be at gmail dot com
CC: priour.be at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: 13.0.1 20230328 (experimental)
The reproducer below demonstrates an excessive duplication of the same warning
-Wanalyzer-out-of-bounds. The warning appears duplicated thrice, at points (1),
(2) and (3), yet none appear at (4) (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437)
See https://godbolt.org/z/Tcrv8h614 for live warnings on trunk, both gcc and
g++.
int consecutive_oob_in_frame () // one warning from analysis of initial EN
{
int arr[] = {1,2,3,4,5,6,7};
int y1 = arr[9]; // injurious line (1)
return y1;
}
int goo () {
int x = consecutive_oob_in_frame (); // causes another warning (2)
return 2 * x;
}
int main () {
goo (); // causes another warning (3)
consecutive_oob_in_frame (); // silent (4)
return 0;
}
Currently the expected behavior would be to see it appear whenever when
consecutive_oob_in_frame is called directly. It means that the above should
rather emits at points (2) and (4).
[Bug analyzer/109437] New: -Wanalyzer-out-of-bounds is emitted at most once per frame.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437
Bug ID: 109437
Summary: -Wanalyzer-out-of-bounds is emitted at most once per
frame.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: priour.be at gmail dot com
CC: priour.be at gmail dot com
Target Milestone: ---
Build: 13.0.1 20230328 (experimental)
OOB refers to Out-Of-Bounds.
Curiously, it seems that if a frame was a cause for a OOB (either by containing
the spurious code or by being a caller to such code), it will only emit one set
of warning, rather than at each unique compromising statements.
int consecutive_oob_in_frame ()
{
int arr[] = {1,2,3,4,5,6,7};
int y1 = arr[9]; // only this one is diagnosed
int y2 = arr[10]; // no OOB warning emitted here ...
int y3 = arr[50]; // ... nor here.
return (y1+y2+y3);
}
int main () {
consecutive_oob_in_frame (); // OOB warning emitted
int x [] = {1,2};
x[5]; /* silent, probably because another set of OOB warnings
has already been issued with this frame being the source */
return 0;
}
As per David suggestion, it might be worth to implement
pending_diagnostic::supercedes_p vfunc for the OOB checker.
[Bug c++/88061] section attributes of variable templates are ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061
--- Comment #6 from Barry Revzin ---
Any action on this one?
A workaround right now is to change code that would ideally look like (which is
pretty clean in my opinion):
template
void foo() {
[[gnu::section(".meow")]] static int value = 0;
}
to code that looks like:
template
void foo() {
static int PUT_IN_MEOW_value = 0;
}
and add a linker script that moves these variables over:
.meow : {
KEEP(*(SORT(.*PUT_IN_MEOW_*)))
}
But this is, to put it mildly, less than ideal.
[Bug target/109436] New: AArch64: suboptimal codegen in 128 bit constant stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109436
Bug ID: 109436
Summary: AArch64: suboptimal codegen in 128 bit constant stores
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sinan.lin at linux dot alibaba.com
Target Milestone: ---
When splitting a 128-bit constant, there may be cases where the part that is
cut out is a constant 0. And we could use a zero register to avoid the "mov
reg, 0" instruction.
e.g.
```
__int128 Data;
void init() {
Data = 0xf;
}
```
gcc
```
init:
adrpx0, .LANCHOR0
add x0, x0, :lo12:.LANCHOR0
mov x2, 1048575
mov x3, 0
stp x2, x3, [x0]
ret
```
clang
```
init:
mov w8, #1048575
adrpx9, Data
add x9, x9, :lo12:Data
stp x8, xzr, [x9]
ret
```
[Bug target/109402] v850: non-v850e version of __muldi3() in /libgcc/config/v850/lib1funcs.S operates sp in reversed direction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109402 --- Comment #2 from Mikael Pettersson --- Please send patches to gcc-patches for review.
[Bug target/107674] [11/12/13 Regressions] arm: MVE codegen regressions on VCTP and vector LDR/STR instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:ddc9b5ee13cd686c8674f92d46045563c06a23ea commit r13-7114-gddc9b5ee13cd686c8674f92d46045563c06a23ea Author: Richard Earnshaw Date: Thu Apr 6 14:44:30 2023 +0100 arm: mve: fix auto-inc generation [PR107674] My change r13-416-g485a0ae0982abe caused the compiler to stop generating auto-inc operations on mve loads and stores. The fix is to check whether there is a replacement register available when in strict mode and the register is still a pseudo. gcc: PR target/107674 * config/arm/arm.cc (arm_effective_regno): New function. (mve_vector_mem_operand): Use it.
[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028 --- Comment #7 from LIU Hao --- clang generates 14 bytes: ``` mov rax, 0x7FFF # 48 B8 FF FF FF FF FF FF FF 7F and rax, rcx # 48 23 C1 ret # C3 `` but in principle this function requires only 8 bytes: ``` lea rax, qword ptr [rcx + rcx]# 48 8D 04 09 shr rax, 1# 48 D1 E8 ret # C3 ``
[Bug target/109416] Missed constant propagation cases after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109416 --- Comment #3 from Sinan --- Hi Andrew, Thank you for taking the time to explain the issue. I appreciate it. I think the issue between init/init2 and init3 might be different. Regarding init3, any 32-bit backend attempting to split a complex constant will encounter such a suboptimal case. I tried with mip in gcc 12, and here are the ouputs for `init` and `init3` init: lui $2,%hi(Data) move$5,$0 move$4,$0 sw $5,%lo(Data+4)($2) jr $31 sw $4,%lo(Data)($2) init3: lui $2,%hi(Data) li $5,15 # 0xf li $4,15 # 0xf sw $5,%lo(Data+4)($2) jr $31 sw $4,%lo(Data)($2) register $4 or $5 could be eliminated.
[Bug other/109435] [MIPS64R6] Typedef struct alignment returns incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 --- Comment #1 from Jovan Dmitrović --- This is compile command that I used: mipsisa64r6-linux-gnuabi64-gcc -march=mips64r6 -mabi=64 -O0 -o foo foo.c -static I used the MIPS gcc package from Ubuntu's package repository. Also, I used qemu-mips64 to run the executable file.
[Bug other/109435] New: [MIPS64R6] Typedef struct alignment returns incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435
Bug ID: 109435
Summary: [MIPS64R6] Typedef struct alignment returns incorrect
results
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jovan.dmitrovic at syrmia dot com
Target Milestone: ---
Consider the following testcase:
#include
typedef struct uint8 {
unsigned v[8];
} uint8 __attribute__ ((aligned(128)));
unsigned callee(int x, uint8 a) {
return a.v[0];
}
uint8 identity(uint8 in) {
return in;
}
int main() {
uint8 vec = {1, 2, 3, 4, 5, 6, 7, 8};
printf("res1: %d\n", callee(99, identity(vec)));
uint8 temp = identity(vec);
printf("res2: %d\n", callee(99, temp));
}
When this code is compiled for MIPS64 R6, output is as follows:
res1: 3
res2: 1
However, when aligned attribute is removed from the testcase, res1 and res2
become 1,
which are values that were expected in the first place.
Furthermore, this bug is reproducible only if there is a unused argument x in
function callee. Adding more arguments or switching their places also produces
expected values. Type of x doesn't seem to impact the result.
[Bug c++/107853] [10/11 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 Patrick Palka changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] variadic |variadic template with a|template with a variadic |variadic template friend|template friend with a |with a requires of fold |requires of fold expression |expression | --- Comment #9 from Patrick Palka --- Fixed for GCC 13 and 12.3 so far
[Bug c++/109425] mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- (In reply to Hannes Hauswedell from comment #2) > Thanks for the quick reply, and nice that it is already fixed for 13! > > I assume this will not be backported? It wouldn't be a huge problem, because > it is possible to workaround with non-friend operators. It's already been backported to the 12 branch, so the upcoming GCC 12.3 (or a recent enough snapshot of the release branch) will also include the fix. No decision yet about backporting to the 11/10 branches. Having to work around this by defining these functions as non-friends is pretty inconvenient..
[Bug c++/109425] mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 --- Comment #3 from Marek Polacek --- (In reply to Hannes Hauswedell from comment #2) > Thanks for the quick reply, and nice that it is already fixed for 13! > > I assume this will not be backported? It wouldn't be a huge problem, because > it is possible to workaround with non-friend operators. I think this is up to Patrick to decide.
[Bug c++/109431] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field with static constexpr array inside a template constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431 Marek Polacek changed: What|Removed |Added Keywords|needs-bisection | CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with r262173: commit 307193b82cecb8ab79cf8880d642e1a3acb9c9f6 Author: Jason Merrill Date: Tue Jun 26 22:59:44 2018 -0400 PR c++/86320 - memory-hog with std::array of pair
[Bug c++/109433] [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Keywords|needs-bisection | Status|UNCONFIRMED |NEW Priority|P3 |P2 Ever confirmed|0 |1 Last reconfirmed||2023-04-06 --- Comment #1 from Jakub Jelinek --- With -std=c++11, started to ICE with r12-6326-ge948436eab818c527dd6. With -std=c++14, started to ICE with r9-1483-g307193b82cecb8ab79cf.
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #6 from Xi Ruoyao --- FWIW use --with-system-zlib when you configure GCC if you want to use zlib installed on the system instead of the shipped copy.
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Macleod --- fixed.
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:7f056d5f4a0b9e29561d0375d5b4ad42c9f3f61e commit r13-7113-g7f056d5f4a0b9e29561d0375d5b4ad42c9f3f61e Author: Andrew MacLeod Date: Wed Apr 5 15:59:38 2023 -0400 Check if dependency is valid before using in may_recompute_p. When the IL is rewritten after a statement has been processed and dependencies cached, its possible that an ssa-name in the dependency cache is no longer in the IL. Check this before trying to recompute. PR tree-optimization/109417 gcc/ * gimple-range-gori.cc (gori_compute::may_recompute_p): Check if dependency is in SSA_NAME_FREE_LIST. gcc/testsuite/ * gcc.dg/pr109417.c: New.
[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028 --- Comment #6 from LIU Hao --- Looks like this has been fixed? https://gcc.godbolt.org/z/xP5E76aYz Despite that however, GCC generates suboptimal code that uses an XMM register to perform the bitwise AND operation.
[Bug tree-optimization/109434] [12/13 Regression] std::optional weird -Wmaybe-unitialized and behaviour with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-04-06
Known to fail||12.1.0
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||needs-bisection,
||needs-reduction
Summary|std::optional weird |[12/13 Regression]
|-Wmaybe-unitialized and |std::optional weird
|behaviour with -O2 |-Wmaybe-unitialized and
||behaviour with -O2
Target Milestone|--- |12.3
Known to work||10.1.0, 11.1.0
--- Comment #1 from Andrew Pinski ---
DSE2 removes the original store:
optInt = {};
optInt = foo ();
Deleted dead store: optInt = {};
Even though foo can throw ...
Confirmed.
[Bug c++/109434] New: std::optional weird -Wmaybe-unitialized and behaviour with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
Bug ID: 109434
Summary: std::optional weird -Wmaybe-unitialized and behaviour
with -O2
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.pecka at cesnet dot cz
Target Milestone: ---
Created attachment 54816
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54816=edit
reproducer
Hello,
I've seen a compile warning on a code (see attachment) that looks bogus.
In file included from optional.cpp:2:
In member function ‘constexpr bool std::_Optional_base_impl<_Tp,
_Dp>::_M_is_engaged() const [with _Tp = int; _Dp = std::_Optional_base]’,
inlined from ‘constexpr bool std::optional<_Tp>::has_value() const [with
_Tp = int]’ at /usr/include/c++/12.2.1/optional:988:35,
inlined from ‘int main()’ at optional.cpp:21:63:
/usr/include/c++/12.2.1/optional:471:58: warning: ‘*(unsigned
char*)((char*) +
offsetof(std::optional,std::optional::.std::_Optional_base::_M_payload.std::_Optional_payload::.std::_Optional_payload_base::_M_engaged))’ may be used
uninitialized [-Wmaybe-uninitialized]
471 | { return static_cast(this)->_M_payload._M_engaged;
}
| ^~
optional.cpp: In function ‘int main()’:
optional.cpp:15:24: note: ‘*(unsigned char*)((char*) +
offsetof(std::optional,std::optional::.std::_Optional_base::_M_payload.std::_Optional_payload::.std::_Optional_payload_base::_M_engaged))’ was declared
here
15 | std::optional optInt;
|^~
The warning is present only when compiling with -Wall -O2. When I run the
executable, I see unexpected weird output, e.g.
catch 56
val=72704.00
which look like some uninitialized variable is really there. When run under
valgrind, I see reports about unitialized variables.
Code seems to be working correctly when compiled with -O1 or lower and the
executable seem to be behaving expectedly as well.
Compiling and executing under clang++ works as well regardless of the
optimization level.
I don't have older versions of g++ (< 12) but compiling the attached code on
godbolt with g++ 11 and lower does not trigger any warning.
Interesting part is that declaring optDbl as std::optional makes the code
behave correctly.
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 --- Comment #6 from Jonathan Wakely --- It's a pattern with this person: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED_known_to_fail_type=allwords_known_to_work_type=allwords=zhonghao%40pku.org.cn=1=substring_id=377697=gcc_format=advanced=INVALID See PR 86306 for discussion and their justification for these low quality reports. I think they're genuinely trying to be helpful, just not succeeding.
[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698
Matthijs Kooijman changed:
What|Removed |Added
CC||matthijs at stdin dot nl
--- Comment #4 from Matthijs Kooijman ---
I also ran into this problem, with an STM32 codebase that uses libopencm3 (for
peripheral code and the linker script) and uses section(".data") to put a bit
of code in RAM (to prevent flash reads while programming flash).
To fix this problem in my code, I switched from section(".data") to
section(".ramtext"), which is second section that is also put into RAM and
seems intended especially for this purpose. This works with the libopencm3
linker script, which defines this section, YMMV with other linker scripts. E.g.
from
https://github.com/libopencm3/libopencm3/blob/189017b25cebfc609a6c1a5a02047691ef845b1b/ld/linker.ld.S#L136:
.data : {
_data = .;
*(.data*) /* Read-write initialized data */
*(.ramtext*)/* "text" functions to run in ram */
. = ALIGN(4);
_edata = .;
} >ram AT >rom
>From looking at the linker script, it seems that .data and .ramtext are treated
pretty much in the same way, so I suspect that there is something else (maybe
some builtin rules in gcc/ld/as) that make the data section special in a way
that it causes this problem to be triggered.
Hopefully this is helpful for anyone else running into this same problem.
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 --- Comment #5 from Xi Ruoyao --- (In reply to Jonathan Wakely from comment #4) > N.B. this code is just copied from PR 54402. It might have been helpful to > say where you found the code. > > zhonghao, it's really not helpful to just copy code that you don't > understand into bug reports with stupid, incorrect claims like "while > expanding templates". Maybe you're trying to be helpful, but you're just > wasting our time. I'm wondering if this is an attempt for some kind of "academic research" here like the notorious UMN incident in LKML.
[Bug c++/109433] [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.3 Keywords||needs-bisection
[Bug c++/109433] New: [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433
Bug ID: 109433
Summary: [12/13 Regression] ICE with -std=c++11 and static
constexpr array inside a template constexpr
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Note this is not exactly a dup of bug 109431 as it works in GCC 11.3.0.
Note also it ICEs with -std=c++14 in GCC 11.3.0 (which looks to be the same as
PR109431 ) but works with -std=c++11.
testcase:
```
struct RangeLimits
{
int low = 1;
};
template
int parameterLimits(void)
{
static RangeLimits constexpr param_limits[ 2 ] = {};
auto const = param_limits[ 1 ];
return 0;
}
auto s = parameterLimits<1>();
```
Maybe they are the same issue but I am not 100% sure as they regressed at
different times and produce different ICEs.
The ICE on the trunk:
:10:55: internal compiler error: unexpected expression 'const
RangeLimits()' of kind cast_expr
10 | static RangeLimits constexpr param_limits[ 2 ] = {};
| ^
[Bug c++/109431] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field with static constexpr array inside a template constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5 Known to fail||9.1.0 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code, ||needs-bisection Known to work||8.5.0 Ever confirmed|0 |1 Summary|internal compiler error: in |[10/11/12/13 Regression] |output_constructor_regular_ |internal compiler error: in |field (varasm.c:5207) |output_constructor_regular_ ||field with static constexpr ||array inside a template ||constexpr function Last reconfirmed||2023-04-06 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/109431] internal compiler error: in output_constructor_regular_field (varasm.c:5207)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431
--- Comment #1 from Andrew Pinski ---
Reduced:
```
struct RangeLimits
{
int low = 0;
int high = 1;
constexpr RangeLimits() { }
};
template
int parameterLimits(void)
{
static RangeLimits constexpr param_limits[ 2 ] = {};
auto const = param_limits[ 1 ];
return 0;
}
auto s = parameterLimits<1>();
```
[Bug tree-optimization/109429] ivopts: Compute complexity for unsupported addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 --- Comment #3 from Jovan Dmitrović --- Another thing that has come to attention is the register pressure costs being calculated improperly. More information and a patch are submitted at the link below. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608896.html
[Bug tree-optimization/109429] ivopts: Compute complexity for unsupported addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 --- Comment #2 from Jovan Dmitrović --- *** Bug 109430 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/109430] ivopts: Revert register pressure cost when there are enough registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109430 Jovan Dmitrović changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jovan Dmitrović --- Moved to 109429, as this doesn't warrant a thread of its own. *** This bug has been marked as a duplicate of bug 109429 ***
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 --- Comment #4 from Jonathan Wakely --- N.B. this code is just copied from PR 54402. It might have been helpful to say where you found the code. zhonghao, it's really not helpful to just copy code that you don't understand into bug reports with stupid, incorrect claims like "while expanding templates". Maybe you're trying to be helpful, but you're just wasting our time.
[Bug c/29129] [4.2/4.3/4.4 Regression] [DR#341] unnamed parameters using [*]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129 --- Comment #14 from Jonathan Wakely --- You need to change godbolt.org to compile C not C++. Please stop adding completely useless comments to bugzilla or I will block your account.
[Bug c/64480] List designated initializer triggers -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480 --- Comment #5 from Jonathan Wakely --- (In reply to zhonghao from comment #4) > Is this bug fixed? I tried the latest gcc, but it still rejects the sample > code. No, the latest gcc accepts this C code without errors. Please stop commenting on old bugs if you are not capable of understanding the difference between C and C++, or I will block your account.
[Bug libstdc++/88508] std::bad_cast in std::basic_ostringstream.oss.fill()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508 --- Comment #3 from Jonathan Wakely --- (In reply to Frank Heckenbach from comment #2) > And all that because the library > doesn't know what the space character is in UTF-8. That's a completely wrong description of the problem. The standard library does not come with support for using char8_t as the character type for streams. That's it. Period. The problem has nothing to do with the setw manipulator or the space character or even UTF-8, it's that char8_t type is not supported by streams out of the box. You would need to imbue the stream with the relevant facets such as ctype.
[Bug tree-optimization/109407] instruction cmpxchgl run error when using with g++ -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407 --- Comment #2 from johgjc --- thank you very much. At 2023-04-04 23:55:25, "pinskia at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407 > >Andrew Pinski changed: > > What|Removed |Added > > Resolution|--- |INVALID > Status|UNCONFIRMED |RESOLVED > >--- Comment #1 from Andrew Pinski --- >The inline-asm is incorrect as the EAX/RAX register gets clobbered by cmpxchgl >So you need something like (which works now): > >int tmp; >__asm__ __volatile__( >"lock;" >"cmpxchgl %[NEW_VALUE], %[DST];" >"sete %[RET];" >: [RET] "=q"(dwRtnV),[DST] "+m"(dwOriV) >, "=a"(tmp) // newly added >:[NEW_VALUE] "r"(dwDstV), "a"(dwExpV) >: "memory", "cc" >); > >-- >You are receiving this mail because: >You reported the bug.
[Bug tree-optimization/109429] ivopts: Compute complexity for unsupported addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429
--- Comment #1 from Jovan Dmitrović ---
It seems that commit f9f69dd changed the way complexity is calculated, so now
the complexity equals zero across the board, for each candidate.
Here is one testcase:
void daxpy(float *vector1, float *vector2, int n, float fp_const)
{
for (int i = 0; i < n; ++i)
vector1[i] += fp_const * vector2[i];
}
void dgefa(float *vector, int m, int n, int l)
{
for (int i = 0; i < n - 1; ++i)
{
for (int j = i + 1; j < n; ++j)
{
float t = vector[m * j + l];
daxpy([m * i + i + 1],
[m * j + i + 1], n - (i + 1), t);
}
}
}
Following tables compare IV candidates.
= Before f9f69dd =
Group 1:
cand costcompl. inv.expr.inv.vars
1 13 1 3; NIL;
2 13 2 4; NIL;
4 9 1 5; NIL;
5 1 0 NIL; NIL;
7 9 1 3; NIL;
= Before f9f69dd =
= After f9f69dd =
Group 1:
cand costcompl. inv.expr.inv.vars
1 10 0 4; NIL;
2 10 0 5; NIL;
4 6 0 6; NIL;
5 1 0 NIL; NIL;
7 6 0 4; NIL;
= After f9f69dd =
This leads to different candidate being selected in our test case.
= Before f9f69dd =
Selected IV set for loop 3 at fp_foo.c:3, 10 avg niters, 2 IVs:
Candidate 4:
Var befor: ivtmp.17_52
Var after: ivtmp.17_103
Incr POS: before exit test
IV struct:
Type: unsigned long
Base: (unsigned long) (vector_27(D) + _10)
Step: 4
Object: (void *) vector_27(D)
Biv:N
Overflowness wrto loop niter: Overflow
Candidate 5:
Var befor: ivtmp.18_99
Var after: ivtmp.18_98
Incr POS: before exit test
IV struct:
Type: unsigned long
Base: (unsigned long) (vector_27(D) + _14)
Step: 4
Object: (void *) vector_27(D)
Biv:N
Overflowness wrto loop niter: Overflow
= Before f9f69dd =
= After f9f69dd =
Selected IV set for loop 3 at fp_foo.c:3, 10 avg niters, 1 IVs:
Candidate 4:
Var befor: ivtmp.17_52
Var after: ivtmp.17_103
Incr POS: before exit test
IV struct:
Type: unsigned long
Base: (unsigned long) (vector_27(D) + _10)
Step: 4
Object: (void *) vector_27(D)
Biv:N
Overflowness wrto loop niter: Overflow
= After f9f69dd =
Finally, here is the difference in assembly:
= Before f9f69dd =
.L83:
lwc1$f5,0($3)
lwc1$f8,0($2)
lwc1$f7,4($2)
lwc1$f6,8($2)
lwc1$f9,12($2)
lwc1$f10,16($2)
maddf.s $f8,$f0,$f5
lwc1$f11,20($2)
lwc1$f12,24($2)
lwc1$f13,28($2)
ld $12,72($sp)
swc1$f8,0($2)
lwc1$f14,4($3)
maddf.s $f7,$f0,$f14
swc1$f7,4($2)
lwc1$f15,8($3)
maddf.s $f6,$f0,$f15
swc1$f6,8($2)
lwc1$f16,12($3)
maddf.s $f9,$f0,$f16
swc1$f9,12($2)
lwc1$f17,16($3)
maddf.s $f10,$f0,$f17
swc1$f10,16($2)
lwc1$f18,20($3)
maddf.s $f11,$f0,$f18
swc1$f11,20($2)
lwc1$f19,24($3)
maddf.s $f12,$f0,$f19
swc1$f12,24($2)
lwc1$f20,28($3)
maddf.s $f13,$f0,$f20
swc1$f13,28($2)
daddiu $2,$2,32
bne $2,$12,.L83
daddiu $3,$3,32
...
= Before f9f69dd =
= After f9f69dd =
.L93:
dsubu $18,$2,$4
lwc1$f13,0($2)
daddu $19,$18,$5
daddiu $16,$2,4
lwc1$f14,0($19)
dsubu $17,$16,$4
daddu $25,$17,$5
lwc1$f15,4($2)
daddiu $19,$2,12
daddiu $20,$2,8
maddf.s $f13,$f1,$f14
dsubu $16,$19,$4
daddiu $17,$2,16
dsubu $18,$20,$4
daddu $19,$16,$5
daddiu $16,$2,20
lwc1$f10,8($2)
daddu $20,$18,$5
lwc1$f16,12($2)
dsubu $18,$17,$4
lwc1$f17,16($2)
dsubu $17,$16,$4
lwc1$f18,20($2)
daddiu $16,$2,24
lwc1$f20,24($2)
daddu $18,$18,$5
swc1$f13,0($2)
daddu $17,$17,$5
lwc1$f19,0($25)
daddiu $25,$2,28
lwc1$f11,28($2)
daddiu $2,$2,32
dsubu $16,$16,$4
dsubu $25,$25,$4
maddf.s $f15,$f1,$f19
daddu $16,$16,$5
daddu $25,$25,$5
swc1$f15,-28($2)
lwc1$f21,0($20)
ld $20,48($sp)
maddf.s $f10,$f1,$f21
swc1$f10,-24($2)
[Bug c/29129] [4.2/4.3/4.4 Regression] [DR#341] unnamed parameters using [*]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #13 from zhonghao at pku dot org.cn --- I tried the latest gcc, but it rejects the sample code: :1:23: error: expected primary-expression before ']' token 1 | void f(unsigned int [*]); | ^ Compiler returned: 1 Is this a regression? Or, the idea is changed, and this code shall be rejected?
[Bug c/64480] List designated initializer triggers -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #4 from zhonghao at pku dot org.cn --- Is this bug fixed? I tried the latest gcc, but it still rejects the sample code.
[Bug analyzer/109432] New: tracker bug for issues with -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109432 Bug ID: 109432 Summary: tracker bug for issues with -Wanalyzer-out-of-bounds Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: priour.be at gmail dot com CC: priour.be at gmail dot com Target Milestone: ---
[Bug c++/109431] New: internal compiler error: in output_constructor_regular_field (varasm.c:5207)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431 Bug ID: 109431 Summary: internal compiler error: in output_constructor_regular_field (varasm.c:5207) Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gh0s-t at yandex dot ru Target Milestone: --- Created attachment 54815 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54815=edit preprocessed file for short source example Problem occurs from 9.1 to newer gcc versions. But code compiles on older convenient gcc versions. godbolt.org used. As I can see, the problem is in function body static and constexpr keywords mixing at array aggregate initialization with empty initializer-list (at line #111 in preprocessed file). Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-9.1.0/bin/g++ Target: x86_64-linux-gnu Configured with: ../gcc-9.1.0/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build Thread model: posix gcc version 9.1.0 (Compiler-Explorer-Build) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-masm=intel' '-S' '-v' '-std=c++17' '-g' '-D' '_REENTRANT' '-fPIC' '-pipe' '-Wall' '-Wextra' '-fsanitize=undefined' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/compiler-explorer/gcc-9.1.0/bin/../libexec/gcc/x86_64-linux-gnu/9.1.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/ -D_GNU_SOURCE -D _REENTRANT -quiet -dumpbase example.cpp -masm=intel -mtune=generic -march=x86-64 -auxbase-strip /app/output.s -g -g -Wall -Wextra -std=c++17 -version -fdiagnostics-color=always -fPIC -fsanitize=undefined -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o /app/output.s GNU C++17 (Compiler-Explorer-Build) version 9.1.0 (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0/backward" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0 /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0/x86_64-linux-gnu /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0/backward /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/include /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/include-fixed /usr/local/include /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++17 (Compiler-Explorer-Build) version 9.1.0 (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2c5ce497dfd6253343a5b735244577eb : In function 'int main()': :105:16: warning: variable 's' set but not used [-Wunused-but-set-variable] 105 | auto const s = parameterLimits(ParamId::Id1); |
[Bug tree-optimization/109430] New: ivopts: Revert register pressure cost when there are enough registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109430 Bug ID: 109430 Summary: ivopts: Revert register pressure cost when there are enough registers Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jovan.dmitrovic at syrmia dot com Target Milestone: --- Greetings everyone, this issue has been reported in December 2022, and I have since pinged the community once, but had no responses. The issue lies in register pressure costs being calculating improperly. More information and a patch are submitted at the link below. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608896.html
[Bug tree-optimization/109429] New: ivopts: Compute complexity for unsupported addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 Bug ID: 109429 Summary: ivopts: Compute complexity for unsupported addressing modes Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jovan.dmitrovic at syrmia dot com Target Milestone: --- Greetings everyone, I have pinged the mailing list about this issue about a month ago (I am not the original poster), and heard no response since. For some addressing modes, it seems that the complexity is calculated in sub-optimal manner. More information and a patch are contained in the link below. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608895.html
[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495 --- Comment #8 from Jakub Jelinek --- No, works just fine. Perhaps you are compiling with C++ when this is C?
[Bug c/85696] OpenMP with variably modified and default(none) won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696 --- Comment #12 from Jakub Jelinek --- If you are trying to compile C code which isn't valid C++ by C++, then such an error is expected.
[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495
zhonghao at pku dot org.cn changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
--- Comment #7 from zhonghao at pku dot org.cn ---
I tried to compile the sample code with the latest gcc.
struct __attribute__ ((aligned (8))) s { char c; };
_Static_assert (_Alignof (struct s) >= 8, "wrong alignment");
However, it does not compile. Is this a regression?
