public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* optimization/3186: behaviour of -ffloat-store seems reversed
@ 2001-06-14 11:26 mac
  0 siblings, 0 replies; 2+ messages in thread
From: mac @ 2001-06-14 11:26 UTC (permalink / raw)
  To: gcc-gnats

>Number:         3186
>Category:       optimization
>Synopsis:       behaviour of -ffloat-store seems reversed
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 14 11:26:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Maciej Kalisiak
>Release:        2.95.4 (in fact, all the versions I've looked at)
>Organization:
>Environment:
Linux 2.2.19, Intel Pentium III.
>Description:
It appears to me that the -ffloat-store flag does the
reverse of what appears in the documentation.

I'm not sure whether this is a SW bug or a documentation
mistake, or just my misunderstanding of the manual page.
>How-To-Repeat:
Compile float.cc once with "-O3", and once with "-O3
-ffloat-store".  You'll notice that for the binary compiled
only with "-O3", the float result is less precise than 
the double result,  while in the "-O3 -ffloat-store" case,
the float result is identical to the double result.  It
appears then that the calculations with -ffloat-store have
higher precision, as if -ffloat-store caused the float
temporary results to be read in from the higher-precision
registers, rather than pulling them in from memory.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="float.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="float.cc"

I2luY2x1ZGUgPGlvc3RyZWFtPgoKdm9pZApkb3VibGVzKCkKewogIGRvdWJsZSBpdmFsPTEyODsJ
CS8vIGkKICBkb3VibGUgQjAwMD0xMzYuNzAzMTI1MDA7CS8vIGEKICBkb3VibGUgQjAwMT0xMjUu
NDY4NzUwMDA7CS8vIGIKICBkb3VibGUgQjAxMD0xMjUuNDY4NzUwMDA7CS8vIGMKICBkb3VibGUg
QjAxMT0xMjguNTYyNTAwMDA7CS8vIGQKICBkb3VibGUgQjEwMD0xMjUuNDY4NzUwMDA7CS8vIGUK
ICBkb3VibGUgQjEwMT0xMjguNTYyNTAwMDA7CS8vIGYKICBkb3VibGUgQjExMD0xMjguNTYyNTAw
MDA7CS8vIGcKICBkb3VibGUgQjExMT0xMzEuMzc1MDAwMDA7CS8vIGgKICBkb3VibGUgQXQgPSAt
IEIxMTAqQjAxMSAtIEIxMDAqQjAwMSArIEIxMDAqQjAxMSArIEIxMTAqQjAwMQogICAgICAgICAg
ICAgIC0gQjAwMCpCMTExIC0gQjAxMCpCMTAxICsgQjAxMCpCMTExICsgQjAwMCpCMTAxOwogIGRv
dWJsZSBCdCA9IC0gaXZhbCpCMDAxICsgaXZhbCpCMDExIC0gaXZhbCpCMTAwICsgaXZhbCpCMTEw
CiAgICAgICAgICAgICAgLSBCMTEwKkIwMDEgKyBpdmFsKkIwMDAgLSBpdmFsKkIwMTAgKyBpdmFs
KkIxMDEKICAgICAgICAgICAgICAtIDIqQjAwMCpCMTAxICsgQjAwMCpCMTExICsgQjAxMCpCMTAx
ICsgMipCMTAwKkIwMDEKICAgICAgICAgICAgICAtIEIxMDAqQjAxMSAtIGl2YWwqQjExMTsKICBk
b3VibGUgQ3QgPSAgIEIwMDAqQjEwMSAtIEIxMDAqQjAwMSAtIGl2YWwqQjAwMCArIGl2YWwqQjAw
MQogICAgICAgICAgICAgICsgaXZhbCpCMTAwIC0gaXZhbCpCMTAxOwogIGNvdXQgPDwgQXQgPDwg
IiAiIDw8IEJ0IDw8ICIgIiA8PCBDdCA8PCBlbmRsOwp9CgoKdm9pZApmbG9hdHMoKQp7CiAgZmxv
YXQgaXZhbD0xMjg7CiAgZmxvYXQgQjAwMD0xMzYuNzAzMTI1MDA7CS8vIGEKICBmbG9hdCBCMDAx
PTEyNS40Njg3NTAwMDsJLy8gYgogIGZsb2F0IEIwMTA9MTI1LjQ2ODc1MDAwOwkvLyBjCiAgZmxv
YXQgQjAxMT0xMjguNTYyNTAwMDA7CS8vIGQKICBmbG9hdCBCMTAwPTEyNS40Njg3NTAwMDsJLy8g
ZQogIGZsb2F0IEIxMDE9MTI4LjU2MjUwMDAwOwkvLyBmCiAgZmxvYXQgQjExMD0xMjguNTYyNTAw
MDA7CS8vIGcKICBmbG9hdCBCMTExPTEzMS4zNzUwMDAwMDsJLy8gaAogIGZsb2F0IEF0ID0gLSBC
MTEwKkIwMTEgLSBCMTAwKkIwMDEgKyBCMTAwKkIwMTEgKyBCMTEwKkIwMDEKICAgICAgICAgICAg
ICAtIEIwMDAqQjExMSAtIEIwMTAqQjEwMSArIEIwMTAqQjExMSArIEIwMDAqQjEwMTsKICBmbG9h
dCBCdCA9IC0gaXZhbCpCMDAxICsgaXZhbCpCMDExIC0gaXZhbCpCMTAwICsgaXZhbCpCMTEwCiAg
ICAgICAgICAgICAgLSBCMTEwKkIwMDEgKyBpdmFsKkIwMDAgLSBpdmFsKkIwMTAgKyBpdmFsKkIx
MDEKICAgICAgICAgICAgICAtIDIqQjAwMCpCMTAxICsgQjAwMCpCMTExICsgQjAxMCpCMTAxICsg
MipCMTAwKkIwMDEKICAgICAgICAgICAgICAtIEIxMDAqQjAxMSAtIGl2YWwqQjExMTsKICBmbG9h
dCBDdCA9ICAgQjAwMCpCMTAxIC0gQjEwMCpCMDAxIC0gaXZhbCpCMDAwICsgaXZhbCpCMDAxCiAg
ICAgICAgICAgICAgKyBpdmFsKkIxMDAgLSBpdmFsKkIxMDE7CiAgY291dCA8PCBBdCA8PCAiICIg
PDwgQnQgPDwgIiAiIDw8IEN0IDw8IGVuZGw7Cn0KCgptYWluKCkKewogIGNvdXQucHJlY2lzaW9u
KDEwKTsKICBjb3V0LmZsYWdzKGlvczo6Zml4ZWQpOwoKICBjb3V0IDw8ICJEb3VibGVzOiIgPDwg
ZW5kbDsKICBkb3VibGVzKCk7CgogIGNvdXQgPDwgIkZsb2F0czoiIDw8IGVuZGw7CiAgZmxvYXRz
KCk7CiAgCiAgZXhpdCgxKTsKfQo=


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: optimization/3186: behaviour of -ffloat-store seems reversed
@ 2002-04-02  1:41 rth
  0 siblings, 0 replies; 2+ messages in thread
From: rth @ 2002-04-02  1:41 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, mac, nobody

Synopsis: behaviour of -ffloat-store seems reversed

State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Tue Apr  2 01:41:37 2002
State-Changed-Why:
    -ffloat-store only affects assignments to variables.
    You're computing everything in single expressions.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3186


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-04-02  9:41 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-14 11:26 optimization/3186: behaviour of -ffloat-store seems reversed mac
2002-04-02  1:41 rth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).