This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ATTRIBUTE_NORETURN on sets_cc0_p
- To: egcs at cygnus dot com, mark at markmitchell dot com
- Subject: Re: ATTRIBUTE_NORETURN on sets_cc0_p
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Thu, 15 Oct 1998 00:08:52 -0400 (EDT)
> From: Mark Mitchell <mark@markmitchell.com>
>
> On x86-linux-gnu (which defines HAVE_cc0), I'm seeing:
>
> ../../gcc/jump.c: In function `sets_cc0_p':
> ../../gcc/jump.c:3335: warning: function declared `noreturn' has a
> `return' statement
>
> That's not good; this function does return and we don't want the
> compiler assuming it doesn't. That could be very dangerous.
>
> I see that rtl.h has:
>
> extern int sets_cc0_p PROTO ((rtx))
> #ifndef HAVE_cc0
> ATTRIBUTE_NORETURN
> #endif
> ;
>
> Perhaps HAVE_cc0 is not yet be set at that point?
> --
> Mark Mitchell mark@markmitchell.com
Right. HAVE_cc0 is defined in insn-config.h which appears after
rtl.h in jump.c. We have to move insn-config.h above rtl.h, but in
*every* file, not just jump.c. The harmful scenario is other files
which incorrectly assume sets_cc0_p() doesn't return, (and don't even
complain about it.)
The idea I have is to make genconfig put something like this in
insn-config.h
> #ifdef RTX_CODE
> #error "insn-config.h must be included before rtl.h."
> #endif
and then see what breaks. :-) That'll show us all the spots, and
(importantly) leaving it there will ensure this header file ordering bug
doesn't creep back in. I'll try to crank out a patch tomorrow.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Icon CMT Corp.