This is the mail archive of the gcc@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: Optimization bug?


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
>


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