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 <eg...@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
