This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch gcc-4.0 should not apply mathematical associative rules for addition or multiplication


Geoff Keating <geoffk@geoffk.org> writes:

| On 05/10/2004, at 1:12 PM, Gabriel Dos Reis wrote:
| 
| > Geoffrey Keating <geoffk@geoffk.org> writes:
| >
| > [...]
| >
| > | > + static inline bool
| > | > + associative_fp_binop (tree exp)
| > | > + {
| > | > +   enum tree_code code = TREE_CODE (exp);
| > | > +   return !(!flag_unsafe_math_optimizations
| > |
| > | This flag is not clearly the right one.  Why did you pick it from the
| > | alternatives?
| >
| > That flag is clearly the right flag to pick.  See the explanation he
| > gave.
| > It contains an example that illustrates the problem too.
| 
| Fariborz said
| 
| > For different values of "x" this leads to undeserved or absent
| > floating point exceptions
| 
| So, why not flag_trapping_math?

Because fundamentally the rearragement leads to wrong code generation
which implies that, you get floating point exception if the result
raises an exception -- but it could be a finite value completely wrong
that leads your airplane crash later.  The exception is just *one*
manifestation of that wrongness.  So testing for flag_trapping_math is wrong.

|  The case involves an infinity, what
| about flag_finite_math_only?

Because the result could be finite but wrong.  So testing for
flag_trapping is wrong.

Really, the issue is straight.  The flag hee tested was the right to pick.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]