Re: [PATCH] Optimize abs(x) < 0.0

Re: [PATCH] Optimize abs(x) < 0.0

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

For the sh64 target, this optimization fails when using software
floating point, and for -m5-compact [-ml].

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

[-- Attachment #2: 20020720-1.c-failures --]
[-- Type: text/plain, Size: 4570 bytes --]

grep -c 'FAIL: gcc.c-torture/execute/20020720-1.c compilation' testsuite-m5*/gcc.log
testsuite-m5-32media-nofpu/gcc.log:5
testsuite-m5-32media-nofpu-ml/gcc.log:5
testsuite-m5-64media/gcc.log:0
testsuite-m5-64media-ml/gcc.log:0
testsuite-m5-64media-nofpu/gcc.log:5
testsuite-m5-64media-nofpu-ml/gcc.log:5
testsuite-m5-compact/gcc.log:5
testsuite-m5-compact-ml/gcc.log:5
testsuite-m5-compact-nofpu/gcc.log:5
testsuite-m5-compact-nofpu-ml/gcc.log:5
testsuite-m5/gcc.log:0
testsuite-m5-ml/gcc.log:0

grep 'FAIL: gcc.c-torture/execute/20020720-1.c compilation' testsuite-m5*/gcc.log
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O1 
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O2 
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -fomit-frame-pointer 
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -g 
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -Os 
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O1 
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O2 
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -fomit-frame-pointer 
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -g 
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -Os 
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O1 
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O2 
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -fomit-frame-pointer 
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -g 
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -Os 
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O1 
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O2 
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -fomit-frame-pointer 
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -g 
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -Os 
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O1 
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O2 
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -fomit-frame-pointer 
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -g 
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -Os 
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O1 
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O2 
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -fomit-frame-pointer 
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -g 
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -Os 
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O1 
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O2 
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -fomit-frame-pointer 
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -g 
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -Os 
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O1 
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O2 
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -fomit-frame-pointer 
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -O3 -g 
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation,  -Os 

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

> For the sh64 target, this optimization fails when using software
> floating point, and for -m5-compact [-ml].

Oh well.  It looks like its just a fact of life that some GCC
backends allow more optimizations than others.  Probably best
to just delete the testcase for the time being.

Ok for mainline?


2002-07-23  Roger Sayle  <roger@eyesopen.com>

	* gcc.c-torture/execute/20020720-1.c: Delete testcase as not
	all machine descriptions expose optimization opportunity.


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: [PATCH] Optimize abs(x) < 0.0

[Andrew Pinski]

What about disabling the case for the ones that fail, right now?

Thanks,
Andrew Pinski

On Tuesday, July 23, 2002, at 09:26 , Roger Sayle wrote:

> gcc.c-torture/execute/20020720-1.c

Re: [PATCH] Optimize abs(x) < 0.0

[Richard Henderson]

On Tue, Jul 23, 2002 at 07:26:50PM -0600, Roger Sayle wrote:
> 	* gcc.c-torture/execute/20020720-1.c: Delete testcase as not
> 	all machine descriptions expose optimization opportunity.

You could move it to gcc.dg, and control based on the
platforms for which it is known to work.  That way you
can at least detect regressions.


r~

Re: [PATCH] Optimize abs(x) < 0.0

[Kaveh R. Ghazi]

 > From: Richard Henderson
 > 
 > On Tue, Jul 23, 2002 at 07:26:50PM -0600, Roger Sayle wrote:
 > >  * gcc.c-torture/execute/20020720-1.c: Delete testcase as not
 > >  all machine descriptions expose optimization opportunity.
 > 
 > You could move it to gcc.dg, and control based on the
 > platforms for which it is known to work.  That way you
 > can at least detect regressions.
 > r~

No need to move the test, you can XFAIL from within the
gcc.c-torture/execute directory also.

E.g. see execute/20020227-1.x et al.


--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

Hi Joern and David,

I was wondering if you could please test the following patch to
mark gcc.c-torture/execute/20020720-1.c as XFAIL on your platforms.
I've checked that this doesn't break "make check" on i686-pc-linux-gnu
but I have absolutely no idea whether it has any other effect on
any other platform :>

I'd also appreciate it if somebody on the mailing list that understands
how these things are supposed to work could confirm that the file below
does whats intended.

Many thanks in advance,


2002-07-23  Roger Sayle  <roger@eyesopen.com>

	* gcc.c-torture/execute/20020720-1.x: Mark MIPS, AIX and
	some compiler flags on sh64 as XFAIL.


*** /dev/null	Thu Aug 30 14:30:55 2001
--- gcc.c-torture/execute/20020720-1.x	Tue Jul 23 21:25:22 2002
***************
*** 0 ****
--- 1,15 ----
+ # This test has been reported to fail on AIX and MIPS.
+ if { [istarget "powerpc-*-aix*"] || [istarget "rs6000-*-aix*"] \
+      || [istarget "mips*-*-*"] } {
+     set torture_execute_xfail [istarget]
+ }
+
+ # This test has also been reported to fail on sh64 with specific flags
+ if { [istarget "sh64*-*-*"] } {
+     if { [string match "*nofpu*" $CFLAGS] \
+          || [string match "*compact*" $CFLAGS] } {
+         set torture_execute_xfail [istarget]
+     }
+ }
+
+ return 0

Roger
--

Re: [PATCH] Optimize abs(x) < 0.0

[Kaveh R. Ghazi]

 > From: Roger Sayle <roger@eyesopen.com>
 > 
 > I'd also appreciate it if somebody on the mailing list that
 > understands how these things are supposed to work could confirm that
 > the file below does whats intended.
 > 
 > *** /dev/null	Thu Aug 30 14:30:55 2001
 > --- gcc.c-torture/execute/20020720-1.x	Tue Jul 23 21:25:22 2002
 > ***************
 > *** 0 ****
 > --- 1,15 ----
 > + # This test has been reported to fail on AIX and MIPS.
 > + if { [istarget "powerpc-*-aix*"] || [istarget "rs6000-*-aix*"] \
 > +      || [istarget "mips*-*-*"] } {
 > +     set torture_execute_xfail [istarget]
 > + }

I'm pretty sure that your testcase always succeeds at -O0 in which
case the above will spuriously yield an XPASS at -O0.  I *think* that
if instead of setting torture_execute_xfail you "return 1" it'll
bypass the test entirely rather than run it and that should give you
clean results.  But I could be wrong.

Note you *can* test the .x file by putting your target in the list and
inserting a syntax error into the testcase.  That will test whether
the xfail is setup properly.


 > + # This test has also been reported to fail on sh64 with specific flags
 > + if { [istarget "sh64*-*-*"] } {
 > +     if { [string match "*nofpu*" $CFLAGS] \
 > +          || [string match "*compact*" $CFLAGS] } {
 > +         set torture_execute_xfail [istarget]
 > +     }
 > + }
 > +
 > + return 0

This may not work, I seem to recall that CFLAGS doesn't always contain
what you want.  Instead try using torture_eval_before_execute &
compiler_conditional_xfail_data.  Again, see execute/20020227-1.x.

		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

Hi Kaveh,
> I'm pretty sure that your testcase always succeeds at -O0 in which
> case the above will spuriously yield an XPASS at -O0.  I *think* that
> if instead of setting torture_execute_xfail you "return 1" it'll
> bypass the test entirely rather than run it and that should give you
> clean results.  But I could be wrong.

Thanks for taking a look at this.  And yes the test case would XPASS at
-O0.  I've made the suggested changes to "return 1" in my local copy.

> > + # This test has also been reported to fail on sh64 with specific flags
> > + if { [istarget "sh64*-*-*"] } {
> > +     if { [string match "*nofpu*" $CFLAGS] \
> > +          || [string match "*compact*" $CFLAGS] } {
> > +         set torture_execute_xfail [istarget]
> > +     }
> > + }
> > +
> > + return 0
>
> This may not work, I seem to recall that CFLAGS doesn't always contain
> what you want.  Instead try using torture_eval_before_execute &
> compiler_conditional_xfail_data.  Again, see execute/20020227-1.x.

This issue I'd like to leave to Joern.  The SH test results posted
to the gcc-testresults list don't show the problem, and the compiler
flags that cause the sh64 failures weren't mentioned in Joern's posting
and aren't described in the GCC documentation.  Hopefully Joern can
determine if the the substrings above appear in the $CFLAGS with the
invocations he uses.

Roger
--

Re: [PATCH] Optimize abs(x) < 0.0

[Joern Rennecke]

Roger Sayle wrote:
> > This may not work, I seem to recall that CFLAGS doesn't always contain
> > what you want.  Instead try using torture_eval_before_execute &
> > compiler_conditional_xfail_data.  Again, see execute/20020227-1.x.
> 
> This issue I'd like to leave to Joern.  The SH test results posted
> to the gcc-testresults list don't show the problem, and the compiler
> flags that cause the sh64 failures weren't mentioned in Joern's posting
> and aren't described in the GCC documentation.  Hopefully Joern can
> determine if the the substrings above appear in the $CFLAGS with the
> invocations he uses.

I've tested your patch, and it doesn't work.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

After building a toolchain and cross-compiler to sh-elf and running
the testsuite on the sh-hms-sim simulator, I've discovered that the
testcase also fails on vanilla "sh-*-*" without any special compiler
options for me.

I've tested the patch below on the sh-hms-sim simulator and confirmed
that the 20020720-1.c tests no longer appear in the list of failures.
This revision lists all the targets I currently know to fail.

Ok for mainline?

[I also believe that I may yet be able to implement this optimization
on some of the failing targets with a patch to combine.c that implements
a four instruction combination.]


2002-07-23  Roger Sayle  <roger@eyesopen.com>

	gcc.c-torture/execute/20020720-1.x: Skip this test on
	several targets known to fail.


*** /dev/null	Thu Aug 30 14:30:55 2001
--- gcc.c-torture/execute/20020720-1.x	Wed Jul 24 20:28:03 2002
***************
*** 0 ****
--- 1,8 ----
+ # This test, 20020720-1.c, fails on the following targets:
+ if { [istarget "powerpc-*-aix*"] || [istarget "rs6000-*-aix*"] \
+      || [istarget "mips*-*-*"] || [istarget "xtensa-*-*"] \
+      || [istarget "sh-*-*"] } {
+     return 1
+ }
+
+ return 0

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: [PATCH] Optimize abs(x) < 0.0

[Richard Henderson]

On Wed, Jul 24, 2002 at 10:33:31PM -0600, Roger Sayle wrote:
> + # This test, 20020720-1.c, fails on the following targets:

Please expand on the reasons why the test fails.  That it fails
is obvious from the fact that we're attempting not to test it.


r~

Re: [PATCH] Optimize abs(x) < 0.0

[Bob Wilson]

Richard Henderson wrote:
> On Wed, Jul 24, 2002 at 10:33:31PM -0600, Roger Sayle wrote:
> 
>>+ # This test, 20020720-1.c, fails on the following targets:
> 
> 
> Please expand on the reasons why the test fails.  That it fails
> is obvious from the fact that we're attempting not to test it.

I haven't investigated the Xtensa failure in detail, but I assume it is because 
the default Xtensa processor configuration does not include hardware support for 
floating-point operations.  The RTL will never contain FLOAT_EXTEND operations 
and Roger's patch has no effect.  It doesn't hurt anything, either, except that 
the test requires the call to link_error() be optimized away and that doesn't 
happen.

--Bob

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

Hi Richard,
> Please expand on the reasons why the test fails.  That it fails
> is obvious from the fact that we're attempting not to test it.

How about the following?  I guess I must have been (un)lucky that
the two platforms that I tested my original patch on (alpha and
i386) where able to handle the test case without difficulty.  As
I mentioned in my previous mail, I'm working on a patch that should
also fix the powerpc failures.


2002-07-25  Roger Sayle  <roger@eyesopen.com>

        gcc.c-torture/execute/20020720-1.x: Skip this test on
        several targets known to fail.


*** /dev/null	Thu Aug 30 14:30:55 2001
--- 20020720-1.x	Thu Jul 25 15:17:22 2002
***************
*** 0 ****
--- 1,16 ----
+ # The following targets fail 20020720-1.c for several reasons:
+ # (1) They implement floating point instructions via software, or
+ # (2) Their machine descriptions obfuscate the "abs(x) < 0.0" comparison.
+ #     For example, 1 insn performs abs, 1 insn loads 0.0, 1 insn sets
+ #     CC mode flags based upon the FP comparison, and a 4th insn makes
+ #     a conditional branch based upon the appropriate bits in the flags.
+ #     If the intermediate comparison can't be recognized, the combiner
+ #     is unable to optimize all four RTL instructions simultaneously.
+
+ if { [istarget "powerpc-*-*"] || [istarget "rs6000-*-*"] \
+      || [istarget "mips*-*-*"] || [istarget "xtensa-*-*"] \
+      || [istarget "sh-*-*"] } {
+     return 1
+ }
+
+ return 0

Roger
--

Re: [PATCH] Optimize abs(x) < 0.0

[Richard Henderson]

On Thu, Jul 25, 2002 at 03:24:38PM -0600, Roger Sayle wrote:
> I mentioned in my previous mail, I'm working on a patch that should
> also fix the powerpc failures.

If this is about making combine match 4 insns, don't.
That'll touch write-only code for sure.

Better to have the abs patterns split post-reload.

>         gcc.c-torture/execute/20020720-1.x: Skip this test on
>         several targets known to fail.

Ok.


r~

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

On Thu, 25 Jul 2002, Richard Henderson wrote:
> On Thu, Jul 25, 2002 at 03:24:38PM -0600, Roger Sayle wrote:
> > I mentioned in my previous mail, I'm working on a patch that should
> > also fix the powerpc failures.
>
> If this is about making combine match 4 insns, don't.
> That'll touch write-only code for sure.
>
> Better to have the abs patterns split post-reload.

The plan is actually not that intrusive.  Rather then generic 4
insn matching in combine, I'm hoping to tweak simplify_set which
already identifies the "fourth" CCmode user instruction via
"cc_use = find_single_use(...)".  Then before calling the
function simplify_comparison, which doesn't handle always
true/always false comparisons, call simplify_relational_operation
which does.  If simplify_relational_operation returns non-NULL,
we can delete the current insn and optimize its use at cc_use.

Its using combine's SUBST machinery to delete the current insn
and optimize cc_use via undobuf.other_insn thats just beyond my
current skill level.  For example, I'm unsure if combine/recog
can handle/recognize INSN_DELETED notes.


> >     gcc.c-torture/execute/20020720-1.x: Skip this test on
> >     several targets known to fail.
>
> Ok.

Many thanks.  Applied.

Roger
--

Re: [PATCH] Optimize abs(x) < 0.0

[Bob Wilson]

This test should also be skipped or marked as XFAIL for -O1 and higher
optimization levels for xtensa-*-* targets.  If you haven't yet
committed the patch, please add that.  Otherwise, let me know and I'll
add it separately.

--Bob

> I was wondering if you could please test the following patch to
> mark gcc.c-torture/execute/20020720-1.c as XFAIL on your platforms.
> I've checked that this doesn't break "make check" on i686-pc-linux-gnu
> but I have absolutely no idea whether it has any other effect on
> any other platform :>
> 
> I'd also appreciate it if somebody on the mailing list that understands
> how these things are supposed to work could confirm that the file below
> does whats intended.
> 
> Many thanks in advance,
> 
> 
> 2002-07-23  Roger Sayle  <roger@eyesopen.com>
> 
>         * gcc.c-torture/execute/20020720-1.x: Mark MIPS, AIX and
>         some compiler flags on sh64 as XFAIL.
> 
> 
> *** /dev/null   Thu Aug 30 14:30:55 2001
> --- gcc.c-torture/execute/20020720-1.x  Tue Jul 23 21:25:22 2002
> ***************
> *** 0 ****
> --- 1,15 ----
> + # This test has been reported to fail on AIX and MIPS.
> + if { [istarget "powerpc-*-aix*"] || [istarget "rs6000-*-aix*"] \
> +      || [istarget "mips*-*-*"] } {
> +     set torture_execute_xfail [istarget]
> + }
> +
> + # This test has also been reported to fail on sh64 with specific flags
> + if { [istarget "sh64*-*-*"] } {
> +     if { [string match "*nofpu*" $CFLAGS] \
> +          || [string match "*compact*" $CFLAGS] } {
> +         set torture_execute_xfail [istarget]
> +     }
> + }
> +
> + return 0

Re: [PATCH] Optimize abs(x) < 0.0

[David Edelsohn]

	It surprises me that this seems to work on PowerPC Linux, but not
AIX -- not even with I target a PowerPC processor instead of common mode
(in case that made a difference).

Thanks, David

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

> Your new testcase is fails on AIX for some reason.

Ahh!  As Richard Henderson had feared:
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01103.html

I'll see if there's anything I can do to fix it on the AIX
box I have here.  If I don't have a solution in a day or two,
we can either delete the test entirely or mark it XFAIL on
the powerpc.

Sorry for any inconvenience this may have caused.

Roger
--

Re: [PATCH] Optimize abs(x) < 0.0

[David Edelsohn]

	Your new testcase is fails on AIX for some reason.

David

Re: [PATCH] Optimize abs(x) < 0.0

[Gabriel Dos Reis]

Brad Lucier <lucier@math.purdue.edu> writes:

[...]

| > The proposed transformation doesn't preserve semantics in presence
| > of signaling NaNs. I suggest it to be applied only either unsafe-math
| > or say -fno-nan-values or whatever.
| 
| There is an option -fno-trapping-math that tells the compiler that
| the libraries are set up to do no trapping of floating-point arithmetic;
| perhaps the transformation should be predicated on this flag.

That is indeed a good suggestion.  Roger is working on a flag
-fsignaling-nan, maybe be they could be combined, say
-fno-trapping-math implying -fno-signaling-nan?

-- Gaby

Re: [PATCH] Optimize abs(x) < 0.0

[Brad Lucier]

> Richard Henderson <rth@redhat.com> writes:
> 
> | On Mon, Jul 22, 2002 at 09:34:03AM +0200, Gabriel Dos Reis wrote:
> | > Then, what does GCC return for fabs(x) when x is a signaling NaN?
> | 
> | An SNaN with the sign bit clear.
> 
> Therefore the expression fabs(x) < 0.0 may trap. 
> 
> Removing that expression in the proposed transformation changes
> that behaviour.  
> 
> The proposed transformation doesn't preserve semantics in presence
> of signaling NaNs. I suggest it to be applied only either unsafe-math
> or say -fno-nan-values or whatever.

There is an option -fno-trapping-math that tells the compiler that
the libraries are set up to do no trapping of floating-point arithmetic;
perhaps the transformation should be predicated on this flag.

Brad

Re: [PATCH] Optimize abs(x) < 0.0

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

[...]

| I tell you that there are a *lot* of places in the 
| compiler where we do not conserve fp signals.  We cannot
| possibly promise that we will not lose any, and I guess
| becuase of that, I feel no need to preserve them either.

I hear you.  However, I'm not convinced that because we didn't take
care of the issue in the past means that we should continue not to
take care of it.  I think new transformations should try hard to
locate where they are not preserving fp signals and use appropriate
flags.

-- Gaby

Re: [PATCH] Optimize abs(x) < 0.0

[Richard Henderson]

On Mon, Jul 22, 2002 at 06:26:45PM +0200, Gabriel Dos Reis wrote:
> Therefore the expression fabs(x) < 0.0 may trap. 

Or, it may not.  We might choose to reverse the branch,
which means using the UNGE comparator, which uses the
non-trapping fcmpd instead of the trapping fcmped insn.

I tell you that there are a *lot* of places in the 
compiler where we do not conserve fp signals.  We cannot
possibly promise that we will not lose any, and I guess
becuase of that, I feel no need to preserve them either.


r~

Re: [PATCH] Optimize abs(x) < 0.0

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| On Mon, Jul 22, 2002 at 09:34:03AM +0200, Gabriel Dos Reis wrote:
| > Then, what does GCC return for fabs(x) when x is a signaling NaN?
| 
| An SNaN with the sign bit clear.

Therefore the expression fabs(x) < 0.0 may trap. 

Removing that expression in the proposed transformation changes
that behaviour.  

The proposed transformation doesn't preserve semantics in presence
of signaling NaNs. I suggest it to be applied only either unsafe-math
or say -fno-nan-values or whatever.

-- Gaby

Re: [PATCH] Optimize abs(x) < 0.0

[Richard Henderson]

On Mon, Jul 22, 2002 at 09:34:03AM +0200, Gabriel Dos Reis wrote:
> Then, what does GCC return for fabs(x) when x is a signaling NaN?

An SNaN with the sign bit clear.


r~

Re: [PATCH] Optimize abs(x) < 0.0

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| > 2) Even in the case where fabs(x)
| > may not cause a trap by itself, the expression
| > 
| >    fabs(x) < 0.0 
| > 
| > may because of the comparaison (SPARC V9 for example has mode to
| > trigger exception when comparing a signaling NaN against something).
| 
| We don't preserve signals anywere else in gcc (e.g. eliminated
| because the result is dead).  I don't see why we should start now.

Then, what does GCC return for fabs(x) when x is a signaling NaN?

-- Gaby

Re: [PATCH] Optimize abs(x) < 0.0

[Richard Henderson]

> 2) Even in the case where fabs(x)
> may not cause a trap by itself, the expression
> 
>    fabs(x) < 0.0 
> 
> may because of the comparaison (SPARC V9 for example has mode to
> trigger exception when comparing a signaling NaN against something).

We don't preserve signals anywere else in gcc (e.g. eliminated
because the result is dead).  I don't see why we should start now.


r~

Re: [PATCH] Optimize abs(x) < 0.0

[Gabriel Dos Reis]

Roger Sayle <roger@eyesopen.com> writes:

| On 21 Jul 2002, Gabriel Dos Reis wrote:
| > Michael Matz <matz@suse.de> writes:
| > | > The issue is that floating-point comparaison is tree-valued (true,
| > | > false, undordered).  In case of the NaN case abs(x) should return
| > | > 'unordered' (not false)
| > |
| > | But it doesn't and can't in C.  What it should or should not returns is
| > | irrelevant here.
| >
| > I disagree that what comes out of abs(x) is irrelevant here.  If
| > abs(x) should have raised a floating-point exception then, that does
| > matter.
| 
| I've just come across the following ISO C standards URL:
| http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n965.htm
| Document N965 of Working Group JTC1/SC22/WG14 entitled
| "Optional support for Signaling NaNs".

Thanks for inputing references into this discussion.

| It includes the paragraph:
| 
| >> Whether an operation that merely returns the value of a numeric
| >> operand, changing at most its sign, triggers signaling NaNs is
| >> unspecified. Such operations include conversions that do not change
| >> precision, the unary + and - operators, and the fabs and copysign
| >> functions.
| 
| It would appear that "fabs" is not required to trigger a signal in
| ISO C's optional extensions.  Hence the transformation is safe even
| in the presence of (the future extension) "-fsignaling-nans".

No, I don't think it is safe in that case.  1) It is true that the
above wording does not require fabs(x) to trigger a trap; but it
doesn't not forbid trapping either.  2) Even in the case where fabs(x)
may not cause a trap by itself, the expression

   fabs(x) < 0.0 

may because of the comparaison (SPARC V9 for example has mode to
trigger exception when comparing a signaling NaN against something).

-- Gaby

Re: [PATCH] Optimize abs(x) < 0.0

[Toon Moene]

Roger Sayle wrote:

> I've just come across the following ISO C standards URL:
> http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n965.htm
> Document N965 of Working Group JTC1/SC22/WG14 entitled
> "Optional support for Signaling NaNs".
> 
> It includes the paragraph:
> 
> >> Whether an operation that merely returns the value of a numeric
> >> operand, changing at most its sign, triggers signaling NaNs is
> >> unspecified. Such operations include conversions that do not change
> >> precision, the unary + and - operators, and the fabs and copysign
> >> functions.
> 
> It would appear that "fabs" is not required to trigger a signal in
> ISO C's optional extensions.  Hence the transformation is safe even
> in the presence of (the future extension) "-fsignaling-nans".

Well, until there's a language that goes above and beyond ISO's C (think
Fortran 2004).

:-)

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

On 21 Jul 2002, Gabriel Dos Reis wrote:
> Michael Matz <matz@suse.de> writes:
> | > The issue is that floating-point comparaison is tree-valued (true,
> | > false, undordered).  In case of the NaN case abs(x) should return
> | > 'unordered' (not false)
> |
> | But it doesn't and can't in C.  What it should or should not returns is
> | irrelevant here.
>
> I disagree that what comes out of abs(x) is irrelevant here.  If
> abs(x) should have raised a floating-point exception then, that does
> matter.

I've just come across the following ISO C standards URL:
http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n965.htm
Document N965 of Working Group JTC1/SC22/WG14 entitled
"Optional support for Signaling NaNs".

It includes the paragraph:

>> Whether an operation that merely returns the value of a numeric
>> operand, changing at most its sign, triggers signaling NaNs is
>> unspecified. Such operations include conversions that do not change
>> precision, the unary + and - operators, and the fabs and copysign
>> functions.

It would appear that "fabs" is not required to trigger a signal in
ISO C's optional extensions.  Hence the transformation is safe even
in the presence of (the future extension) "-fsignaling-nans".

Roger
--

Re: [PATCH] Optimize abs(x) < 0.0

[Gabriel Dos Reis]

Michael Matz <matz@suse.de> writes:

[...]

| > The issue is that floating-point comparaison is tree-valued (true,
| > false, undordered).  In case of the NaN case abs(x) should return
| > 'unordered' (not false)
| 
| But it doesn't and can't in C.  What it should or should not returns is
| irrelevant here.

I disagree that what comes out of abs(x) is irrelevant here.  If
abs(x) should have raised a floating-point exception then, that does
matter.

-- Gaby

Re: [PATCH] Optimize abs(x) < 0.0

[Gabriel Dos Reis]

Toon Moene <toon@moene.indiv.nluug.nl> writes:

[...]

| The code in the patch is OK because it doesn't introduce a hole where there
| wasn't one before :-)

I'm not sure I agree:  If x is a signaling NaN, then abs(x) can raise
a floating-point exception (if toggled).  The optimisation removes
that behaviour.

It is true that C leaves signaling NaNs as implementation defined
issues, but I find the definition in the patch rather drastic :-)

-- Gaby

Re: [PATCH] Optimize abs(x) < 0.0

[Michael Matz]

Hi,

On 21 Jul 2002, Gabriel Dos Reis wrote:

> I'm not sure I agree with your reasoning.

Well, if there is no program which delivers a different answer depending
on the presence of optimization X, then X is correct.  Can you think about
any such program for this particular optimization?

> The issue is that floating-point comparaison is tree-valued (true,
> false, undordered).  In case of the NaN case abs(x) should return
> 'unordered' (not false)

But it doesn't and can't in C.  What it should or should not returns is
irrelevant here.

Maybe there are languages, where you can have a three-valued logic, but
for the languages currently implemented by GCC (not sure about Ada,
though) this isn't the case, so the optimization is correct in this
context.  Sure, the context could be another one, where this wouldn't be
correct, but it isn't.


Ciao,
Michael.

Re: [PATCH] Optimize abs(x) < 0.0

[Toon Moene]

Roger Sayle wrote:

> > Now computer hardware is forced to project that three valued logic onto a
> > two valued logical "true, false" dichotomy.  The solution chosen is to have
> > both comparisons above return "false".  That means that to check for a NaN
> > and use a > or <= comparison, you have to use *both*, else the NaN will
> > just escape your check.
> 
> When applying a code transformation it is sufficient to guarantee that
> the behaviour of the transformed code is the same as the original.
> In this case, I don't have to explicitly "check for a NaN" with two
> comparisons iff the optimized code produces the same results in the
> presence of NaNs and finite values.

Yep, rethinking this, it is the original code writer who should make sure
that abs(a) < 0.0 is the correct check, i.e.:

> [You might also appreciate that "x == x" is a better explicit check
> for finite vs. NaN that would require only a single comparison]

He/she should have done the above check.

The code in the patch is OK because it doesn't introduce a hole where there
wasn't one before :-)

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: [PATCH] Optimize abs(x) < 0.0

[Gabriel Dos Reis]

Roger Sayle <roger@eyesopen.com> writes:

[...]

| Your suggestion of requiring two tests to check for a NaN amounts to
| 
| 	(x<0.0) || (x>=0.0)? finite_case : NaN_case
| 
| where finite_case of "abs(x) < 0.0" always returns false, and the
| NaN_case "abs(NaN) < 0.0" is "NaN < 0.0" which is also prescribed
| false in the mapping to a two valued logic.  So the entire expression
| (foo? false : false) can be optimized to false.
| 
| So yes, NaN escapes my checks, but the it escapes the correct way.

I'm not sure I agree with your reasoning.

The issue is that floating-point comparaison is tree-valued (true,
false, undordered).  In case of the NaN case abs(x) should return
'unordered' (not false) -- the fact that it returns false is just an
artifact of implementation to be used in *conjunction* with the
opposite comparaison.  Therefore I agree with Toon's reasoning that
your transformation is safe only under -funsafe-math or in the absence
of NaNs.

| [You might also appreciate that "x == x" is a better explicit check
| for finite vs. NaN that would require only a single comparison]

As an aside, I think "x == x" evaluating to true for checking for
finite values vs. NaNs is a common misconception: x == x may trap if x
is a signaling NaN, therefore the comparaison may not yield any value.

-- Gaby

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

> Now computer hardware is forced to project that three valued logic onto a
> two valued logical "true, false" dichotomy.  The solution chosen is to have
> both comparisons above return "false".  That means that to check for a NaN
> and use a > or <= comparison, you have to use *both*, else the NaN will
> just escape your check.

When applying a code transformation it is sufficient to guarantee that
the behaviour of the transformed code is the same as the original.
In this case, I don't have to explicitly "check for a NaN" with two
comparisons iff the optimized code produces the same results in the
presence of NaNs and finite values.

Your suggestion of requiring two tests to check for a NaN amounts to

	(x<0.0) || (x>=0.0)? finite_case : NaN_case

where finite_case of "abs(x) < 0.0" always returns false, and the
NaN_case "abs(NaN) < 0.0" is "NaN < 0.0" which is also prescribed
false in the mapping to a two valued logic.  So the entire expression
(foo? false : false) can be optimized to false.

So yes, NaN escapes my checks, but the it escapes the correct way.

[You might also appreciate that "x == x" is a better explicit check
for finite vs. NaN that would require only a single comparison]

Roger
--

Re: [PATCH] Optimize abs(x) < 0.0

[Toon Moene]

Roger Sayle wrote:

> On Sat, 20 Jul 2002, Toon Moene wrote:

> > Roger Sayle wrote:

> > > This patch optimizes expressions of the form "abs(x) < 0.0" and
> > > "float_extend(abs(x)) < 0.0" as always false.  Additionally, for
> > > symmetry, it also optimizes "abs(x) >= 0.0" to always true when
> > > x is an integer mode (or a floating point mode with NaNs) or if
> > > "-ffast-math" has been specified.

> > Wow !  Great !  Except that it only works under unsafe math assumptions
> > (abs(NaN) is NaN, which is unordered in comparisons).

> Nope, its always safe.  "abs(x) < 0.0" is false under all conditions,
> including the presence of NaNs, infinities and signed zeros.  Its
> "abs(x) >= 0.0" that is always true only when the user specifies
> "-ffast-math".  You got lucky with "C / R" that the condition appears
> in the RTL the right way around, so that the conditional branches will
> be optimized away with just "-O".

Ah, yes, I already thought that would be your reasoning.  Correct to the
letter, but not the spirit :-)

The outcome of comparing a number with NaN is: `unordered', which means
just what it says: There is no sensible answer to the question "is a NaN
greater than or equal to or less than this finite number".

This is three-valued logic:

	a > NaN gives "unordered"
	a <= NaN gives "unordered"

Now computer hardware is forced to project that three valued logic onto a
two valued logical "true, false" dichotomy.  The solution chosen is to have
both comparisons above return "false".  That means that to check for a NaN
and use a > or <= comparison, you have to use *both*, else the NaN will
just escape your check.

IOW, your X < 0.0 will return false for the wrong reason if you're not also
testing X >= 0.0.  As you don't do that in the code snippet you changed,
your X < 0.0 test (or rather the assumptions in the code following) will be
wrong, *unless* you already assume no NaNs, i.e., are covered by
!HONOR_NANS.

Hope this helps,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

On Sat, 20 Jul 2002, Toon Moene wrote:
> Roger Sayle wrote:
> > This patch optimizes expressions of the form "abs(x) < 0.0" and
> > "float_extend(abs(x)) < 0.0" as always false.  Additionally, for
> > symmetry, it also optimizes "abs(x) >= 0.0" to always true when
> > x is an integer mode (or a floating point mode with NaNs) or if
> > "-ffast-math" has been specified.
>
> Wow !  Great !  Except that it only works under unsafe math assumptions
> (abs(NaN) is NaN, which is unordered in comparisons).

Nope, its always safe.  "abs(x) < 0.0" is false under all conditions,
including the presence of NaNs, infinities and signed zeros.  Its
"abs(x) >= 0.0" that is always true only when the user specifies
"-ffast-math".  You got lucky with "C / R" that the condition appears
in the RTL the right way around, so that the conditional branches will
be optimized away with just "-O".

Roger
--

Re: [PATCH] Optimize abs(x) < 0.0

[Toon Moene]

Roger Sayle wrote:

> This patch optimizes expressions of the form "abs(x) < 0.0" and
> "float_extend(abs(x)) < 0.0" as always false.  Additionally, for
> symmetry, it also optimizes "abs(x) >= 0.0" to always true when
> x is an integer mode (or a floating point mode with NaNs) or if
> "-ffast-math" has been specified.
> 
> In addition to the new testcase below, which is optimized on all
> platforms, this patch also has the effect of removing conditional
> branches from division of complex numbers by reals on platforms
> that represent "(set (reg:DF) (const_double:DF 0x0))" explicitly.

Wow !  Great !  Except that it only works under unsafe math assumptions
(abs(NaN) is NaN, which is unordered in comparisons).
Thanks !

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: [PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

On Sat, 20 Jul 2002, Richard Henderson wrote:
> On Sat, Jul 20, 2002 at 12:08:33PM -0600, Roger Sayle wrote:
> > 	* simplify-rtx.c (simplify_relational_operation): Optimize
> > 	abs(x) < 0.0 (and abs(x) >= 0.0 when using -ffast-math).
> >
> > 	* gcc.c-torture/execute/20020720-1.c: New test case.
>
> Ok.  We'll see how broadly the testcase applied.  I could
> see the optimizers getting confused on some platforms.

Many thanks.  Commited.

If we encounter any platforms that fail the new testcase, we can
remove it from the testsuite.  I thought it better to try to add
a new test, than submit a patch without one.

Many thanks once again.

Roger
--

Re: [PATCH] Optimize abs(x) < 0.0

[Richard Henderson]

On Sat, Jul 20, 2002 at 12:08:33PM -0600, Roger Sayle wrote:
> 	* simplify-rtx.c (simplify_relational_operation): Optimize
> 	abs(x) < 0.0 (and abs(x) >= 0.0 when using -ffast-math).
> 
> 	* gcc.c-torture/execute/20020720-1.c: New test case.

Ok.  We'll see how broadly the testcase applied.  I could
see the optimizers getting confused on some platforms.


r~

[PATCH] Optimize abs(x) < 0.0

[Roger Sayle]

This patch optimizes expressions of the form "abs(x) < 0.0" and
"float_extend(abs(x)) < 0.0" as always false.  Additionally, for
symmetry, it also optimizes "abs(x) >= 0.0" to always true when
x is an integer mode (or a floating point mode with NaNs) or if
"-ffast-math" has been specified.

In addition to the new testcase below, which is optimized on all
platforms, this patch also has the effect of removing conditional
branches from division of complex numbers by reals on platforms
that represent "(set (reg:DF) (const_double:DF 0x0))" explicitly.

Without this patch, the following FORTRAN example,

       COMPLEX FUNCTION CF(C, R)
       COMPLEX C
       REAL R
       CF = C/R
       END

generates the following sequence on the alpha:

cf_:
        .frame $30,0,$26,0
        .prologue 0
        lds $f14,0($17)
        lds $f13,0($18)
        lds $f15,4($17)
        cpys $f31,$f13,$f10		<--- ABS
        cmptlt $f10,$f31,$f10		<--- COMPARE
        fbne $f10,$L2			<--- JUMP
        divs $f31,$f13,$f10
        muls $f14,$f10,$f12
        muls $f10,$f31,$f11
        muls $f15,$f10,$f10
        subs $f15,$f12,$f12
        adds $f11,$f13,$f11
        adds $f10,$f14,$f10
$L4:
        divs $f12,$f11,$f12
        divs $f10,$f11,$f10
        sts $f12,4($16)
        sts $f10,0($16)
        ret $31,($26),1
        .align 4
$L2:
        divs $f13,$f31,$f10
        muls $f15,$f10,$f12
        muls $f13,$f10,$f11
        muls $f14,$f10,$f10
        subs $f12,$f14,$f12
        adds $f11,$f31,$f11
        adds $f10,$f15,$f10
        br $31,$L4
        .end cf_


But with this patch, we now generate the shorter and more efficient

cf_:
        .frame $30,0,$26,0
        .prologue 0
        lds $f15,0($17)
        lds $f14,0($18)
        lds $f12,4($17)
        divs $f31,$f14,$f10
        muls $f15,$f10,$f13
        muls $f10,$f31,$f11
        muls $f12,$f10,$f10
        subs $f12,$f13,$f12
        adds $f11,$f14,$f11
        adds $f10,$f15,$f10
        divs $f12,$f11,$f12
        divs $f10,$f11,$f10
        sts $f12,4($16)
        cpys $f31,$f31,$f31
        sts $f10,0($16)
        ret $31,($26),1
        .end cf_


This patch has been tested by a complete bootstrap (all languages
except Ada and treelang) and "make -k check" in the gcc directory
on both alphaev67-dec-osf5.1 and i686-pc-linux-gnu with no new
regressions.  The libstdc++-v3 and libjava test suites weren't run
due to the current "Program timed out" issues in libjava.

Ok for mainline?


2002-07-20  Roger Sayle  <roger@eyesopen.com>

	* simplify-rtx.c (simplify_relational_operation): Optimize
	abs(x) < 0.0 (and abs(x) >= 0.0 when using -ffast-math).

	* gcc.c-torture/execute/20020720-1.c: New test case.


Index: simplify-rtx.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.110
diff -c -3 -p -r1.110 simplify-rtx.c
*** simplify-rtx.c	11 Jul 2002 23:52:59 -0000	1.110
--- simplify-rtx.c	20 Jul 2002 02:54:15 -0000
*************** simplify_relational_operation (code, mod
*** 2075,2080 ****
--- 2075,2102 ----
  	    return const0_rtx;
  	  break;

+ 	case LT:
+ 	  /* Optimize abs(x) < 0.0.  */
+ 	  if (trueop1 == CONST0_RTX (mode))
+ 	    {
+ 	      tem = GET_CODE (trueop0) == FLOAT_EXTEND ? XEXP (trueop0, 0)
+ 						       : trueop0;
+ 	      if (GET_CODE (tem) == ABS)
+ 		return const0_rtx;
+ 	    }
+ 	  break;
+
+ 	case GE:
+ 	  /* Optimize abs(x) >= 0.0.  */
+ 	  if (trueop1 == CONST0_RTX (mode) && !HONOR_NANS (mode))
+ 	    {
+ 	      tem = GET_CODE (trueop0) == FLOAT_EXTEND ? XEXP (trueop0, 0)
+ 						       : trueop0;
+ 	      if (GET_CODE (tem) == ABS)
+ 		return const1_rtx;
+ 	    }
+ 	  break;
+
  	default:
  	  break;
  	}
*** /dev/null	Thu Aug 30 14:30:55 2001
--- gcc.c-torture/execute/20020720-1.c	Sat Jul 20 11:04:10 2002
***************
*** 0 ****
--- 1,36 ----
+ /* Copyright (C) 2002  Free Software Foundation.
+
+    Ensure that fabs(x) < 0.0 optimization is working.
+
+    Written by Roger Sayle, 20th July 2002.  */
+
+ extern void abort (void);
+ extern double fabs (double);
+ extern void link_error (void);
+
+ void
+ foo (double x)
+ {
+   double p, q;
+
+   p = fabs (x);
+   q = 0.0;
+   if (p < q)
+     link_error ();
+ }
+
+ int
+ main()
+ {
+   foo (1.0);
+   return 0;
+ }
+
+ #ifndef __OPTIMIZE__
+ void
+ link_error ()
+ {
+   abort ();
+ }
+ #endif
+

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833