[Bug target/99217] [MIPS] wrong function entry with -fpatchable-function-entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99217
--- Comment #5 from huangpei at loongson dot cn
---
Hi, with this fix and bug 93242 fixed, a.c with mips16 is OK,
ambrosehua@3A1000-800M:~$ gcc -fpatchable-function-entry=3 -mips16 -mabi=32
-c a.c -S -o a.1.s
ambrosehua@3A1000-800M:~$ cat a.1.s
.file 1 "a.c"
.section .mdebug.abi32
.previous
.nanlegacy
.module fp=xx
.module nooddspreg
.abicalls
.text
.align 2
.globl f
.setmips16
.setnomicromips
.entf
.type f, @function
f:
.section__patchable_function_entries,"a",@progbits
.4byte $LPFE1
.text
$LPFE1:
.setnoreorder
nop
.setreorder
.setnoreorder
nop
.setreorder
.setnoreorder
nop
.setreorder
.frame $17,8,$31 # vars= 0, regs= 1/0, args= 0, gp= 0
.mask 0x0002,-4
.fmask 0x,0
save8,$17
move$17,$sp
.setnoreorder
nop
.setreorder
move$sp,$17
restore 8,$17
jr $31
.endf
.size f, .-f
.ident "GCC: (Debian 8.3.0-8.lnd.4) 8.3.0"
ambrosehua@3A1000-800M:~$ objdump -tdr a.1.o
a.1.o: file format elf32-tradlittlemips
SYMBOL TABLE:
ldf *ABS* a.c
ld .text .text
ld .data .data
ld .bss .bss
ld .mdebug.abi32 .mdebug.abi32
ld __patchable_function_entries
__patchable_function_entries
l .text 0xf0 $LPFE1
ld .reginfo .reginfo
ld .MIPS.abiflags .MIPS.abiflags
ld .pdr .pdr
ld .comment .comment
ld .gnu.attributes .gnu.attributes
g F .text 0012 f
Disassembly of section .text:
:
0: 6500nop
2: 6500nop
4: 6500nop
6: 6491save8,s1
8: 673dmoves1,sp
a: 6500nop
c: 65b9movesp,s1
e: 6411restore 8,s1
10: e8a0jrc ra
12: 6500nop
14: 6500nop
16: 6500nop
18: 6500nop
1a: 6500nop
1c: 6500nop
1e: 6500nop
but， with b.c,
ambrosehua@3A1000-800M:~$ cat b.c
void f(float a, float b)
{
}
it is much more complicated.
ambrosehua@3A1000-800M:~$ gcc -fpatchable-function-entry=3 -mips16 -mabi=32
-c b.c -S -o b.1.s
ambrosehua@3A1000-800M:~$ cat b.1.s
.section .mdebug.abi32
.previous
.nanlegacy
.module fp=xx
.module nooddspreg
.abicalls
.text
.align 2
.globl f
.setmips16
.setnomicromips
.entf
.type f, @function
f:
.section__patchable_function_entries,"a",@progbits
.4byte $LPFE1
.text
$LPFE1:
.setnoreorder
nop
.setreorder
.setnoreorder
nop
.setreorder
.setnoreorder
nop
.setreorder
# Stub function for f (float, float)
.section.mips16.fn.f,"ax",@progbits
.align 2
.setmips16
.setnomicromips
.ent__fn_stub_f
.type __fn_stub_f, @function
__fn_stub_f:
.section__patchable_function_entries
.4byte $LPFE2
.section.mips16.fn.f
$LPFE2:
.setnoreorder
nop
.setreorder
.setnoreorder
nop
.setreorder
.setnoreorder
nop
.setreorder
.setnomips16
.setnomicromips
.ent__fn_stub_f
.type __fn_stub_f, @function
__fn_stub_f:
.setnoreorder
.cpload $25
.setreorder
.reloc 0,R_MIPS_NONE,f
la $25,__fn_local_f
mfc1$4,$f12
mfc1$5,$f14
jr $25
.end__fn_stub_f
__fn_local_f = f
.text
.frame $17,8,$31 # vars= 0, regs= 1/0, args= 0, gp= 0
.mask 0x0002,-4
.fmask 0x,0
save8,$17
move$17,$sp
sw $4,8($17)
sw $5,12($17)
.setnoreorder
nop
.setreorder
move$sp,$17
restore 8,$17
jr $31
.endf
.size f, .-f
.ident "GCC: (Debian 8.3.0-8.lnd.4) 8.3.0"
for comparison， without -fpatchable-function-entry=3
ambrosehua@3A1000-800M:~$ gcc -mips16 -mabi=32 -c b.c -S -o b.2.s
ambrosehua@3A1000-800M:~$
[Bug c++/97222] GCC discards attributes aligned and may_alias for typedefs passed as template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222 Andrew Pinski changed: What|Removed |Added CC||liavonlida at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 100742 has been marked as a duplicate of this bug. ***
[Bug c++/100742] False positive -Wignored-attributes with std::map and aligned(8) attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100742 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 97222. *** This bug has been marked as a duplicate of bug 97222 ***
[Bug c++/97222] GCC discards attributes aligned and may_alias for typedefs passed as template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222 Andrew Pinski changed: What|Removed |Added CC||kip at thevertigo dot com --- Comment #7 from Andrew Pinski --- *** Bug 84055 has been marked as a duplicate of this bug. ***
[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Andrew Pinski --- Even though PR 97222 is newer, it has more insight of what the issue is so marking this one as a dup of bug 97222 *** This bug has been marked as a duplicate of bug 97222 ***
[Bug c++/97222] GCC discards attributes aligned and may_alias for typedefs passed as template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222 Andrew Pinski changed: What|Removed |Added CC||paul.groke at dynatrace dot com --- Comment #6 from Andrew Pinski --- *** Bug 82270 has been marked as a duplicate of this bug. ***
[Bug c++/82270] incorrect warning [-Wignored-attributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82270 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Even though PR 97222 is newer, it has more insight of what the issue is so marking this one as a dup of bug 97222 *** This bug has been marked as a duplicate of bug 97222 ***
[Bug c++/60402] [DR 1395] const overload with variadics declared ambiguous according to standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60402 Andrew Pinski changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #3 from Andrew Pinski --- [Moved to DR at the November, 2016 meeting.] (In reply to Daniel Krügler from comment #2) > No, this is not related to bug 58156. According to the current core language > of C++11, the code is indeed ambiguous. > > There exists currently a core language issue to fix that, see > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1395 Hmm, but this example is still rejected in both GCC and clang (and MSVC) but accepted for ICC. The example in both defect reports is done correctly with GCC and all.
[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550 --- Comment #7 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > (In reply to cqwrteur from comment #4) > > (In reply to Andrew Pinski from comment #2) > > > Looks like it is a register allocation/scheduling issue. The extra > > > instructions are mov. > > > > Are there good algos that can allocate registers optimal? > > note the move instructions might be "free" on most modern x86 machine, it > just takes up icache space and decode time. > having so little registers and having a 2 operand instruction set makes > register allocation a hard problem really. Yes LLVM might get it right in > this testcase but there are others where GCC might do a better job. https://github.com/openssl/openssl/blob/38288f424faa0cf61bd705c497bb1a1657611da1/crypto/sha/asm/sha512-x86_64.pl#L18 OpenSSL's comments: # 40% improvement over compiler-generated code on Opteron. On EM64T # sha256 was observed to run >80% faster and sha512 - >40%. No magical # tricks, just straight implementation... I really wonder why gcc # [being armed with inline assembler] fails to generate as fast code. # The only thing which is cool about this module is that it's very # same instruction sequence used for both SHA-256 and SHA-512. In # former case the instructions operate on 32-bit operands, while in # latter - on 64-bit ones. All I had to do is to get one flavor right, # the other one passed the test right away:-)
[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550 --- Comment #6 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > (In reply to cqwrteur from comment #4) > > (In reply to Andrew Pinski from comment #2) > > > Looks like it is a register allocation/scheduling issue. The extra > > > instructions are mov. > > > > Are there good algos that can allocate registers optimal? > > note the move instructions might be "free" on most modern x86 machine, it > just takes up icache space and decode time. > having so little registers and having a 2 operand instruction set makes > register allocation a hard problem really. Yes LLVM might get it right in > this testcase but there are others where GCC might do a better job. I know. I am just investigating why compilers generate lesser optimal assembly than openssl for sha512. https://github.com/tearosccebe/fast_io/blob/988d75ddb4af7c745df97124a6f3d1842936bfa3/include/fast_io_crypto/hash/sha512_scalar.h#L20 One round GCC would generate 55 instructions while OpenSSL only needs 47 instructions. The performance difference is quite noticeable since more register allocations here might add more trivial load/store to memory for saving temporaries.
[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550 --- Comment #5 from Andrew Pinski --- (In reply to cqwrteur from comment #4) > (In reply to Andrew Pinski from comment #2) > > Looks like it is a register allocation/scheduling issue. The extra > > instructions are mov. > > Are there good algos that can allocate registers optimal? note the move instructions might be "free" on most modern x86 machine, it just takes up icache space and decode time. having so little registers and having a 2 operand instruction set makes register allocation a hard problem really. Yes LLVM might get it right in this testcase but there are others where GCC might do a better job.
[Bug c++/59704] Wrong overload chosen, compiler errornously thinks non-constant zero expression is implicitly castable to null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59704 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #4 from Andrew Pinski --- The oiriginal testcase in comment #0 and the testcase in the dup (PR 62145) are fixed in GCC 6+.
[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550 --- Comment #4 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > Looks like it is a register allocation/scheduling issue. The extra > instructions are mov. Are there good algos that can allocate registers optimal?
[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550 --- Comment #3 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > Looks like it is a register allocation/scheduling issue. The extra > instructions are mov. yeah. I feel gcc generally has issues with register allocations.
[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization, ra --- Comment #2 from Andrew Pinski --- Looks like it is a register allocation/scheduling issue. The extra instructions are mov.
[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
--- Comment #1 from Andrew Pinski ---
#include
#include
inline constexpr std::uint_least64_t s0(std::uint_least64_t x) noexcept
{
return std::rotr(x,1)^std::rotr(x,8)^(x>>7);
}
inline constexpr std::uint_least64_t s1(auto x) noexcept
{
return std::rotr(x,19)^std::rotr(x,61)^(x>>6);
}
void rd(std::uint_least64_t* x) noexcept
{
x[0]+=s0(x[1])+s1(x[14])+x[9];
}
[Bug c++/59704] Wrong overload chosen, compiler errornously thinks non-constant zero expression is implicitly castable to null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59704 --- Comment #3 from Andrew Pinski --- (In reply to Arthur O'Dwyer from comment #2) > Here is another example: > https://wandbox.org/permlink/UYsLyMaLcBb6sjJa That is PR 52145.
[Bug rtl-optimization/103550] New: 2 more instructions generated by gcc than clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550 Bug ID: 103550 Summary: 2 more instructions generated by gcc than clang Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- GCC https://godbolt.org/z/Y5W3xfeao clang https://godbolt.org/z/8EW6v77PP GCC generates 2 more instructions. why?
[Bug c++/52145] [C++11] [DR 903] zero-valued integer constant expression should prefer conversion to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145
Andrew Pinski changed:
What|Removed |Added
Blocks|88655 |94404
Alias||cwg903
--- Comment #11 from Andrew Pinski ---
Here is a testcase which tests all of the null pointerness in C++11 (+):
#include
extern "C" int puts(const char*);
typedef unsigned long uint64_t;
typedef long int64_t;
struct Foo { Foo(int64_t) { } };
bool t = true;
void foo(const char*)
{
if (t)
__builtin_abort();
puts("In foo(const char*)");
}
void foo(const Foo&)
{
if (!t)
__builtin_abort();
puts("In foo(const Foo&)");
}
int main()
{
#if __cplusplus >= 201103L
t= true;
#else
t= false;
#endif
foo((int)0);
foo((unsigned)0);
foo((short)0);
foo((unsigned short)0);
foo((int64_t)0);
foo((uint64_t)0);
foo(int());
#if __cplusplus >= 201103L
foo(int{});
t= false;
foo(nullptr);
#endif
foo(0u);
foo(0ul);
foo(0ull);
foo(0);
foo(NULL);
}
CUT
We get this right for C++98 but wrong for C++11.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88655
[Bug 88655] Different overloaded function being called depending on which
compiler is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues
[Bug c++/52145] [C++11] [DR 903] zero-valued integer constant expression should prefer conversion to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145 Andrew Pinski changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 77712 has been marked as a duplicate of this bug. ***
[Bug c++/77712] [DR903] int() is incorrectly treated as a null pointer constant in C++11 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77712 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 52145. *** This bug has been marked as a duplicate of bug 52145 ***
[Bug c++/52145] [C++11] [DR 903] zero-valued integer constant expression should prefer conversion to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145 Andrew Pinski changed: What|Removed |Added CC||dominique.pelle at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 88655 has been marked as a duplicate of this bug. ***
[Bug c++/88655] Different overloaded function being called depending on which compiler is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88655 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 52145. *** This bug has been marked as a duplicate of bug 52145 ***
[Bug c++/65707] internal compiler error: in unify, at cp/pt.c:18577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65707 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.2
[Bug c++/60223] [c++11] ICE with C++11-style default template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60223 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.2
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028 Alexandre Oliva changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Alexandre Oliva --- Fixed
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028 --- Comment #8 from Alexandre Oliva --- Fixed
[Bug c++/90391] nonconforming value initialization when type T has a base class with a user-defined default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90391 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2019-06-12 00:00:00 |2021-12-3 --- Comment #2 from Andrew Pinski --- This seems wrong: b.D.38353.i = 0; b.j = 0; B::B ();
[Bug c++/86473] a problem in member lookup?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86473 Andrew Pinski changed: What|Removed |Added Known to fail||10.3.0 Known to work||11.1.0 Keywords||needs-bisection --- Comment #3 from Andrew Pinski --- Looks to be fixed in GCC 11+.
[Bug c++/90412] g++ suggest did you mean for namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90412 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-04 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/70438] result type of vector operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70438 --- Comment #4 from Andrew Pinski --- The documentation says: The result of the comparison is a vector of the same width and number of elements as the comparison operands with a signed integral element type. But it is obviously not true.
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028 --- Comment #7 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:daca416fc2816a5e481b26c8d2010127101d77ce commit r12-5787-gdaca416fc2816a5e481b26c8d2010127101d77ce Author: Alexandre Oliva Date: Sat Dec 4 00:17:16 2021 -0300 [PR103028] test ifcvt trap_if seq more strictly after reload When -fif-conversion2 is enabled, we attempt to replace conditional branches around unconditional traps with conditional traps. That canonicalizes compares, which may change an immediate that barely fits into one that doesn't. The compare for the trap is first checked using the predicates of cbranch predicates, and then, compare and conditional trap insns are emitted and recognized. In the failing s390x testcase, i <=u 0x_ is canonicalized into i
[Bug c++/65994] auto deduces object instead of initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65994 --- Comment #4 from Andrew Pinski --- CWG2038 : http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2038 Looks like it is explicit that there should be a difference between C++11/14 and C++17 But I can't find a compiler which accepts this code for C++11 or C++14 modes
[Bug c++/85589] Non type template parameter should allow object with no linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85589 --- Comment #3 from Andrew Pinski --- I suspect r9-3836-g4be5c72cf3ea3 fixed this (maybe on accident).
[Bug c++/77950] GCC produces un-demanglable symbols with [] (auto&) { ... } lambdas in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77950
--- Comment #2 from Ian Lance Taylor ---
Just a note that my Go demangler does demangle this symbol now, producing
ossia::vec_merger_impl<2>::operator() > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
>(eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
const&)::{lambda(auto:1&)#1}&&
eggs::variants::detail::forward::operator() > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
>(eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
const&)::{lambda(auto:1&)#1}&&>(std::remove_reference::operator() > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
>(eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
const&)::{lambda(auto:1&)#1}&&>::type&)
[Bug c++/83258] Rejecting function pointer non-type template parameter without linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83258
--- Comment #11 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #4)
> Testcase from Bug 85589:
>
> template struct foo {};
>
> int main() {
> static auto v = "str";
> (void) foo {};
> }
Note comment #4 is already fixed (I reopened PR 85589 to close it was fixed [or
as a dup if I can find one]).
The rest of the testcases still fail on the trunk.
[Bug libstdc++/103549] [12 regression] Uninitialized member warning from regex header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103549 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-12-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- I think this is intentional, or at least not a bug. The match_results type can't be used for much until it's "ready" and the member will be set then. But it looks like this would read the indeterminate value: cmatch m1, m2; m1.swap(m2); So we should initialize it as you suggest.
[Bug c++/85589] Non type template parameter should allow object with no linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85589 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|NEW Ever confirmed|0 |1 Resolution|DUPLICATE |--- Last reconfirmed||2021-12-04 --- Comment #2 from Andrew Pinski --- Reopening as this one is fixed while the other PR is not.
[Bug c++/57570] Deduction succeeds despite type mismatch of non-type template parameter and deduced argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57570 Andrew Pinski changed: What|Removed |Added Known to fail||5.1.0, 6.1.0, 7.1.0, 7.5.0 Ever confirmed|0 |1 Last reconfirmed||2021-12-04 Keywords||needs-bisection Known to work||8.1.0 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Seems to be fixed in GCC 8+.
[Bug libstdc++/103549] New: [12 regression] Uninitialized member warning from regex header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103549
Bug ID: 103549
Summary: [12 regression] Uninitialized member warning from
regex header
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
With a recent checkout of gcc12 (20211201) on a x86_64-pc-linux-gnu host,
compiling the following source with -O2 -Wall gives a warning
about an uninitialized member in the regex header:
-- x.cc ---
#include
#include
std::string plover(char *s)
{
return std::regex_replace (s, std::regex{"xyzzy"}, "plugh");
}
---
$ g++ -c -O2 -Wall x.cc
In file included from /usr/local/gcc/include/c++/12.0.0/regex:66,
from x.cc:2:
In member function ‘std::__cxx11::match_results< ,
>& std::__cxx11::match_results<
, >::operator=(const
std::__cxx11::match_results< ,
>&) [with _Bi_iter = const char*; _Alloc =
std::allocator >]’,
inlined from ‘std::__cxx11::regex_iterator<_Bi_iter, _Ch_type, _Rx_traits>&
std::__cxx11::regex_iterator<_Bi_iter, _Ch_type, _Rx_traits>::operator=(const
std::__cxx11::regex_iterator<_Bi_iter, _Ch_type, _Rx_traits>&) [with _Bi_iter =
const char*; _Ch_type = char; _Rx_traits = std::__cxx11::regex_traits]’
at /usr/local/gcc/include/c++/12.0.0/bits/regex.h:2699:7,
inlined from ‘std::__cxx11::regex_iterator<_Bi_iter, _Ch_type,
_Rx_traits>::regex_iterator(_Bi_iter, _Bi_iter, const
std::__cxx11::regex_iterator<_Bi_iter, _Ch_type, _Rx_traits>::regex_type&,
std::regex_constants::match_flag_type) [with _Bi_iter = const char*; _Ch_type =
char; _Rx_traits = std::__cxx11::regex_traits]’ at
/usr/local/gcc/include/c++/12.0.0/bits/regex.h:2685:10,
inlined from ‘_Out_iter std::regex_replace(_Out_iter, _Bi_iter, _Bi_iter,
const std::__cxx11::basic_regex<_Ch_type, _Rx_traits>&, const _Ch_type*,
std::regex_constants::match_flag_type) [with _Out_iter =
std::back_insert_iterator >; _Bi_iter = const
char*; _Rx_traits = std::__cxx11::regex_traits; _Ch_type = char]’ at
/usr/local/gcc/include/c++/12.0.0/bits/regex.tcc:470:14,
inlined from ‘std::__cxx11::basic_string<_Ch_type> std::regex_replace(const
_Ch_type*, const std::__cxx11::basic_regex<_Ch_type, _Rx_traits>&, const
_Ch_type*, std::regex_constants::match_flag_type) [with _Rx_traits =
std::__cxx11::regex_traits; _Ch_type = char]’ at
/usr/local/gcc/include/c++/12.0.0/bits/regex.h:2638:20,
inlined from ‘std::string plover(char*)’ at x.cc:6:61:
/usr/local/gcc/include/c++/12.0.0/bits/regex.h:1784:7: warning:
‘.std::__cxx11::regex_iterator >::_M_match.std::__cxx11::match_results::_M_begin’ may be used uninitialized [-Wmaybe-uninitialized]
1784 | operator=(const match_results&) = default;
| ^~~~
/usr/local/gcc/include/c++/12.0.0/bits/regex.h: In function ‘std::string
plover(char*)’:
/usr/local/gcc/include/c++/12.0.0/bits/regex.h:2685:19: note: ‘’
declared here
2685 | *this = regex_iterator();
| ^~~~
$
This warning seems to be correct. The match_results class in regex.h
is default-constructed here, and it has a member
_Bi_iter _M_begin;
In this example, _Bi_iter is const char*, so it is indeed not initialized
if the class is default-constructed.
The following change gets rid of the warning for me:
diff --git a/libstdc++-v3/include/bits/regex.h
b/libstdc++-v3/include/bits/regex.h
index 785edc71800..5318f378ada 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -2109,7 +2109,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
_M_suffix()
{ return _Unchecked::operator[](_Unchecked::size() - 1); }
- _Bi_iter _M_begin;
+ _Bi_iter _M_begin {};
/// @endcond
};
[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271 Jim Wilson changed: What|Removed |Added CC||kito.cheng at gmail dot com --- Comment #18 from Jim Wilson --- I found the place where the movti patterns were removed. This is a riscv-gcc commit from Kito. commit 38650bdbe91bf37c3cce706ce612097b657a91d5 Author: Kito Cheng Date: Mon Sep 12 14:52:56 2016 +0800 Remove 128 bit support, just let gcc handle it I don't see a github pull request or issue for it, so I don't know why Kito removed the support. This is a little too long ago to easily find info related to the change. This is a gcc-6.1 source base. Unless perhaps Kito remembers why he made the change, all I can do is readd the support and wait to see if something else breaks. I do think that we should readd the movti support to fix a couple of bugs. I suspect a code size or performance issue, but wrong code and ICEs are worse problems than code size and performance.
[Bug c++/70932] flexible array member with non-trivial destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932 Andrew Pinski changed: What|Removed |Added Known to work|10.1.0, 11.1.0, 12.0| Keywords|needs-bisection,| |rejects-valid | --- Comment #13 from Andrew Pinski --- (In reply to Andrew Pinski from comment #12) > Looks like this was fixed in GCC 10+. Actually no, what changed in GCC 10, is that synthesized deconstructor is not created until actually used; that is it is lazy.
[Bug c++/70932] flexible array member with non-trivial destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932 Andrew Pinski changed: What|Removed |Added Known to fail||8.1.0, 9.1.0, 9.4.0 Keywords||needs-bisection, ||rejects-valid Known to work||10.1.0, 11.1.0, 12.0 --- Comment #12 from Andrew Pinski --- Looks like this was fixed in GCC 10+.
[Bug libstdc++/92300] Useless allocator call in std::map, when insert does not perform any insertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300 --- Comment #5 from Jonathan Wakely --- Created attachment 51924 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51924=edit Patch to avoid creating a node if inserting something key-like into a map This avoids the allocate/deallocate pair for the failed insertion in your original example.
[Bug libstdc++/92300] Useless allocator call in std::map, when insert does not perform any insertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> This inserts the correct value type, and doesn't perform an addition
> allocation:
>
> assert(a.insert(std::pair(1, 1)).second);
> assert(a.insert(std::pair(2, 2)).second);
> assert(!a.insert(std::pair(1, 3)).second);
Or simply a.insert({1, 1}) which calls the same overload as those lines above.
Basically the problem is that you are using make_pair when it isn't only
unnecessary, it's actively harmful. There are much better solutions in modern
C++.
However, there are other scenarios where this optimization would be useful,
where you already have a pair from some other source (rather than creating it
incorrectly at the point of insertion).
[Bug c++/82873] Generated copy constructor calls constructors for 0-sized array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82873 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101029 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Fixed even in GCC 10.4.0 by the patches which fix PR 101029.
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 --- Comment #23 from Peter Bergner --- (In reply to Peter Bergner from comment #22) > So this is also broken in GCC11, so I'm testing the simple backport. Regression testing of the backport was clean. Just need approval for the backport.
[Bug c++/82873] Generated copy constructor calls constructors for 0-sized array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82873 Andrew Pinski changed: What|Removed |Added Known to fail||10.3.0 Known to work||11.2.0 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > This looks fixed on the trunk. And in GCC 11.2.0
[Bug c++/57977] zero-length const array in union prohibits default copy ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57977 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||rejects-valid --- Comment #4 from Andrew Pinski --- Confirmed
[Bug c++/82873] Generated copy constructor calls constructors for 0-sized array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82873 Andrew Pinski changed: What|Removed |Added Known to work||12.0 Keywords||link-failure --- Comment #3 from Andrew Pinski --- This looks fixed on the trunk.
[Bug libstdc++/70692] No warning when std::function binds a reference to a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692 --- Comment #5 from Jonathan Wakely --- "A type trait to detect reference binding to temporary" https://wg21.link/p2255r2 is the current direction to resolve this.
[Bug c++/103540] diagnosting concept depends on itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103540
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Jonathan Wakely ---
Please provide the code here in bugzilla, not just a URL, as requested at
https://gcc.gnu.org/bugs/
#include
template
concept StrictNodeType = requires {
typename N::something;
};
template using Int = int;
template
struct X {using something = Int; };
using ThisBreaks = Int>;
As well as the "depends on itself" error and the incomplete "because" note,
there is an error pointing to exactly the right spot already:
:11:17: error: template constraint failure for 'template
requires StrictNodeType using Int = int'
11 | struct X {using something = Int; };
| ^
[Bug c++/97222] GCC discards attributes aligned and may_alias for typedefs passed as template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222 Andrew Pinski changed: What|Removed |Added CC||myriachan at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 84415 has been marked as a duplicate of this bug. ***
[Bug c++/84415] Using __m128 as a template parameter causes warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84415 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Even though this bug is older, PR 97222 has more information on the issue at hand. So closing this one as a dup of bug 97222. *** This bug has been marked as a duplicate of bug 97222 ***
[Bug bootstrap/103547] [12 Regression] Bootstrap failure with --with-cpu=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547 --- Comment #3 from H.J. Lu --- r12-5778 builds now. It has happened once before. I will leave it open until we find out exactly what is going on.
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 Peter Bergner changed: What|Removed |Added Known to fail||11.0 Target Milestone|12.0|11.4 --- Comment #22 from Peter Bergner --- So this is also broken in GCC11, so I'm testing the simple backport.
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 since r8-7594-g078c5aff5ed83e9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #10) > On Thu, Dec 02, 2021 at 09:51:23PM +, anlauf at gcc dot gnu.org wrote: > > > > Submitted as: > > https://gcc.gnu.org/pipermail/fortran/2021-December/057102.html > > > > Just saw the commit fly by. Thanks for pursuing this issue! Heh, you could also do some more regtesting...
[Bug fortran/103283] ICE in gfc_trans_array_constructor_subarray, at fortran/trans-array.c:1972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103283 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #3) > integer, parameter :: k(*) = x(1)%a > > This fails with: > > pr103283-z1.f90:6:28: > > 6 | integer, parameter :: k(*) = x(1)%a > |1 > Error: Cannot initialize implied-shape array at (1) with scalar Doing some debugging, we seem to lose the shape when simplifying the r.h.s. near the end of expr.c::simplify_parameter_variable: /* Do not copy subobject refs for constant. */ if (e->expr_type != EXPR_CONSTANT && p->ref != NULL) e->ref = gfc_copy_ref (p->ref); t = gfc_simplify_expr (e, type); Initially the ref looks fine, but it might be evaluated improperly. We end up with a scalar instead of a rank-1 array.
[Bug bootstrap/103547] [12 Regression] Bootstrap failure with --with-cpu=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547 Tamar Christina changed: What|Removed |Added CC|tamar.christina at arm dot com | --- Comment #2 from Tamar Christina --- I can't seem to reproduce this. With the current HEAD, using the same options as here it works fine on a Skylake-avx512 system. ~/gcc-native> ./install/bin/gcc -v Using built-in specs. COLLECT_GCC=./install/bin/gcc COLLECT_LTO_WRAPPER=/gcc-native/install/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /gcc-dsg/configure --with-cpu=native --prefix=/gcc-native/install --enable-clocale=gnu --with-system-zlib --enable-shared --enable-cet --with-demangler-in-ld --enable-libmpx --with-multilib-list=m32,m64,mx32 --with-fpmath=sse Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20211203 (experimental) (GCC) with a base gcc of 7.5.0, what bootstrap gcc are you using?
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 --- Comment #21 from Peter Bergner --- Fixed on trunk.
[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939 --- Comment #7 from Jason Merrill --- (In reply to Andrew Pinski from comment #6) > Note I think this paper applies to C++20 too or at least part of it. > > From CWG1291: > [Accepted at the November, 2020 meeting as part of paper P1787R6 and moved > to DR at the February, 2021 meeting.] Yes, but I think we need to be conservative about changes that break existing code. My expectation in comment #0 that the amount of code broken would be small seems to have been over-optimistic.
[Bug rtl-optimization/103541] unnecessary spills around const functions calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > PR 5739 is related (though I have not looked fully). comment #10 which points out IRA was doing worse.
[Bug rtl-optimization/103541] unnecessary spills around const functions calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=5739 --- Comment #2 from Andrew Pinski --- PR 5739 is related (though I have not looked fully).
[Bug rtl-optimization/103541] unnecessary spills around const functions calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541 --- Comment #1 from Andrew Pinski --- I thought I had seen this before ...
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 --- Comment #20 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:cff7879a381d3f5ed6556206896e6a6229800167 commit r12-5781-gcff7879a381d3f5ed6556206896e6a6229800167 Author: Martin Liska Date: Fri Dec 3 11:58:25 2021 -0600 rs6000: Fix up flag_shrink_wrap handling in presence of -mrop-protect [PR101324] PR101324 shows a problem in disabling shrink-wrapping when using -mrop-protect when there is a attribute optimize/pragma. The fix envolves moving the handling of flag_shrink_wrap so it gets re-disbled when we change or add options. 2021-12-03 Martin Liska gcc/ PR target/101324 * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the disabling of shrink-wrapping when using -mrop-protect from here... (rs6000_override_options_after_change): ...to here. 2021-12-03 Peter Bergner gcc/testsuite/ PR target/101324 * gcc.target/powerpc/pr101324.c: New test.
[Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103537
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Last reconfirmed||2021-12-03
--- Comment #3 from Andrew Pinski ---
(In reply to Hedayat Vatankhah from comment #2)
> With these options, the code runs a bit more but still crashes.
Right those options are supposed to be used to catch issues in your code.
> The output
> of each option is given below:
>
> Output with -fsanitize=undefined:
> /home/hedayat/Projects/powerfake/powerfake.h:257:40: runtime error: load of
> misaligned address 0x0044c556 for type ' *', which requires 8
> byte alignment
> 0x0044c556: note: pointer points here
> 00 e8 ac 5a 00 00 84 c0 74 17 48 8d 55 f4 48 8d 45 f8 48 89 c6 bf 00 5c
> 4b 00 e8 17 5b 00 00 eb
> ^
> zsh: segmentation fault (core dumped) ./sample/samples
Can you check the above part of the problem.
template
remove_func_cv_t unify_pmf(FuncType f)
{
return reinterpret_cast>(f);
}
This looks like it could cause issues.
So does:
return std::make_pair(reinterpret_cast(func_ptr),
std::type_index(typeid(FuncType)));
I get the feeling you don't understand how pointer to member functions work in
some cases.
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 since r8-7594-g078c5aff5ed83e9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 --- Comment #10 from Steve Kargl --- On Thu, Dec 02, 2021 at 09:51:23PM +, anlauf at gcc dot gnu.org wrote: > > Submitted as: https://gcc.gnu.org/pipermail/fortran/2021-December/057102.html > Just saw the commit fly by. Thanks for pursuing this issue!
[Bug tree-optimization/103544] [11/12 Regression] compiler crashes when trying to vectorize loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103544
Andrew Pinski changed:
What|Removed |Added
Component|c++ |tree-optimization
Known to work||10.1.0, 10.3.0
Last reconfirmed||2021-12-03
Summary|compiler crashes when |[11/12 Regression] compiler
|trying to vectorize loop|crashes when trying to
||vectorize loop
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Target Milestone|--- |11.3
Known to fail||11.1.0, 11.2.0
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Testcase without any headers:
int crash_me(char* ptr, unsigned long size){
short result[16] = {0};
unsigned long no_iters = 0;
for(unsigned long i = 0; i < size - 12; i+= 13){
for(unsigned long j = 0; j < 12; j++){
result[j] += ptr[i + j] - '0';
}
no_iters++;
}
int result_int = 0;
for(int j = 0; j < 12; j++){
int bit_value = result[j] > no_iters/2 ? 1 : 0;
result_int |= bit_value;
}
return result_int;
}
[Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103537 --- Comment #2 from Hedayat Vatankhah --- With these options, the code runs a bit more but still crashes. The output of each option is given below: Output with -fsanitize=undefined: /home/hedayat/Projects/powerfake/powerfake.h:257:40: runtime error: load of misaligned address 0x0044c556 for type ' *', which requires 8 byte alignment 0x0044c556: note: pointer points here 00 e8 ac 5a 00 00 84 c0 74 17 48 8d 55 f4 48 8d 45 f8 48 89 c6 bf 00 5c 4b 00 e8 17 5b 00 00 eb ^ zsh: segmentation fault (core dumped) ./sample/samples Output with -fsanitize=address: AddressSanitizer:DEADLYSIGNAL = ==261345==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x00412704 bp 0x7ffcdfbd4c10 sp 0x7ffcdfbd4c00 T0) ==261345==The signal is caused by a READ memory access. ==261345==Hint: this fault was caused by a dereference of a high value address (see register values below). Dissassemble the provided pc to learn which register was used. #0 0x412704 in decltype(auto) PowerFake::internal::TagBase::Call(FakeTest::SampleClass2&, int) (/home/hedayat/Projects/powerfake/build.o/sample/samples+0x412704) #1 0x404c14 in FakeOverloaded() (/home/hedayat/Projects/powerfake/build.o/sample/samples+0x404c14) #2 0x40364e in main (/home/hedayat/Projects/powerfake/build.o/sample/samples+0x40364e) #3 0x7ff8f02a055f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f) #4 0x7ff8f02a060b in __libc_start_main_alias_1 (/lib64/libc.so.6+0x2d60b) #5 0x403584 in _start (/home/hedayat/Projects/powerfake/build.o/sample/samples+0x403584) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/hedayat/Projects/powerfake/build.o/sample/samples+0x412704) in decltype(auto) PowerFake::internal::TagBase::Call(FakeTest::SampleClass2&, int) ==261345==ABORTING
[Bug c++/103544] compiler crashes when trying to vectorize loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103544
--- Comment #1 from Andrew Pinski ---
Testcase:
#include
#include
int crash_me(char* ptr, size_t size){
std::array result = {0};
size_t no_iters = 0;
for(size_t i = 0; i < size - 12; i+= 13){
for(size_t j = 0; j < 12; j++){
result[j] += ptr[i + j] - '0';
}
no_iters++;
}
int result_int = 0;
for(int j = 0; j < 12; j++){
int bit_value = result[j] > no_iters/2 ? 1 : 0;
result_int |= bit_value;
}
return result_int;
}
[Bug bootstrap/103547] [12 Regression] Bootstrap failure with --with-cpu=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547 Andrew Pinski changed: What|Removed |Added Keywords||build, wrong-code Target Milestone|--- |12.0 Summary|[12 Regression] Bootstrap |[12 Regression] Bootstrap |failure |failure with ||--with-cpu=skylake-avx512
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 since r8-7594-g078c5aff5ed83e9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 --- Comment #9 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f46d32dd29b7623915e31b0508e2e925526fa7d8 commit r12-5779-gf46d32dd29b7623915e31b0508e2e925526fa7d8 Author: Harald Anlauf Date: Thu Dec 2 22:33:49 2021 +0100 Fortran: improve checking of array specifications gcc/fortran/ChangeLog: PR fortran/103505 * array.c (match_array_element_spec): Try to simplify array element specifications to improve early checking. * expr.c (gfc_try_simplify_expr): New. Try simplification of an expression via gfc_simplify_expr. When an error occurs, roll back. * gfortran.h (gfc_try_simplify_expr): Declare it. gcc/testsuite/ChangeLog: PR fortran/103505 * gfortran.dg/pr103505.f90: New test. Co-authored-by: Steven G. Kargl
[Bug tree-optimization/103542] [10/11/12 Regregression] bogus -Warray-bounds while index is limited by switch/case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103542 Andrew Pinski changed: What|Removed |Added Known to fail||10.3.0 Keywords||diagnostic Target Milestone|--- |10.4 Component|other |tree-optimization Summary|bogus -Warray-bounds while |[10/11/12 Regregression] |index is limited by |bogus -Warray-bounds while |switch/case |index is limited by ||switch/case Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to work||9.4.0 Last reconfirmed||2021-12-03 --- Comment #1 from Andrew Pinski --- Confirmed. Part of the problem is we split the get_default_config function early on losing that id<=3
[Bug bootstrap/103547] [12 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina --- That's weird, I did bootstrap it on x86_64 before with default options. I'll try with these.
[Bug target/103548] Identical MMA assemble quads are incorrectly combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103548 Peter Bergner changed: What|Removed |Added Target||powerpc*-*-* Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Target Milestone|--- |12.0 Last reconfirmed||2021-12-03 Status|UNCONFIRMED |ASSIGNED Known to fail||10.0, 11.0, 12.0 Ever confirmed|0 |1 --- Comment #1 from Peter Bergner --- Mine.
[Bug libstdc++/70692] No warning when std::function binds a reference to a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692 Andrew Pinski changed: What|Removed |Added CC||gcc at hazlewoods dot net --- Comment #4 from Andrew Pinski --- *** Bug 103543 has been marked as a duplicate of this bug. ***
[Bug c++/103543] Potential compiler warning for return of temporary with std::function converting from T(*)()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103543 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- This is a dup of bug 70692. *** This bug has been marked as a duplicate of bug 70692 ***
[Bug target/43892] PowerPC suboptimal "add with carry" optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #36 from Roger Sayle --- Patch proposed: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586169.html
[Bug c++/103543] Potential compiler warning for return of temporary with std::function converting from T(*)()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103543
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Summary|Potential compiler warning |Potential compiler warning
|for return of temporary?|for return of temporary
||with std::function converting from
||T(*)()
--- Comment #1 from Andrew Pinski ---
That is because the lambda itself returns a S and not a const reference.
You do get a warning with -Wsystem-headers inside invoke.
With:
[]() -> S const& { return S{}; };
You do get the correct warning.
Also this has nothing to do with lambdas really but really std::function as
shown by:
struct S
{
int s{};
};
using F = std::function;
auto fn()
{
return S{};
}
int main()
{
F f = fn; // No warning
__builtin_printf("%d.\n", f().s);
}
CUT
The above code is the same as the lambda case really.
[Bug analyzer/103521] [12 regression] gcc.dg/analyzer/pr93032-mztools.c broken after r12-5585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103521 --- Comment #1 from seurer at gcc dot gnu.org --- The message changed recently: FAIL: gcc.dg/analyzer/pr93032-mztools.c leak of fpOut at line 329 (test for warnings, line 328) FAIL: gcc.dg/analyzer/pr93032-mztools.c leak of fpOutCD at line 330 (test for warnings, line 328)
[Bug c++/54366] [meta-bug] decltype issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54366 Bug 54366 depends on bug 81176, which changed state. Bug 81176 Summary: decltype(auto) yields reference type for structured binding https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81176 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/81176] decltype(auto) yields reference type for structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81176 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Test added in abd7712f91c99690f8b0046ea168b2782afbac69.
[Bug c++/103403] [11 Regression] auto return type with a trailing return type of decl(auto) uses rvalue reference type instead of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403 Marek Polacek changed: What|Removed |Added Summary|[11/12 Regression] auto |[11 Regression] auto return |return type with a trailing |type with a trailing return |return type of decl(auto) |type of decl(auto) uses |uses rvalue reference type |rvalue reference type |instead of reference type |instead of reference type --- Comment #6 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/103403] [11/12 Regression] auto return type with a trailing return type of decl(auto) uses rvalue reference type instead of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:abd7712f91c99690f8b0046ea168b2782afbac69 commit r12-5778-gabd7712f91c99690f8b0046ea168b2782afbac69 Author: Marek Polacek Date: Tue Nov 30 21:07:25 2021 -0500 c++: Fix for decltype(auto) and parenthesized expr [PR103403] In r11-4758, I tried to fix this problem: int & = 0; decltype(auto) j = i; // should behave like int & = i; error wherein do_auto_deduction was getting confused with a REFERENCE_REF_P and it didn't realize its operand was a name, not an expression, and deduced the wrong type. Unfortunately that fix broke this: int&& r = 1; decltype(auto) rr = (r); where 'rr' should be 'int &' since '(r)' is an expression, not a name. But because I stripped the INDIRECT_REF with the r11-4758 change, we deduced 'rr's type as if decltype had gotten a name, resulting in 'int &&'. I suspect I thought that the REF_PARENTHESIZED_P check when setting 'bool id' in do_auto_deduction would handle the (r) case, but that's not the case; while the documentation for REF_PARENTHESIZED_P specifically says it can be set in INDIRECT_REF, we don't actually do so. This patch sets REF_PARENTHESIZED_P even on REFERENCE_REF_P, so that do_auto_deduction can use it. It also removes code in maybe_undo_parenthesized_ref that I think is dead -- and we don't hit it while running dg.exp. To adduce more data, it also looks dead here: https://splichal.eu/lcov/gcc/cp/semantics.c.gcov.html (It's dead since r9-1417.) Also add a fixed test for c++/81176. PR c++/103403 gcc/cp/ChangeLog: * cp-gimplify.c (cp_fold): Don't recurse if maybe_undo_parenthesized_ref doesn't change its argument. * pt.c (do_auto_deduction): Don't strip REFERENCE_REF_P trees if they are REF_PARENTHESIZED_P. Use stripped_init when checking for id-expression. * semantics.c (force_paren_expr): Set REF_PARENTHESIZED_P on REFERENCE_REF_P trees too. (maybe_undo_parenthesized_ref): Remove dead code. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/decltype-auto2.C: New test. * g++.dg/cpp1y/decltype-auto3.C: New test. * g++.dg/cpp1y/decltype-auto4.C: New test. * g++.dg/cpp1z/decomp-decltype1.C: New test.
[Bug target/103548] New: Identical MMA assemble quads are incorrectly combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103548
Bug ID: 103548
Summary: Identical MMA assemble quads are incorrectly combined
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We incorrectly combine multiple identical build/assemble quads/accs leading to
incorrect assembly being generated:
typedef unsigned char vec_t __attribute__((vector_size(16)));
void
foo (__vector_quad *dst, vec_t *src)
{
__vector_quad quad0, quad1;
/* Adjacent loads should be combined into two lxvp instructions.
and identical build accs should not be combined. */
__builtin_mma_build_acc (, src[0], src[1], src[2], src[3]);
__builtin_mma_build_acc (, src[0], src[1], src[2], src[3]);
dst[0] = quad0;
dst[2] = quad1;
}
...gives:
lxv 3,0(4)
lxv 2,16(4)
lxv 1,32(4)
lxv 0,48(4)
xxmtacc 0
xxmfacc 0
stxvp 2,0(3)
stxvp 0,32(3)
xxmfacc 0
stxvp 2,128(3)
stxvp 0,160(3)
blr
Notive we only have 4 loads and 1 xxmtacc but 2 xxmfacc. This is incorrect. I
have a patch I'm testing.
Note that for build/assemble pair, we are allowed to combine identical
calls...amd we do.
[Bug bootstrap/103547] New: [12 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547 Bug ID: 103547 Summary: [12 Regression] Bootstrap failure Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: tamar.christina at arm dot com Target Milestone: --- Target: x86-64 On Linux/x86-64, r12-5775 failed to bootstrap when configured --with-arch=native --with-cpu=native --prefix=/usr/12.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared --enable-cet --with-demangler-in-ld --enable-libmpx --with-multilib-list=m32,m64,mx32 --with-fpmath=sse where native == skylake-avx512: https://gcc.gnu.org/pipermail/gcc-regression/2021-December/075945.html In file included from ../../src-master/gcc/gimple-ssa-strength-reduction.c:37: In member function ‘hash_table::value_type* hash_table::alloc_entries(size_t) const [with Descriptor = hash_map::hash_entry; bool Lazy = false; Allocator = xcallocator]’, inlined from ‘void hash_table::expand() [with Descriptor = hash_map::hash_entry; bool Lazy = false; Allocator = xcallocator]’ at ../../src-master/gcc/hash-table.h:802:40: ../../src-master/gcc/system.h:784:34: error: section type conflict with ‘void hash_table::expand() [with Descriptor = hash_map::hash_entry; bool Lazy = false; Allocator = xcallocator]’ 784 |((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~ ../../src-master/gcc/hash-table.h:715:3: note: in expansion of macro ‘gcc_assert’ 715 | gcc_assert (nentries != NULL); | ^~ In file included from ../../src-master/gcc/coretypes.h:482, from ../../src-master/gcc/gimple-ssa-strength-reduction.c:38: ../../src-master/gcc/hash-table.h: In member function ‘void hash_table::expand() [with Descriptor = hash_map::hash_entry; bool Lazy = false; Allocator = xcallocator]’: ../../src-master/gcc/hash-table.h:779:1: note: ‘void hash_table::expand() [with Descriptor = hash_map::hash_entry; bool Lazy = false; Allocator = xcallocator]’ was declared here 779 | hash_table::expand () | ^~~ /export/gnu/import/git/gcc-test-master-intel64-native/bld/./prev-gcc/xg++ -B/export/gnu/import/git/gcc-test-master-intel64-native/bld/./prev-gcc/ -B/usr/12.0.0/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/libsupc++ -L/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src-master/gcc -I../../src-master/gcc/. -I../../src-master/gcc/../include -I../../src-master/gcc/../libcpp/include -I../../src-master/gcc/../libcody -I../../src-master/gcc/../libdecnumber -I../../src-master/gcc/../libdecnumber/bid -I../libdecnumber -I../../src-master/gcc/../libbacktrace -o loop-invariant.o -MT loop-invariant.o -MMD -MP -MF ./.deps/loop-invariant.TPo ../../src-master/gcc/loop-invariant.c /export/gnu/import/git/gcc-test-master-intel64-native/bld/./prev-gcc/xg++ -B/export/gnu/import/git/gcc-test-master-intel64-native/bld/./prev-gcc/ -B/usr/12.0.0/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/libsupc++ -L/export/gnu/import/git/gcc-test-master-intel64-native/bld/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
[Bug analyzer/103546] New: Analyzer reports null dereference in flex scanners
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103546 Bug ID: 103546 Summary: Analyzer reports null dereference in flex scanners Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: m...@nieper-wisskirchen.de Target Milestone: --- I am trying to compile a flex-generated lexical scanner with the analyzer enabled. However, the analyzer reports a NULL dereference in the flex-generated file. Is this really a bug in Flex? It looks like a false positive to me. This is the MWE: $ flex --version flex 2.6.4 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.2.0-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2) $ cat scan.l %% $ flex scan.l $ gcc -fanalyzer -Werror -c lex.yy.c In function ‘yy_init_buffer’: lex.yy.c:1290:26: error: dereference of NULL ‘b’ [CWE-476] [-Werror=analyzer-null-dereference]
[Bug target/103269] Enable ZMM in MOVE_MAX and STORE_MAX_PIECES without -mprefer-vector-width=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103269 --- Comment #2 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:654cd743c88a28fb292f7c2cf5f4b10e4047e7d9 commit r12-5777-g654cd743c88a28fb292f7c2cf5f4b10e4047e7d9 Author: H.J. Lu Date: Mon Nov 15 18:52:56 2021 -0800 x86: Add -mmove-max=bits and -mstore-max=bits Add -mmove-max=bits and -mstore-max=bits to enable 256-bit/512-bit move and store, independent of -mprefer-vector-width=bits: 1. Add X86_TUNE_AVX512_MOVE_BY_PIECES and X86_TUNE_AVX512_STORE_BY_PIECES which are enabled for Intel Sapphire Rapids processor. 2. Add -mmove-max=bits to set the maximum number of bits can be moved from memory to memory efficiently. The default value is derived from X86_TUNE_AVX512_MOVE_BY_PIECES, X86_TUNE_AVX256_MOVE_BY_PIECES, and the preferred vector width. 3. Add -mstore-max=bits to set the maximum number of bits can be stored to memory efficiently. The default value is derived from X86_TUNE_AVX512_STORE_BY_PIECES, X86_TUNE_AVX256_STORE_BY_PIECES and the preferred vector width. gcc/ PR target/103269 * config/i386/i386-expand.c (ix86_expand_builtin): Pass PVW_NONE and PVW_NONE to ix86_target_string. * config/i386/i386-options.c (ix86_target_string): Add arguments for move_max and store_max. (ix86_target_string::add_vector_width): New lambda. (ix86_debug_options): Pass ix86_move_max and ix86_store_max to ix86_target_string. (ix86_function_specific_print): Pass ptr->x_ix86_move_max and ptr->x_ix86_store_max to ix86_target_string. (ix86_valid_target_attribute_tree): Handle x_ix86_move_max and x_ix86_store_max. (ix86_option_override_internal): Set the default x_ix86_move_max and x_ix86_store_max. * config/i386/i386-options.h (ix86_target_string): Add prefer_vector_width and prefer_vector_width. * config/i386/i386.h (TARGET_AVX256_MOVE_BY_PIECES): Removed. (TARGET_AVX256_STORE_BY_PIECES): Likewise. (MOVE_MAX): Use 64 if ix86_move_max or ix86_store_max == PVW_AVX512. Use 32 if ix86_move_max or ix86_store_max >= PVW_AVX256. (STORE_MAX_PIECES): Use 64 if ix86_store_max == PVW_AVX512. Use 32 if ix86_store_max >= PVW_AVX256. * config/i386/i386.opt: Add -mmove-max=bits and -mstore-max=bits. * config/i386/x86-tune.def (X86_TUNE_AVX512_MOVE_BY_PIECES): New. (X86_TUNE_AVX512_STORE_BY_PIECES): Likewise. * doc/invoke.texi: Document -mmove-max=bits and -mstore-max=bits. gcc/testsuite/ PR target/103269 * gcc.target/i386/pieces-memcpy-17.c: New test. * gcc.target/i386/pieces-memcpy-18.c: Likewise. * gcc.target/i386/pieces-memcpy-19.c: Likewise. * gcc.target/i386/pieces-memcpy-20.c: Likewise. * gcc.target/i386/pieces-memcpy-21.c: Likewise. * gcc.target/i386/pieces-memset-45.c: Likewise. * gcc.target/i386/pieces-memset-46.c: Likewise. * gcc.target/i386/pieces-memset-47.c: Likewise. * gcc.target/i386/pieces-memset-48.c: Likewise. * gcc.target/i386/pieces-memset-49.c: Likewise.
[Bug testsuite/103545] New: [12 regression] gcc.target/powerpc/undef-bool-2.c fails after r12-5580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103545 Bug ID: 103545 Summary: [12 regression] gcc.target/powerpc/undef-bool-2.c fails after r12-5580 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:85289ba36c2e62de84cc0232c954d9a74bda708a, r12-5580 make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/undef-bool-2.c" FAIL: gcc.target/powerpc/undef-bool-2.c (test for excess errors) # of expected passes1 # of unexpected failures1 I am only seeing this on power 10. Excess errors: /home/seurer/gcc/git/build/gcc-test/gcc/include/xmmintrin.h:1356:25: error: 'vector' undeclared (first use in this function); did you mean 'vec_or'? /home/seurer/gcc/git/build/gcc-test/gcc/include/xmmintrin.h:1356:31: error: expected ')' before 'unsigned' /home/seurer/gcc/git/build/gcc-test/gcc/include/xmmintrin.h:1356:45: error: expected ')' before '__A' commit 85289ba36c2e62de84cc0232c954d9a74bda708a (HEAD, refs/bisect/bad) Author: Paul A. Clarke Date: Thu Oct 21 11:21:01 2021 -0500 rs6000: Add Power10 optimization for most _mm_movemask*
[Bug c++/103544] New: compiler crashes when trying to vectorize loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103544
Bug ID: 103544
Summary: compiler crashes when trying to vectorize loop
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: monad at posteo dot net
Target Milestone: ---
the following program crashes g++:
int crash_me(char* ptr, size_t size){
std::array result = {0};
size_t no_iters = 0;
for(size_t i = 0; i < size - 12; i+= 13){
for(size_t j = 0; j < 12; j++){
result[j] += ptr[i + j] - '0';
}
no_iters++;
}
int result_int = 0;
for(int j = 0; j < 12; j++){
int bit_value = result[j] > no_iters/2 ? 1 : 0;
result_int |= bit_value;
}
return result_int;
}
it results in:
during GIMPLE pass: vect
: In function 'int crash_me(char*, size_t)':
:4:5: internal compiler error: in vect_transform_reduction, at
tree-vect-loop.c:7378
4 | int crash_me(char* ptr, size_t size){
| ^~~~
0x1786229 internal_error(char const*, ...)
???:0
0x678608 fancy_abort(char const*, int, char const*)
???:0
0xf53cdc vect_transform_reduction(_loop_vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, gimple**, _slp_tree*)
???:0
0xf4936d vect_transform_stmt(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
???:0
0xf861ee vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>)
???:0
0xf64ed0 vect_transform_loop(_loop_vec_info*, gimple*)
???:0
0xf90d61 vectorize_loops()
???:0
optimization flags used: -O3 -march=haswell
g++ version: 11.1 on my local machine, 11.2 on godbolt.
godbolt link: https://godbolt.org/z/WjPbcE4sa
[Bug target/83782] [9/10/11 Regression] Inconsistent address for hidden ifunc in a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782 --- Comment #5 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:37fbf9175b22dea2e5eca4393edd0c47e3008994 commit r12-5775-g37fbf9175b22dea2e5eca4393edd0c47e3008994 Author: H.J. Lu Date: Fri Dec 3 09:00:54 2021 -0800 x86: Scan leal in PR target/83782 tests for x32 Update PR target/83782 tests to scan leal for x32 to fix: FAIL: gcc.target/i386/pr83782-1.c scan-assembler leaq[ \\t]foo\\(%rip\\),[ \\t]%rax FAIL: gcc.target/i386/pr83782-2.c scan-assembler leaq[ \\t]foo\\(%rip\\),[ \\t]%rax PR target/83782 * gcc.target/i386/pr83782-1.c: Also scan leal x32. * gcc.target/i386/pr83782-2.c: Likewise.
[Bug target/95962] Inefficient code for simple arm_neon.h iota operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95962
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Tamar Christina from comment #3)
> This is now fixed on trunk, at least for ld1/st1.
Nice!
> Was this ticket about the general problem for loads or just the ld1/st1
> examples?
>
> I'll leave it open since we still need to do the rest of the loads/stores.
Yeah, agree we should keep it open for {ld,st}[234].
[Bug middle-end/102808] [12 regression] sve/mask_gather_load_1.c fails since g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102808 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from rsandifo at gcc dot gnu.org --- Fixed by g:8bb81b3c4945dbae8d490e7a4054ddeb5a3b506c. (Forgot there was a PR for this, oops.)
[Bug target/102758] [12 Regression] Failure to use registers optimally with return values (2 operands related and subreg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102758 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > Richard? How does the new fwprop behave wrt hardregs? It doesn't sound like this is new vs. old fwprop, since new fwprop was in GCC 11. Generally the idea was to follow the existing behaviour as closely as possible, so I don't know of any specific differences re: hard regs.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 95307, which changed state. Bug 95307 Summary: Compiler accepts reinterpret_cast in constexpr https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/95307] Compiler accepts reinterpret_cast in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Comment 1 testcase is rejected with GCC 11+. If there are more cases left to be resolved, let's open a new PR.
[Bug c++/103543] New: Potential compiler warning for return of temporary?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103543
Bug ID: 103543
Summary: Potential compiler warning for return of temporary?
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at hazlewoods dot net
Target Milestone: ---
A return of a temporary from a lambda assigned to `std::function<>` does not
cause a warning, unlike a regular function.
Would be useful if it trapped, but it may be too far down the deduction path.
#include
#include
struct S
{
int s{};
};
using F = std::function;
S const& fn()
{
return S{}; // Warning: returning ref to temporary
}
int main()
{
F f = [](){ return S{}; }; // No warning
std::cout << f().s << std::endl; // Ouch
}
g++-11 -W -Wall -std=c++20 -O2 -pedantic-errors test.cpp --save-temps
g++-11 --version
g++-11 (GCC) 11.2.1 20211105
[Bug other/103542] New: bogus -Warray-bounds while index is limited by switch/case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103542
Bug ID: 103542
Summary: bogus -Warray-bounds while index is limited by
switch/case
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
gcc 11.2.0 reports the following on a reduced test case:
$ powerpc-linux-gcc -c array-bounds-fruit.c -O2 -Wall -Werror
array-bounds-fruit.c: In function 'get_default_config.part.0':
array-bounds-fruit.c:69:37: error: array subscript 4 is above array bounds of
'struct fruit_config[4]' [-Werror=array-bounds]
69 | do_something(id, [id].num_lemons);
| ~~^~~~
array-bounds-fruit.c:19:28: note: while referencing 'config'
19 | static struct fruit_config config[4];
|^~
cc1: all warnings being treated as errors
Above is for powerpc, but I have the same problem with ARM.
The offending line is inside a switch/case, within the block where 'id' is
tested to be 0, 1, 2, or 3.
gcc/g++ is considering a case where 'id' becomes 4, which is not possible in
this code.
If I make any more changes (even seemingly unrelated changes) to the test case,
the error disappears.
Test code:
#include
#include
#include
enum {
ID_0 = 0,
ID_1 = 1,
ID_2 = 2,
ID_3 = 3,
MAX_IDS,
};
#define MAX_ENTRIES 256
struct fruit_config {
uint32_t num_apples;
uint32_t num_lemons;
uint32_t * lemons;
};
static struct fruit_config config[4];
static uint32_t unrelated_table[MAX_IDS][MAX_ENTRIES];
uint32_t do_something(const uint32_t id, uint32_t * number_of_entries)
{
uint32_t error = 0;
switch (id) {
/* merging these case statements with identical body removes the issue
*/
case ID_0: {
*number_of_entries = 0;
break;
}
case ID_1: {
*number_of_entries = 0;
break;
}
case ID_2: {
*number_of_entries = 0;
break;
}
case ID_3: {
*number_of_entries = 0;
break;
}
default: {
error = 0xff;
*number_of_entries = 0;
break;
}
}
return error;
}
struct fruit_config * get_default_config(const uint32_t id)
{
switch (id) {
case ID_0:
case ID_1:
case ID_2:
case ID_3:
{
uint32_t entry = 0;
for (entry = 0; entry
[Bug rtl-optimization/103541] New: unnecessary spills around const functions calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
Bug ID: 103541
Summary: unnecessary spills around const functions calls
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
While looking into reasons why modref causes some code size increases I noticed
that we produce unnecessary spill on x86-64 here:
float a;
__attribute__((const)) float foo (float);
float
test()
{
return a + foo(a) + a;
}
we load "a" into register and then spill it to stack because all SSE registers
are clobbered by the call. This seems to happen somewhere between gcc 4.1 and
4.6. It is caused by:
/* We can combine a reg def from one insn into a reg use in
another over a call if the memory is readonly or the call
const/pure. However, we can't set reg_equiv notes up for
reload over any call. The problem is the equivalent form
may reference a pseudo which gets assigned a call
clobbered hard reg. When we later replace REG with its
equivalent form, the value in the call-clobbered reg has
been changed and all hell breaks loose. */
ret = valid_combine;
if (!MEM_READONLY_P (memref)
&& !RTL_CONST_OR_PURE_CALL_P (insn))
return valid_none;
in ira.c:validate_equiv_mem
If I read the comment correctly it is afraid of the address of memory reading
being altered by the call (using call clobbered registers). But here it is a
constant, so perhaps we can just rule this out when MEM rtx does not mention
registers or does not mention any callee clobbered registers?
[Bug target/103383] Microblaze bswaphi2 can cause issues with delay slots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103383 --- Comment #9 from Rich --- of course, that should be -mxl-barrel-shift...
