[Bug c++/118199] [15 regression] -fno-elide-constructors vs no_unique_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-12-26
--- Comment #10 from Andrew Pinski ---
(In reply to Sam James from comment #9)
> Created attachment 59975 [details]
> cvise-reduced.ii
>
> Attached cvise output as I hadn't cancelled it earlier, pinskia's is smaller
> though (just figured I'd post so the CPU time hadn't gone to waste).
It is interesting cvise did not simplify the constructors:
h(int) : j(d()) {}
h() : h(1) {}
To just:
h() : j(d()) {}
It is like it does not know constructors can delegate to others.
[Bug ada/118203] New: Redefined 'Image (with Put_Image aspect) causes STORAGE_ERROR when in a case expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118203
Bug ID: 118203
Summary: Redefined 'Image (with Put_Image aspect) causes
STORAGE_ERROR when in a case expression
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: 00120260a at gmail dot com
CC: dkm at gcc dot gnu.org
Target Milestone: ---
code:
with Ada.Text_IO, Ada.Strings.Text_Buffers;
procedure main is
use Ada.Text_IO, Ada.Strings.Text_Buffers;
Ln: Boolean := True;
type Clicks is (Left, Middle, Right) with Put_Image => My_Put_Image;
procedure My_Put_Image (Output : in out Root_Buffer_Type'Class; Value :
Clicks);
procedure My_Put_Image (Output : in out Root_Buffer_Type'Class; Value :
Clicks) is
begin
null;
end My_Put_Image;
A: clicks := left;
begin
Put_line ("Works, 'Image on its own statement' : "); Put
(clicks'(left)'Image);
Put_line ("Good outside a case expression: " & (case LN is when True =>
"a ", when False => "b " ) & A'Image);
Put_line ("Fails when inside it: " & (case LN is when True => "a ",
when False => "b " & A'Image));
end main;
-
I checked, it matters not that put_image has anything in it or not. It suffices
that the aspect is present. And if expressions don't cause this, only case
expressions.
[Bug sanitizer/118204] New: Clang is dropping -fsanitize=vptr from default -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118204 Bug ID: 118204 Summary: Clang is dropping -fsanitize=vptr from default -fsanitize=undefined Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- I'm filing this in case we want/need to change behaviour to follow Clang, but not saying we do need to. Clang is changing -fsanitize=undefined to no longer imply -fsanitize=vptr in https://github.com/llvm/llvm-project/pull/121115. The rationale there is: """ This makes undefined more consistent. vptr check adds additional constraints: rtti is no, or compilation error c++abi, or linking error trap is off, or silently disabled So it's not obvious if -fsanitizer=undefined will have it on. """ Do we want to do this? I suspect not, because I think that the situation with some checks not being enabled by the meta/larger options is already confusing, and this makes it worse.
[Bug c++/118199] [15 regression] -fno-elide-constructors vs no_unique_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 --- Comment #11 from Andrew Pinski --- Created attachment 59976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59976&action=edit Reduced further from 59975
[Bug c++/118199] [15 regression] -fno-elide-constructors vs no_unique_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199
--- Comment #12 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Sam James from comment #9)
> > Created attachment 59975 [details]
> > cvise-reduced.ii
> >
> > Attached cvise output as I hadn't cancelled it earlier, pinskia's is smaller
> > though (just figured I'd post so the CPU time hadn't gone to waste).
>
> It is interesting cvise did not simplify the constructors:
> h(int) : j(d()) {}
> h() : h(1) {}
>
> To just:
> h() : j(d()) {}
>
> It is like it does not know constructors can delegate to others.
Filed https://github.com/marxin/cvise/issues/155 .
[Bug c++/118199] [15 regression] -fno-elide-constructors vs no_unique_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 Andrew Pinski changed: What|Removed |Added Attachment #59976|0 |1 is obsolete|| --- Comment #13 from Andrew Pinski --- Created attachment 59978 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59978&action=edit Slightly more reduced
[Bug preprocessor/118168] -Wmisleading-indentation causes 10x+ overhead or higher (visible on mypy-1.13.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168 ak at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||ak at gcc dot gnu.org
[Bug sanitizer/118204] Clang is dropping -fsanitize=vptr from default -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118204 --- Comment #2 from Andrew Pinski --- > c++abi, or linking error What does that mean? Is it because for clang, msvc abi can be used and it is incompatible there? It is not obvious. How i wish the explanation would be easier to understand.
[Bug sanitizer/118204] Clang is dropping -fsanitize=vptr from default -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118204 --- Comment #1 from Sam James --- Note that for https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fsanitize-trap, we already document the incompatibility with vptr: > Currently this feature works with -fsanitize=undefined (and its suboptions > except for -fsanitize=vptr), [...] > If -fsanitize-trap=undefined or -fsanitize-trap=all is used and > -fsanitize=vptr is enabled on the command line, the instrumentation is > silently ignored as the instrumentation always needs libubsan support, > -fsanitize-trap=vptr is not allowed.
[Bug sanitizer/118204] Clang is dropping -fsanitize=vptr from default -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118204 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > > c++abi, or linking error > > What does that mean? Is it because for clang, msvc abi can be used and it is > incompatible there? > > > It is not obvious. How i wish the explanation would be easier to understand. Oh it just means the c++ library must be linked in too. I had to look into the documentation change to understand that. Not a big issue for gcc, since you either have to link using g++ or add -lstdc++ already.
[Bug sanitizer/118204] Clang is dropping -fsanitize=vptr from default -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118204 --- Comment #4 from Andrew Pinski --- (In reply to Sam James from comment #1) > Note that for > https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index- > fsanitize-trap, we already document the incompatibility with vptr: > > Currently this feature works with -fsanitize=undefined (and its suboptions > > except for -fsanitize=vptr), [...] > > If -fsanitize-trap=undefined or -fsanitize-trap=all is used and > > -fsanitize=vptr is enabled on the command line, the instrumentation is > > silently ignored as the instrumentation always needs libubsan support, > > -fsanitize-trap=vptr is not allowed. Though I have to admit, the wording here is hard to understand. Does it mean the instrumentation for vptr is not done if -fsanitizer=undefined is used? I understand the last part though; even though it should be a separate sentence or using a semicolon instead of a comma.
[Bug target/113149] Function multiversioning prefers arch=x86-64-v3 to actual processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113149 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #2 from Andi Kleen --- Can you please post the patch to gcc-patches? it makes sense to me.
[Bug c++/118201] New: ICE: in maybe_explain_implicit_delete, at cp/method.cc:3143
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118201
Bug ID: 118201
Summary: ICE: in maybe_explain_implicit_delete, at
cp/method.cc:3143
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wangbopku15 at gmail dot com
Target Milestone: ---
Extended from official test:
https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/g%2B%2B.old-deja/g%2B%2B.pt/mi1.C.
When the dtors of some of the classes are set defaulted, the ICE appears.
Please see https://godbolt.org/z/K7WYb4rda
Input test:
~~~
class PK_CryptoSystem
{
};
class PK_Encryptor : public virtual PK_CryptoSystem
{
};
class PK_FixedLengthCryptoSystem : public virtual PK_CryptoSystem
{
public:
virtual unsigned int CipherTextLength() const =0;
};
class PK_FixedLengthEncryptor : public virtual PK_Encryptor, public virtual
PK_FixedLengthCryptoSystem
{
};
class PK_SignatureSystem
{
public:
virtual ~PK_SignatureSystem() {}
};
class PK_Signer : public virtual PK_SignatureSystem
{
public:
virtual void Sign() = 0;
};
class PK_Verifier : public virtual PK_SignatureSystem
{
};
class PK_Precomputation
{
~PK_Precomputation()=default;
};
template class
PK_WithPrecomputation : public T, public virtual PK_Precomputation
{
~PK_WithPrecomputation()=default;
};
typedef PK_WithPrecomputation PKWPFLE;
typedef PK_WithPrecomputation PKWPS;
template class
ECPublicKey : public PKWPFLE
{
public:
unsigned int CipherTextLength() const { return 1; }
EC ec;
~ECPublicKey()=default;
};
template
class ECPrivateKey : public ECPublicKey, public PKWPS
{
void Sign() {}
int d;
~ECPrivateKey()=default;
};
template
class ECKEP : public ECPrivateKey
{
};
class GF2NT : public PK_CryptoSystem
{
int t1;
~GF2NT()=default;
};
class EC2N : public PK_CryptoSystem
{
GF2NT field;
int a;
~EC2N()=default;
};
template class ECKEP;
int
main ()
{
ECKEP foo;
return 0;
}
~~~
Compiler Output:
~~~
: In instantiation of 'class ECPrivateKey':
:56:7: required from 'class ECKEP'
56 | class ECKEP : public ECPrivateKey
| ^
:70:16: required from here
70 | template class ECKEP;
|^~~
:53:5: error: non-deleted function 'ECPrivateKey::~ECPrivateKey()
[with EC = EC2N]' overriding deleted function
53 | ~ECPrivateKey()=default;
| ^
:36:5: note: overridden function is
'PK_WithPrecomputation::~PK_WithPrecomputation() [with T = PK_Signer]'
36 | ~PK_WithPrecomputation()=default;
| ^
: In function 'int main()':
:75:15: error: use of deleted function 'ECKEP::ECKEP()'
75 | ECKEP foo;
| ^~~
:56:7: note: 'ECKEP::ECKEP()' is implicitly deleted because the
default definition would be ill-formed:
56 | class ECKEP : public ECPrivateKey
| ^
: At global scope:
:56:7: error: use of deleted function
'ECPrivateKey::ECPrivateKey()'
:49:7: note: 'ECPrivateKey::ECPrivateKey()' is implicitly deleted
because the default definition would be ill-formed:
49 | class ECPrivateKey : public ECPublicKey, public PKWPS
| ^~~~
:49:7: error: use of deleted function
'ECPublicKey::ECPublicKey()'
:41:1: note: 'ECPublicKey::ECPublicKey()' is implicitly deleted
because the default definition would be ill-formed:
41 | ECPublicKey : public PKWPFLE
| ^~~
:41:1: error: use of deleted function
'PK_WithPrecomputation::~PK_WithPrecomputation() [with T =
PK_FixedLengthEncryptor]'
:36:5: note: 'PK_WithPrecomputation::~PK_WithPrecomputation()
noexcept () [with T = PK_FixedLengthEncryptor]' is implicitly
deleted because its exception-specification does not match the implicit
exception-specification 'noexcept'
36 | ~PK_WithPrecomputation()=default;
| ^
:41:1: error: use of deleted function 'EC2N::EC2N()'
41 | ECPublicKey : public PKWPFLE
| ^~~
:64:7: note: 'EC2N::EC2N()' is implicitly deleted because the default
definition would be ill-formed:
64 | class EC2N : public PK_CryptoSystem
| ^~~~
:64:7: error: 'GF2NT::~GF2NT()' is private within this context
:62:5: note: declared private here
62 | ~GF2NT()=default;
| ^
:41:1: note: use '-fdiagnostics-all-candidates' to display considered
candidates
41 | ECPublicKey : public PKWPFLE
| ^~~
:41:1: error: use of deleted function 'EC2N::~EC2N()'
:68:5: note: 'EC2N::~EC2N()' is implicitly deleted because the default
definition would be ill-formed:
68 | ~EC2N()=default;
| ^
:68:5: error: 'GF2NT::~GF2NT()' is private within this context
:62:5: note: declared private here
62 | ~GF2NT()=default;
| ^
[Bug c++/118193] [12/13/14/15 regression] ICE: in verify_ctor_sanity, at cp/constexpr.cc:5362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118193 Sam James changed: What|Removed |Added Summary|ICE: in verify_ctor_sanity, |[12/13/14/15 regression] |at cp/constexpr.cc:5362 |ICE: in verify_ctor_sanity, ||at cp/constexpr.cc:5362 Target Milestone|--- |12.5
[Bug c++/118192] ICE: in build_data_member_initialization, at cp/constexpr.cc:453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118192 Sam James changed: What|Removed |Added Keywords||ice-checking --- Comment #1 from Sam James --- It ICEs w/ checking going back at least to 10.
[Bug c++/118201] [12/13/14/15 regression] ICE: in maybe_explain_implicit_delete, at cp/method.cc:3143
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118201 Sam James changed: What|Removed |Added Keywords||ice-checking Summary|ICE: in |[12/13/14/15 regression] |maybe_explain_implicit_dele |ICE: in |te, at cp/method.cc:3143|maybe_explain_implicit_dele ||te, at cp/method.cc:3143 Target Milestone|--- |12.5 --- Comment #1 from Sam James --- It started to ICE with 11 with checking.
[Bug c++/118193] [12/13/14/15 regression] ICE: in verify_ctor_sanity, at cp/constexpr.cc:5362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118193 --- Comment #1 from Sam James --- I assumed based on the function name that it'd be ice-checking but it appears not.
[Bug c++/118202] [12/13/14/15 regression] ICE segmentation fault when instantiating a derived template class with default template argument and special overloaded ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118202
Sam James changed:
What|Removed |Added
Target Milestone|--- |12.5
Summary|ICE segmentation fault when |[12/13/14/15 regression]
|instantiating a derived |ICE segmentation fault when
|template class with default |instantiating a derived
|template argument and |template class with default
|special overloaded ctor |template argument and
||special overloaded ctor
--- Comment #1 from Sam James ---
Started with 11 with checking ("assertions" on godbolt).
[Bug c++/118202] New: ICE segmentation fault when instantiating a derived template class with default template argument and special overloaded ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118202
Bug ID: 118202
Summary: ICE segmentation fault when instantiating a derived
template class with default template argument and
special overloaded ctor
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wangbopku15 at gmail dot com
Target Milestone: ---
The following code triggers an ICE on the trunk:
~~~
template
class A;
template
class B: public A {
B();
B(A a);
};
void
FPS()
{
B b;
}
~~~
The default template argument values, the default ctor of `B` and the
overloaded ctor with a parameter of base type `A` are essential factors to
reproduce the bug.
https://godbolt.org/z/b6n34sYEh
~~~
:4:19: error: expected class-name before '{' token [-Wtemplate-body]
4 | class B: public A {
| ^
:6:7: error: missing template argument list after 'A'; template
placeholder not permitted in parameter [-Wtemplate-body]
6 | B(A a);
| ^
|<>
:2:7: note: 'template class A' declared here
2 | class A;
| ^
: In function 'void FPS()':
:12:5: internal compiler error: Segmentation fault
12 | B b;
| ^
0x2938075 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x294ee76 internal_error(char const*, ...)
???:0
0xcf4a96 copy_guide_p(tree_node const*)
???:0
0xafb9e9 perform_dguide_overload_resolution(tree_node*, vec const*, int)
???:0
0xd0595f do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int, tree_node*)
???:0
0xbbee51 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xce5603 c_parse_file()
???:0
0xe450d9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/118199] [15 regression] ICE when building widelands-1.2.1 (with -fno-elide-constructors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 Sam James changed: What|Removed |Added Target Milestone|--- |15.0 Keywords||ice-on-valid-code
[Bug c++/118199] [15 regression] ICE when building widelands-1.2.1 (with -fno-elide-constructors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 --- Comment #1 from Sam James --- Created attachment 59971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59971&action=edit addons.cc.ii.xz
[Bug c++/118199] New: [15 regression] ICE when building widelands-1.2.1 (with -fno-elide-constructors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199
Bug ID: 118199
Summary: [15 regression] ICE when building widelands-1.2.1
(with -fno-elide-constructors)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Originally reported downstream in Gentoo at https://bugs.gentoo.org/946900.
```
$ g++ -c ./src/logic/CMakeFiles/logic_addons.dir/addons.cc.ii
-fno-elide-constructors
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/hashtable.h:37,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/unordered_map.h:33,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/unordered_map:43,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/functional:65,
from
/var/tmp/portage/games-strategy/widelands-1.2.1/work/widelands-1.2.1/src/logic/addons.h:23,
from
/var/tmp/portage/games-strategy/widelands-1.2.1/work/widelands-1.2.1/src/logic/addons.cc:19:
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/hashtable_policy.h: In
constructor
‘std::__detail::_Hashtable_alloc<_NodeAlloc>::_Hashtable_alloc(_Alloc&&) [with
_Alloc = std::a
llocator, std::__cxx11::basic_string >, true> >;
_NodeAlloc = std::allocator,
std::__cxx11::basic_string >, true> >]’:
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/hashtable_policy.h:1522:11:
internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.cc:911
1522 | : _M_alloc{std::forward<_Alloc>(__a)}
| ^~~
0x5ed25b18940c internal_error(char const*, ...)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:517
0x5ed25b1895a7 fancy_abort(char const*, int, char const*)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic.cc:1722
0x5ed2599b4530 cp_gimplify_expr(tree_node**, gimple**, gimple**)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/cp-gimplify.cc:911
0x5ed25b355398 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:18722
0x5ed25b411c9a gimplify_addr_expr
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:7323
0x5ed25b355920 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:18863
0x5ed25b40f35a gimplify_expr
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:19907
0x5ed25b40f35a gimplify_arg(tree_node**, gimple**, unsigned long, bool)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:3827
0x5ed25b40f35a gimplify_call_expr
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:4369
0x5ed25b3563e1 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:18785
0x5ed25b354926 gimplify_stmt(tree_node**, gimple**)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:7999
0x5ed25b35669a gimplify_cleanup_point_expr
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:7737
0x5ed25b35669a gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:19215
0x5ed25b35683e gimplify_stmt(tree_node**, gimple**)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:7999
0x5ed25b35683e gimplify_statement_list
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:2280
0x5ed25b35683e gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:19267
0x5ed25b354926 gimplify_stmt(tree_node**, gimple**)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:7999
0x5ed25bc273f6 gimplify_bind_expr
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:1675
0x5ed25b356a24 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:19017
0x5ed25b354926 gimplify_stmt(tree_node**, gimple**)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:7999
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug middle-end/118200] New: note_simd_array_uses crashes in SIMT region with offloading to nvptx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118200
Bug ID: 118200
Summary: note_simd_array_uses crashes in SIMT region with
offloading to nvptx
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: prathamesh3492 at gcc dot gnu.org
Target Milestone: ---
Hi,
While working on patch to enable SVE with offloading
(https://gcc.gnu.org/pipermail/gcc/2024-December/245265.html),
I came across an issue in note_simd_array_uses, which seems to crash while
processing GOMP internal functions (GOMP_SIMD_VF) in SIMT region. This happens
because in SIMT region, first argument to GOMP internal function is lhs of call
to IFN_GOMP_SIMT_ENTER, rather than default definition, and
note_simd_array_uses crashes at:
ns.simduid = DECL_UID (SSA_NAME_VAR (gimple_call_arg (stmt, 0)));
because the SSA temporary name in this case has SSA_NAME_VAR set to NULL.
This can also be reproduced on trunk with the following test:
#include
#define N 1000
int A[N];
int B[N];
int main()
{
int i;
int sum = 0;
#pragma omp target map(sum), map(A), map(B), map (i)
#pragma omp teams distribute parallel for simd reduction(+:sum)
for (i = 0; i < N; i++)
sum += A[i] * B[i];
return sum;
}
and with following set of options: -O1 -fopenmp -foffload=nvptx-none
-fno-tree-ccp -fno-tree-dce -fno-tree-fre -fno-tree-vrp -fno-tree-forwprop
-fno-tree-copy-prop -fno-tree-dominator-opts
(The rationale behind these set of options is to disable elimination of dead
code that results after omp_device_lower pass).
which results in following ICE:
during GIMPLE pass: vect
dump file: a-foo.c.182t.vect
foo.c: In function ‘main._omp_fn.1’:
foo.c:13:11: internal compiler error: Segmentation fault
13 | #pragma omp teams distribute parallel for simd reduction(+:sum)
| ^~~
0x244e3e3 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x103d8bf crash_signal
../../gcc/gcc/toplev.cc:322
0x13fe9a4 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3810
0x13fe9a4 note_simd_array_uses
../../gcc/gcc/tree-vectorizer.cc:421
0x14021db execute
../../gcc/gcc/tree-vectorizer.cc:1274
In this case, input to ompdevlow pass is:
[local count: 118111600]:
simduid.12_73 = .GOMP_SIMT_ENTER (simduid.12_71(D), 0B, 0B);
.omp_simt.13_75 = .GOMP_SIMT_ENTER_ALLOC (simduid.12_73);
_76 = .GOMP_SIMD_VF (simduid.12_73);
which is then folded to:
[local count: 118111600]:
simduid.12_73 = simduid.12_71(D);
.omp_simt.13_75 = 0B;
_76 = .GOMP_SIMD_VF (simduid.12_73);
and input to vect pass:
[local count: 118111600]:
simduid.12_73 = simduid.12_71(D);
_76 = .GOMP_SIMD_VF (simduid.12_73);
When worked around the issue in note_simd_array_uses, it similarly fails in
adjust_simduid_builtins at:
data.simduid = DECL_UID (SSA_NAME_VAR (arg));
since arg (simduid.12_73) is an argument to one of the GOMP internal functions
and similarly expects it to be default def.
Thanks,
Prathamesh
[Bug c/118191] missing option to read __float128 from command line argument or string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118191 --- Comment #3 from newbie-02 --- strto**d**128 ... name collision with 'strtod128' for decimal128 types from libdfp?? can't even say if that or something from glibc is called on my system. It works, but I'd like to understand, to be able to tell to others. Can anyone shed some light how to distinguish, where to find and how to activate strtof128? :-) merry X-mas
[Bug c++/118199] [15 regression] -fno-elide-constructors vs no_unique_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 Sam James changed: What|Removed |Added Keywords|needs-bisection | --- Comment #8 from Sam James --- (In reply to Andrew Pinski from comment #4) > I think a libstdc++ change exposed this r15-6273-g689d4abc0b836a
[Bug gcov-profile/118102] profile-use and profile-dir= during IPA pass: profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118102 --- Comment #17 from Sam James --- Yes. I can't promise to spend that long on it, but I will try reproduce it and go from there.
[Bug c++/118199] [15 regression] -fno-elide-constructors vs no_unique_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking Summary|[15 regression] ICE when|[15 regression] |building widelands-1.2.1|-fno-elide-constructors vs |(with |no_unique_address |-fno-elide-constructors)| --- Comment #6 from Andrew Pinski --- /* Likewise, but allow extra temps of trivial type so that gimplify_init_ctor_preeval can materialize subobjects of a CONSTRUCTOR on the rhs of an assignment, as in constexpr-aggr1.C. */ gcc_checking_assert (!TARGET_EXPR_ELIDING_P (*expr_p) || !TREE_ADDRESSABLE (TREE_TYPE (*expr_p)));
[Bug c++/118199] [15 regression] ICE when building widelands-1.2.1 (with -fno-elide-constructors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 --- Comment #5 from Andrew Pinski --- Created attachment 59974 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59974&action=edit Reduced testcase
[Bug c++/118199] [15 regression] -fno-elide-constructors vs no_unique_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #7 from Andrew Pinski --- I am not sure the reduced testcase is a regression but the reduced unincluded testcase is a regression.
[Bug target/118166] simple bit operations for __int128 do not use vector operations/registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118166 --- Comment #3 from Gero --- Created attachment 59973 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59973&action=edit addsub_128
[Bug gcov-profile/118102] profile-use and profile-dir= during IPA pass: profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118102 --- Comment #16 from ganime --- sending private messages to sjames direct mail works? i want clear out some specific commands private over personal message > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118102 > > --- Comment #15 from Sam James --- > Can you give me the exact commands you ran for cmake and so on? Assume I don't > have mariadb cloned and write a small script please? >
[Bug target/118166] simple bit operations for __int128 do not use vector operations/registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118166 --- Comment #4 from Gero --- Changing the register sets is of course a problem. But u/int128 could also be realized in xmm ? - Addition/subtraction can be implemented efficiently (see attachemant). - For multiplications/shl/shr/... this should also be possible ? - Division is a separate function. On other ISAs these problems may not occur and the operations can be implemented better/more efficiently. But you can judge this better than I can. Merry Christmas Gero
[Bug target/115459] [14 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115459
--- Comment #11 from GCC Commits ---
The master branch has been updated by Maciej W. Rozycki :
https://gcc.gnu.org/g:524fedd7f658f9c57e5f230f21cadf406c5d5011
commit r15-6439-g524fedd7f658f9c57e5f230f21cadf406c5d5011
Author: Maciej W. Rozycki
Date: Wed Dec 25 22:23:40 2024 +
Alpha: Fix offset adjustment in unaligned access helpers
Correct the offset adjustment made in the multi-word unaligned access
helpers such that it is actually used by the unaligned load and store
instructions, fixing a bug introduced with commit 1eb356b98df2 ("alpha
gprel optimizations")[1] back in 2001, which replaced address changes
made directly according to the argument of the MEM expression passed
with one made according to an address previously extracted from said MEM
expression. The address is however incorrectly extracted from said MEM
before an adjustment has been made to it for the offset supplied.
This bug is usually covered by the fact that our block move and clear
operations are hardly ever provided with correct block alignment data
and we also usually fail to fetch that information from the MEM supplied
(although PR target/115459 shows it does happen sometimes). Instead the
bit alignment of 8 is usually conservatively used, meaning that a zero
offset is passed to `alpha_expand_unaligned_store_words' and then code
has been written such that neither `alpha_expand_unaligned_load_words'
nor `alpha_expand_unaligned_store_words' cannot ever be called with
nonzero offset from `alpha_expand_block_move'.
The only situation where `alpha_expand_unaligned_store_words' can be
called with nonzero offset is from `alpha_expand_block_clear' with a BWX
target for a misaligned block that has been embedded in a data object of
a higher alignment such that there is a small unaligned prefix our code
decides to handle so as to align further stores.
For instance it happens when a block clear is called for a block of 9
bytes embedded at offset 1 in a structure aligned to a 2-byte word, as
illustrated by the test case included. Now this test case does not work
without the change that comes next applied, because the backend cannot
see the word alignment of the struct and uses the bit alignment of 8
instead.
Should this change be swapped with the next one incorrect code such as:
stb $31,1($16)
lda $3,1($16)
ldq_u $2,8($16)
ldq_u $1,1($16)
mskqh $2,$3,$2
stq_u $2,8($16)
mskql $1,$3,$1
stq_u $1,1($16)
would be produced, where the unadjusted offsets of 1/8 can be seen with
the LDQ_U/STQ_U operations along with byte masks calculated accordingly
rather than the expected offsets of 2/9. As a result the byte at the
offset of 9 fails to get cleared. In these circumstances this would
also show as execution failures with the memclr.c test:
FAIL: gcc.c-torture/execute/memclr.c -O1 execution test
FAIL: gcc.c-torture/execute/memclr.c -Os execution test
-- not at `-O0' though, as the higher alignment cannot be retrieved in
that case, and then not at `-O2' or higher optimization levels either,
because then we choose to open-code this block clear instead:
ldbu $1,0($16)
stw $31,8($16)
stq $1,0($16)
avoiding the bug in `alpha_expand_unaligned_store_words'.
I am leaving the pattern match test case XFAIL-ed here for documentation
purposes and it will be un-XFAIL-ed along with the fix to retrieve the
correct alignment. The run test is of course never expected to fail.
References:
[1]
[Bug target/115459] [14 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115459
--- Comment #12 from GCC Commits ---
The master branch has been updated by Maciej W. Rozycki :
https://gcc.gnu.org/g:e0dae4da4c45e3959b0624551f80283c45a60446
commit r15-6440-ge0dae4da4c45e3959b0624551f80283c45a60446
Author: Maciej W. Rozycki
Date: Wed Dec 25 22:23:40 2024 +
Alpha: Also use tree information to get base block alignment
We hardly ever emit code using machine instructions for aligned memory
accesses for block move and clear operation and the reason for this
appears to be that suboptimal alignment is often passed by the caller
and then we only try to find a better alignment by checking pseudo
register pointer alignment information, and from observation it's most
often only set for stack frame references.
This code originates from before Tree SSA days and we can do better
nowadays, by looking up the original tree node associated with a MEM
RTL, so implement this approach, factoring out repeating code from
`alpha_expand_block_move' and `alpha_expand_block_clear' to a new
function.
In some cases howewer tree information is not available while pointer
alignment is, such as with the case concerned with PR target/115459,
where we have:
(gdb) pr orig_src
(mem:BLK (plus:DI (reg/f:DI 65 virtual-stack-vars [ lock.206_2 ])
(const_int 8368 [0x20b0])) [8 S18 A8])
(gdb) pr orig_dst
(mem/j/c:BLK (plus:DI (reg/f:DI 65 virtual-stack-vars [ lock.206_2 ])
(const_int 8208 [0x2010])) [8 MEM[(struct
gnat__debug_pools__print_info_stdout__internal__L_18__B1182b__S1183b___PAD
*)_339].F[1 ...]{lb: 1 sz: 1}+0 S18 A128])
(gdb)
showing no tree information and the alignment of 8 only for `orig_src',
while indeed REGNO_POINTER_ALIGN returns 128 for pseudo 65. So retain
the old approach and return the largest alignment determined and its
associated offset.
Add test cases accordingly and remove XFAILs from memclr-a2-o1-c9-ptr.c
now that it does get aligned code produced now.
gcc/
* config/alpha/alpha.cc
(alpha_get_mem_rtx_alignment_and_offset): New function.
(alpha_expand_block_move, alpha_expand_block_clear): Use it for
alignment retrieval.
gcc/testsuite/
* gcc.target/alpha/memclr-a2-o1-c9-ptr.c: Remove XFAILs.
* gcc.target/alpha/memcpy-di-aligned.c: New file.
* gcc.target/alpha/memcpy-di-unaligned.c: New file.
* gcc.target/alpha/memcpy-di-unaligned-dst.c: New file.
* gcc.target/alpha/memcpy-di-unaligned-src.c: New file.
[Bug target/115459] [14 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115459
--- Comment #10 from GCC Commits ---
The master branch has been updated by Maciej W. Rozycki :
https://gcc.gnu.org/g:2984a3fac3d6b98e2cd6d7ee1c701159be86af78
commit r15-6438-g2984a3fac3d6b98e2cd6d7ee1c701159be86af78
Author: Maciej W. Rozycki
Date: Wed Dec 25 22:23:40 2024 +
Alpha: Adjust MEM alignment for block clear [PR115459]
By inference it appears to me that the same fix for PR target/115459
needs to be applied to the block clear operation that has been done for
block move, as implemented by commit ccfe71518039 ("[alpha] adjust MEM
alignment for block move [PR115459]").
gcc/
PR target/115459
* config/alpha/alpha.cc (alpha_expand_block_clear): Adjust MEM
to match inferred alignment.
[Bug tree-optimization/117001] O3 auto tree loop vectorization produces incorrect output on armv8.2-a+sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117001 Sam James changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED --- Comment #7 from Sam James --- With tip of 12 (or 13/14/15), I can't seem to reproduce it with qemu-user. But I also can't with 11.5.0 either with this setup.
[Bug c++/118202] [12/13/14/15 regression] ICE segmentation fault when instantiating a derived template class with default template argument and special overloaded ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118202 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-12-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/117001] O3 auto tree loop vectorization produces incorrect output on armv8.2-a+sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117001 Sam James changed: What|Removed |Added Last reconfirmed|2024-10-07 00:00:00 |2024-12-26 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug c++/118202] [12/13/14/15 regression] ICE segmentation fault when instantiating a derived template class with default template argument and special overloaded ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118202 --- Comment #3 from Andrew Pinski --- At first I thought it was related to PR 86439 but this ICEs also in GCC 11 while that added perform_dguide_overload_resolution for GCC 12. So it must be some other change that happened beforehand.
[Bug c++/118199] [15 regression] -fno-elide-constructors vs no_unique_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 --- Comment #9 from Sam James --- Created attachment 59975 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59975&action=edit cvise-reduced.ii Attached cvise output as I hadn't cancelled it earlier, pinskia's is smaller though (just figured I'd post so the CPU time hadn't gone to waste).
[Bug c++/118199] [15 regression] ICE when building widelands-1.2.1 (with -fno-elide-constructors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 --- Comment #2 from Andrew Pinski --- Reducing ...
[Bug c++/118199] [15 regression] ICE when building widelands-1.2.1 (with -fno-elide-constructors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 --- Comment #3 from Andrew Pinski --- Created attachment 59972 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59972&action=edit Reduced unincluded testcase
[Bug c++/118199] [15 regression] ICE when building widelands-1.2.1 (with -fno-elide-constructors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118199 --- Comment #4 from Andrew Pinski --- I think a libstdc++ change exposed this
