Re: A vtable thunks bug.

Re: A vtable thunks bug.

[Ulrich Drepper]

meissner@cygnus.com writes:

> I will note that in general, you don't want multilib if you can avoid it....

Underline this at least three times!!!  I have no interest in even
thinking about this.

-- Uli
---------------.      drepper@cygnus.com  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper@gnu.ai.mit.edu  `------------------------

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

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: 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: suggested addition to -Wparentheses: warn about ` ! x & 1 '

[Michael R Cook]

>>>>> "PS" == Peter Seebach  writes:

 >> Hmm, maybe you could make an option -Wall-parentheses, which warns if
 >> any construct is ambigous if operator precedence is not taken into account.
 >> That would cover this case, and all the related ones...

 PS> Yeah, but I don't want warnings on
 PS> 	2 * 3 + 5;

Ideally, all warnings would be very specific, and would be given a
unique identifier, and we'd be able to enable and disable them
individually.  Even better would be if we could enable/disable them
on a sub-file basis; for example:

  __warning(+4701); /* Enable the "Misaligned frobnicator" warning */
  x = 2 * 3 + 5;
  __warning(-4701); /* Disable */

or

  x = __warning(+4701, 2 * 3 + 5);
    /* Evaluate the expression `e' with warning 4701 enabled. */

For macros and headers, we'd want to be able to maintain a kind of
stack for enabling and disabling warnings.  For example, if a
warning is disabled N times, it would have to be enabled N times
before it really became enabled.  Perhaps something like:
__warning(++4701) and __warning(--4701).

Warning identifiers could be assigned so that similar warnings were
consecutive, so you could maybe enable and disable sets of similar
warnings all at once:

 __warning(+3201..3299) /* gimme all of the parentheses warnings */

This functionality would subsume probably all of the existing -W
options.

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:
  > 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

[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: 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.