Re: g77 problem in egcs-ss-970828

Re: g77 problem in egcs-ss-970828

[Toon Moene]

I wrote:

> I'm sending this to egcs, because I'm not entirely sure that this  
> front end bug is *not* caused by the snapshots C compiler
> miscompiling the g77 frontend.
>
> Given the following Fortran routine:
>
>       SUBROUTINE AAP(NOOT)
>       DIMENSION NOOT(*)
>       END

And Mumit Kahn replied:

>  I can verify this problem on at 2 other platforms, and
>  it does not happen with the previous snapshots
>  (2.90.00-2.90.02) on either of these machines
>  (i686-linux-gnulibc1 and hppa1.1-hp-hpux10.20).

This makes it highly unlikely that it is caused by miscompilation  
by the snapshot's C compiler.

Craig, do you now where to look for this g77 front end bug ?

TIA,
Toon

Re: A vtable thunks bug.

[Alexandre Oliva]

Ulrich Drepper writes:

> Alexandre Oliva  writes:
>> What if libstdc++ were multilib'ed: one version compiled with
>> -fvtable-thunks and another -fno-vtable-thunks, on appropriate hosts?
>> This way a user could select which library to use.

> multilibs are good to provide different features but not to work
> around bugs.

As far as I understand, object files compiled with -fvtable-thunks are
not binary-compatible with ones compiled without this flag.  This is,
alone, a reason either to build multiple versions of a library, so
that users can compile their own programs with whatever option they
want and know that they will work with their installed library (except
for this bug), or to disable the ability to select one or another
method at run-time.

In fact, if such objects are not binary-compatible, it would be wise
to mangle names of methods in a different way, so that people cannot
link object files or libraries produced with one flag with ones
produced with the other.


However, if there's no such binary incompatibility, and I'm just
writing garbage, please disregard all this idea about multi libstdc++
because of vtable-thunks, and feel free to correct me :-)

Regards,

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

Re: FreeBSD and exception name clash

[Jeffrey A Law]

  In message you write:
  > Is fixincludes supposed to fix the following error:
Yes.  It should have turned it into __math_exception.

Jeff

Re: g77 problem in egcs-ss-970828

[Jeffrey A Law]

  In message you write:
  > I'm sending this to egcs, because I'm not entirely sure that this  
  > front end bug is *not* caused by the snapshots C compiler  
  > miscompiling the g77 frontend.
  > 
  > Given the following Fortran routine:
  > 
  >       SUBROUTINE AAP(NOOT)
  >       DIMENSION NOOT(*)
  >       END
  > 
  > (for non-Fortraners, NOOT(*) means something like noot[] in C) I  
  > get the following error from g77:
I'll look at it.  Either the code to catch too-large array sizes
is incorrectly giving an error, or something is wrong in the fortran
front end (which was upgraded for this snapshot).

jeff

Re: g77 problem in egcs-ss-970828

[Dave Love]

>>>>> "Toon" == Toon Moene  writes:

 >> SUBROUTINE AAP(NOOT)
 >> DIMENSION NOOT(*)
 >> END

 Toon> And Mumit Kahn replied:

 >> I can verify this problem on at 2 other platforms, and
 >> it does not happen with the previous snapshots
 >> (2.90.00-2.90.02) on either of these machines
 >> (i686-linux-gnulibc1 and hppa1.1-hp-hpux10.20).

 Toon> This makes it highly unlikely that it is caused by miscompilation  
 Toon> by the snapshot's C compiler.

 Toon> Craig, do you now where to look for this g77 front end bug ?

It doesn't occur with the gcc 2.7-based g77 patched up to g77-970827
on x86 linux.

I don't know if it's relevant, but there are longstanding problems
describing assumed-size and adjustable arrays about which there's an
essay somewhere in f/com.c IIRC.

Re: g77 problem in egcs-ss-970828

[Jeffrey A Law]

  In message you write:
  > Toon Moene  writes:
  > > I'm sending this to egcs, because I'm not entirely sure that this  
  > > front end bug is *not* caused by the snapshots C compiler  
  > > miscompiling the g77 frontend.
  > > 
  > > Given the following Fortran routine:
  > > 
  > >       SUBROUTINE AAP(NOOT)
  > >       DIMENSION NOOT(*)
  > >       END
  > 
  > 
  > I can verify this problem on at 2 other platforms, and it does not happen
  > with the previous snapshots (2.90.00-2.90.02) on either of these machines
  > (i686-linux-gnulibc1 and hppa1.1-hp-hpux10.20).
It's a bad interaction between the fold-const.c changes to detect
overflows in array index & size calculations and the g77 front end
(I brought the fold-const.c changes over between the 970825 and 970828
snapshots.

Backing out the fold-const.c (and c-decl.c) changes fixes the problem.
I think that's the way to go; we'll bring the fold-const and c-decl
changes back into egcs after the first release when we can analyze
this problem further.

jeff

Re: g77 problem in egcs-ss-970828

[Mumit Khan]

Toon Moene  writes:
> I'm sending this to egcs, because I'm not entirely sure that this  
> front end bug is *not* caused by the snapshots C compiler  
> miscompiling the g77 frontend.
> 
> Given the following Fortran routine:
> 
>       SUBROUTINE AAP(NOOT)
>       DIMENSION NOOT(*)
>       END


I can verify this problem on at 2 other platforms, and it does not happen
with the previous snapshots (2.90.00-2.90.02) on either of these machines
(i686-linux-gnulibc1 and hppa1.1-hp-hpux10.20).

Mumit

g77 problem in egcs-ss-970828

[Toon Moene]

I'm sending this to egcs, because I'm not entirely sure that this  
front end bug is *not* caused by the snapshots C compiler  
miscompiling the g77 frontend.

Given the following Fortran routine:

      SUBROUTINE AAP(NOOT)
      DIMENSION NOOT(*)
      END

(for non-Fortraners, NOOT(*) means something like noot[] in C) I  
get the following error from g77:

/usr/test/bin/g77 -v array2large.f
g77 version 0.5.21-19970826
 /usr/test/bin/gcc -v -xf77 array2large.f -xnone -lf2c -lm
Reading specs from  
/usr/test/lib/gcc-lib/m68k-next-nextstep3/egcs-2.90.03/specs
gcc version egcs-2.90.03 970828 (gcc2-970802 experimental)
 /usr/test/lib/gcc-lib/m68k-next-nextstep3/egcs-2.90.03/f771  
array2large.f -fset-g77-defaults -quiet -dumpbase array2large.f  
-version -fversion -o /usr/tmp/cc022314.s
GNU F77 version egcs-2.90.03 970828 (gcc2-970802 experimental)  
(m68k-next-nextstep3) compiled by GNU C version egcs-2.90.03 970828  
(gcc2-970802 experimental).
GNU Fortran Front End version 0.5.21-19970826
array2large.f: In subroutine `aap':
array2large.f:1:
         SUBROUTINE AAP(NOOT)
                        ^
Array `noot' at (^) is too large to handle

I picked up egcs-core-970828.tar.gz and egcs-g77-970828.tar.gz from  
the anonymous ftp site, unpacked and did a

% setenv CC cc; ./configure --prefix=/usr/test; make

Because that didn't do a make bootstrap in the gcc directory, I  
went into that directory and did

% make bootstrap LANGUAGES=c CFLAGS="-g -O3"

That worked; the subsequent `make compare' completed without error.

Then I built g77, thusly:

% make CC="stage2/xgcc -Bstage2/" CFLAGS="-O -g -O3" LDFLAGS=""  
libdir=/usr/test/lib STAGE_PREFIX=stage2/ LANGUAGES="c f77"

and installed the stuff.

Hope this is accurate enough,
Toon.