This is the mail archive of the 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]

Re: patch to fix tentative struct type collision

> When you say "fix," you are making an assumption.  You are assuming
> that the type system in the middle-end is the type system that you
> want in the frontend.  Although the frontend type system and the
> middle-end type system look very similar, since they use the same
> structures, they are different by definition: different frontends
> require different type systems.  The middle-end type system is
> currently, unfortunately, undefined.  The use of the word "fix" here
> is incorrect in the absence of a defined middle-end type system.  When
> you say "fix," I read "change."  And it makes me nervous to change
> working code, in the absence of a specification that we want to
> follow, in the absence of a test case, for the support of a relatively
> obscure language, when there are already straightforward working
> approaches which are used by existing frontends.

I too feel that we need to better define (and possibly change) the
middle-end type system, but my reasoning has nothing to do with
frontends or language issues.

I see THREE type systems.  The easiest to define is that used by debug
output and hence what we have in VAR_DECL and other decls.  Those contain
enough information about naming and respresentation to enable a debugger
to display all relevant information about a variable of that type.

The second type system is used by the front end and is basically a superset
of that type system, making some additional distinctions that may be
required for language purposes.  In some cases the front end uses an
entirely different representation for entities (e.g., Ada) so its usage
of the GCC type system is identicatl to that used for debug output.  In
others (e.g., C++), the type system used is an extension of the debug
type system.

However, the middle end (and here I mean in GIMPLE) has a different
purpose for a type system.  There, it need not distinguish between two
types if they can have no effect on code generation.  Outside of an
ADDR_EXPR, two integral types are identical if the have the same mode,
signedness, precision, and bounds, for example.  (If the address is
taken, we also have to worry about alias set.)  Currently, we let the
front end decide if two types are the same in the middle-end, but I think
that's wrong: as I said above, the relevant test should be if the types
will cause the same RTL to be generated and have no differences that
are relevant to the optimizers (e.g., TYPE_MIN_VALUE). 

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