This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: bootstrap failure on ppc64-linux: ICE in set_variable_part
Kenneth Zadeck wrote:
> Richard Sandiford wrote:
>
>> Janis Johnson <janis187@us.ibm.com> writes:
>>
>>
>>> On Mon, 2007-09-17 at 23:41 +0200, Andreas Schwab wrote:
>>>
>>>
>>>> Janis Johnson <janis187@us.ibm.com> writes:
>>>>
>>>>
>>>>
>>>>> Bootstrap of powerpc64-linux fails building libgfortran with:
>>>>>
>>>>> /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function 'set_integer':
>>>>> /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal compiler error: in set_variable_part, at var-tracking.c:2381
>>>>> Please submit a full bug report, with preprocessed source if appropriate.
>>>>> See <http://gcc.gnu.org/bugs.html> for instructions.
>>>>>
>>>>> My last successful build was revision 128522; earliest known break
>>>>> was 128536, still breaks with 128551.
>>>>>
>>>>>
>>>> Bisection has identified this change:
>>>>
>>>> 2007-09-16 Richard Sandiford <rsandifo@nildram.co.uk>
>>>>
>>>> * dse.c (find_shift_sequence): Allow word as well as subword shifts.
>>>> Do the tentative shift expansion with the DF_NO_INSN_RESCAN flag set.
>>>> Fix the call to insn_rtx_cost. Skip access sizes that require a
>>>> real truncation of the store register. Use convert_move instead
>>>> of gen_lowpart when narrowing the result.
>>>> (replace_read): Use convert_move instead of gen_lowpart when
>>>> narrowing the store rhs.
>>>>
>>>>
>>> My hunt just found the same patch Here's a small test that fails
>>> with cc1 for powerpc64-linux with "-O2 -g -m64 -mstrict-align":
>>> -------------
>>> extern void *memcpy (void *, const void *, signed long);
>>>
>>> void
>>> set_integer (void *dest, __int128_t value, int length)
>>> {
>>> switch (length)
>>> {
>>> case 16:
>>> {
>>> __int128_t tmp = value;
>>> memcpy (dest, (void *) &tmp, length);
>>> }
>>> break;
>>> case 1:
>>> {
>>> signed char tmp = value;
>>> memcpy (dest, (void *) &tmp, length);
>>> }
>>> break;
>>> }
>>> }
>>> -----------
>>> Janis
>>>
>>>
>> I think this is a latent bug in var-tracking.c. It's getting confused
>> by the negative offsets in:
>>
>> (insn:HI 17 47 19 4 /tmp/foo.c:11 (set (reg:DI 26 26 [orig:124 tmp+-7 ] [124])
>> (lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
>> (const_int 56 [0x38]))) 292 {*lshrdi3_internal1} (nil))
>>
>> (insn:HI 19 17 21 4 /tmp/foo.c:11 (set (reg:DI 27 27 [orig:125 tmp+-6 ] [125])
>> (lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
>> (const_int 48 [0x30]))) 292 {*lshrdi3_internal1} (nil))
>>
>> where the registers have come from paradoxical subregs of QImode registers.
>> (DSE itself didn't create those; combine did. DSE just created DImode
>> shift instructions.)
>>
>> FWIW, the part of the patch that exposed the bug as the change from
>> "access_bytes < UNITS_PER_WORD" to "access_bytes <= UNITS_PER_WORD".
>> Your testcase passes if we change that back.
>>
>>
>>
> i would prefer that the above change be reverted and the rest of the
> patch left in.
> kenny
>
>> From my POV of view, feel free to commit that change until the underlying
>> var-tracking bug is fixed. Alternatively, I think it'd be OK to revert
>> the whole of my patch _and_ revert Kenny's patch. (Please don't just
>> revert mine, as it would reintroduce a bootstrap failure on MIPS targets.)
>>
>> I'm afraid I won't have time to work on this myself. Hopefully Kenny
>> will. (At the end of the day, I was only trying to fix MIPS breakage
>> in the original DSE patch, rather than asking Kenny to it for me. ;))
>>
>> Richard
>>
>>
>
>
I should also point out that i am at a conference this week in romania
and cannot really test anything, especially on the ppc. So someone else
needs to revert this regression.
Kenny