Optimization bug?
Richard Biener
richard.guenther@gmail.com
Mon Sep 21 08:33:00 GMT 2015
On Sun, Sep 20, 2015 at 6:21 PM, Martin Sebor <msebor@gmail.com> wrote:
> On 09/20/2015 12:38 AM, Richard Biener wrote:
>>
>> On September 20, 2015 1:40:12 AM GMT+02:00, Martin Sebor
>> <msebor@gmail.com> wrote:
>>>
>>> On 09/19/2015 03:32 PM, Sören Brinkmann wrote:
>>>>
>>>> Hi Andrew,
>>>>
>>>> On Sat, 2015-09-19 at 11:34AM -0700, pinskia@gmail.com wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Sep 19, 2015, at 11:00 AM, Sören Brinkmann
>>>
>>> <soren.brinkmann@xilinx.com> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I recently came across some bug in my program that I could narrow
>>>
>>> down
>>>>>>
>>>>>> to the snipped below (also attached with a Makefile).
>>>>>>
>>>>>> extern unsigned int _vector_table;
>>>>>
>>>>>
>>>>> You need the attribute weak here if the location of _vector_table
>>>
>>> can be a null pointer.
>>>>
>>>>
>>>> Indeed, that fixes the problem. Would you have any additional
>>>
>>> background
>>>>
>>>> why the 'weak' is required in this case? To me it sounded like the
>>>> '-fno-delete-null-pointer-checks' should be sufficient.
>>>
>>>
>>> -fno-delete-null-pointer-checks prevents GCC from removing tests
>>> for null pointers after such pointers have been dereferenced. For
>>> example, in the following function, GCC normally eliminates the
>>> second if statement because the first statement lets it assume
>>> that p is not null (otherwise dereferencing it would be undefined).
>>>
>>> int foo (int *p) {
>>> if (*p == 0) return 0;
>>> if (p == 0) return 1;
>>> return 2;
>>> }
>>>
>>> The option doesn't affect other assumptions such as that every
>>> object and function in a program lives at a valid, non-null
>>> address.
>>
>>
>> Actually we abuse this flag for exactly this purpose so I think the
>> testcase shows a bug. Unless the particular target cannot have global vars
>> at address zero.
>>
>> Would you mind opening a bugreport?
>
>
> I'm not sure I follow. I've tested the original example with 6.0,
> 5.1, 4.9, 4.8.3, and 4.8.1. All of these eliminate the test with
> -fno-delete-null-pointer-checks. Are you saying that's a bug? If
> so, what version retains the test?
It looks it's broken since forever (since we can optimize this which
is starting with GCC 3.4). But the issue is a "trivial" one in
RTLs nonzero_address_p.
Richard.
> Martin
>
More information about the Gcc
mailing list