This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, PR 57748] Check for out of bounds access, Part 2


On Fri, Oct 25, 2013 at 8:29 AM, Bernd Edlinger
<bernd.edlinger@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]