public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Possible code to remove DECL_NONSHAREABLE?
@ 2020-11-27 12:47 Matthew Malcomson
  2020-11-30 17:58 ` Jeff Law
  0 siblings, 1 reply; 2+ messages in thread
From: Matthew Malcomson @ 2020-11-27 12:47 UTC (permalink / raw)
  To: gcc; +Cc: jakub, matz, Richard Biener

Hi there,

I was just looking through the history of how some code came about, and 
get the impression that DECL_NONSHAREABLE was meant to be removed.

It seems like it was added to solve PR49103, with the idea that it could 
be removed once a more robust solution was added.

Original comment and email mentioning the idea of this not being the 
final solution:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103#c12
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-06/msg00480.html

Email mentioning the idea to remove it later
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-06/msg01025.html


I seems that the more invasive solution was eventually added.
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg00253.html
Commit 47598145be, From-SVN: r181172


Does that mean that the original DECL_NONSHAREABLE hack can be removed?
(It seems like the extra bit in the tree structure can't since it's now 
used for something else, but I suspect we can still remove the code 
using it for this DECL_NONSHAREABLE purpose).

I've ran a quick test on an AArch64 native configuration I had handy and 
that fortran test still passed, but don't have the time to look into it 
fully (especially given how I'm not familiar with this area).

Cheers,
Matthew

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Possible code to remove DECL_NONSHAREABLE?
  2020-11-27 12:47 Possible code to remove DECL_NONSHAREABLE? Matthew Malcomson
@ 2020-11-30 17:58 ` Jeff Law
  0 siblings, 0 replies; 2+ messages in thread
From: Jeff Law @ 2020-11-30 17:58 UTC (permalink / raw)
  To: Matthew Malcomson, gcc; +Cc: jakub



On 11/27/20 5:47 AM, Matthew Malcomson via Gcc wrote:
> Hi there,
>
> I was just looking through the history of how some code came about,
> and get the impression that DECL_NONSHAREABLE was meant to be removed.
>
> It seems like it was added to solve PR49103, with the idea that it
> could be removed once a more robust solution was added.
>
> Original comment and email mentioning the idea of this not being the
> final solution:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103#c12
> https://gcc.gnu.org/legacy-ml/gcc-patches/2011-06/msg00480.html
>
> Email mentioning the idea to remove it later
> https://gcc.gnu.org/legacy-ml/gcc-patches/2011-06/msg01025.html
>
>
> I seems that the more invasive solution was eventually added.
> https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg00253.html
> Commit 47598145be, From-SVN: r181172
>
>
> Does that mean that the original DECL_NONSHAREABLE hack can be removed?
> (It seems like the extra bit in the tree structure can't since it's
> now used for something else, but I suspect we can still remove the
> code using it for this DECL_NONSHAREABLE purpose).
>
> I've ran a quick test on an AArch64 native configuration I had handy
> and that fortran test still passed, but don't have the time to look
> into it fully (especially given how I'm not familiar with this area).
Seems like a gcc-12 thing to me.

jeff


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-11-30 17:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-27 12:47 Possible code to remove DECL_NONSHAREABLE? Matthew Malcomson
2020-11-30 17:58 ` Jeff Law

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).