[Bug c/52283] "error: case label does not reduce to an integer constant" for constant folded cast expr

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-02-16 20:10:34 UTC ---
On Thu, 16 Feb 2012, manu at gcc dot gnu.org wrote:

> Is this folding actually necessary for anything beyond diagnostics? I thought
> it was agreed that folding in the FEs was EVIL and we should stop doing it.

Folding with c_fully_fold is done (a) where required for language 
semantics (in particular integer constant expressions ... remember that 
it's not possible to avoid doing struct layout quite early, for example, 
even if it would seem cleaner to have separate phases there, because 
offsetof can be used in an integer constant expression, and whether such 
an expression evaluates to 0 affects the types of other expressions), (b) 
for diagnostics (folded expressions work better in various cases that try 
to avoid diagnostics for e.g. signed/unsigned conversions that can't 
actually cause any problems), (c) in certain cases where the expression 
being built up is something such as SAVE_EXPR it would be problematic for 
the front end to try to take apart to fold inside later and (d) as a final 
lowering stage for a full expression that converts it into the form that 
will be gimplified.

> I wouldn't be surprised if the compiler got noticeably faster by removing all
> early folding and all the workarounds and hacks that come with it, and
> replacing it by doing a temporary c_fully_fold at those specific places that
> needed it (and throwing away the result and keeping the original code around).

The places that use c_fully_fold on something less than a full expression 
are doing it because it's actually needed there and removing it will break 
things.  Furthermore, if you throw away the result as you suggest, so 
repeatedly folding the same expression as a subexpression of larger 
expressions, you would be liable to make things slower.  (When 
c_fully_fold is run on something less than a full expression, the result 
is wrapped so that it *doesn't* recurse inside that subexpression when 
called on a larger expression containing it.)

For cases in (c) it may be useful to create new C-family tree codes that 
represent the operations in question at a level closer to the C source 
code, so allowing the lowering to SAVE_EXPR etc. to be delayed until a 
later c_fully_fold call.  For (b), it may be useful to create codes 
representing that a conversion was implicit, or that a diagnostic should 
be generated under certain conditions, again either processing them later 
in c_fully_fold or passing down the "diagnose this if ..." information for 
diagnostics to be generated at a later stage if the code is still 
reachable after some optimization and the compiler can't rule out whatever 
the problem is - but doing things any later than the final lowering to 
GENERIC / GIMPLE runs into the usual trade-offs between predictable 
diagnostics and avoiding diagnostics where a human can see there is no 
problem.

In any case you can't just remove the folding without creating appropriate 
new representations.