* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
@ 2005-12-30 23:01 ` pinskia at gcc dot gnu dot org
2005-12-30 23:05 ` pinskia at gcc dot gnu dot org
` (20 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-12-30 23:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-30 23:01 -------
The code is undefined so seg faulting is an okay thing to do.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
2005-12-30 23:01 ` [Bug rtl-optimization/25609] " pinskia at gcc dot gnu dot org
@ 2005-12-30 23:05 ` pinskia at gcc dot gnu dot org
2005-12-30 23:05 ` pinskia at gcc dot gnu dot org
` (19 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-12-30 23:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-30 23:05 -------
Mark as a dup of bug 15574.
*** This bug has been marked as a duplicate of 15574 ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
2005-12-30 23:01 ` [Bug rtl-optimization/25609] " pinskia at gcc dot gnu dot org
2005-12-30 23:05 ` pinskia at gcc dot gnu dot org
@ 2005-12-30 23:05 ` pinskia at gcc dot gnu dot org
2005-12-30 23:06 ` drepper at redhat dot com
` (18 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-12-30 23:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-30 23:05 -------
Reopening to ....
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (2 preceding siblings ...)
2005-12-30 23:05 ` pinskia at gcc dot gnu dot org
@ 2005-12-30 23:06 ` drepper at redhat dot com
2005-12-30 23:07 ` pinskia at gcc dot gnu dot org
` (17 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: drepper at redhat dot com @ 2005-12-30 23:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from drepper at redhat dot com 2005-12-30 23:06 -------
No, it's *NOT* undefined. The libc interface decides what is defined and what
is not and it is *EXPLICITLY* documented that NULL pointers are printed as
(null).
The standard might leave it undefined but this does *NOT* mean the
implementation cannot define it.
--
drepper at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (3 preceding siblings ...)
2005-12-30 23:06 ` drepper at redhat dot com
@ 2005-12-30 23:07 ` pinskia at gcc dot gnu dot org
2005-12-30 23:08 ` drepper at redhat dot com
` (16 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-12-30 23:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-30 23:07 -------
You are wrong.
*** This bug has been marked as a duplicate of 15685 ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (4 preceding siblings ...)
2005-12-30 23:07 ` pinskia at gcc dot gnu dot org
@ 2005-12-30 23:08 ` drepper at redhat dot com
2005-12-30 23:08 ` pinskia at gcc dot gnu dot org
` (15 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: drepper at redhat dot com @ 2005-12-30 23:08 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from drepper at redhat dot com 2005-12-30 23:08 -------
This is NOT a dup of 15574.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (5 preceding siblings ...)
2005-12-30 23:08 ` drepper at redhat dot com
@ 2005-12-30 23:08 ` pinskia at gcc dot gnu dot org
2005-12-30 23:15 ` drepper at redhat dot com
` (14 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-12-30 23:08 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-30 23:08 -------
(In reply to comment #4)
> The standard might leave it undefined but this does *NOT* mean the
> implementation cannot define it.
That is true but GCC is a C compiler and not a glibc implemention C compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (6 preceding siblings ...)
2005-12-30 23:08 ` pinskia at gcc dot gnu dot org
@ 2005-12-30 23:15 ` drepper at redhat dot com
2005-12-30 23:37 ` pinskia at gcc dot gnu dot org
` (13 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: drepper at redhat dot com @ 2005-12-30 23:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from drepper at redhat dot com 2005-12-30 23:14 -------
> That is true but GCC is a C compiler and not a glibc implemention C compiler.
This doesn't mean anything. As soon as you configure gcc to target it to Linux
the behavior of the runtime is as defined by the C library. gcc doesn't come
with it's own C library so it cannot possibly override any decisions made about
undefined behavior. I explicitly said that this optimization need ony be
disabled for platforms using glibc. I don't give a rats ass what other
platforms do.
--
drepper at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (7 preceding siblings ...)
2005-12-30 23:15 ` drepper at redhat dot com
@ 2005-12-30 23:37 ` pinskia at gcc dot gnu dot org
2005-12-30 23:44 ` drepper at redhat dot com
` (12 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-12-30 23:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-30 23:36 -------
I should note that glibc is not the world.
Also the patch which added the transformations:
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00826.html
If you see that RTH approved it without any objections.
I still say that this is valid no matter what and people are wrong in assuming
that GCC is not going to it as it is undefined code which means depending on it
is going to cause portablity issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (8 preceding siblings ...)
2005-12-30 23:37 ` pinskia at gcc dot gnu dot org
@ 2005-12-30 23:44 ` drepper at redhat dot com
2005-12-30 23:49 ` pinskia at gcc dot gnu dot org
` (11 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: drepper at redhat dot com @ 2005-12-30 23:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from drepper at redhat dot com 2005-12-30 23:44 -------
glibc *is* the world as far as Linux is concerned. You consistently and
deliberately misinterpret what I write: I'm not talking about any platform
which does not use glibc or glibc's behavior.
And RTH already concurred in private that this is a problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (9 preceding siblings ...)
2005-12-30 23:44 ` drepper at redhat dot com
@ 2005-12-30 23:49 ` pinskia at gcc dot gnu dot org
2005-12-31 0:19 ` drepper at redhat dot com
` (10 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-12-30 23:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from pinskia at gcc dot gnu dot org 2005-12-30 23:49 -------
(In reply to comment #10)
> glibc *is* the world as far as Linux is concerned.
That is not true at all and you know that. There is uclibc.
This is still undefined code even if the underlaying printf defines it.
This is still a dup of bug 15685 as that is the orginal bug about this issue.
*** This bug has been marked as a duplicate of 15685 ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (10 preceding siblings ...)
2005-12-30 23:49 ` pinskia at gcc dot gnu dot org
@ 2005-12-31 0:19 ` drepper at redhat dot com
2006-01-01 22:18 ` joseph at codesourcery dot com
` (9 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: drepper at redhat dot com @ 2005-12-31 0:19 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (11 preceding siblings ...)
2005-12-31 0:19 ` drepper at redhat dot com
@ 2006-01-01 22:18 ` joseph at codesourcery dot com
2007-11-16 16:17 ` manu at gcc dot gnu dot org
` (8 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: joseph at codesourcery dot com @ 2006-01-01 22:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from joseph at codesourcery dot com 2006-01-01 22:18 -------
Subject: Re: New: too agressive printf optimization
On Fri, 30 Dec 2005, drepper at redhat dot com wrote:
> There should at least be a mode in which gcc does not perform the
> transformation if it cannot be sure the pointer is not NULL. The default for
The mode is -fno-builtin-printf. The same applies for users with custom
printf format handlers which modify static variables; they may also need
to use -fno-builtin-printf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (12 preceding siblings ...)
2006-01-01 22:18 ` joseph at codesourcery dot com
@ 2007-11-16 16:17 ` manu at gcc dot gnu dot org
2007-11-16 22:11 ` Andrew Pinski
2007-11-16 22:11 ` pinskia at gmail dot com
` (7 subsequent siblings)
21 siblings, 1 reply; 24+ messages in thread
From: manu at gcc dot gnu dot org @ 2007-11-16 16:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from manu at gcc dot gnu dot org 2007-11-16 16:17 -------
Is there any difference in the standard behaviour between printf("%s", NULL)
and puts(NULL)? I mean, why printf("%s", NULL) receives special consideration
but neither puts(NULL) nor fprintf(stdout, "%s", NULL) do?
Anyway, can this be closed as a duplicate of bug 15685 ?
--
manu at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (13 preceding siblings ...)
2007-11-16 16:17 ` manu at gcc dot gnu dot org
@ 2007-11-16 22:11 ` pinskia at gmail dot com
2008-01-15 17:59 ` gustavodn at gmail dot com
` (6 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: pinskia at gmail dot com @ 2007-11-16 22:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from pinskia at gmail dot com 2007-11-16 22:11 -------
Subject: Re: too agressive printf optimization
> Is there any difference in the standard behaviour between printf("%s", NULL)
> and puts(NULL)? I mean, why printf("%s", NULL) receives special consideration
> but neither puts(NULL) nor fprintf(stdout, "%s", NULL) do?
No both are undefined.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (14 preceding siblings ...)
2007-11-16 22:11 ` pinskia at gmail dot com
@ 2008-01-15 17:59 ` gustavodn at gmail dot com
2008-01-15 19:30 ` manu at gcc dot gnu dot org
` (5 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: gustavodn at gmail dot com @ 2008-01-15 17:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from gustavodn at gmail dot com 2008-01-15 17:20 -------
"Glibc being Linux being the world" is not really relevant, IMHO. What is
relevant is printf() (or any function) is, fundamentally, implemented by
library, not by compiler, so compiler should not prevent library from defining
behavior not defined in the standard.
So I think gcc should either:
- provide means to disable printf (or more generaly, any specific function)
optimization based on library being linked
- not optimize printf in this way, unless requested (i.e. do not include this
optimization in any predefined optimizations list
- probably other alternatives
--
gustavodn at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gustavodn at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (15 preceding siblings ...)
2008-01-15 17:59 ` gustavodn at gmail dot com
@ 2008-01-15 19:30 ` manu at gcc dot gnu dot org
2008-01-15 21:09 ` manu at gcc dot gnu dot org
` (4 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: manu at gcc dot gnu dot org @ 2008-01-15 19:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from manu at gcc dot gnu dot org 2008-01-15 18:51 -------
This will be fixed yesterday if printf("%s\n", s) were equivalent to puts(s) in
glibc.
Also there is a way to disable the optimization: "-fno-builtin-printf".
People that don't rely on undefined behaviour don't deserve to be punished with
suboptimal code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (16 preceding siblings ...)
2008-01-15 19:30 ` manu at gcc dot gnu dot org
@ 2008-01-15 21:09 ` manu at gcc dot gnu dot org
2008-01-15 21:39 ` gustavodn at gmail dot com
` (3 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: manu at gcc dot gnu dot org @ 2008-01-15 21:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from manu at gcc dot gnu dot org 2008-01-15 20:48 -------
There is an explanation for the optimisation, a potential fix [*] and there is
a workaround.
[*] http://sourceware.org/bugzilla/show_bug.cgi?id=5618
--
manu at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (17 preceding siblings ...)
2008-01-15 21:09 ` manu at gcc dot gnu dot org
@ 2008-01-15 21:39 ` gustavodn at gmail dot com
2008-01-15 23:03 ` manu at gcc dot gnu dot org
` (2 subsequent siblings)
21 siblings, 0 replies; 24+ messages in thread
From: gustavodn at gmail dot com @ 2008-01-15 21:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from gustavodn at gmail dot com 2008-01-15 21:08 -------
(In reply to comment #17)
> This will be fixed yesterday if printf("%s\n", s) were equivalent to puts(s) in
> glibc.
[+] The standard requires them to be equivalent? Per standard, they can't be
equivalent if both are undefined when NULL is passed, right?
> Also there is a way to disable the optimization: "-fno-builtin-printf".
>
> People that don't rely on undefined behaviour don't deserve to be punished with
> suboptimal code.
It is not undefined, per glibc. GCC is defining undefined behavior, just as
much as glibc, to optimize, that should be documented or fixed.
(In reply to comment #18)
> There is an explanation for the optimisation, a potential fix [*] and there is
> a workaround.
>
> [*] http://sourceware.org/bugzilla/show_bug.cgi?id=5618
[+]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (18 preceding siblings ...)
2008-01-15 21:39 ` gustavodn at gmail dot com
@ 2008-01-15 23:03 ` manu at gcc dot gnu dot org
2008-01-16 6:22 ` gustavodn at gmail dot com
2008-01-16 13:18 ` manu at gcc dot gnu dot org
21 siblings, 0 replies; 24+ messages in thread
From: manu at gcc dot gnu dot org @ 2008-01-15 23:03 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from manu at gcc dot gnu dot org 2008-01-15 21:49 -------
(In reply to comment #19)
> (In reply to comment #17)
> > This will be fixed yesterday if printf("%s\n", s) were equivalent to puts(s) in
> > glibc.
>
> [+] The standard requires them to be equivalent? Per standard, they can't be
> equivalent if both are undefined when NULL is passed, right?
I didn't say the standard requires them to be equivalent. Per standard, two
undefined invocations of printf don't need to be equivalent.
Anyway, if you really want to believe that printf("%s\n",s) and puts(s) should
not have the same effect for defined behaviour, then we will have to agree to
disagree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (19 preceding siblings ...)
2008-01-15 23:03 ` manu at gcc dot gnu dot org
@ 2008-01-16 6:22 ` gustavodn at gmail dot com
2008-01-16 13:18 ` manu at gcc dot gnu dot org
21 siblings, 0 replies; 24+ messages in thread
From: gustavodn at gmail dot com @ 2008-01-16 6:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from gustavodn at gmail dot com 2008-01-16 01:52 -------
(In reply to comment #20)
> Anyway, if you really want to believe that printf("%s\n",s) and puts(s) should
> not have the same effect for defined behaviour, then we will have to agree to
> disagree.
That's confused, what is being discussed is undefined behavior X optimization
trusting it. Still, the manpage for puts() says "output of characters and
strings", while the one for printf() says "formatted output conversion". puts()
just sends a string to stdout, printf() converts data into their string
representation. So I agree to disagree about the expectation on what they do
about NULL: puts() should do nothing or merely return error, while printf()
*could* convert or otherwise print a string representation of it.
Given the impasse, and given Glibc defines what it does, I understand the next
correct thing for someone who cares to do, is to report a bug on GCC about this
issue on any specific distributions using GCC together with Glibc.
cya
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug rtl-optimization/25609] too agressive printf optimization
2005-12-30 22:59 [Bug rtl-optimization/25609] New: too agressive printf optimization drepper at redhat dot com
` (20 preceding siblings ...)
2008-01-16 6:22 ` gustavodn at gmail dot com
@ 2008-01-16 13:18 ` manu at gcc dot gnu dot org
21 siblings, 0 replies; 24+ messages in thread
From: manu at gcc dot gnu dot org @ 2008-01-16 13:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from manu at gcc dot gnu dot org 2008-01-16 12:36 -------
(In reply to comment #21)
> (In reply to comment #20)
> > Anyway, if you really want to believe that printf("%s\n",s) and puts(s) should
> > not have the same effect for defined behaviour, then we will have to agree to
> > disagree.
>
> That's confused, what is being discussed is undefined behavior X optimization
> trusting it.
No, if we follow your reasoning, as you repeat constantly, "It is not
undefined, per glibc."
> Still, the manpage for puts() says "output of characters and
> strings", while the one for printf() says "formatted output conversion". puts()
> just sends a string to stdout, printf() converts data into their string
> representation. So I agree to disagree about the expectation on what they do
> about NULL: puts() should do nothing or merely return error, while printf()
> *could* convert or otherwise print a string representation of it.
Finally, we agree about something. :-) Anyway, this has little to do with this
bug. This is my personal opinion on how glic could fix if they really wanted. I
guess other GCC developers think: "There is nothing to fix, expecting something
from undefined behaviour is wrong and the optimisation is valid for all defined
cases".
> Given the impasse, and given Glibc defines what it does, I understand the next
> correct thing for someone who cares to do, is to report a bug on GCC about this
> issue on any specific distributions using GCC together with Glibc.
What you want us to do? We should avoid optimising printf("%s\n", s) to puts(s)
just because s may be NULL? So, in your opinion, we should punish people that
don't rely on printf("%s\n", NULL) being defined, and defined as something
different as puts(NULL)? Sorry, we disagree.
You are welcome to waste your (and others people) time reporting duplicated
bugs. We will point them to this discussion. I think there is far enough
information here and, in particular, in
http://sourceware.org/bugzilla/show_bug.cgi?id=5618 , for anyone to make their
own opinion about the issue. If distributions want to patch GCC or use
-fno-builtin-printf by default, they are allow to do it. Good luck with that.
Please, I am sure you are not that kind of internet character that needs to
have the last word on everything, so accept that this is closed. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
^ permalink raw reply [flat|nested] 24+ messages in thread