Re: [PATCH] Fix PR target/19933 and PR target/21315

[Bruce Korb <bruce dot korb at gmail dot com>]

Hi all,

This is sort of a collective response:

> > Would the solution to this problem not be to strengthen this regexp?
> 
> That's what we've done -- but the problem is that fixes are on by 
> default.  So, if someone adds a new fix, it may fire spuriously on my 
> system.  Or, if my system gets a new header, it may be spuriously fixed 
> by an existing fix.

We try to write reg-exes that only identify real problems.
I also try to avoid spurious fixes, but I can only do so when I have a
sample of a spuriously fixed header.... :)

> > The reasoning is that we keep fixing unless we are sure we don't need to.  
> > Using only __GNUC__ seems hazardous, as it could pop up in another unrelated 
> > part of the header.
> 
> But equally __GNUC__ could appear elsewhere as part of a proper 
> conditioning of the definitions.
> 
> #if __GNUC__ >= 4
> #define __have_somthing
> #endif

I believe a reasonable approach is to assume (or hope ;) that fixes are
only temporary and that at some point an OS manufacturer will fix their
headers.  Once fixed, it would be highly unlikely that the header would
become unfixed.  So, the appearance of __GNUC__ in the file iso/math_c99.h
is a marking point in the evolution of that file.  It indicates that the
math stuff has been fixed for GCC and is no longer needed.  If Sun were
to change its mind and take this code out (unlikely given that they are
about to open-source the OS), *then* you jigger the bypass stuff so that
the fix is skipped if "__GNUC__" appears, but not if some other marker
is also present.

> The question is: should we avoid getting in the way of updates at the risk of 
> not fixing anymore, which means allowing broken headers to again slip through 
> the cracks?

If the OS updates its headers, there is no way around the problem that
GCC's notion of the headers is now out of date.  The fixed headers must
be rebuilt (unless they are okay, but there is still the INITIALIZER
stuff that remains broken).  I think that has been made relatively easy now, yes?
If I didn't have a day job, I might polish and doc the thing, but I think
it is mostly there now....

> I would rather that we explicitly list the fixes that are required for 
> each OS, than that we assume that all fixes may need to be applied 
> everywhere.
> 
> In practice, as far as I can tell, all distributions are moving to be 
> more standards-compliant, not less.  Our system distribution customers 
> are actively trying to fix their headers so as to avoid the need to have 
> GCC fix them.  And, they are frustruated by the fact that even after 
> they fix them, they may still end up getting fixed spuriously, 
> especially if the spurious fix is coming from something added for some 
> other system entirely that just happens to fire on their headers.

Ask them to please send me information on how to distinguish their headers.
Once upon a time long ago it was said that the fixes ought not be platform
specific.  The thinking was that a problem for one is often a problem
for another.  Do we want to revisit that?  I could easily insert #if-def-ing
code into the output so some/most fixes are not even compiled for particular
platforms.  a la:

   if = 'defined(__sun__)',
        'defined(__linux) && (__GNUC__ < 4)';

and it is compiled if either __sun__ is defined or if __linux
is defined and GNUC is less than four.  Or reverse it with "ifnot".
Anyway, the problem is solvable if there is sufficient desire to fix it.

> I'm not really convinced, but Joseph and you have more experience dealing with 
> this kind of things than me, so I'll make the change suggested by Joseph for 
> the next revision of the patch.  Thanks for your feedback.

I'll try to take a swing at playing with your patch later today.
Otherwise, it will likely be some weeks before I have time.

Another issue with our header fixing system is that it is a near-monotonically
increasing.  It would be nice to find a way to retire these things.....

Cheers, Bruce