This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for PR 37418
On Sun, 14 Sep 2008, Paolo Bonzini wrote:
> Joseph S. Myers wrote:
> > This patch fixes (or at least works around) PR 37418, an ICE involving
> > taking addresses of noreturn functions failing subsequent GIMPLE
> > validity checks.
> >
> > The underlying problem is that the qualifiers GCC uses to represent
> > noreturn attributes
>
> [snip]
>
> Maybe it is the opportunity to deprecate using qualifiers to represent
> const and noreturn function, leaving the attributes as the only possibility?
This is a matter of internal representation, not how people write their
programs. Both ways of expressing a noreturn function in the source code
- with an attribute or with a qualifier - end up getting represented the
same way in the internal representation. If you change the representation
away from the readonly and volatile bits, you need to find everywhere
referring to those bits and update it to refer to something else if it
applies to functions - and also update it if it handles both functions and
non-functions. There are a lot of references to those bits to check.
As I said in my message, I think there should be separate accessor macros
for the const and noreturn properties whether or not you use the same
underlying bits. But there are still lots of uses of the four existing
macros (TREE_READONLY, TREE_THIS_VOLATILE, TYPE_READONLY, TYPE_VOLATILE) -
the first two on both decls and types, the last two on types only - to
check, plus references to TYPE_QUALS; every case needs considering for
whether both functions and non-functions, only functions, or only
non-functions may appear. As I said, the existing low-level macros would
then stop being used by front-end code in favour of macros particular to
more specific types of arguments.
Deprecating the possibility of using qualifiers in source code to add
these attributes would be of no significant help in sorting out the
internal representation.
--
Joseph S. Myers
joseph@codesourcery.com