[Bug pch/12919] [tree-ssa/3.4 Regression] ICE: in default_pch_valid_p, at toplev.c:4235 during libstdc++-v3 build

[geoffk at apple dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From geoffk at apple dot com  2003-11-07 18:11 -------
Subject: Re:  [tree-ssa/3.4? Regression] ICE: in default_pch_valid_p, at toplev.c:4235 during libstdc++-v3 build


On Friday, November 7, 2003, at 07:42  AM, pinskia at gcc dot gnu dot 
org wrote:

> I want to say somehow this loop (the one before the abort) is wrong 
> for some targets;
...
>   if (memcmp (data, &target_flags, sizeof (target_flags)) != 0)
>     {
>       for (i = 0; i < ARRAY_SIZE (target_switches); i++)
>         {
>           int bits;
>           int tf;
>
>           memcpy (&tf, data, sizeof (target_flags));
>
>           bits = target_switches[i].value;
>           if (bits < 0)
>             bits = -bits;
>           if ((target_flags & bits) != (tf & bits))
>             {
>               flag_that_differs = target_switches[i].name;
>               goto make_message;
>             }
>         }
>       abort ();
>     }
>
> Keating any way to know if this true?

The abort() in this loop (assuming the loop is compiled correctly) can 
only happen if you have two target_flags values, one in the PCH and one 
in the current invocation of GCC, that differ but differ only in a bit 
that is not in the target_switches array.  If you're at the abort() in 
GDB it should be pretty easy to find this out, just do

print/x target_flags
x/w data

and then go look at the bits that differ and match them to flags in 
your machine's description.

If your machine does use flags in target_flags that don't have 
equivalents in target_switches, you should override this routine in the 
target hook structure.