RFD: HAVE_* pattern flags

Joern Rennecke joern.rennecke@embecosm.com
Wed Oct 17 00:32:00 GMT 2012


Sorry for the recent loop-doloop.c breakage.  I did test it, but I didn't take
a day to re-test it the two hundred configurations in config-list.mk and
sift out the pre-broken ports; as i had only changed 'target-independent'
code since the last full test, I only tested in on i686-pc-linux-gnu.
Which unfortunately did not cover the piece of code that was affected
by the merge failure.

I remember at some point we said that we wanted less #ifdef and more if ()
tests, so that we get more uniform syntax / warning coverage when testing
one target.  One big blind spot that's left there are the
HAVE_xxx flags for instruction patterns, like HAVE_doloop_end
or HAVE_nonlocal_goto .  So, three questions:

- Is there consensus that we would like to change this?

- What would a good naming scheme be?
   - Change the semantics of the HAVE_pattern macros for officially named
     patterns so that they are defined as 0 when the pattern is not provided?
     That choice would actually force people to change #ifdef into if (),
     without the possibility of #if, where targets can have non-constant
     pattern predicates.
   - Have_pattern?
   - have_pattern?
   - any other preferences?

- how do we get the list of 'official' named patterns?
   - We could have a header file that is maintained by hand, with a string
     of #ifdef / #define / #endif .
   - Or we could build the list automatically, something like grep for
     @code{..} in md.texi, and check if at least one target defines a
     pattern with that name.
   - introduce a special markup for named patterns in md.texi, and  
grep for that.
   - have some markup in the compiler source files that check the value
   - a special case of the previous option, mixed with a special choice for the
     previous (naming) question: using a naming scheme that can be picked out
     by the generator file, e.g. HAVE_named_pattern_nonlocal_goto_receiver.



More information about the Gcc mailing list