This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Problems with genautomata
- From: law at redhat dot com
- To: vmakarov at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 19 Jun 2002 11:25:05 -0600
- Subject: Problems with genautomata
- Reply-to: law at redhat dot com
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