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

[Peter Seebach]

>> | > I was a little surprised to see that gcc -Wparentheses doesn't
>> | > warn about this mix of `!' and `&':
>> | >
>> | >   int foo (int x) { return ! x&1; }
>> | >
>> | > Can anyone think of a reason not to add this functionality?

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

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

>> Would you give an example or two of such useful constructs?

>!x & y , where y is a variable.

That could be spelled as
	y & !x;

unambiguously.  (And, IMHO, more idiomatically, as I always try to leave
the thing masked on the left, and the mask on the right.)

>!x & (y) , where y is a macro argument that may or may not be constant...

I'd probably do that as
	(!x) & (y)

I will admit to occasionally being bitten by things like the '!x & y', just
because I do enough sh to think of '!' as working on everything in sight.

-s

Re: suggested addition to -Wparentheses: warn about ` ! x & 1 '

[Jim Meyering]

Joern Rennecke <amylaar@cygnus.co.uk> writes:
| > I was a little surprised to see that gcc -Wparentheses doesn't
| > warn about this mix of `!' and `&':
| >
| >   int foo (int x) { return ! x&1; }
| >
| > Can anyone think of a reason not to add this functionality?
|
| Yes.  It's easy to remember that the unary operators have a high
| priority.  There are some useful constructs that would be warned about,
| and adding superflous parantheses often makes the code harder to read.

But first you have to know that.
Some people don't.

Would you give an example or two of such useful constructs?

Re: suggested addition to -Wparentheses: warn about ` ! x & 1 '

[Joern Rennecke]

> I was a little surprised to see that gcc -Wparentheses doesn't
> warn about this mix of `!' and `&':
> 
>   int foo (int x) { return ! x&1; }
> 
> Can anyone think of a reason not to add this functionality?

Yes.  It's easy to remember that the unary operators have a high
priority.  There are some useful constructs that would be warned about,
and adding superflous parantheses often makes the code harder to read.

suggested addition to -Wparentheses: warn about ` ! x & 1 '

[Jim Meyering]

I think it would be worthwhile to add at least one more case in which
-Wparentheses gives a warning.  I just saw someone fix a bug that
such an addition would have highlighted.

I was a little surprised to see that gcc -Wparentheses doesn't
warn about this mix of `!' and `&':

  int foo (int x) { return ! x&1; }

Can anyone think of a reason not to add this functionality?