This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/25609] too agressive printf optimization
- From: "drepper at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 31 Dec 2005 00:19:04 -0000
- Subject: [Bug rtl-optimization/25609] too agressive printf optimization
- References: <bug-25609-700@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #12 from drepper at redhat dot com 2005-12-31 00:19 -------
> That is not true at all and you know that. There is uclibc.
Now you've completely given up on logic? First of all, uclibc and whatever
other libc immitation is out there does not define the linux API. glibc *is*
the world, all the others are just replacements of varying degree of
conformance. This can be seen in the fact that even uclibc implements printf
with the behavior in question.
But more importantly here: even if there were one piece of code which behaves
differently, this does not disqualify the argument that the API for Linux
defines the behavior in question. This is an OR operation, not AND. glibc
defines the behavior and this means the compiler must handle such code
approriately if compiled for Linux.
--
drepper at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609