[haiku-development] Re: Aw: Re: hrev45320: Yet another non-obvious effect of -ftree-vrp "optimization"
- From: Pawel Dziepak <pdziepak@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 15 Mar 2013 15:41:18 +0100
2013/3/14 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> Am 14/03/2013 18:01, schrieb Pawel Dziepak:
>>
>> 2013/3/14 Ingo Weinhold <ingo_weinhold@xxxxxx>:
>>
>>> Or IOW, the feature is just buggy. It would be interesting whether the
>>> bug
>>> has been fixed in newer gcc versions.
>>
>> I did some tests on a simplified example on GCC 4.7.2. What I found
>> out is that although GCC does not replace strdup() with its builtin
>> version it uses that "builtin information" to perform VRP.[...]
>
>
> Isn't that just a porting issue?
> Somewhere GCC stores that information, and it's usually right. Just not on
> Haiku. IMO one should "simply" update GCC to know that strdup(), free(),
> etc. accept NULL pointers.
The problem is that GCC applies the same attributes to both built-in
functions and their user defined version even if eventually the
built-in version is never used. Changing the attributes of GCC
built-in functions is trivial this [1] patch for GCC would do this for
strdup() and solve this particular problem. However, if anyone tried
to compile anything that uses built-in strdup() GCC would have wrong
information about it (and that may result in another problem). I see
two solutions for this, either we patch GCC so that its built-in
strdup() would accept NULL pointers or disable (at least some)
built-in functions at all (it would be easier if there would a flag
that disables built-in functions but does not prevent the optimizer
from recognizing standard library functions and applying appropriate
attributes). Moreover, if we choose to disable built-in functions it
may be worth to add appropriate GCC attributes to them manually (like
in this example [2]) in order not to reduce optimizer effectiveness.
Paweł
[1] http://pastebin.com/4S4MCEFu
[2] http://pastebin.com/D6FaSNpu
Other related posts:
