On Fri, Oct 25, 2013 at 8:29 AM, Bernd Edlinger
<bernd.edlin...@hotmail.de> wrote:
> Hi Richard,
>
>
>>> Did you just propose:
>>>
>>> --- stor-layout.c.orig 2013-10-22 10:46:49.233261818 +0200
>>> +++ stor-layout.c 2013-10-24 14:54:00.425259062 +0200
>>> @@ -471,27 +471,7 @@
>>> static enum machine_mode
>>> mode_for_array (tree elem_type, tree size)
>>> {
>>> - tree elem_size;
>>> - unsigned HOST_WIDE_INT int_size, int_elem_size;
>>> - bool limit_p;
>>> -
>>> - /* One-element arrays get the component type's mode. */
>>> - elem_size = TYPE_SIZE (elem_type);
>>> - if (simple_cst_equal (size, elem_size))
>>> - return TYPE_MODE (elem_type);
>>> -
>>> - limit_p = true;
>>> - if (host_integerp (size, 1) && host_integerp (elem_size, 1))
>>> - {
>>> - int_size = tree_low_cst (size, 1);
>>> - int_elem_size = tree_low_cst (elem_size, 1);
>>> - if (int_elem_size> 0
>>> - && int_size % int_elem_size == 0
>>> - && targetm.array_mode_supported_p (TYPE_MODE (elem_type),
>>> - int_size / int_elem_size))
>>> - limit_p = false;
>>> - }
>>> - return mode_for_size_tree (size, MODE_INT, limit_p);
>>> + return BLKmode;
>>> }
>>>
>>> ???
>>
>> Yes. Does it work?
>>
>> Richard.
>>
>
> No.
>
> PASS: gcc.target/i386/pr14289-1.c (test for errors, line 10)
> FAIL: gcc.target/i386/pr14289-1.c (test for excess errors)
> Excess errors:
> /home/ed/gnu/gcc-4.9-20131013/gcc/testsuite/gcc.target/i386/pr14289-1.c:5:14:
> error: data type of 'a' isn't suitable for a register
>
> Does that look like an ABI-Change?
>
> the test case uses:
> register int a[2] asm("ebx");
Eh ... even
register struct { int i; int a[0]; } asm ("ebx");
works. Also with int a[1] but not with a[2]. So just handling trailing
arrays makes this case regress as well.
Now I'd call this use questionable ... but we've likely supported that
for decades and cannot change that now.
Back to fixing everything in expand.
Richard.
> Bernd.
