This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR c/14411

On Monday 22 November 2004 21:53, Zack Weinberg wrote:
> Alexey Neyman <> writes:
> > This patch allows one to mark a function as setjmp-like/longjmp-like 
> > with attributes setjmp/longjmp, respectively.
> >
> > Comments from (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.


Heavily laden, it rocks and weaves, but does it turn over?
                        -- Pkunks, SC2

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]