This is the mail archive of the gcc@gcc.gnu.org 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]

Problems with genautomata


I'm sitting here trying to figure out why the automaton generator is failing
miserably for hppa64-hp-hpux11.00 native in the mainline sources.  Every
indication I'm getting is that we have a bug in genautomata.c that just
happens to expose itself on hppa64-hp-hpux11.00.


In a nutshell we're calling make_numeric_value with a negative number which
causes it to abort.

To understand what's happening, we have to first look at your datastructures,
most notably:

/* The following structures represent parsed reservation strings.  */
enum regexp_mode
{
  rm_unit,
  rm_reserv,
  rm_nothing,
  rm_sequence,
  rm_repeat,
  rm_allof,
  rm_oneof
}; 
/* Cpu unit in reservation.  */
struct unit_regexp
{
  char *name;
  unit_decl_t unit_decl;
};

[ ... ]
/* Representation of reservations separated by '|' (see file
   rtl.def).  */
struct oneof_regexp
{
  int regexps_num;
  regexp_t regexps [1];
};

/* Representation of a reservation string.  */
struct regexp
{
  /* What node in the union? */
  enum regexp_mode mode;
  pos_t pos;
  union
  {
    struct unit_regexp unit;
    struct reserv_regexp reserv;
    struct nothing_regexp nothing;
    struct sequence_regexp sequence;
    struct repeat_regexp repeat;
    struct allof_regexp allof;
    struct oneof_regexp oneof;
  } regexp;
};


It appears that the mode in the toplevel regexp structure determines how we
interpret the bits found in the regexp.regexp union.  Correct?


So if the mode is rm_unit, then we should only be able to access
regexp.regexp.unit, not regex.regexp.oneof?  Correct?


So build a debuggable genattrtab for i686-pc-linux-gnu.

Put a breakpoint before this code within make_insn_alts_attr:

          XVECEXP (condexp, 0, 2 * insn_num + 1)
            = make_numeric_value (decl->decl.insn_reserv.transformed_regexp
                                  ->regexp.oneof.regexps_num);

Make the breakpoint conditional on decl->decl.insn_reserv.transformed_regexp 
== rm_unit

Then run genattrtab using the attached machine description.

Your breakpoint should trigger and you'll clearly see that even though the
mode is rm_unit, we access the oneof member of the union, this can't be good.

Anyway, accessing ...->regexp->oneof->regexps_num when mode is rm_unit
effectively uses the *address* of the unit's name as an integer.  On most
native targets this doesn't result in make_numeric_value aborting as most
addresses are positive.

However, on PA64, the address happens to have the high bit set, thus if
we interpret it as an integer, it's value is negative which in turn causes
make_numeric_value to abort.


This (of course) keeps the PA64 from bootstrapping and needs to be resolved.

I would strongly recommend that when you have a selector to access different
fields in a union that you use checking macros like we do for trees/rtl to
ensure that you only access the field that is appropriate for the given mode.
Clearly if ENABLE_CHECKING is not defined, then you wouldn't do the extra
sanity checks.

jeff







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