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