Probable bug in gcc/reg-stack.c (example given)

Probable bug in gcc/reg-stack.c (example given)

[Craig Burley]

A longstanding bug in gcc, reported against g77, has been
narrowed down by g77 users enough for me to be able to translate
it into C for purposes of reproduction.  It probably afflicts only
ix86 machines, and shows up on my 486.  The sample program is
enclosed below.

When compiled by `gcc -O2 t.c', then run by `./a.out', it
produces a "Floating point exception" on my i486 running GNU/Linux,
which in this case means it has unexpectedly overflowed the
floating-point ("387 coprocessor") stack.

Looking at the RTL and reading up on reg-stack.c a bit -- not enough
time to figure out the problem and fix it myself right now -- the
problem seems to be that reg-stack.c doesn't recognize that the
second assignment to `xmax', `xmax = 2.0', is to a live register,
which must thus be popped first, then loaded.  Perhaps this is
because reg-stack's own version of flow analysis, or basic block
analysis, doesn't see that `lab100' can be reached from the
`goto *next;' at `lab20', or some such thing.  Anyway, the 1.0 value
in it is not popped before the new 2.0 value is loaded.  After a
few iterations, this leads to the stack overflowing -- though if
that were silent, in this particular case it wouldn't be a problem.

The Fortran equivalent for this code is known as DNRM2, but apparently
a very old version.  In any case, it's Fortran's ugly, but long-ago-
popular, `ASSIGN' and `GOTO variable' features that correspond to
the gcc extensions such as `goto *next;' being used in this example.
They exist in lots of code, so it'd be helpful to have this bug fixed
soon.

If anyone comes up with a fix for this, that'd be great, especially
if it was in the next week or so; it might go into g77-0.5.21, which
is due out September 1.

        tq vm, (burley)


-------- t.c:
#include <stdio.h>

double
dnrm2 (int n, double dx[])
{
  void *next;
  double xmax;
  double rtnval;
  int i;

  next = &&lab100;
  rtnval = 10.0;
  i = 1;
  xmax = 1.0;

lab20:
  goto *next;
lab100:
  next = &&lab110;
  xmax = 2.0;
lab110:
  if (dx[i] > xmax) i = i + 1;
  if (i <= n) goto lab20;
  return rtnval;
}

int
main()
{
  double r[10];
  int n;
  int i;
  double a;

  r[1] = 10.0;
  n = 1;

  for (i = 1; i < 11; ++i)
    {
      a = dnrm2(n, r);
      printf ("a = %g\n", a);
    }
  return 0;
}

formatting

[Jeffrey A Law]

Don't forget the space between PROTO and the open parens.

I don't think it's worth going back and fixing all the old
prototypes at this time, but we should some day.

jeff

Re: A prototype patch for expr.h/real.h

[Jeffrey A Law]

  In message <m0x0pEb-0004ecC@ocean.lucon.org>you write:
  > Hi,
  > 
  > Here is a prototype patch for expr.h and real.h. Please let me know
  > when it will be installed or tell me how to make it acceptable.
I've installed this after fixing minor formatting problems.

jeff

Re: formatting

[Jeffrey A Law]

  In message <m0x0qt2-0004ecC@ocean.lucon.org>you write:
  > > 
  > > 
  > > Don't forget the space between PROTO and the open parens.
  > > 
  > > I don't think it's worth going back and fixing all the old
  > > prototypes at this time, but we should some day.
  > > 
  > 
  > How about a sed/awk script?
Yup.  My thoughts exactly.  But I don't think we want to do it
at this time.  Remember, we need to be working towards a release
in 2 weeks; stuff like this certainly isn't needed for a release.


Jeff

Re: formatting

[H.J. Lu]

> 
> 
> Don't forget the space between PROTO and the open parens.
> 
> I don't think it's worth going back and fixing all the old
> prototypes at this time, but we should some day.
> 

How about a sed/awk script?

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: formatting

[Greg McGary]

Jeffrey A Law <law@hurl.cygnus.com> writes:

> > How about a sed/awk script?

When you get around to doing this, perl is *much* more convenient for
batch edits such as this:

	perl -p -i -e 's/PROTO\('/PROTO (/g' FILES...