Re: What is acceptable for -ffast-math? (Was: associative law in combine)

[Kevin Handy <kth at srv dot net>]

Alexandre Oliva wrote:
> 
> On Jul 30, 2001, dewar@gnat.com wrote:
> 
> > <<I am serious.  The preprocessor should protect individual parentheses
> > from becoming consecutive by introducing whitespace.  We should tell:
> >>>
> 
> > Sometimes I must say that people seem to work hard to dream up the most
> > infeasible and ugly syntactical ideas that one could possibly imagine :-)
> 
> :-)
> 
> Would you prefer
> 
> __extension__ __attribute__ ((optimize=0)) (a*b) +
> __extension__ __attribute__ ((optimize=0)) (a*c)
> 
> ? :-)
> 
> I'd much rather write ((a*b)) + ((a*c)), which will even compile with
> other compilers, and might be picked up in a future revision of the C
> and C++ Standards.

I'd think that trying to write a parser for this would be much
harder than necessary. You'd have to be able to handle

   ((a*b) + (a*c))

as well as

   ((a*b) + c)

and what about three parentheses

   (((a * b) +  c) + (a*d))

and you'd have to keep track of which parentheses had another
parentheses attached to them (both before and after), or track 
white space as part of the parsing.

If you want to use something like

   __extension__ __attribute__ ((optimize=0)) (a*b) + (a*c)

you could always wrap it in a macro

   #define noopt(x) __extension__ __attribute__ ((optimize=0)) (x)

   noopt((a*b) + (a*c))

which would give the benefit to non-gcc users that you could document
what it means, and if other compilers had other ways of specifying
the same thing, you could handle it in macros.