This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC]: patch to detect invalid and missing ATTRIBUTE const/pure
- From: Dan Nicolaescu <dann at godzilla dot ICS dot UCI dot EDU>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, john at feith dot com, gcc-patches at gcc dot gnu dot org, jh at suse dot cz, mark at codesourcery dot com, rth at redhat dot com
- Date: Fri, 22 Mar 2002 09:20:49 -0800
- Subject: Re: [RFC]: patch to detect invalid and missing ATTRIBUTE const/pure
- References: <200203221503.KAA05140@caip.rutgers.edu><20020322102752.P1213@devserv.devel.redhat.com>
Jakub Jelinek <jakub@redhat.com> writes:
> On Fri, Mar 22, 2002 at 10:03:27AM -0500, Kaveh R. Ghazi wrote:
> > > From: John Wehle <john@feith.com>
> > >
> > > With your change mark_constant_function will attempt to mark
> > > non-static functions which can cause problems due to potentially
> > > differing implementations of a routine present in a shared library.
> > > -- John
> >
> > I don't quite understand how that arises. Here's my understanding:
> >
> > Supposing mark_constant_function is examining an extern function foo,
> > let's say it decides to mark foo as pure. That marking only takes
> > effect for the rest of that module since the extern prototype of foo()
> > seen by other files still doesn't have the attribute automatically
> > added to it.
> >
> > Now any calls to foo() inside the original module would resovle to the
> > definition inside the file, regardless of whether we eventually link
> > with a shared lib having another copy of foo, right?
>
> Only if foo is static or MODULE_LOCAL_P. Otherwise anyone can interpose
> a different version of foo which is not pure.
How about functions declared inline (and extern inline) ?
Shouldn't be safe to be marked pure too? (in case the inlining logic
decides not to inline them).