Re: Could __builtin_printf parameters be optimized when being compiled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 15/02/2023 15:49, Segher Boessenkool wrote:
On Wed, Feb 15, 2023 at 03:10:15PM +0000, Jonny Grant wrote:
On 15/02/2023 14:30, Richard Earnshaw wrote:
int main()
{
      __builtin_printf("file %s:%d", __FILE__, __LINE__);
}

Note that the format needs to end in "\n" if you want this to be
converted to a puts() call.  Without it it strangely doesn't seem to
be optimised, although fprintf() is converted to fwrite() in such cases.
This could be done for printf() as well: you are guaranteed to have
access to stdout as well, at least if you use printf() instead of the
builtin (I'm not sure if we do then).

Well it should do, but unless you've #included stdio.h (which you should have done, but not every program is 100% conforming) you might not have a definition of it and the compiler can't know how to magic up a correct definition of it for your system (c89 said that stdin/out/err are macros, so they might expand to almost anything - in freebsd, for example they expand to __std<in|out|err>p).


I guess it might be possible to handle cases where all the arguments are constant, but even that has its problems, eg:

- can we guarantee identical output to the platform printf?

That's a good question. I was using __builtin_printf so that should be GCC I expect.

Not every printf() implementation has exactly the same output in all
cases.

Another practically important consideration is what it does to i18n.
You really need to leave the format string unmodified for that to be
able to work.


Segher

R.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux