On Thu, 4 Dec 2014, Joseph Myers wrote: > On Thu, 4 Dec 2014, Richard Biener wrote: > > > So what does this all mean in practice for optimization passes? > > I don't know what it means in terms of how to fix the various existing > problems - it's simply how I think a fixed compiler should behave. > > > When b) does not apply then the given stpcpy special-casing shows > > that even then this is not enough. So should that special-casing > > and any extension of it add > > > > && in_system_header_at (DECL_SOURCE_LOCATION (newdecl)) > > > > ? > > I think that would be logically correct (for allowing stpcpy calls to be > generated in optimization if the user included <string.h> with > _POSIX_C_SOURCE=200809L defined, for example, but not if they used > -std=c11 without feature test macros and declared their own stpcpy). But > the same should apply to any optimization of stpcpy calls written by the > user - they can only be assumed to have standard stpcpy semantics if (a) > the selected standard includes stpcpy, e.g. -std=gnu11 or (b) stpcpy was > declared in a system header, not just by the user.
Yeah - it is that current difference that appears most odd to me. We assume stpcpy semantics (stick BUILT_IN_STPCPY on the decl) as soon as we see a (compatible?) decl but we do not allow us to generate a call to it because semantics may be different(!?). OTOH this also means the user cannot provide a conforming implementation on his own and get that used by GCC without editing system headers or including a header with -isystem or similar tricks. Richard.
