This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR c/14411
On Monday 22 November 2004 21:53, Zack Weinberg wrote:
> Alexey Neyman <alex.neyman@auriga.ru> writes:
>
> > This patch allows one to mark a function as setjmp-like/longjmp-like
> > with attributes setjmp/longjmp, respectively.
> >
> > Comments from jsm@polyomino.org.uk (oddly enough, captured in PR
> > c/18180) addressed, except that I did not rename the attribute to
> > "returns_twice". Having the name __attribute__((setjmp)) is
> > consistent with other attributes named after a common function, e.g.
> > __attribute__((malloc)).
>
> I think I'm with Joseph on this - it should be "returns_twice" because
> then it makes sense to apply the attribute to other functions with the
> same property, that don't necessarily have setjmp's other behavior;
> vfork() is an example.
But why do we have __attribute__((malloc)) instead of
__attribute__((returns_nonaliased_pointer)) then?
Not that I have a strong bias towards __attribute__((setjmp)), but I
think, we should remain consistent...
>
> > if (DECL_IS_MALLOC (exp))
> > flags |= ECF_MALLOC;
> >
> > + /* The function exp may have the `setjmp' attribute. */
> > + if (DECL_P (exp) && DECL_IS_SETJMP (exp))
> > + flags |= ECF_RETURNS_TWICE;
> > +
> > + /* The function exp may have the `longjmp' attribute. */
> > + if (DECL_P (exp) && DECL_IS_LONGJMP (exp))
> > + flags |= ECF_LONGJMP;
>
> Given the DECL_IS_MALLOC check immediately above, the conditionals you
> have added do not need DECL_P.
Thank you, fixed.
> > + @item longjmp
> > + @cindex @code{longjmp} attribute
> > + The @code{longjmp} attribute tells the compiler that a function is a
> > + counterpart of the respective @code{setjmp}-like function.
>
> This isn't a good description of the attribute. I don't know why this
> is different from noreturn, so I can't suggest a better description.
Well, the only place it is used is the setting of the calls_longjmp
bitfield in the 'struct function'. That field, however, is only
referenced by the gcc/config/i386/sysv3.h, and this header file
appears unused (is not listed for any configuration in config.gcc).
Perhaps, all these should be removed? If so, should I address this
issue with this patch?
> The patch otherwise looks good. Do you have a copyright assignment on
> file with the FSF?
In progress.
Regards,
Alexey.
--
Heavily laden, it rocks and weaves, but does it turn over?
-- Pkunks, SC2