[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2023-03-17
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #5 from Andrew Pinski --- I suspect the thing you are requesting is having the template keyword as being optional but I am not sure.
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #4 from Andrew Pinski --- You provide a full example of what you want? Because right now your example your provided does not even compile with msvc.
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > There is a defect report in this area of gcc. Sorry c++
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #2 from Andrew Pinski --- There is a defect report in this area of gcc.
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169
--- Comment #1 from steve02081504 ---
(Corrected code)
```c++
template
struct type_info_t{
//...
template
static constexpr bool can_convert_to=XXX;
//...
};
template
constexpr type_info_ttype_info{};
```
[Bug c++/109169] New: Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169
Bug ID: 109169
Summary: Feature request: Allow omitted template prompts
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steve_green at qq dot com
Target Milestone: ---
I have a third party library that has this write up
```c++
template
template struct type_info_t{
//...
template
static constexpr bool can_convert_to=XXX;
//...
}
template
constexpr type_info_ttype_info{};
```
Since msvc supports such writes, the form of `type_info.can_convert_to`,
`compare.able`, `invoke.nothrow` are written throughout the
project.
Although this is not the standard way of writing, I would expect gcc to support
such code.
[Bug c++/109168] bogus error: 'X' is not a valid template argument of type 'Y' because 'X' is not a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109168 --- Comment #1 from Andrew Pinski --- (In reply to waffl3x from comment #0) > BTW, should I be selecting the oldest version that a bug occurs or the > newest version? I observed the behavior all the way back to 10.1, which > appears to be when support for C++20 starts. I guess the better question to > ask is how do I assign multiple versions? There is a known to work and know to fail field which is used exactly for that.
[Bug c++/109168] New: bogus error: 'X' is not a valid template argument of type 'Y' because 'X' is not a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109168
Bug ID: 109168
Summary: bogus error: 'X' is not a valid template argument of
type 'Y' because 'X' is not a variable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at protonmail dot com
Target Milestone: ---
https://godbolt.org/z/5xxPhhno7
struct stores_fptr {
void (*fptr)();
};
void func() {}
struct holds_value {
static constexpr auto value = stores_fptr{};
};
template struct takes_value {};
using go = takes_value;
There are a few workarounds for this that I could find, the most obvious being
the following changes (working example): https://godbolt.org/z/81xr36bYc
template struct takes_value {};
inline constexpr auto f = holds_value::value.fptr;
using go = takes_value;
I want to note, the bug is still present in the broken example if `takes_value`
takes a deduced (auto) non type template parameter, I explicitly state the type
just to reduce the example further.
The first (broken) snippit works in clang, and is broken in gcc trunk, gcc
12.2, and gcc 11.2, I was not able to test on MSVC. I'm mildly concerned that
this is one of those cases where clang is wrong to accept the code, but I was
able to find enough workarounds that I feel like I'm not incorrect.
The code also fails on my system with version: g++ (GCC) 13.0.1 20230219
(experimental)
Here is the gcc version on compiler explorer at the time of writing: g++
(Compiler-Explorer-Build-gcc-0c061da91a3657afdb3fac68e4595af685909a1a-binutils-2.38)
13.0.1 20230316 (experimental)
BTW, should I be selecting the oldest version that a bug occurs or the newest
version? I observed the behavior all the way back to 10.1, which appears to be
when support for C++20 starts. I guess the better question to ask is how do I
assign multiple versions?
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #10 from Hans-Peter Nilsson ---
(In reply to David Malcolm from comment #8)
> Note that section 3.1 ("File Format" > "General") specifies:
> "A SARIF log file SHALL be encoded in UTF-8 [RFC3629]."
> https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html
>
> Though I suppose it would be possible to escape non-ASCII chars so that the
> .sarif file could use the ASCII subset of UTF-8,
ISTM the point of that test is heavy use of UTF-8, so you can't get away with
using the ASCII subset. (I see an identifier using ideographs? Wouldn't want
to review that code... Might as well use Linear A -which you indeed can in
UTF-8- - it's all greek to me!)
> if there's no other way
> around this from the DejaGnu side.
Perhaps add a parameter to dg-scan (it enforces exactly two arguments now) that
scan-sarif-file can use, as it's always UTF-8, making dg-scan apply "fconfigure
$fd -encoding [lindex $orig_args 2]" and the parameter passed as "utf-8" or
something like that, since SARIF files are always UTF-8. Assuming that works,
of course; completely untested theory.
[Bug target/109167] rs6000: _mm_slli_si128 and _mm_bslli_si128 are inconsistent in wrapper header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109167
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Target||powerpc*-linux-gnu
Last reconfirmed||2023-03-17
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Kewen Lin ---
The pair _mm_srli_si128 and _mm_bsrli_si128 doesn't have this issue:
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_srli_si128 (__m128i __A, const int __N)
{
return _mm_bsrli_si128 (__A, __N);
}
And _mm_bsrli_si128 adopts different shifting directions for LE and BE, so I
think the current implementation of _mm_slli_si128 is what we want for
_mm_bslli_si128.
[Bug target/109167] New: rs6000: _mm_slli_si128 and _mm_bslli_si128 are inconsistent in wrapper header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109167
Bug ID: 109167
Summary: rs6000: _mm_slli_si128 and _mm_bslli_si128 are
inconsistent in wrapper header
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
When I was investigating PR109082, I happened to find that in
gcc/config/rs6000/emmintrin.h, we have different definitions for _mm_slli_si128
and _mm_bslli_si128 as follow:
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_bslli_si128 (__m128i __A, const int __N)
{
__v16qu __result;
const __v16qu __zeros = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
if (__N >= 0 && __N < 16)
__result = vec_sld ((__v16qu) __A, __zeros, __N);
else
__result = __zeros;
return (__m128i) __result;
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_slli_si128 (__m128i __A, const int _imm5)
{
__v16qu __result;
const __v16qu __zeros = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
if (_imm5 == 0)
return __A;
else if (_imm5 > 0 && _imm5 < 16)
#ifdef __LITTLE_ENDIAN__
__result = vec_sld ((__v16qu) __A, __zeros, _imm5);
#else
__result = vec_sld (__zeros, (__v16qu) __A, (16 - _imm5));
#endif
else
__result = __zeros;
return (__m128i) __result;
}
But actually as ./gcc/config/i386/emmintrin.h, they should be the same:
#ifdef __OPTIMIZE__
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_bsrli_si128 (__m128i __A, const int __N)
{
return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_bslli_si128 (__m128i __A, const int __N)
{
return (__m128i)__builtin_ia32_pslldqi128 (__A, __N * 8);
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_srli_si128 (__m128i __A, const int __N)
{
return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_slli_si128 (__m128i __A, const int __N)
{
return (__m128i)__builtin_ia32_pslldqi128 (__A, __N * 8);
}
#else
#define _mm_bsrli_si128(A, N) \
((__m128i)__builtin_ia32_psrldqi128 ((__m128i)(A), (int)(N) * 8))
#define _mm_bslli_si128(A, N) \
((__m128i)__builtin_ia32_pslldqi128 ((__m128i)(A), (int)(N) * 8))
#define _mm_srli_si128(A, N) \
((__m128i)__builtin_ia32_psrldqi128 ((__m128i)(A), (int)(N) * 8))
#define _mm_slli_si128(A, N) \
((__m128i)__builtin_ia32_pslldqi128 ((__m128i)(A), (int)(N) * 8))
#endif
[Bug target/109166] Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166 --- Comment #2 from Andrew Pinski --- Armv4t does not have smp so the question is how do you think the below is not atomic? Yes interrupts but that requires more.
[Bug target/109166] Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166 --- Comment #1 from Andrew Pinski --- https://inbox.sourceware.org/gcc-patches/4f596367.2050...@redhat.com/
[Bug target/109166] New: Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166
Bug ID: 109166
Summary: Built-in __atomic_test_and_set does not seem to be
atomic on ARMv4T
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jdx at o2 dot pl
Target Milestone: ---
Host: x86_64-w64-mingw32
Target: arm-eabi
For the following source code:
bool tas(unsigned char *ptr)
{
return __atomic_test_and_set(ptr, __ATOMIC_SEQ_CST);
}
gcc -march=armv4t -marm -O3 -Wall -Wextra gives:
tas:
mov r3, r0
mov r2, #1
ldrbr0, [r0]@ zero_extendqisi2
strbr2, [r3]
bx lr
I am not an ARM assembler expert, but I think that LDRB/STRB pair should be
replaced with SWPB as shown here: https://godbolt.org/z/116MbYK79.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107567.
[Bug libstdc++/109165] New: std::hash>::operator() should be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109165 Bug ID: 109165 Summary: std::hash>::operator() should be const Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- Cpp17Hash requires const-callability.
[Bug tree-optimization/109164] thread_local initialization error with -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164 --- Comment #3 from Andrew Pinski --- I am not 100% if this is a front-end issue or a gimple level optimization issue.
[Bug tree-optimization/109164] thread_local initialization error with -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-16 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- The bug has been in around since thread_local was added it seems back in GCC 4.8.0. Confirmed. Note the wrong code can be reproduced on x86 too.
[Bug tree-optimization/109164] thread_local initialization error with -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164
Andrew Pinski changed:
What|Removed |Added
Summary|thread_local initialization |thread_local initialization
|error with -ftree-pre |error with -ftree-pre
|-foptimize-sibling-calls|
Known to fail||11.3.0
--- Comment #1 from Andrew Pinski ---
Here is a testcase which fails at `-O1 -ftree-pre` and does not need
`-foptimize-sibling-calls`:
struct Struct {
virtual void virtual_func();
};
extern thread_local Struct& thread_local_ref;
bool other_func(void);
bool test_func(void)
{
while (1)
{
thread_local_ref.virtual_func();
if (!other_func())
return 0;
}
}
[Bug c++/109164] New: aarch64 thread_local initialization error with -ftree-pre and -foptimize-sibling-calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164
Bug ID: 109164
Summary: aarch64 thread_local initialization error with
-ftree-pre and -foptimize-sibling-calls
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: loganh at synopsys dot com
Target Milestone: ---
Created attachment 54687
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54687=edit
Bash script that reproduces the issue
With -ftree-pre, -foptimize-sibling-calls, and -O1 enabled, on
aarch64-linux-gnu, GCC 12.1.0 can generate code to access parts of thread_local
variables before the corresponding TLS init function is called if the variable
is accessed from a different TU than the variable is defined in. This
reordering could likely cause a number of different issues, but the one that
I've run into is that:
- When the compiler generates code to call a virtual function on a reference to
a to a global thread_local instance of an object defined in a different
translation unit, and
- The function calls itself in at least once branch,
the address of the object is fetched from TLS before it's initialized, and
when the vtable lookup is attempted on that object to call the virtual function
the program segfaults.
Here's an example of the kind of code that will trip it up:
struct Struct {
virtual void virtual_func();
};
extern thread_local Struct& thread_local_ref;
bool other_func(void);
bool test_func(void) {
thread_local_ref.virtual_func();
return other_func() && test_func();
}
When this is compiled (on aarch64-linux-gnu, with -O1 and -ftree-pre and
-foptimize-sibling-calls) to an object file and then dumped with objdump -C -d,
this is the code produced:
:
0: a9be7bfd stp x29, x30, [sp, #-32]!
4: 910003fd mov x29, sp
8: a90153f3 stp x19, x20, [sp, #16]
c: 9000 adrp x0, 0
10: f940 ldr x0, [x0]
14: d53bd041 mrs x1, tpidr_el0
18: f8606834 ldr x20, [x1, x0]
1c: 9013 adrp x19, 0
20: f9400273 ldr x19, [x19]
24: b453 cbz x19, 2c
28: 9400 bl 0
2c: f9400280 ldr x0, [x20]
30: f941 ldr x1, [x0]
34: aa1403e0 mov x0, x20
38: d63f0020 blr x1
3c: 9400 bl 0
40: 12001c00 and w0, w0, #0xff
44: 3500 cbnz w0, 24
48: a94153f3 ldp x19, x20, [sp, #16]
4c: a8c27bfd ldp x29, x30, [sp], #32
50: d65f03c0 ret
Looking at addresses 0x14 through 0x18, you can see that the address of
'thread_local_ref' is read from the TLS block for the thread; the first time
this function is called, this will result in register x20 containing zero,
since the TLS block isn't intialized until the function call at 0x28. Directly
after that, at location 0x2c, a read is attempted from the address in register
x20 (zero) causing a segfault. Without -ftree-pre and -foptimize-sibling calls,
and without letting `test_func` call itself on at least one path, the code to
get the address of `thread_local_ref` is generated after the TLS init call, so
the problem does not occur.
I've attached a script that will reproduce what I've shown here, as well as
demonstrate the issue in action with a full executable that will produce the
segfault I've described.
[Bug other/109163] SARIF (and other JSON) output files are non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-03-16 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- I'm working on a fix for this.
[Bug c++/105809] [10/11/12/13 Regression] __PRETTY_FUNCTION__ in constexpr in function vs NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:78b3bf0e65072f5fa42a8da43698711220d4f8ef commit r13-6723-g78b3bf0e65072f5fa42a8da43698711220d4f8ef Author: Jason Merrill Date: Thu Mar 16 15:35:15 2023 -0400 c++: __func__ and local class DMI [PR105809] As in 108242, we need to instantiate in the context of the enclosing function, not after it's gone. PR c++/105809 gcc/cp/ChangeLog: * init.cc (get_nsdmi): Split out... (maybe_instantiate_nsdmi_init): ...this function. * cp-tree.h: Declare it. * pt.cc (tsubst_expr): Use it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-__func__3.C: New test.
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b323f52ccf966800297b0520b9e1d4b3951db525 commit r13-6722-gb323f52ccf966800297b0520b9e1d4b3951db525 Author: Jason Merrill Date: Thu Mar 16 15:11:25 2023 -0400 c++: generic lambda, local class, __func__ [PR108242] Here we are trying to do name lookup in a deferred instantiation of t() and failing to find __func__. tsubst_expr already tries to instantiate members of local classes, but was failing with the partial instantiation of generic lambdas. PR c++/108242 gcc/cp/ChangeLog: * pt.cc (tsubst_expr) [TAG_DEFN]: Handle partial instantiation. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-func2.C: New test.
[Bug c++/101869] [10/11/12/13 Regression] ::enumvalue is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101869 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1cc8814098bb46f9fca58a0b831fbf9a8574bdc9 commit r13-6721-g1cc8814098bb46f9fca58a0b831fbf9a8574bdc9 Author: Jason Merrill Date: Thu Mar 16 13:11:32 2023 -0400 c++: ::enumerator [PR101869] We don't want to call build_offset_ref with an enum. PR c++/101869 gcc/cp/ChangeLog: * semantics.cc (finish_qualified_id_expr): Don't try to build a pointer-to-member if the scope is an enumeration. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/enum43.C: New test.
[Bug other/109163] SARIF (and other JSON) output files are non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163 --- Comment #1 from David Malcolm --- This would also help with one of the requests from a SARIF expert's review of GCC's output: https://github.com/oasis-tcs/sarif-spec/issues/531#issuecomment-1181191100 which is that the "version" property should occur first in the file. It also might make testcases easier to write.
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #9 from David Malcolm --- (In reply to David Malcolm from comment #7) [...snip...] > There some variation due to json::object using a hash_map for the key/value > pairs, which means (annoyingly) it outputs things in arbitrary order, > leading to non-determinism in the .sarif content. I've filed this as PR 109163. [...snip...]
[Bug other/109163] New: SARIF (and other JSON) output files are non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163 Bug ID: 109163 Summary: SARIF (and other JSON) output files are non-deterministic Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- gcc/json.cc's json::object uses a hash_map for tracking the key/value pairs, and object::print iterates through them in arbitrary order, so every time we emit json files they can potentially vary, which makes it much harder to compare them from run to run (see e.g. PR 105959). It would probably be much more user-friendly to use an ordered_hash_map here to preserve insertion order and thus have deterministic output. I don't know if this would have a noticeable performance hit.
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #8 from David Malcolm ---
Note that section 3.1 ("File Format" > "General") specifies:
"A SARIF log file SHALL be encoded in UTF-8 [RFC3629]."
https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html
Though I suppose it would be possible to escape non-ASCII chars so that the
.sarif file could use the ASCII subset of UTF-8, if there's no other way around
this from the DejaGnu side.
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
David Malcolm changed:
What|Removed |Added
Last reconfirmed|2023-01-30 00:00:00 |2023-03-16
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #7 from David Malcolm ---
Aha! - thanks for the information.
I think GCC is writing out the .sarif file in UTF-8 form regardless of the
environment on everyone's box. The issue seems to be this line in the testcase
to check for the UTF-8 in the "snippet" output:
{ dg-final { scan-sarif-file "\"text\": \" int
\\u6587\\u5b57\\u5316\\u3051 = " } }
that's failing somewhere within DejaGnu, presumably due to the environment
differences.
There some variation due to json::object using a hash_map for the key/value
pairs, which means (annoyingly) it outputs things in arbitrary order, leading
to non-determinism in the .sarif content.
Perhaps it's possible to express byte-level matching in Tcl? I'll have a look.
Details
===
The source code (gcc/testsuite/c-c++-common/diagnostic-format-sarif-file-4.c)
is indeed UTF-8 encoded; looking at the output of
./contrib/unicode/utf8-dump.py, I see this for line 7:
7 | int 文字化け = *42;
| U+00200x20SPACE
(separator)
| U+00200x20SPACE
(separator)
| U+00690x69 LATIN SMALL LETTER I i
| U+006E0x6e LATIN SMALL LETTER N n
| U+00740x74 LATIN SMALL LETTER T t
| U+00200x20SPACE
(separator)
| U+6587 0xe6 0x96 0x87 CJK UNIFIED IDEOGRAPH-6587 文
| U+5B57 0xe5 0xad 0x97 CJK UNIFIED IDEOGRAPH-5B57 字
| U+5316 0xe5 0x8c 0x96 CJK UNIFIED IDEOGRAPH-5316 化
| U+3051 0xe3 0x81 0x91 HIRAGANA LETTER KE け
| U+00200x20SPACE
(separator)
| U+003D0x3d EQUALS SIGN =
| U+00200x20SPACE
(separator)
| U+002A0x2a ASTERISK *
| U+00340x34 DIGIT FOUR 4
| U+00320x32DIGIT TWO 2
| U+003B0x3bSEMICOLON ;
| U+000A0x0a LINE FEED (LF)
(control character)
Looking at the output on my box via:
hexdump -C testsuite/gcc/diagnostic-format-sarif-file-4.c.sarif|less
and looking for "snippet" shows:
05a0 3a 20 7b 22 63 6f 6e 74 65 78 74 52 65 67 69 6f |: {"contextRegio|
05b0 6e 22 3a 20 7b 22 73 74 61 72 74 4c 69 6e 65 22 |n": {"startLine"|
05c0 3a 20 37 2c 20 22 73 6e 69 70 70 65 74 22 3a 20 |: 7, "snippet": |
05d0 7b 22 74 65 78 74 22 3a 20 22 20 20 69 6e 74 20 |{"text": " int |
05e0 e6 96 87 e5 ad 97 e5 8c 96 e3 81 91 20 3d 20 2a | = *|
05f0 34 32 3b 5c 6e 22 7d 7d 2c 20 22 61 72 74 69 66 |42;\n"}}, "artif|
where it's been encoded in UTF-8 as:
e6 96 87 e5 ad 97 e5 8c 96 e3 81 91 20 3d
which I can confirm with ./contrib/unicode/utf8-dump.py, which shows that the
snippet has been written in UTF-8 form:
| U+00690x69 LATIN SMALL LETTER I i
| U+006E0x6e LATIN SMALL LETTER N n
| U+00740x74 LATIN SMALL LETTER T t
| U+00200x20SPACE
(separator)
| U+6587 0xe6 0x96 0x87 CJK UNIFIED IDEOGRAPH-6587 文
| U+5B57 0xe5 0xad 0x97 CJK UNIFIED IDEOGRAPH-5B57 字
| U+5316 0xe5 0x8c 0x96 CJK UNIFIED IDEOGRAPH-5316 化
| U+3051 0xe3 0x81 0x91 HIRAGANA LETTER KE け
| U+00200x20SPACE
(separator)
| U+003D0x3d EQUALS SIGN =
The test case has:
{ dg-final { scan-sarif-file "\"text\": \" int \\u6587\\u5b57\\u5316\\u3051
= " } }
which is looking for the text of the snippet containing the unicode chars
[Bug c++/109159] [10/11/12/13 Regression] explicit constructor is used in copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needs-bisection | CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Oy, started with r9-3735-gb5ff4f5c0d61e5: commit b5ff4f5c0d61e52e27a0727ae9e011aab525ccfd Author: Marek Polacek Date: Tue Oct 30 19:59:41 2018 + Implement P0892R2, explicit(bool).
[Bug c++/109159] [10/11/12/13 Regression] explicit constructor is used in copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5 Keywords||needs-bisection Summary|explicit constructor is |[10/11/12/13 Regression] |used in copy-initialization |explicit constructor is ||used in copy-initialization
[Bug debug/105089] CTF for a defined extern variable is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089 Indu Bhagat changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Indu Bhagat --- Fixed.
[Bug c++/109159] explicit constructor is used in copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159 Andrew Pinski changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0
[Bug c++/109159] explicit constructor is used in copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2023-03-16
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Reduced testcase without the constraint that GCC accepts:
struct A {
A( float ) {}
template
explicit A( U ) {}
};
void f(A t)
{
t = {1};
}
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2023-03-16 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug libstdc++/109162] New: C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 Bug ID: 109162 Summary: C++23 improvements to std::format Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 106749 Target Milestone: --- https://wg21.link/P2372R3 formatting ranges https://wg21.link/P2585R1 container formatting https://wg21.link/P2419R2 localized chrono formatting (also p2372r3) https://wg21.link/P2693R1 formatting thread::id and stacktrace Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 [Bug 106749] Implement C++23 library features
[Bug ipa/81323] IPA-VRP doesn't handle return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 --- Comment #6 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #4) > Or the ranger could do it itself, similarly to how it handles .ASSUME, but > without actually querying anything but the global range of the return value > if any. Though, doing that in the range means that we won't know ranges of > functions which with LTO are in a different partition, while doing it as IPA > optimization could allow even that to work. Aldy has been doing some IPA/LTO related cleanup with ranges... Hopefully we can get this all connected next release.
[Bug debug/109161] New: Bad CTF generated for stub in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109161
Bug ID: 109161
Summary: Bad CTF generated for stub in function scope
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: ibhagat at gcc dot gnu.org
Target Milestone: ---
$ cat t.c
void set_cpu_arch (void) {
typedef struct arch_stack_entry {
const struct arch_stack_entry *prev;
} arch_stack_entry;
static arch_stack_entry *arch_stack_top;
}
$ gcc -gctf -g3 -c t.c
$ objdump --ctf=.ctf t.o will hang.
The hang is because the compiler spits incorrect CTF.
Byte offsets (which point to the location of the various sub-sections in the
CTF section) encoded in the CTF header as seen via poke:
...
cth_funcoff=0U#B,
cth_objtidxoff=4U#B,
cth_funcidxoff=4U#B,
cth_varoff=8U#B,
cth_typeoff=8U#B,
cth_stroff=96U#B,
...
-- The generated CTF section has one function object, and no variables as can
be seen from the offsets in the header. This is OK.
--There are however, generated types; Further, a subset of which are incorrect
(see below).
(poke) ctf_dump_all_types(ctf)
Types:
1: (kind 1) integer void (size 0) (signed)
2: (kind 5) function set_cpu_arch --> ID 1: (kind 1) integer void (size 0)
3: (kind 6) struct arch_stack_entry (size 8)
[0U#b] prev (ID 5)
[0U#b] (ID 3)
4: (kind 12) const --> ID 3: (kind 6) struct arch_stack_entry (size 8)
5: (kind 3) pointer --> ID 4: (kind 12) const --> ID 3: (kind 6) struct
arch_stack_entry (size 8)
[Problem #1] A struct with two members, one of which is unnamed. The type as
defined by the user has one member named prev in the struct => The generated
CTF is incorrect.
[Problem #2] Well, why is there any generated CTF at all ? Both the variable
and the defined type are function-scope; In CTF, only top-level types,
functions, variables are to be described.
[Bug modula2/109125] [13 regression] SIGBUS in m2pim_ldtoa_ldtoa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125 --- Comment #10 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:f231bca93ca92f6fd55de6fbe4bf8935f9ec558a commit r13-6719-gf231bca93ca92f6fd55de6fbe4bf8935f9ec558a Author: Gaius Mulley Date: Thu Mar 16 20:41:20 2023 + PR modula2/109125 SIGBUS in m2pim_ldtoa_ldtoa 13 regression failures seen on sparc SIGBUS in m2pim_ldtoa_ldtoa. This patch fixes int bool struct field mismatches between the definition modules and their C/C++ implementations. gcc/testsuite/ChangeLog: PR modula2/109125 * gm2/types/run/pass/d.c: Convert data structure from BOOLEAN int to bool and cast int to bool in test function. Signed-off-by: Gaius Mulley
[Bug modula2/107630] runtime libs should be self-contained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107630
--- Comment #3 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:77924dff144cf934e7a73417d237a99f0d9d66ed
commit r13-6718-g77924dff144cf934e7a73417d237a99f0d9d66ed
Author: Gaius Mulley
Date: Thu Mar 16 20:34:32 2023 +
PR 107630 runtime libs should be self-contained
This is a patch to improve the layering of libgm2.
It removes the m2cor Debug.{def,mod} (the codebase will use
m2pim Debug instead). It also layers SysStorage under
both m2pim Storage and m2iso Storage. SysStorage is now
a dependant of m2pim Storage.mod. Halt parameters for
Debug.mod and M2RTS.mod now have the same order.
gcc/m2/ChangeLog:
* gm2-compiler/SymbolKey.mod (PutSymKey): Halt parameters
reordered.
(DelSymKey): Ditto.
* gm2-compiler/ppg.mod (GetEpsilon): Ditto.
(GetReachEnd): Ditto.
(GetFollow): Ditto.
(CodeCondition): Ditto.
(CodeThenDo): Ditto.
(CodeEnd): Ditto.
(RecoverCondition): Ditto.
(ConditionIndent): Ditto.
* gm2-libs-ch/m2rts.h (M2RTS_Halt): Ditto.
* gm2-libs-coroutines/Executive.mod (Assert): Ditto.
(Resume): Remove redundant comments.
(Wait): Remove redundant comments.
* gm2-libs-coroutines/SYSTEM.mod (TRANSFER): Halt parameters
reordered.
(IOTransferHandler): Ditto.
(Finished): Ditto.
(localInit): Ditto.
* gm2-libs-coroutines/TimerHandler.mod (WaitOn): Halt parameters
reordered.
(Cancel): Ditto.
(ReArmEvent): Ditto.
(OnActiveQueue): Ditto.
* gm2-libs-iso/COROUTINES.mod (NEWCOROUTINE): Ditto.
(Transfer): Ditto.
(IOTRANSFER): Ditto.
* gm2-libs-iso/EXCEPTIONS.mod (RAISE): Correct Halt parameters.
* gm2-libs-iso/M2RTS.def (Halt): Halt parameters reordered.
(HaltC): Ditto.
* gm2-libs-iso/M2RTS.mod: Ditto.
* gm2-libs-iso/RTentity.mod (PutKey): Ditto.
(DelKey): Ditto.
(findChildAndParent): Ditto.
(assert): Ditto.
* gm2-libs-iso/Storage.mod (ALLOCATE): Add DebugTrace.
Add UseMallocFree test.
(DEALLOCATE): Add DebugTrace. Add UseMallocFree test.
(assert): Halt parameters reordered.
* gm2-libs-log/Termbase.mod (Read): Ditto.
(KeyPressed): Ditto.
(Write): Ditto.
(Init): Ditto.
* gm2-libs/Debug.def (Halt): Halt parameters reordered.
* gm2-libs/Debug.mod (Halt): Ditto.
* gm2-libs/DynamicStrings.def (PopAllocation): Improve comment.
* gm2-libs/DynamicStrings.mod (PopAllocation): Improve comment.
Halt parameters reordered.
* gm2-libs/M2RTS.def (Halt): Ditto.
(HaltC): Ditto.
* gm2-libs/M2RTS.mod (Halt): Ditto.
(HaltC): Ditto.
* gm2-libs/PushBackInput.mod (PutStr): Ditto.
(PutString): Ditto.
(PutCh): Ditto.
* gm2-libs/RTExceptions.mod (GetBaseExceptionBlock): Ditto.
* gm2-libs/RTint.mod (ReArmTimeVector): Ditto.
(GetTimeVector): Ditto.
(AttachVector): Ditto.
(IncludeVector): Ditto.
(Listen): Ditto.
* gm2-libs/SysStorage.mod (ALLOCATE): Ditto.
(DEALLOCATE): Ditto.
(REALLOCATE): Ditto.
* gm2-libs-coroutines/Debug.def: Removed.
* gm2-libs-coroutines/Debug.mod: Removed.
libgm2/ChangeLog:
* libm2cor/Makefile.am: Remove
* libm2cor/Makefile.in: Rebuild.
* libm2iso/RTco.cc (newSem): Halt parameters reordered.
(currentThread): Ditto.
(never): Ditto.
(defined): Ditto.
(initThread): Ditto.
* libm2iso/m2rts.h (m2iso_M2RTS_HaltC): Ditto.
gcc/testsuite/ChangeLog:
* gm2/complex/pass/arith3.mod: Halt parameters reordered.
* gm2/complex/run/pass/arith3.mod: Ditto.
* gm2/complex/run/pass/arith4.mod: Ditto.
* gm2/complex/run/pass/arith5.mod: Ditto.
* gm2/isolib/run/pass/real2.mod: Ditto.
* gm2/isolib/run/pass/real3.mod: Ditto.
* gm2/isolib/run/pass/realconv.mod: Ditto.
* gm2/isolib/run/pass/realconv2.mod: Ditto.
* gm2/pim/pass/testshort.mod: Ditto.
* gm2/projects/pim/run/pass/tower/AdvSystem.mod: Ditto.
* gm2/projects/pim/run/pass/tower/DrawL.mod: Ditto.
* gm2/warnings/returntype/pass/Termbase.mod: Ditto.
* gm2/warnings/returntype/pass/keypressedsimple.mod: Ditto.
Signed-off-by: Gaius Mulley
[Bug c++/109160] New: [Valid code] Constraint on deduced NTTP from method call causes ICE/Segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109160
Bug ID: 109160
Summary: [Valid code] Constraint on deduced NTTP from method
call causes ICE/Segfault.
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent_saulue at hotmail dot fr
Target Milestone: ---
To my knowledge, the following code is well-formed c++20, and compiles with
clang and MSVC.
- g++ 11.x & 12.x: this code causes a segmentation fault.
- g++ 10.x & 13.0(godbolt trunk): this code causes an ICE.
The issue is reproducible on godbolt: https://godbolt.org/z/bxbeTa69f
Code:
```
struct Traits {
static constexpr bool value = true;
};
template
concept cBarOf = Traits::value;
template
struct Foo {
template auto rhsBar> // <-- this concept causes ICE.
void doNothing(Foo const&);
};
void someFunction() {
Foo lhs{};
lhs.doNothing(lhs);
}
```
Compiler output on my local machine:
```
# g++ --version
g++-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
# g++ -std=c++20 source.cpp
source.cpp: In substitution of ‘template,
Traits>] rhsBar> void Foo::doNothing(const Foo&)
[with auto [requires ::cBarOf<, Traits>] rhsBar = ]’:
source.cpp:16:18: required from here
source.cpp:16:18: internal compiler error: Segmentation fault
16 | lhs.doNothing(lhs);
| ~^
0xd910e3 crash_signal
../../src/gcc/toplev.cc:322
0x7f546f77251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x801af0 iterative_hash_template_arg(tree_node*, unsigned int)
../../src/gcc/cp/pt.cc:1786
0x6e9d99 sat_hasher::hash(sat_entry*)
../../src/gcc/cp/constraint.cc:2491
0x6e9d99 hash_table::find_slot(sat_entry*
const&, insert_option)
../../src/gcc/hash-table.h:435
0x6e9d99 satisfaction_cache::satisfaction_cache(tree_node*, tree_node*,
sat_info)
../../src/gcc/cp/constraint.cc:2584
0x6ec446 satisfy_atom
../../src/gcc/cp/constraint.cc:2914
0x6ec446 satisfy_constraint_r
../../src/gcc/cp/constraint.cc:3023
0x6ecf33 satisfy_normalized_constraints
../../src/gcc/cp/constraint.cc:3048
0x6eaa53 satisfy_nondeclaration_constraints
../../src/gcc/cp/constraint.cc:3130
0x6eaa53 constraint_satisfaction_value
../../src/gcc/cp/constraint.cc:3285
0x6ecfbb constraints_satisfied_p(tree_node*, tree_node*)
../../src/gcc/cp/constraint.cc:3317
0x80c2c2 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../src/gcc/cp/pt.cc:30349
0x8166d9 unify
../../src/gcc/cp/pt.cc:24272
0x816791 unify
../../src/gcc/cp/pt.cc:24476
0x82d48e try_class_unification
../../src/gcc/cp/pt.cc:23437
0x81633b unify
../../src/gcc/cp/pt.cc:24513
0x82bfa3 unify_one_argument
../../src/gcc/cp/pt.cc:22650
0x814938 type_unification_real
../../src/gcc/cp/pt.cc:22773
0x831b0a fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../src/gcc/cp/pt.cc:22096
```
Output of godbolt's gcc(trunk):
```
# g++ --version
g++
(Compiler-Explorer-Build-gcc-0c061da91a3657afdb3fac68e4595af685909a1a-binutils-2.38)
13.0.1 20230316 (experimental)
# g++ -std=c++20
: In substitution of 'template,
Traits>] rhsBar> void Foo::doNothing(const Foo&)
[with auto [requires ::cBarOf<, Traits>] rhsBar = ]':
:16:18: required from here
:16:18: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with 0 elts in hash, at cp/constraint.cc:2571
16 | lhs.doNothing(lhs);
| ~^
0x23b52ae internal_error(char const*, ...)
???:0
0x94819b tree_vec_elt_check_failed(int, int, char const*, int, char const*)
???:0
0xafc7c4 sat_hasher::hash(sat_entry*)
???:0
0xaf7adf satisfaction_cache::satisfaction_cache(tree_node*, tree_node*,
sat_info)
???:0
0xafb922 constraints_satisfied_p(tree_node*, tree_node*)
???:0
0xc79882 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0xcb0831 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xaac75a build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xc5e0df c_parse_file()
???:0
0xd9ac69 c_common_parse_file()
???:0
```
[Bug fortran/38220] C_LOC intrinsic non-pure and without explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to Jeff Hammond from comment #8) > For what it's worth, ISO/IEC DIS 1539-1:2022 (E) now contains the following: > > All standard procedures in the intrinsic module ISO_C_BINDING, other than > C_F_POINTER and C_F_PROCPOINTER, are now pure. Actually the text I have says: 18.2.3.1 General [...] The C_F_POINTER and C_F_STRPOINTER subroutines are impure; all other procedures in the module are simple. 18.2.3.4 C_F_PROCPOINTER (CPTR, FPTR) [...] Class. Simple subroutine. Besides the new concept of "simple procedures" there is no major change here.
[Bug c++/109159] New: explicit constructor is used in copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159
Bug ID: 109159
Summary: explicit constructor is used in copy-initialization
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
The following code must be accepted (as it does in Clang and MSVC):
struct A {
A( float ) {}
template
explicit A( U ) {}
};
template
concept CopyFromIntList = requires( T t ) { t = { 1 }; };
static_assert( !CopyFromIntList );
because 't = {1}' is invalid: chosen constructor is explicit in
copy-initialization.
But in GCC static_assert fails. Online demo:
https://gcc.godbolt.org/z/Pf47E6dno
[Bug c++/106188] [coroutines] Incorrect frame layout after transforming conditional statement without top-level bind expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106188 Arsen Arsenović changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Arsen Arsenović --- Should be fixed on all branches.
[Bug c++/106713] [11/12 Regression] Coroutine regression in GCC 11.3.0: if (co_await ...) crashes with a jump to ud2 since r12-3529-g70ee703c479081ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713 Arsen Arsenović changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Arsen Arsenović --- Should be fixed on all branches.
[Bug c++/105809] [10/11/12/13 Regression] __PRETTY_FUNCTION__ in constexpr in function vs NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554 --- Comment #15 from Jakub Jelinek --- Created attachment 54686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54686=edit gcc13-pr105554.patch This untested patch seems to work.
[Bug c++/109030] [13 Regression] checking ICE in cxx_eval_call_expression with aggregate initialization inside noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109030 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:31cdfdef04701e10cffcec4578b2337684f0e4bc commit r13-6716-g31cdfdef04701e10cffcec4578b2337684f0e4bc Author: Patrick Palka Date: Thu Mar 16 14:47:43 2023 -0400 c++: maybe_constant_init and unevaluated operands [PR109030] This testcase in this PR (already fixed by r13-6526-ge4692319fd5fc7) demonstrates that maybe_constant_init can be called on an unevaluated operand (e.g. from massage_init_elt) so this entry point should also limit constant evaluation in that case, like maybe_constant_value does. PR c++/109030 gcc/cp/ChangeLog: * constexpr.cc (maybe_constant_init_1): For an unevaluated non-manifestly-constant operand, don't constant evaluate and instead call fold_to_constant as in maybe_constant_value. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constexpr-inst2.C: New test.
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #14 from Jakub Jelinek ---
So, I have tried
--- gcc/cgraphclones.cc.jj 2023-02-24 11:05:19.704595633 +0100
+++ gcc/cgraphclones.cc 2023-03-16 19:12:30.452503051 +0100
@@ -1094,6 +1094,15 @@ cgraph_node::create_version_clone_with_b
|| in_lto_p)
new_version_node->unique_name = true;
+ if (target_attributes)
+{
+ push_cfun (DECL_STRUCT_FUNCTION (new_decl));
+ for (tree arg = DECL_ARGUMENTS (new_decl); arg; arg = DECL_CHAIN (arg))
+ if (VECTOR_TYPE_P (TREE_TYPE (arg)))
+ SET_DECL_MODE (arg, TYPE_MODE (TREE_TYPE (arg)));
+ pop_cfun ();
+}
+
/* Update the call_expr on the edges to call the new version node. */
update_call_expr (new_version_node);
but that really didn't help, the problem seems to be actually different.
>From what I can see, tree_function_versioning does:
6240 DECL_RESULT (new_decl) = DECL_RESULT (old_decl);
6241 DECL_ARGUMENTS (new_decl) = DECL_ARGUMENTS (old_decl);
6242 initialize_cfun (new_decl, old_decl,
6243 new_entry ? new_entry->count :
old_entry_block->count);
and initialize_cfun will call allocate_function, which does:
4845 /* Now that we have activated any function-specific
attributes
4846 that might affect layout, particularly vector modes,
relayout
4847 each of the parameters and the result. */
4848 relayout_decl (result);
4849 for (tree parm = DECL_ARGUMENTS (fndecl); parm;
4850 parm = DECL_CHAIN (parm))
4851relayout_decl (parm);
So, we temporarily set DECL_ARGUMENTS and DECL_RESULT of new_decl to
arguments/result of old_decl and allocate_function called relayout_decl on
those, later on we create new arguments (which supposedly have correct
DECL_MODE). But we've changed the old DECL_RESULT/DECL_ARGUMENTS.
[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109140 Sam James changed: What|Removed |Added CC||davem at davemloft dot net --- Comment #11 from Sam James --- Thank you for the extremely thorough bisect!
[Bug c++/100288] [11/12/13 Regression] g++-11 internal error and fails to precompile a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288 Patrick Palka changed: What|Removed |Added Keywords||error-recovery, ||ice-checking Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|11.4|13.0 --- Comment #14 from Patrick Palka --- Fixed for GCC 13, backporting isn't really necessary since the ICE occurs only in non-release builds.
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW --- Comment #9 from Andrew Pinski --- (In reply to seurer from comment #8) > Alas, yes. This system is quite old and not being updated any more. It > hopefully will be retired soon. > > This probably isn't a big deal and as far as I am concerned can be ignored. The patch is still most likely needed for newlib targets as newlib's complex.h does not define CMPLXF .
[Bug c++/100288] [11/12/13 Regression] g++-11 internal error and fails to precompile a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288 --- Comment #13 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c630157fd01140dbce120c1409c413a97dc17104 commit r13-6715-gc630157fd01140dbce120c1409c413a97dc17104 Author: Patrick Palka Date: Thu Mar 16 14:22:54 2023 -0400 c++: checking ICE with diagnosed constraint recursion [PR100288] When satisfaction_cache::get detects constraint recursion, it asserts that entry->result is empty. This makes sense when we're initially detecting/diagnosing recursion from the inner recursive call, but afterwards from the outer recursive call the recursion error is treated like any other unrelated constraint failure encountered during satisfaction, and we set entry->result to whatever the satisfaction value ended up being. Perhaps we should keep entry->result cleared in this case, but that'd require the inner recursive call to communicate to the outer recursive call that constraint recursion occurred, likely via setting entry->result to some sentinel value, which doesn't seem to be worth the complexity. So this patch just relaxes the problematic assert to accept non-empty entry->result as long as we've already issued an error. PR c++/100288 gcc/cp/ChangeLog: * constraint.cc (satisfaction_cache::get): Relax overly strict checking assert in the constraint recursion case. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-recursive-sat5.C: New test.
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145 --- Comment #8 from seurer at gcc dot gnu.org --- Alas, yes. This system is quite old and not being updated any more. It hopefully will be retired soon. This probably isn't a big deal and as far as I am concerned can be ignored.
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554 --- Comment #13 from Jakub Jelinek --- A lot of ipa passes use push_cfun: grep push_cfun ipa*.cc ipa-fnsummary.cc: push_cfun (DECL_STRUCT_FUNCTION (node->decl)); ipa-fnsummary.cc: push_cfun (DECL_STRUCT_FUNCTION (node->decl)); ipa-modref.cc: push_cfun (f); ipa-modref.cc: push_cfun (DECL_STRUCT_FUNCTION (node->decl)); ipa-modref.cc: push_cfun (DECL_STRUCT_FUNCTION (node->decl)); ipa-prop.cc: push_cfun (func); ipa-pure-const.cc: push_cfun (DECL_STRUCT_FUNCTION (decl)); ipa-sra.cc: push_cfun (DECL_STRUCT_FUNCTION (node->decl)); ipa-sra.cc: push_cfun (fun); ipa-utils.cc: push_cfun (dstcfun); ipa-visibility.cc:push_cfun (DECL_STRUCT_FUNCTION (e->caller->decl)); ipa-visibility.cc:push_cfun (DECL_STRUCT_FUNCTION (e->caller->decl)); After all, even create_target_clone -> create_version_clone_with_body -> tree_function_versioning already called and and then pop_cfun () again. multiple-target.cc is something so seldom used that another push_cfun/pop_cfun around the newly proposed loop wouldn't be that bad.
[Bug libstdc++/108636] [10 Regression] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jonathan Wakely --- Fixed for 10.5, 11.4, 12.3 and 13.1
[Bug libstdc++/108636] [10 Regression] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d640e435f156d8f825bf95c2164053b4a3a7b682 commit r10-11253-gd640e435f156d8f825bf95c2164053b4a3a7b682 Author: Jonathan Wakely Date: Thu Feb 2 14:06:40 2023 + libstdc++: Fix std::filesystem errors with -fkeep-inline-functions [PR108636] With -fkeep-inline-functions there are linker errors when including . This happens because there are some filesystem::path constructors defined inline which call non-exported functions defined in the library. That's usually not a problem, because those constructors are only called by code that's also inside the library. But when the header is compiled with -fkeep-inline-functions those inline functions are emitted even though they aren't called. That then creates an undefined reference to the other library internals. The fix is to just move the private constructors into the library where they are called. That way they are never even seen by users, and so not compiled even if -fkeep-inline-functions is used. libstdc++-v3/ChangeLog: PR libstdc++/108636 * include/bits/fs_path.h (path::path(string_view, _Type)) (path::_Cmpt::_Cmpt(string_view, _Type, size_t)): Move inline definitions to ... * src/c++17/fs_path.cc: ... here. * testsuite/27_io/filesystem/path/108636.cc: New test. (cherry picked from commit db8d6fc572ec316ccfcf70b1dffe3be0b1b37212)
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145
--- Comment #7 from Jakub Jelinek ---
So, I think we can either use:
2023-03-16 Jakub Jelinek
PR testsuite/109145
* gcc.dg/tree-ssa/forwprop-39.c (CMPLXF): Define if not defined.
--- gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c.jj 2023-03-13
10:18:59.545433477 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c 2023-03-16 18:48:04.408908088
+0100
@@ -3,6 +3,10 @@
#include
+#ifndef CMPLXF
+#define CMPLXF(x, y) __builtin_complex (x, y)
+#endif
+
extern void push1(void *p, float _Complex x);
void foo (void *q, float _Complex *x)
{
or
2023-03-16 Jakub Jelinek
PR testsuite/109145
* gcc.dg/tree-ssa/forwprop-39.c: Don't include complex.h.
(foo): Use __builtin_complex rather than CMPLXF.
--- gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c.jj 2023-03-13
10:18:59.545433477 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c 2023-03-16 18:49:40.563504504
+0100
@@ -1,14 +1,12 @@
/* { dg-do compile } */
/* { dg-options "-std=c11 -O2 -fdump-tree-forwprop1 -fdump-tree-optimized" }
*/
-#include
-
extern void push1(void *p, float _Complex x);
void foo (void *q, float _Complex *x)
{
float r = __real *x;
float i = __imag *x;
- push1 (q, CMPLXF (r, i));
+ push1 (q, __builtin_complex (r, i));
}
/* { dg-final { scan-tree-dump-not "COMPLEX_EXPR" "forwprop1" } } */
I think my preference would be the latter...
[Bug fortran/109157] -fbound-check: false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109157 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104908 --- Comment #2 from anlauf at gcc dot gnu.org --- Might be related to pr104908.
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Those macros have been only introduced in glibc in 2012: https://sourceware.org/bugzilla/show_bug.cgi?id=13530 Bill, do you have glibc older than 2.16?
[Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 54685 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54685=edit gcc13-pr108685.patch Untested fix.
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145 --- Comment #5 from seurer at gcc dot gnu.org --- The excess error is: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c: In function 'foo': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c:11:13: warning: implicit declaration of function 'CMPLXF' [-Wimplicit-function-declaration]
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145 --- Comment #4 from seurer at gcc dot gnu.org --- Created attachment 54684 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54684=edit Preprocessed file Attached file from this command /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c -fdiagnostics-plain-output -std=c11 -O2 -fdump-tree-forwprop1 -fdump-tree-optimized -E -o forwprop-39.i
[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109140 --- Comment #10 from Mikael Pettersson --- A bisect between 4.6.4 (good) and 4.7.4 (bad) found: 1f9ed162eb30f1b40b65d164b3a40ac78e1f006e is the first bad commit commit 1f9ed162eb30f1b40b65d164b3a40ac78e1f006e Author: David S. Miller Date: Tue Nov 1 08:42:57 2011 + Add vcond/vcondu patterns to sparc backend. If I disable the "vconduv8qiv8qi" expander this test case doesn't cause an ICE.
[Bug c++/101869] [10/11/12/13 Regression] ::enumvalue is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101869 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/91133] [10/11/12/13 Regression] Wrong "partial specialization is not more specialized than" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91133 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|SUSPENDED Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #9 from Jason Merrill --- The error was downgraded to a pedwarn in r12-8256. I still think it is correct, but I'm suspending rather than closing due to the continuing implementation divergence.
[Bug target/109158] New: arm: errors when mixing __attribute__((pcs("aapcs-vfp"))) with +nofp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109158
Bug ID: 109158
Summary: arm: errors when mixing
__attribute__((pcs("aapcs-vfp"))) with +nofp
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: stammark at gcc dot gnu.org
Target Milestone: ---
I've detected a couple of minor issues when using
__attribute__((pcs("aapcs-vfp"))) in no-fp architectures, resulting in wrong
code or an ICE.
reproducer code:
__attribute__((pcs("aapcs-vfp"))) a(__fp16);
void foo() {
a(0.0);
}
Issue 1: when compiled as `-march=armv8.1-m.main+mve+nofp -mfloat-abi=softfp
-mfp16-format=ieee` we emit an invalid FP instruction `vmov.f16` to put the
immediate into `s0` before returning from the function.
I believe this is a simple case of the `*mov_vfp_16`assuming that
all variants are valid with any `TARGET_VFP_FP16INST || TARGET_HAVE_MVE` when
actually the `vmov.f16` cases are only valid with TARGET_VFP_FP16INST, but not
with MVE.
Issue 2: when compiled as `-march=armv8.1-m.main+nofp -mfloat-abi=softfp` (i.e.
no MVE, no FP at all) we ICE with `maximum number of generated reload insns per
insn achieved` -- this class of error also happens with `float` and `double`
types.
IMO this is an invalid configuration and we should be emitting a user error
instead of the ICE, similar to what we do if the user requests -mfloat-abi=hard
without any MVE or FP present:
``` else if (TARGET_HARD_FLOAT_ABI)
{
arm_pcs_default = ARM_PCS_AAPCS_VFP;
if (!bitmap_bit_p (arm_active_target.isa, isa_bit_vfpv2)
&& !bitmap_bit_p (arm_active_target.isa, isa_bit_mve))
error ("%<-mfloat-abi=hard%>: selected architecture lacks an FPU");
}```
[Bug target/109154] [13 regression] jump threading with de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 Tamar Christina changed: What|Removed |Added Summary|[13 regression] aarch64 |[13 regression] jump |-mcpu=neoverse-v1 microbude |threading with de-optimizes |performance regression |nested floating point ||comparisons Status|UNCONFIRMED |NEW CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-03-16 --- Comment #3 from Tamar Christina --- Aldy, any thoughts here?
[Bug target/109154] [13 regression] aarch64 -mcpu=neoverse-v1 microbude performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #2 from Tamar Christina ---
Confirmed, It looks like the extra range information from
g:4fbe3e6aa74dae5c75a73c46ae6683fdecd1a75d is leading jump threading down the
wrong path.
Reduced testcase:
---
int etot_0, fasten_main_natpro_chrg_init;
void fasten_main_natpro() {
float elcdst = 1;
for (int l; l < 1; l++) {
int zone1 = l < 0.0f, chrg_e = fasten_main_natpro_chrg_init * (zone1 ?: 1)
*
(l < elcdst ? 1 : 0.0f);
etot_0 += chrg_e;
}
}
---
and compile with `-O1`. Issue also effects all targets not just AArch64
https://godbolt.org/z/qes4K4oTz. and using `-fno-thread-jumps` confirmed to
"fix" it.
With the new case jump threading seems to duplicate the edges on the l < 0.0f
check.
the dump says:
"Jump threading proved probability of edge 5->7 too small (it is 41.0%
(guessed) should be 69.5% (guessed))"
In BB 3 the branch probabilities are guessed as:
if (_1 < 0.0)
goto ; [41.00%]
else
goto ; [59.00%]
and in BB 5:
if (_1 < 1.0e+0)
goto ; [41.00%]
else
goto ; [59.00%]
and so it thinks that the chances of _1 >= 0.0 && _1 < 1.0 is very small:
if (_1 < 1.0e+0)
goto ; [14.80%]
else
goto ; [85.20%]
The problem is that both BB 4 falls through to BB 5, and BB 6 falls through to
BB 7.
jump threading optimizes BB 5 by splitting the work to be done in BB 5 for the
fall-through from BB 4 back into BB 4.
It then threads the additional edge to BB 7 where the final calculation is now
more expensive. much more than before (three way phi-node).
but because the hot path in BB 6 also falls into BB 7 the overall result is
that all paths become slower. but the hot path actually got an additional
comparison.
This is why the code slows down, for each instance of this occurrence (and in
the example provided by microbude it happens often) we get an addition branch
in a few paths.
this has a bigger slow down in SVE (vs the scalar slowdown) because it then
creates a longer dependency chain on producing the predicate for the BB.
It looks like this threading shouldn't be done if both hot and cold branches
end up in the same place?
[Bug libstdc++/108636] [10/11 Regression] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:05fa584bbb5534ec7a763a2d0e6d89cf251534f5 commit r11-10581-g05fa584bbb5534ec7a763a2d0e6d89cf251534f5 Author: Jonathan Wakely Date: Thu Feb 2 14:06:40 2023 + libstdc++: Fix std::filesystem errors with -fkeep-inline-functions [PR108636] With -fkeep-inline-functions there are linker errors when including . This happens because there are some filesystem::path constructors defined inline which call non-exported functions defined in the library. That's usually not a problem, because those constructors are only called by code that's also inside the library. But when the header is compiled with -fkeep-inline-functions those inline functions are emitted even though they aren't called. That then creates an undefined reference to the other library internals. The fix is to just move the private constructors into the library where they are called. That way they are never even seen by users, and so not compiled even if -fkeep-inline-functions is used. libstdc++-v3/ChangeLog: PR libstdc++/108636 * include/bits/fs_path.h (path::path(string_view, _Type)) (path::_Cmpt::_Cmpt(string_view, _Type, size_t)): Move inline definitions to ... * src/c++17/fs_path.cc: ... here. * testsuite/27_io/filesystem/path/108636.cc: New test. (cherry picked from commit db8d6fc572ec316ccfcf70b1dffe3be0b1b37212)
[Bug libstdc++/104883] should define all std::errc enumerators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104883 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c86ac1a463f97554b1df9ef8a3e18573ef115e35 commit r11-10578-gc86ac1a463f97554b1df9ef8a3e18573ef115e35 Author: Jonathan Wakely Date: Tue Jan 31 22:16:31 2023 + libstdc++: Fix build failures for avr The avr-libc does not define EOVERFLOW, which means that std::errc::value_too_large is not defined, and so cannot be compiled. Define value_too_large for avr with a value that does not clash with any that is defined in . This is a kluge to fix bootstrap for avr; it can be removed after PR libstdc++/104883 is resolved. The avr-libc fails to meet the C and POSIX requirements that each error macro has a distinct integral value, and is usable in #if directives. Add a special case for avr to system_error.cc so that only the valid errors are recognized. Also disable the errno checks in std::filesystem::remove_all that assume a meaningful value for errno. On avr-libc exists but does not define the POSIX functions needed by std::filesystem, so _GLIBCXX_HAVE_UNISTD_H is not sufficient to check for basic POSIX APIs. Check !defined __AVR__ as well as _GLIBCXX_HAVE_UNISTD_H before using those functions. This is a kluge and we should really have a specific macro that says the required functions are available. libstdc++-v3/ChangeLog: * config/os/generic/error_constants.h (errc::value_too_large) [__AVR__]: Define. * src/c++11/system_error.cc (system_category::default_error_condition) [__AVR__]: Only match recognize values equal to EDOM, ERANGE, ENOSYS and EINTR. * src/c++17/fs_ops.cc (fs::current_path) [__AVR__]: Do not use getcwd. * src/filesystem/ops-common.h [__AVR__]: Do not use POSIX open, close etc. (cherry picked from commit 2d2e163d12f64a5e68f9e0381751ed9d5d6d3617)
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476 --- Comment #16 from Maciej S. Szmigiero --- > If you rely on the standard guarantee that extern "C" and extern "C++" make > function types different, you probably get compilation errors. It's the other way around - functions in standard-compliant code should have proper language linkage markings (including implicit markings). They are needed in case some compiler or platform decides that, for example, "C" and "C++" language linkages need to have different calling conventions. Which is something that the standard allows. However, this bug is about having internal linkage for all anonymous namespace functions (including the ones declared with "C" language linkage) - whether "C" and "C++" language linkages should be allowed to have different calling conventions is a different matter.
[Bug fortran/109157] -fbound-check: false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109157 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-16 Priority|P3 |P4 --- Comment #1 from kargl at gcc dot gnu.org --- If you change class(tfieldmetadata_base), dimension(:), intent(in) :: tpfields to type(tfieldmetadata_base), dimension(:), intent(in) :: tpfields the code executes without the runtime error. Likely, gfortran is not using the correct dimension from the vtab created for a class entity.
[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 Marek Polacek changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|ASSIGNED --- Comment #26 from Marek Polacek --- (In reply to Kohei Takahashi from comment #24) > (In reply to Marek Polacek from comment #23) > > (In reply to Kohei Takahashi from comment #21) > > > (In reply to Marek Polacek from comment #18) > > > > (In reply to Barnabás Pőcze from comment #17) > > > > > The simple test case with std::span still triggers the warning: > > > > > https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code > > > > > analysis such a warning will generate too many false positives and > > > > > people > > > > > will simply turn it off. > > > > > > > > There really haven't been that many, except this and one with > > > > range-based > > > > for loops. > > > > > > I think it warns many usage of zip_iterator idiom such as boost.iterator > > > and > > > P2321 style flat_map. Those uses tuple of references like > > > std::tuple > > > by dereferencing iterator, so that any algorithms may yield this warning. > > > > Ah, would you please have a testcase? If that's the case and the warning > > can't be taught to recognize that pattern, then I think we need to move it > > to -Wextra. Thanks. > > In my flat map implementation, https://github.com/Flast/flat_map, the > warning is shown here > https://github.com/Flast/flat_map/blob/ > f7d547fd4dbde763c07eb8d35796248c41989a66/flat_map/__flat_tree.hpp#LL435C42- > L435C52 . You can reproduce it by following > ``` > flat_map$ mkdir build > flat_map$ cd build > flat_map/build$ cmake .. > flat_map/build$ make map_tie_test_17 > ``` > > `_key_extractor` is defined here, > https://github.com/Flast/flat_map/blob/ > f7d547fd4dbde763c07eb8d35796248c41989a66/flat_map/flat_map.hpp#L89-L90, and > the iterator dereference is here, > https://github.com/Flast/flat_map/blob/ > f7d547fd4dbde763c07eb8d35796248c41989a66/flat_map/tied_sequence.hpp#L67-L72. > Hence, reduced code is like https://wandbox.org/permlink/DloAyU3dQgydo7PS, > or https://wandbox.org/permlink/7fM4NDF8u1hiRMFC. Thanks for those reduced testcases. I may be able to fix the warning there.
[Bug tree-optimization/109156] Support Absolute Difference detection in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-03-16 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- .
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson --- Same for cris-elf (latest at r13-6712-gbd2d206b7b7d) and apparently pru-elf (r13-6705-gaf4f6816660293) according to https://gcc.gnu.org/pipermail/gcc-testresults/2023-March/779696.html There's an "excess error" due to a missing definition or declaration of CMPLXF. The newlib complex.h doesn't have CMPLXF. I intend to add a "! target newlib" (sp?) but maybe you guys are working on another solution.
[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 --- Comment #25 from Marek Polacek --- Maybe it would help to say that *any* class that has a reference member is a reference-wrapper and don't warn.
[Bug target/109154] [13 regression] aarch64 -mcpu=neoverse-v1 microbude performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 Richard Biener changed: What|Removed |Added Component|tree-optimization |target Keywords||missed-optimization Target Milestone|--- |13.0
[Bug middle-end/106133] ICE: SIGSEGV in diagnostic_output_format_init_json_file() with -fdiagnostics-format=json-file -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106133 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Martin Liška --- Fixed.
[Bug middle-end/106133] ICE: SIGSEGV in diagnostic_output_format_init_json_file() with -fdiagnostics-format=json-file -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106133 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:c5e2c3dd6afcf9b152df72b30e205b0180c0afd5 commit r13-6713-gc5e2c3dd6afcf9b152df72b30e205b0180c0afd5 Author: Martin Liska Date: Tue Jan 10 15:14:05 2023 +0100 middle-end: always find a basename for -fdiagnostics-format=* In some situations, x_dump_base_name is NULL and thus we can and should use x_main_input_basename which should never be NULL. PR middle-end/106133 gcc/ChangeLog: * gcc.cc (driver_handle_option): Use x_main_input_basename if x_dump_base_name is null. * opts.cc (common_handle_option): Likewise. gcc/testsuite/ChangeLog: * c-c++-common/pr106133.c: New test.
[Bug modula2/109125] [13 regression] SIGBUS in m2pim_ldtoa_ldtoa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Gaius Mulley ---
> Created attachment 54675
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54675=edit
> Proposed fix v3
>
> Many thanks for testing and diagnosing the latest bugs. Here is a proposed
> fix
> for the bool parameters in dtoa and ldtoa:
This fixes all but one last failure:
+FAIL: gm2/types/run/pass/varient4.mod execution, -O
+FAIL: gm2/types/run/pass/varient4.mod execution, -O -g
+FAIL: gm2/types/run/pass/varient4.mod execution, -O3 -fomit-frame-pointer
+FAIL: gm2/types/run/pass/varient4.mod execution, -O3 -fomit-frame-pointer
-fin
line-functions
+FAIL: gm2/types/run/pass/varient4.mod execution, -Os
+FAIL: gm2/types/run/pass/varient4.mod execution, -g
gm2.log shows
executed
/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/gm2/varient4.x0 with
result failFAIL: gm2/types/run/pass/varient4.mod execution, -g
There's one unrelated issue here: the "excuted...with result fail"
message needs to end in a newline so you can grep for ^FAIL: in the log
file. This is from gm2-torture.exp (gm2-torture-execute), where the
send_log call needs an "\n"appended. gm2-simple.exp
(gm2-simple-execute) has the same issue.
The failing test just exits with status 1.
Running it under gdb shows that the exit happens after this:
36 zero ; hmm.bar := TRUE ; test(hmm, 3, 1) ;
Thread 2 hit Breakpoint 4, d_test (s=0x34bc0 , n=3, v=1)
at /vol/gcc/src/hg/master/local/gcc/testsuite/gm2/types/run/pass/d.c:44
44switch (n) {
(gdb) p s
$1 = (this *) 0x34bc0
(gdb) p *$1
$2 = {tag = 0, that = {first = {foo = 0, bar = 16777216, inner = {bt = 0,
bf = 0}}, an = 0}, final = 0}
(gdb) n
48case 3: assert(s->that.first.bar == v); break;
(gdb) p s->that.first.bar
$3 = 16777216
(gdb) p v
$4 = 1
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145 --- Comment #2 from seurer at gcc dot gnu.org --- I am updating some tools on the system and will try again.
[Bug sanitizer/108541] ASAN since GCC 9 missed a stack-buffer-overflow since r9-4503-g6e644a50045f8032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108541
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |WONTFIX
--- Comment #2 from Martin Liška ---
Ok, I've got a reduced test-case:
cat pr108541.c
struct S {
// WORKS: char padding[48];
char padding[49];
};
struct S h, *i;
int main() {
int *dummy;
int m = 1;
char *ptr = (char *)
*(struct S *)(char *)(ptr - 0) = h;
return 0;
}
so the shadow memory looks like this:
0x7530: f1 f1 f1 f1 f1 f1 04 f2 00 f3 f3 f3
[48, 52) 'm' (line 12)
[64, 72) 'dummy' (line 9)
what happens here: during the expansion of .ASAN_CHECK (5, ptr_5, 49, 1);
we check for the memory area beginning (that's fine), and than the ending,
which is out of the poisoned memory. It's unfortunate that the middle area of
the 49B contains a poisoned memory.
Closing as won't fix, we can't check every single byte of shadow memory, that
would be very slow.
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug tree-optimization/105973] Wrong branch prediction for if (COND) { if(x) noreturn1(); else noreturn2(); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105973 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug middle-end/106133] ICE: SIGSEGV in diagnostic_output_format_init_json_file() with -fdiagnostics-format=json-file -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106133 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Martin Liška --- I've been waiting for a review for quite some time: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614059.html
[Bug middle-end/108311] system.h defines va_copy but we require C++11 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108311 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Martin Liška --- Also part of: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609503.html
[Bug middle-end/108312] NULL definition in system.h is no longer needed any more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108312 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #3 from Martin Liška --- The patch was sent and hasn't been approved: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609503.html
[Bug fortran/109157] New: -fbound-check: false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109157 Bug ID: 109157 Summary: -fbound-check: false positive Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: philippe.wautelet at aero dot obs-mip.fr Target Milestone: --- Hello, The following code triggers a wrong out of bound detection: > cat ndimlist.f90 program ndimlistbug implicit none integer, parameter :: FIELDSIZE=5 type :: tfieldmetadata_base integer, dimension(10) :: ndimlist = -2 end type tfieldmetadata_base type(tfieldmetadata_base), dimension(FIELDSIZE) :: tzfields call write_diachro_lfi( tzfields ) contains subroutine write_diachro_lfi( tpfields ) class(tfieldmetadata_base), dimension(:), intent(in) :: tpfields print *,tpfields(1)%ndimlist print *,tpfields(1)%ndimlist(8) end subroutine write_diachro_lfi end program ndimlistbug If compiled with gfortran 12.2.0 (but also 11.1.0, 11.2.0, 11.3.0 and 12.1.0), it gives: > gfortran -g -fbounds-check ndimlist.f90 > ./a.out -2 -2 -2 -2 -2 -2 -2 -2 -2 -2 At line 18 of file ndimlist.f90 Fortran runtime error: Index '8' of dimension 1 of array 'tpfields%_data%ndimlist' above upper bound of 5 Error termination. Backtrace: #0 0x400aec in write_diachro_lfi at /home/waup/F90/bug_gcc/ndimlist/ndimlist.f90:18 #1 0x4008ee in ndimlistbug at /home/waup/F90/bug_gcc/ndimlist/ndimlist.f90:11 #2 0x400b8f in main at /home/waup/F90/bug_gcc/ndimlist/ndimlist.f90:11 It seems there is a confusion between the size of tpfields and the size of tpfields()%ndimlist. This can be seen if FIELDSIZE is set to at least the size of ndimlist. The bug is not present with versions of gfortran below 11.
[Bug tree-optimization/109156] Support Absolute Difference detection in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #3 from Tamar Christina --- Reserving work
[Bug tree-optimization/109156] Support Absolute Difference detection in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156 --- Comment #2 from Tamar Christina --- (In reply to Richard Biener from comment #1) > (In reply to Tamar Christina from comment #0) > > 2. It looks like all targets that implement SAD do so with an instruction > > that does ABD and then perform a reduction. So it looks like no target has > > the semantics for SAD. > > x86 for example does SAD on 16 QImode data and 4 SImode accumulators which > means it sums 4 QImode absolute differences each (but SAD_EXPR leaves > unspecified which, so SAD_EXPR is only usable when you in the end sum > the accumulator lanes as well). > Oh I see, psadbw is actually SAD. sorry I missed the `s` in the instruction! > So I don't think 2. is true. > > > So this brings up the question of why the detection wasn't done based on ABD > > instead and leaving the reduction explicit in the vectorizer. > > > > So question is, should we create a completely new standalone pattern for ABD > > or should be make ABD the thing being detected and change SAD_EXPR to > > recognize ADB + reduction. > > > > Removing SAD completely in favor of ABD + reduction means that hand > > optimized versions in targets need updating so I'm in favor of still > > emitting SAD. > > I'd do a separate internal function for ABD, possibly sharing part of the > detection as you proposed. Great, will do so, thanks!
[Bug analyzer/109094] [13 Regression] ICE in -fanalyzer seen in qemu's target/i386/tcg/translate.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-03-16 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #5 from David Malcolm --- I'm working on reducing this.
[Bug tree-optimization/109156] Support Absolute Difference detection in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156 --- Comment #1 from Richard Biener --- (In reply to Tamar Christina from comment #0) > 2. It looks like all targets that implement SAD do so with an instruction > that does ABD and then perform a reduction. So it looks like no target has > the semantics for SAD. x86 for example does SAD on 16 QImode data and 4 SImode accumulators which means it sums 4 QImode absolute differences each (but SAD_EXPR leaves unspecified which, so SAD_EXPR is only usable when you in the end sum the accumulator lanes as well). So I don't think 2. is true. > So this brings up the question of why the detection wasn't done based on ABD > instead and leaving the reduction explicit in the vectorizer. > > So question is, should we create a completely new standalone pattern for ABD > or should be make ABD the thing being detected and change SAD_EXPR to > recognize ADB + reduction. > > Removing SAD completely in favor of ABD + reduction means that hand > optimized versions in targets need updating so I'm in favor of still > emitting SAD. I'd do a separate internal function for ABD, possibly sharing part of the detection as you proposed.
[Bug tree-optimization/109154] [13 regression] aarch64 -mcpu=neoverse-v1 microbude performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #1 from Tamar Christina --- Thanks for the report, taking a look!
[Bug tree-optimization/109156] New: Support Absolute Difference detection in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156
Bug ID: 109156
Summary: Support Absolute Difference detection in GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
Today we support Sum of Absolute differences
#include
#define TYPE_IN signed char
#define TYPE_OUT signed int
TYPE_OUT SABD_example (int n, TYPE_IN *restrict a, TYPE_IN *restrict b)
{
TYPE_OUT out = 0;
for (int i = 0; i < n; i++)
out += abs(b[i] - a[i]);
return out;
}
which is implemented through the SAD_EXPR tree code.
The goal is to support absolute difference ABD and widening absolute difference
(no reduction).
#include
#define TYPE_IN signed int
#define TYPE_OUT signed int
void ABD_example (int n, TYPE_IN *restrict a, TYPE_IN *restrict b, TYPE_OUT
*restrict out)
{
for (int i = 0; i < n; i++)
out[i] = abs(b[i] - a[i]);
}
This code shares 90% of the work with the vect_recog_sad_pattern expression
with one difference, the SAD expression starts at a reduction, the ADB
expressions start at an optional cast but otherwise from the abs.
There are two ways we're thinking of implementing ABD, (ABDL we can't do at the
moment because we can't do widening in IFNs).
1. refactor the SAD detection code such that the body of the code that detects
ABD is refactored out and can be used by a new pattern. This has the down side
of us having to do duplicate work in patterns that may match this. In general
this doesn't happen often because SAD stops at the + and should be OK if ADB
matches after SAD. though cast_forwardprop may make this hard to do.
2. It looks like all targets that implement SAD do so with an instruction that
does ABD and then perform a reduction. So it looks like no target has the
semantics for SAD.
So this brings up the question of why the detection wasn't done based on ABD
instead and leaving the reduction explicit in the vectorizer.
So question is, should we create a completely new standalone pattern for ABD or
should be make ABD the thing being detected and change SAD_EXPR to recognize
ADB + reduction.
Removing SAD completely in favor of ABD + reduction means that hand optimized
versions in targets need updating so I'm in favor of still emitting SAD.
[Bug analyzer/109094] [13 Regression] ICE in -fanalyzer seen in qemu's target/i386/tcg/translate.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094 --- Comment #4 from David Malcolm --- (In reply to Martin Liška from comment #3) > Fixed? Sadly no, the comment above is just to mention that at least the crash is now captured in the .sarif dump.
[Bug target/109004] [10/11/12/13 Regression] wrong code for -O2 (any above -O0) with g++ 11.3 for POWER9 (cross-compiler on x86_64 host)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109004 --- Comment #11 from bugreporter66 at gmail dot com --- Created a QEMU bug here: https://gitlab.com/qemu-project/qemu/-/issues/1547
[Bug tree-optimization/106912] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 since r13-1575-gcf3a120084e94614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106912 --- Comment #12 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614071.html https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614070.html
[Bug target/109004] [10/11/12/13 Regression] wrong code for -O2 (any above -O0) with g++ 11.3 for POWER9 (cross-compiler on x86_64 host)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109004 --- Comment #10 from bugreporter66 at gmail dot com --- I checked the simple version of the test with QEMU 6.2.0 and 7.0.0: ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ powerpc64le-linux-gnu-g++ -O2 -mcpu=power9 -ffast-math -static sample.cpp -o sample_p64 ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ qemu-ppc64le --version qemu-ppc64le version 6.2.0 Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ qemu-ppc64le -cpu POWER9 sample_p64 qemu: uncaught target signal 6 (Aborted) - core dumped Aborted (core dumped) ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ... ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ qemu-ppc64le --version qemu-ppc64le version 7.0.0 Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ qemu-ppc64le -cpu POWER9 sample_p64 ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ ubuntu-mate@ubuntu-mate:~/Downloads/test_p64$ So it works after 7.0.0
