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: 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.
  > 
  > Except that FreeBSD, and some other free software OS's, don't bother to
  > run fixincludes because they know their header files are already correct.
Grrr.  I looked for this in the makefile fragments; turns out they
turn off fixincludes in the configure script.  Ugh.

I think we'll need to enable fixincludes for the freebsd and likely
other platforms.

Jeff

Re: FreeBSD and exception name clash

[Jim Wilson]

	  > Is fixincludes supposed to fix the following error:

	Yes.  It should have turned it into __math_exception.

Except that FreeBSD, and some other free software OS's, don't bother to
run fixincludes because they know their header files are already correct.

This particular problem is due to a change in the C++ standard which
requires the C++ library to define a `class exception' where it did not
before, and since `exception' is a common term in computer math, this
often causes a conflict with existing math.h files.  So the real problem
here is that new code in the C++ library is conflicting with the existing
math library.

The FreeBSD folks will probably want to fix their C library to avoid the
conflict in newer OS versions.

For older OS versions, we may need to re-enable fixincludes.

Jim

FreeBSD and exception name clash

[Kent Vander Velden]

Is fixincludes supposed to fix the following error:

xns|Thu7:09am} uname -a
FreeBSD pseudo.cc.iastate.edu 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Fri
Aug 15 00:29:41 CDT 1997    
kent@pseudo.cc.iastate.edu:/usr/src/sys/compile/PSEUDO  i386

xns|Thu7:17am} cat test.C
#include <set>
#include <math.h>

int
main() {
  return 0;
}

xns|Thu7:18am} ~/egcs/bin/c++ -nostdinc++ -I/home/kent/egcs/include
-I/home/kent/egcs/include/g++/ -L/home/kent/egcs/lib -o test test.C
In file included from test.C:2:
/usr/include/math.h:67: redefinition of `class exception'
/home/kent/egcs/lib/gcc-lib/i386-unknown-freebsd3.0/egcs-2.90.02/include/exception:20:
previous definition here
/usr/include/math.h:73: confused by earlier errors, bailing out

  Thanks.