[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Bug 109753 depends on bug 115403, which changed state. Bug 115403 Summary: [15 Regression] highway build from git fails with 'target specific option mismatch' (templates) since r15-902-geff00046409a72 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115403 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #22 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e397f8524a7982004eb616217477434ce350e80f commit r15-2332-ge397f8524a7982004eb616217477434ce350e80f Author: Jason Merrill Date: Thu Jul 25 17:36:09 2024 -0400 c++: #pragma target and deferred instantiation [PR115403] My patch for 109753 applies the current #pragma target/optimize to a function when we compile it, which was a problem for a template instantiation deferred until EOF, where different #pragmas are active. So let's only do this for artificial functions. PR c++/115403 PR c++/109753 gcc/cp/ChangeLog: * decl.cc (start_preparsed_function): Only call decl_attributes for artificial functions. gcc/testsuite/ChangeLog: * g++.dg/ext/pragma-target1.C: New test.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Richard Biener changed: What|Removed |Added Depends on||115403 --- Comment #21 from Richard Biener --- PR115403 needs to be addressed before backporting? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115403 [Bug 115403] [15 Regression] highway build from git fails with 'target specific option mismatch' (templates) since r15-902-geff00046409a72
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Andrew Pinski changed: What|Removed |Added CC||malat at debian dot org --- Comment #20 from Andrew Pinski --- *** Bug 115556 has been marked as a duplicate of this bug. ***
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Jason Merrill changed: What|Removed |Added Summary|[13/14/15 Regression] |[13/14 Regression] pragma |pragma GCC target causes|GCC target causes |std::vector not to compile |std::vector not to compile |(always_inline on |(always_inline on |constructor)|constructor) --- Comment #19 from Jason Merrill --- Fixed for 15 so far.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #15 from Jason Merrill --- Created attachment 57706 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57706&action=edit one approach I tried just making implicit functions respect #pragma target, but that regresses pr105306 due to seeming internal confusion over whether -Ofast or #pragma optimize apply to the implicit ~C. I haven't tracked that down yet.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #14 from Jan Hubicka --- > I think the issue might be that whoever is creating > __static_initialization_and_destruction_0 fails to honor the active > target pragma. Which means back to my suggestion to have multiple ones > when different target options are on the individual CTORs and any of them > have always-inline (with always-inline we can't rely on an out-of-line copy > to exist). If I remember right, __static_initialization_and_destruction_0 call all static constructors of priority 0. So it has really no active pragma since it may change across translation unit. We also have similar code in IPA where we collect constructors across whole program. Motivation was to get them inlined and obtain better code locality. Back then Firefox had iostram constructor in every object file and those ctors made whole text segment to be loaded on demand during startup. Probably correct solution would be to group construtor into groups by compatible optimization/target pgramas in the inliner's definition. A quick hack would be to generate wrapper calls which will "eat" the always inline...
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #13 from Richard Biener --- I think the issue might be that whoever is creating __static_initialization_and_destruction_0 fails to honor the active target pragma. Which means back to my suggestion to have multiple ones when different target options are on the individual CTORs and any of them have always-inline (with always-inline we can't rely on an out-of-line copy to exist). Yes, for libstdc++ purposes which seems to get more and more "always-inline" it would be good to have a different attribute that would only cause to disregard inline limits and not have "always-inline" semantics. [[inline_without_limits]] or [[inline_no_limits]]
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #12 from Jan Hubicka --- I think this is a problem with two meanings of always_inline. One is "it must be inlined or otherwise we will not be able to generate code" other is "disregard inline limits". I guess practical solution here would be to ingore always inline for functions called from static construction wrappers (since they only optimize around array of function pointers). Question is how to communicate this down from FE to ipa-inline...
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Martin Jambor changed: What|Removed |Added Keywords|needs-bisection | --- Comment #11 from Martin Jambor --- It seems there is nothing to bisect any more, please re-add the keyword if I am wrong.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Richard Biener changed: What|Removed |Added Target Milestone|13.2|13.3 --- Comment #10 from Richard Biener --- GCC 13.2 is being released, retargeting bugs to GCC 13.3.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #9 from Richard Biener ---
(In reply to Xi Ruoyao from comment #8)
> In local-fnsummary2:
>
> __attribute__((always_inline, target ("avx2")))
> void aa::aa (struct aa * const this)
> {
>[local count: 1073741824]:
> return;
>
> }
>
> this seems correct. But:
>
> void __static_initialization_and_destruction_0 ()
> {
>:
> aa::aa (&_M_impl);
> return;
>
> }
>
> Note that __static_initialization_and_destruction_0 is not attributed with
> avx2.
I think that's correct. Maybe we need multiple CTOR/DTOR functions
in such case.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #8 from Xi Ruoyao ---
In local-fnsummary2:
__attribute__((always_inline, target ("avx2")))
void aa::aa (struct aa * const this)
{
[local count: 1073741824]:
return;
}
this seems correct. But:
void __static_initialization_and_destruction_0 ()
{
:
aa::aa (&_M_impl);
return;
}
Note that __static_initialization_and_destruction_0 is not attributed with
avx2.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Xi Ruoyao changed: What|Removed |Added CC||gcc.gnu.org at aryanc403 dot com --- Comment #7 from Xi Ruoyao --- *** Bug 110675 has been marked as a duplicate of this bug. ***
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Richard Biener changed: What|Removed |Added Component|target |c++ CC||rguenth at gcc dot gnu.org Priority|P3 |P2 --- Comment #6 from Richard Biener --- That would be a C++ frontend issue then, no? Maybe it's also only some of the aliases? And the actual issue would be latent then.
