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



On 05/10/2004, at 2:04 PM, Gabriel Dos Reis wrote:


Geoff Keating <geoffk@geoffk.org> writes:

| On 05/10/2004, at 1:04 PM, Fariborz Jahanian wrote:
|
| >>> + && (code == MULT_EXPR || code == PLUS_EXPR)
| >>> + && FLOAT_TYPE_P (TREE_TYPE (exp)));
| >>
| >> This function appears to disallow folding
| >>
| >> (x * 2.0) * 2.0
| >>
| >> into
| >>
| >> x * 4.0
| >>
| >> which seems to me to be valid.
| >
| > Wording of ANSIC disallows such foldings even if it is safe sometimes.
|
| Could you explain why you think the standard says this? The quote you
| gave said "In the following fragment, rearrangements suggested by
| mathematical rules for real numbers are often not valid" but it did
| not say that they were *always* not valid.


But it does not say they are always valid either.

Are you claiming that the folding I describe above is *not* valid?


I'm having real trouble following your logic.

I pointed out that the standard says ! forall (rearrangement, is valid) and that Fariborz was claiming that forall (rearrangement, ! is valid), and that this does not follow. I also pointed out that exists (rearrangement, is valid), which implies ! forall (rearrangement, ! is valid).


We apply transformations under the name of optimizations only when we
know that they are always valid under the usual conditions.  Here,
the reassociation is a general unsafe transformation for floating
point data type.

No, we don't! Nearly every optimisation we make is not valid under "usual conditions". What we do is we test to see whether the proper conditions for the optimisation are met, so that if the test succeeds the optimization is valid under *all* conditions.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


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