* Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 @ 2023-12-16 20:15 Andrew Pinski 2023-12-17 16:26 ` Florian Weimer 2023-12-17 21:20 ` Eric Gallager 0 siblings, 2 replies; 7+ messages in thread From: Andrew Pinski @ 2023-12-16 20:15 UTC (permalink / raw) To: GCC Mailing List -fgnu-tm support has not been improved since GCC 5 or earlier. It is not even supported with LTO. Does it make sense to deprecate the support for GCC 14 and remove it in GCC 15? Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 2023-12-16 20:15 Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 Andrew Pinski @ 2023-12-17 16:26 ` Florian Weimer 2023-12-17 18:05 ` Andrew Pinski 2023-12-17 21:20 ` Eric Gallager 1 sibling, 1 reply; 7+ messages in thread From: Florian Weimer @ 2023-12-17 16:26 UTC (permalink / raw) To: Andrew Pinski via Gcc; +Cc: Andrew Pinski * Andrew Pinski via Gcc: > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > not even supported with LTO. Does it make sense to deprecate the > support for GCC 14 and remove it in GCC 15? Is this the stuff around libitm and that adds _ITM_registerTMCloneTable and _ITM_deregisterTMCloneTable symbol references to *all* binaries (whether they use transactional memory or not)? Thanks, Florian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 2023-12-17 16:26 ` Florian Weimer @ 2023-12-17 18:05 ` Andrew Pinski 0 siblings, 0 replies; 7+ messages in thread From: Andrew Pinski @ 2023-12-17 18:05 UTC (permalink / raw) To: Florian Weimer; +Cc: Andrew Pinski via Gcc On Sun, Dec 17, 2023 at 8:26 AM Florian Weimer <fweimer@redhat.com> wrote: > > * Andrew Pinski via Gcc: > > > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > > not even supported with LTO. Does it make sense to deprecate the > > support for GCC 14 and remove it in GCC 15? > > Is this the stuff around libitm and that adds _ITM_registerTMCloneTable > and _ITM_deregisterTMCloneTable symbol references to *all* binaries > (whether they use transactional memory or not)? Yes. and the front-end support for it. Thanks, Andrew > > Thanks, > Florian > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 2023-12-16 20:15 Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 Andrew Pinski 2023-12-17 16:26 ` Florian Weimer @ 2023-12-17 21:20 ` Eric Gallager 2023-12-18 1:33 ` Andrew Pinski 1 sibling, 1 reply; 7+ messages in thread From: Eric Gallager @ 2023-12-17 21:20 UTC (permalink / raw) To: Andrew Pinski; +Cc: GCC Mailing List On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc <gcc@gcc.gnu.org> wrote: > > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > not even supported with LTO. Does it make sense to deprecate the > support for GCC 14 and remove it in GCC 15? > > Thanks, > Andrew Pinski Personally, since GCC is in stage 3 now, I would push that schedule back a release and move deprecation to GCC 15, and then only remove it for GCC 16 if no one objects, but then again I don't actually use -fgnu-tm myself, so I wouldn't be too upset if the faster schedule is chosen instead. Eric Gallager ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 2023-12-17 21:20 ` Eric Gallager @ 2023-12-18 1:33 ` Andrew Pinski 2023-12-18 8:01 ` Richard Biener 0 siblings, 1 reply; 7+ messages in thread From: Andrew Pinski @ 2023-12-18 1:33 UTC (permalink / raw) To: Eric Gallager; +Cc: GCC Mailing List On Sun, Dec 17, 2023 at 1:20 PM Eric Gallager <egall@gwmail.gwu.edu> wrote: > > On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc <gcc@gcc.gnu.org> wrote: > > > > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > > not even supported with LTO. Does it make sense to deprecate the > > support for GCC 14 and remove it in GCC 15? > > > > Thanks, > > Andrew Pinski > > Personally, since GCC is in stage 3 now, I would push that schedule > back a release and move deprecation to GCC 15, and then only remove it > for GCC 16 if no one objects, but then again I don't actually use > -fgnu-tm myself, so I wouldn't be too upset if the faster schedule is > chosen instead. Considering -fgnu-tm has been broken for LTO ever since LTO was introduced, and broken with -fsanitize=undefined and broken with many code that might use internal functions (known since 2015), I suspect nobody is using this option in production nor even trying it out. If this was stage1, I might even just recommend removing the support. But deprecating it during stage 3 seems like a fair compromise. > Eric Gallager ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 2023-12-18 1:33 ` Andrew Pinski @ 2023-12-18 8:01 ` Richard Biener 2023-12-20 16:40 ` Jason Merrill 0 siblings, 1 reply; 7+ messages in thread From: Richard Biener @ 2023-12-18 8:01 UTC (permalink / raw) To: Andrew Pinski; +Cc: Eric Gallager, GCC Mailing List On Mon, Dec 18, 2023 at 2:35 AM Andrew Pinski via Gcc <gcc@gcc.gnu.org> wrote: > > On Sun, Dec 17, 2023 at 1:20 PM Eric Gallager <egall@gwmail.gwu.edu> wrote: > > > > On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc <gcc@gcc.gnu.org> wrote: > > > > > > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > > > not even supported with LTO. Does it make sense to deprecate the > > > support for GCC 14 and remove it in GCC 15? > > > > > > Thanks, > > > Andrew Pinski > > > > Personally, since GCC is in stage 3 now, I would push that schedule > > back a release and move deprecation to GCC 15, and then only remove it > > for GCC 16 if no one objects, but then again I don't actually use > > -fgnu-tm myself, so I wouldn't be too upset if the faster schedule is > > chosen instead. > > Considering -fgnu-tm has been broken for LTO ever since LTO was > introduced, and broken with -fsanitize=undefined and broken with many > code that might use internal functions (known since 2015), I suspect > nobody is using this option in production nor even trying it out. If > this was stage1, I might even just recommend removing the support. But > deprecating it during stage 3 seems like a fair compromise. Btw, I'm OK with deprecating it for GCC 14. Can you please propose a patch for changes.html and add a diagnostic message when -fgnu-tm is used (disabled with -Wno-deprecated)? Thanks, Richard. > > Eric Gallager ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 2023-12-18 8:01 ` Richard Biener @ 2023-12-20 16:40 ` Jason Merrill 0 siblings, 0 replies; 7+ messages in thread From: Jason Merrill @ 2023-12-20 16:40 UTC (permalink / raw) To: Richard Biener; +Cc: Andrew Pinski, Eric Gallager, GCC Mailing List [-- Attachment #1: Type: text/plain, Size: 1986 bytes --] On Mon, Dec 18, 2023 at 3:04 AM Richard Biener via Gcc <gcc@gcc.gnu.org> wrote: > On Mon, Dec 18, 2023 at 2:35 AM Andrew Pinski via Gcc <gcc@gcc.gnu.org> > wrote: > > > > On Sun, Dec 17, 2023 at 1:20 PM Eric Gallager <egall@gwmail.gwu.edu> > wrote: > > > > > > On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc <gcc@gcc.gnu.org> > wrote: > > > > > > > > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > > > > not even supported with LTO. Does it make sense to deprecate the > > > > support for GCC 14 and remove it in GCC 15? > > > > > > > > Thanks, > > > > Andrew Pinski > > > > > > Personally, since GCC is in stage 3 now, I would push that schedule > > > back a release and move deprecation to GCC 15, and then only remove it > > > for GCC 16 if no one objects, but then again I don't actually use > > > -fgnu-tm myself, so I wouldn't be too upset if the faster schedule is > > > chosen instead. > > > > Considering -fgnu-tm has been broken for LTO ever since LTO was > > introduced, and broken with -fsanitize=undefined and broken with many > > code that might use internal functions (known since 2015), I suspect > > nobody is using this option in production nor even trying it out. If > > this was stage1, I might even just recommend removing the support. But > > deprecating it during stage 3 seems like a fair compromise. > > Btw, I'm OK with deprecating it for GCC 14. Can you please propose a > patch for changes.html and add a diagnostic message when -fgnu-tm is used > (disabled with -Wno-deprecated)? > Deprecation makes sense to me. But keep in mind that transactional memory is still the subject of research and standardization efforts, though the current proposal (wg21.link/n4923) is significantly simpler than the earlier TS that GCC implemented. I don't know how much of the current implementation would carry over, but I'd be cautious about tearing everything out just yet. Jason ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-12-20 16:41 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-12-16 20:15 Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15 Andrew Pinski 2023-12-17 16:26 ` Florian Weimer 2023-12-17 18:05 ` Andrew Pinski 2023-12-17 21:20 ` Eric Gallager 2023-12-18 1:33 ` Andrew Pinski 2023-12-18 8:01 ` Richard Biener 2023-12-20 16:40 ` Jason Merrill
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).