Re: [tree-ssa] gimp vs expand_end_case_type

[law at redhat dot com]

In message <20030903075414.GA6198@redhat.com>, Richard Henderson writes:
 >The following cures a stage2 miscompile of alpha on the branch.
 >
 >I suppose the problem started manefesting itself with the bits
 >that remove unnecessary casts from the instruction stream, either
 >directly during gimplification or later during dominance opts.
 >
 >The problem is, the cast here isn't completely unnecessary.  
 >The exact type of the expression Means Things to the code that
 >expands switch statements.  Arguably, this is wrong, and we 
 >should store this type somewhere else. 
 >
 >Alternatively, we could have a langhook that indicates whether
 >
 >  (1) type values are truely constrained by their min/max,
 >  (2) an enumeration type is truely constrainted to be one
 >      of the values listed.
 >
 >For C, both of these statements are false.  For other languages,
 >one or both may be true.  Having this langhook would mean that
 >C would not have to be so concerned about preserving the cast 
 >from "enum X" to "unsigned int".
 >
 >For now, this at least lets me get through make compare...
 >
 >
 >r~
 >
 >
 >        * gimplify.c (gimplify_switch_expr): Leave the outermost cast
 >        as part of the switch condition.
 >        * gcc.c-torture/execute/20030903-1.c: New.
FWIW, I'm not 100% convinced that the code to detect "useless" type
conversions is truly safe.  While I think the rules I put forth for
ignoring certain type casts make logical sense, the typing system in
the front-ends and expanders isn't something I know all that well.

Anyway, just something to keep in mind if you run into more of these
kinds of problems in the future.

jeff