[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||dilyan.palauzov at aegee dot 
org

--- Comment #231 from Andrew Pinski  ---
*** Bug 113679 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #230 from Andrew Pinski  ---
*** Bug 110622 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[malat at debian dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Mathieu Malaterre  changed:

   What|Removed |Added

 CC||malat at debian dot org

--- Comment #229 from Mathieu Malaterre  ---
*** Bug 110622 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[vincent-gcc at vinc17 dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #228 from Vincent Lefèvre  ---
PR64410 and PR68180 should also be removed from "See Also".

[Bug middle-end/323] optimized code gives strange floating point results

[vincent-gcc at vinc17 dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #227 from Vincent Lefèvre  ---
In "See Also", there are several bugs that are related only to vectorization
optimizations. What is the relation with this bug?

For instance, PR89653 is "GCC (trunk and all earlier versions) fails to
vectorize (SSE/AVX2/AVX-512) the following loop [...]". If this is
SSE/AVX2/AVX-512, where does x86 extended precision occur?

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||drh at sqlite dot org

--- Comment #226 from Andrew Pinski  ---
*** Bug 110564 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #225 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:98e341130f87984af07c884fea773c0bb3cc8821

commit r13-3290-g98e341130f87984af07c884fea773c0bb3cc8821
Author: Jakub Jelinek 
Date:   Fri Oct 14 09:28:57 2022 +0200

c++: Implement excess precision support for C++ [PR107097, PR323]

The following patch implements excess precision support for C++.
Like for C, it uses EXCESS_PRECISION_EXPR tree to say that its operand
is evaluated in excess precision and what the semantic type of the
expression is.
In most places I've followed what the C FE does in similar spots, so
e.g. for binary ops if one or both operands are already
EXCESS_PRECISION_EXPR, strip those away or for operations that might need
excess precision (+, -, *, /) check if the operands should use excess
precision and convert to that type and at the end wrap into
EXCESS_PRECISION_EXPR with the common semantic type.
This patch follows the C99 handling where it differs from C11 handling.

There are some cases which needed to be handled differently, the C FE can
just strip EXCESS_PRECISION_EXPR (replace it with its operand) when
handling
explicit cast, but that IMHO isn't right for C++ - the discovery what exact
conversion should be used (e.g. if user conversion or standard or their
sequence) should be decided based on the semantic type (i.e. type of
EXCESS_PRECISION_EXPR), and that decision continues in convert_like* where
we pick the right user conversion, again, if say some class has ctor
from double and long double and we are on ia32 with standard excess
precision promoting float/double to long double, then we should pick the
ctor from double.  Or when some other class has ctor from just double,
and EXCESS_PRECISION_EXPR semantic type is float, we should choose the
user ctor from double, but actually just convert the long double excess
precision to double and not to float first.  We need to make sure
even identity conversion converts from excess precision to the semantic one
though, but if identity is chained with other conversions, we don't want
the identity next_conversion to drop to semantic precision only to widen
afterwards.

The existing testcases tweaks were for cases on i686-linux where excess
precision breaks those tests, e.g. if we have
  double d = 4.2;
  if (d == 4.2)
then it does the expected thing only with -fexcess-precision=fast,
because with -fexcess-precision=standard it is actually
  double d = 4.2;
  if ((long double) d == 4.2L)
where 4.2L is different from 4.2.  I've added -fexcess-precision=fast
to some tests and changed other tests to use constants that are exactly
representable and don't suffer from these excess precision issues.

There is one exception, pr68180.C looks like a bug in the patch which is
also present in the C FE (so I'd like to get it resolved incrementally
in both).  Reduced testcase:
typedef float __attribute__((vector_size (16))) float32x4_t;
float32x4_t foo(float32x4_t x, float y) { return x + y; }
with -m32 -std=c11 -Wno-psabi or -m32 -std=c++17 -Wno-psabi
it is rejected with:
pr68180.c:2:52: error: conversion of scalar âlong doubleâ to vector
âfloat32x4_tâ {aka â__vector(4) floatâ} involves truncation
but without excess precision (say just -std=c11 -Wno-psabi or -std=c++17
-Wno-psabi)
it is accepted.  Perhaps we should pass down the semantic type to
scalar_to_vector and use the semantic type rather than excess precision
type
in the diagnostics.

2022-10-14  Jakub Jelinek  

PR middle-end/323
PR c++/107097
gcc/
* doc/invoke.texi (-fexcess-precision=standard): Mention that the
option now also works in C++.
gcc/c-family/
* c-common.def (EXCESS_PRECISION_EXPR): Remove comment part about
the tree being specific to C/ObjC.
* c-opts.cc (c_common_post_options): Handle flag_excess_precision
in C++ the same as in C.
* c-lex.cc (interpret_float): Set const_type to excess_precision ()
even for C++.
gcc/cp/
* parser.cc (cp_parser_primary_expression): Handle
EXCESS_PRECISION_EXPR with REAL_CST operand the same as REAL_CST.
* cvt.cc (cp_ep_convert_and_check): New function.
* call.cc (build_conditional_expr): Add excess precision support.
When type_after_usual_arithmetic_conversions returns
error_mark_node,
use gcc_checking_assert that it is because of uncomparable floating
point ranks instead of checking all those conditions and make it
work also with complex types.
(convert_like_internal): Likewise.  Add NESTED_P argument, pass
true
to recursive calls 

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||xeioexception at gmail dot com

--- Comment #224 from Andrew Pinski  ---
*** Bug 106165 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[timturnerc at yahoo dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Tim Turner  changed:

   What|Removed |Added

 CC||timturnerc at yahoo dot com

--- Comment #223 from Tim Turner  ---
/gdb/arch/arc.c:117:43:   required from here http://www.compilatori.com/
 /usr/include/c++/4.8.2/bits/hashtable_policy.h:195:39: error: no matching
https://www.mktrade.fi/ function for call to ‘std::pairhttp://www-look-4.com/
target_desc_deleter> >::pair(const arc_arch_features&, target_desc*&)’
  : _M_v(std::forward<_Args>(__args)...) { } http://www.acpirateradio.co.uk/
   ^ 
/usr/include/c++/4.8.2/bits/hashtable_policy.h:195:39: note: candidates are:
https://www.webb-dev.co.uk/
In file included from /usr/include/c++/4.8.2/utility:70:0,
 from /usr/include/c++/4.8.2/tuple:38,
http://www.logoarts.co.uk/
 from /usr/include/c++/4.8.2/functional:55, 
 from ../../gdb/../gdbsupport/ptid.h:35,
https://komiya-dental.com/
 from ../../gdb/../gdbsupport/common-defs.h:123,
 from ../../gdb/arch/arc.c:19: http://www.slipstone.co.uk/
/usr/include/c++/4.8.2/bits/stl_pair.h:206:9: note: templatehttp://the-hunters.org/  class ... _Args2, long
unsigned int ..._Indexes2> std::pair<_T1, http://embermanchester.uk/
_T2>::pair(std::tuple<_Args1 ...>&, std::tuple<_Args2 ...>&, std::_Index_tuple
http://fishingnewsletters.co.uk/
 <_Indexes1 ...>, std::_Index_tuple<_Indexes2 ...>)
 pair(tuple<_Args1...>&, tuple<_Args2...>&, http://connstr.net/
 ^
>8-
http://joerg.li/
Thanks to Tome de Vries' investigation, same fix applies in ARC's case as well:
8<- http://www.jopspeech.com/
diff --git a/gdb/arch/arc.c b/gdb/arch/arc.c
index 3808f9f..a5385ce 100644 http://www.go-mk-websites.co.uk/
--- a/gdb/arch/arc.c
+++ b/gdb/arch/arc.c http://www.wearelondonmade.com/
@@ -114,7 +114,7 @@ struct arc_arch_features_hasher
   target_desc *tdesc = arc_create_target_description (features);
https://waytowhatsnext.com/

   /* Add the newly created target description to the repertoire.  */
http://www.mconstantine.co.uk/
 -  arc_tdesc_cache.emplace (features, tdesc); http://www.iu-bloomington.com/
 +  arc_tdesc_cache.emplace (features, target_desc_up (tdesc));

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||c25devbiz at aol dot com

--- Comment #222 from Andrew Pinski  ---
*** Bug 103030 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[jessicaking07 at protonmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Jessica King  changed:

   What|Removed |Added

 CC||jessicaking07 at protonmail 
dot co
   ||m

--- Comment #221 from Jessica King  ---
If you have some problems with your computer and can't deal with all the
homework you need in time - Exclusivethesis can help you. You can dissertation
abstracts online https://exclusivethesis.com/dissertation-abstracts-online/ and
receive a high-quality work

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||kevin.glass at pnl dot gov

--- Comment #220 from Andrew Pinski  ---
*** Bug 30813 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||merkert at comcast dot net

--- Comment #219 from Andrew Pinski  ---
*** Bug 39128 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||vanyacpp at gmail dot com

--- Comment #218 from Andrew Pinski  ---
*** Bug 94852 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #217 from joseph at codesourcery dot com  ---
On Fri, 7 Feb 2020, vincent-gcc at vinc17 dot net wrote:

> According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
> the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think that
> the correct one is CONFIRMED.

That's generic Bugzilla documentation that's not relevant to the custom 
GCC configuration of bug states, which is documented at 
 (we also have NEW and ASSIGNED 
not CONFIRMED and IN_PROGRESS).  SUSPENDED is accurate for a bug that is 
explicitly known to be hard and not being worked on, for reasons other 
than waiting for further information from the submitter.  It's completely 
correct for this bug, which should be left as SUSPENDED unless someone 
decides to work on it and so changes it to ASSIGNED with themselves as 
assignee.

[Bug middle-end/323] optimized code gives strange floating point results

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #216 from Manuel López-Ibáñez  ---
(In reply to Vincent Lefèvre from comment #215)
> According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
> the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think that
> the correct one is CONFIRMED.

Those are not the main policies. They are here:
https://gcc.gnu.org/bugs/management.html

fields.html needs to be updated some day to match the actual fields used by GCC
(there is no CONFIRMED status, there is NEW) and the above policies.

This is one of those bugs that it is so broad, controversial and noisy that
almost no active developer is going to look at it. Bugs don't get fixed because
they are NEW. There are 6979 NEW bug reports right now and many of them will
never get fixed (1300 of them are more than 10 years old).

My humble suggestion for those interested in floating-point issues in GCC would
be to create self-contained specific bugs with minimised reproducible
testcases, a clear analysis of what GCC is doing wrong, what GCC should be
doing instead, and suggestions on how it could be fixed. If the bug just says
some variation of "optimized code gives strange floating point results", it
will end up here and probably nobody will ever look at it.

For Rich's specific bug report, the relevant discussion is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c127 and the expected fix is
known: Implement -fexcess-precision=standard for C++ as it was done for C.
Perhaps it would be useful to create a new PR that blocks this one that
analyses what needs to be done towards that specific goal, collects testcases,
etc. The main issue is not that this PR is not in the developers' radar. All
GCC developers working on the C/C++ FEs and optimizers are aware of the
infamous PR323 and of the solution suggested in comment 127.

The issue is simply that no one working on the C++ FE has the time or
motivation to implement -fexcess-precision=standard. If you are interested in
that, just study this email:
https://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html and do for C++ the
same steps that Joseph did C.

[Bug middle-end/323] optimized code gives strange floating point results

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #215 from Vincent Lefèvre  ---
According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think that
the correct one is CONFIRMED.

[Bug middle-end/323] optimized code gives strange floating point results

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #214 from Rich Felker  ---
I'm not particular in terms of the path it takes as long as this gets back to a
status where it's on the radar for fixing.

[Bug middle-end/323] optimized code gives strange floating point results

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #213 from Eric Gallager  ---
(In reply to Eric Gallager from comment #212)
> (In reply to Rich Felker from comment #211)
> > If new reports are going to be marked as duplicates of this, then can it
> > please be moved from SUSPENDED status to REOPENED? The situation is far
> > worse than what seems to have been realized last this was worked on, as
> > evidenced by pr 85957. These issues just came up again breaking real-world
> > software in https://github.com/OSGeo/PROJ/issues/1906
> 
> Uh... I'm not seeing "REOPENED" on the menu for possible statuses? Maybe a
> bug can only have the REOPENED status if it's actually been closed in the
> past, and this might not have actually been closed before? I thought this
> had been closed at one point, but it looks like I was wrong... Hold on, let
> me check the (very long) history for this bug...

OK, never mind, it looks like this bug has actually been closed before like I
thought originally; whether or not a bug can have its status changed to
REOPENED or not must depend on its current status, rather than any past status
it might have had... So, I guess I can either close it temporarily and then
immediately reopen it, or give it some other status. Which would you prefer?

[Bug middle-end/323] optimized code gives strange floating point results

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #212 from Eric Gallager  ---
(In reply to Rich Felker from comment #211)
> If new reports are going to be marked as duplicates of this, then can it
> please be moved from SUSPENDED status to REOPENED? The situation is far
> worse than what seems to have been realized last this was worked on, as
> evidenced by pr 85957. These issues just came up again breaking real-world
> software in https://github.com/OSGeo/PROJ/issues/1906

Uh... I'm not seeing "REOPENED" on the menu for possible statuses? Maybe a bug
can only have the REOPENED status if it's actually been closed in the past, and
this might not have actually been closed before? I thought this had been closed
at one point, but it looks like I was wrong... Hold on, let me check the (very
long) history for this bug...

[Bug middle-end/323] optimized code gives strange floating point results

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #211 from Rich Felker  ---
If new reports are going to be marked as duplicates of this, then can it please
be moved from SUSPENDED status to REOPENED? The situation is far worse than
what seems to have been realized last this was worked on, as evidenced by pr
85957. These issues just came up again breaking real-world software in
https://github.com/OSGeo/PROJ/issues/1906

[Bug middle-end/323] optimized code gives strange floating point results

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #210 from Rich Felker  ---
If new reports are going to be marked as duplicates of this, then can it please
be moved from SUSPENDED status to REOPENED? The situation is far worse than
what seems to have been realized last this was worked on, as evidenced by pr
85957. These issues just came up again breaking real-world software in
https://github.com/OSGeo/PROJ/issues/1906

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #209 from Andrew Pinski  ---
*** Bug 93620 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[castro8583bennett at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Carlo B.  changed:

   What|Removed |Added

 CC||castro8583bennett at gmx dot 
com

--- Comment #208 from Carlo B.  ---
Why not try some Loops my friend

Castro B,
http://gratisdatingsite.nl

[Bug middle-end/323] optimized code gives strange floating point results

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Jakub Jelinek  changed:

   What|Removed |Added

 CC||neha.gnu.gcc at gmail dot com

--- Comment #207 from Jakub Jelinek  ---
*** Bug 87128 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #206 from Andrew Pinski  ---
*** Bug 85957 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||lukeshu at lukeshu dot com

--- Comment #205 from Andrew Pinski  ---
*** Bug 85957 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||manuel.serrano at inria dot fr

--- Comment #204 from Andrew Pinski  ---
*** Bug 85661 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 CC||j.d.pryce at ntlworld dot com

--- Comment #203 from egallager at gcc dot gnu.org ---
*** Bug 34261 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski  changed:

   What|Removed |Added

 CC||theJ893 at gmail dot com

--- Comment #201 from Andrew Pinski  ---
*** Bug 62623 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Joseph S. Myers jsm28 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||timo.kreuzer at reactos dot org

--- Comment #200 from Joseph S. Myers jsm28 at gcc dot gnu.org ---
*** Bug 66282 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andreas Schwab sch...@linux-m68k.org changed:

   What|Removed |Added

 CC||friend1992friend1992@yandex
   ||.ru

--- Comment #199 from Andreas Schwab sch...@linux-m68k.org ---
*** Bug 64808 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #195 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Martin von Gagern from comment #193)
 Would it make sense to file one bug report per language, marking all of them
 as blocking this one here, so we can keep track of progress per language?
 I'm particularly interested in C++, but I guess others might care for other
 front-ends.

Feel free to do just that, specially if you are planning to work on it. This PR
has become too long and full of outdated info (and useless comments) to be
really useful.

[Bug middle-end/323] optimized code gives strange floating point results

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

URL||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=323#c127

--- Comment #196 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
I believe the latest status of this PR is explained by comment 127. I added
this as the URL of the bug for people to find.

Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general) is
seriously lacking info and outdated. From now on, I'll point people to:
https://gcc.gnu.org/wiki/FAQ#PR323

[Bug middle-end/323] optimized code gives strange floating point results

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #197 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Manuel López-Ibáñez from comment #196)
 Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general)
 is seriously lacking info and outdated. From now on, I'll point people to:
 https://gcc.gnu.org/wiki/FAQ#PR323

Note that this bug was mainly about the excess precision of x87 FPU, though its
summary just says optimized code gives strange floating point results. But
the users should be aware that the floating-point results can still depend on
the optimization level because this is allowed by the ISO C standard. For
instance, if one has code like x*y+z, a FMA can be used or not depending on the
target architecture and the optimization level (see also bug 37845 about this),
and this can change the results.

[Bug middle-end/323] optimized code gives strange floating point results

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- Comment #198 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Vincent Lefèvre from comment #197)
 (In reply to Manuel López-Ibáñez from comment #196)
  Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general)
  is seriously lacking info and outdated. From now on, I'll point people to:
  https://gcc.gnu.org/wiki/FAQ#PR323
 
 Note that this bug was mainly about the excess precision of x87 FPU, though

I added your comment to the FAQ but feel welcome to extend it:
https://gcc.gnu.org/wiki/FAQ#PR323

What it is also missing is a criteria to distinguish normal behavior from
actual GCC bugs (and there are GCC bugs like bug 37845 and others for
optimizations that should only be done with ffast-math). Currently, any
floating-point issue is likely to end up here.

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||meidingerc1 at gmail dot com

--- Comment #194 from Andrew Pinski pinskia at gcc dot gnu.org ---
*** Bug 61626 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[Martin.vGagern at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Martin von Gagern Martin.vGagern at gmx dot net changed:

   What|Removed |Added

 CC||Martin.vGagern at gmx dot net

--- Comment #193 from Martin von Gagern Martin.vGagern at gmx dot net ---
(In reply to Joseph S. Myers from comment #127)
   It would be possible to implement the option for non-C languages, to
   provide whatever predictable semantics are appropriate for those
   languages (whether or not described in their standards).  Note that
   bug 323 was originally reported with a C++ testcase.  […]  It
   would probably be most appropriate not to close bug 323 without having
   some form of predictable semantics available for each language.

Would it make sense to file one bug report per language, marking all of them as
blocking this one here, so we can keep track of progress per language? I'm
particularly interested in C++, but I guess others might care for other
front-ends.

[Bug middle-end/323] optimized code gives strange floating point results

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 CC||sarantis.pantazis at gmail dot 
com

--- Comment #192 from Dominique d'Humieres dominiq at lps dot ens.fr ---
*** Bug 59168 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||oliverst at online dot de

--- Comment #191 from Richard Biener rguenth at gcc dot gnu.org ---
*** Bug 57669 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[ondrej at sury dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Ondřej Surý ondrej at sury dot org changed:

   What|Removed |Added

 CC||ondrej at sury dot org

--- Comment #190 from Ondřej Surý ondrej at sury dot org 2013-04-26 16:07:17 
UTC ---
*** Bug 57080 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 CC||mikpe at it dot uu.se



--- Comment #189 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-30 
08:57:24 UTC ---

*** Bug 55939 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 CC||tasin at hm dot edu



--- Comment #188 from Richard Biener rguenth at gcc dot gnu.org 2012-12-31 
16:12:05 UTC ---

*** Bug 55787 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[soren.sandmann at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Søren Sandmann Pedersen soren.sandmann at gmail dot com changed:

   What|Removed |Added

 CC||soren.sandmann at gmail dot
   ||com

--- Comment #187 from Søren Sandmann Pedersen soren.sandmann at gmail dot com 
2012-12-15 02:09:20 UTC ---
*** Bug 55700 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323



Andrew Pinski pinskia at gcc dot gnu.org changed:



   What|Removed |Added



 CC||joerg.rich...@pdv-fs.de



--- Comment #186 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-30 
18:06:40 UTC ---

*** Bug 55544 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 CC||jkuittinen293482 at gmail

   ||dot com



--- Comment #185 from Paolo Carlini paolo.carlini at oracle dot com 
2012-11-12 14:53:28 UTC ---

*** Bug 55267 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||JoaquinMonleon at gmail dot
   ||com

--- Comment #184 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-24 
08:08:06 UTC ---
*** Bug 53095 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||dov.grobgeld at gmail dot
   ||com

--- Comment #183 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-13 
06:28:44 UTC ---
*** Bug 38777 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||juanval at gmail dot com

--- Comment #182 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-22 
15:15:24 UTC ---
*** Bug 48236 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[acfbuerger at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Alexander Bürger acfbuerger at googlemail dot com changed:

   What|Removed |Added

 CC||acfbuerger at googlemail
   ||dot com

--- Comment #181 from Alexander Bürger acfbuerger at googlemail dot com 
2011-03-08 19:08:38 UTC ---
*** Bug 47600 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||stenedjo at gmail dot com

--- Comment #180 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 
12:35:53 UTC ---
*** Bug 47834 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ichudov at algebra dot com

--- Comment #179 from Andrew Pinski pinskia at gcc dot gnu.org 2011-01-13 
22:06:14 UTC ---
*** Bug 47282 has been marked as a duplicate of this bug. ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #140 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-05 
18:45:34 UTC ---
*** Bug 45899 has been marked as a duplicate of this bug. ***