GCC Status Report (2004-03-09)

Mark Mitchell mark@codesourcery.com
Thu Apr 1 17:33:00 GMT 2004

Eric Botcazou wrote:

>>ATM the blockage is between clearing and storing of the individual
>>non-zero fields in the initializer, while for 20030408-1.c or 20040401-1.c
>>to work on IA-64, the blockage needs to be in between the last store to
>>the (partially) const object and the rest of the function.
>Then this is a more general problem with /u :-(
Gentlemen, I'm starting to conclude that the current design for 
RTX_UNCHANGING_P is fatally flawed.  In particular, the fact that there 
is no conservative setting means that we are simply going to get 
something wrong no matter what we do.

I keep getting confused about exactly which problems are fixed by 
exactly which patches, but there are clearly multiple problems.

We could simply disable RTX_UNCHANGING_P -- but that would leave to 
massive pessimization all over the place.  So much so that people would 
probably find that more annoying that the code-generation problems we've 
got at the moment.

If the problem is merely structures with some "const" and some non-const 
fields, then let's simply ignore the "const" on those fields when 
generating RTL.  Yes, that means that adding "const" to a field may 
result in worse code.  That's not a major problem; the really important 
case is "const" scalars, followed probably by completely "const" 
objects.  The case in PR 13424 (a non-"const" object with some "const" 
fields) is not the common case.

If the problem is more complex than that, then let's just punt.

I'm not particularly interested in "well, if we did this, and if that, 
then this or that."  I need to make a decision here: do I roll the 
release or not.  The thing I need to know is whether or not we can 
quickly implement a fix that is (a) safe, and (b) not inordinately 
pessimizing.  For the purposes of replying to this email, pretend I am 
the prototypical pointy-haired boss, with no knowledge of compilers 
whatsoever; just tell me whether you can solve the problem, and by 
when.  If you can't solve the problem quickly, then we'll move on, and 
hopefully get a solution by 3.4.1.


Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

More information about the Gcc-patches mailing list