comparisons..

comparisons..

[Andrew Morton]

unsigned long x;
 
int y()
{
        return (x < 0);
}

This is usually a bug.  Is there a way of getting gcc to warn about it?

Re: comparisons..

[Michael Meissner]

On Thu, Jul 13, 2000 at 03:45:54AM +0000, Andrew Morton wrote:
> unsigned long x;
>  
> int y()
> {
>         return (x < 0);
> }
> 
> This is usually a bug.  Is there a way of getting gcc to warn about it?

The friendly manual says:

`-W'
     Print extra warning messages for these events:

        * A nonvolatile automatic variable might be changed by a call to
          `longjmp'.  These warnings as well are possible only in
          optimizing compilation.

          The compiler sees only the calls to `setjmp'.  It cannot know
          where `longjmp' will be called; in fact, a signal handler
          could call it at any point in the code.  As a result, you may
          get a warning even when there is in fact no problem because
          `longjmp' cannot in fact be called at the place which would
          cause a problem.

        * A function can return either with or without a value.
          (Falling off the end of the function body is considered
          returning without a value.)  For example, this function would
          evoke such a warning:

               foo (a)
               {
                 if (a > 0)
                   return a;
               }

        * An expression-statement or the left-hand side of a comma
          expression contains no side effects.  To suppress the
          warning, cast the unused expression to void.  For example, an
          expression such as `x[i,j]' will cause a warning, but
          `x[(void)i,j]' will not.

        * An unsigned value is compared against zero with `<' or `<='.

        * A comparison like `x<=y<=z' appears; this is equivalent to
          `(x<=y ? 1 : 0) <= z', which is a different interpretation
          from that of ordinary mathematical notation.

        * Storage-class specifiers like `static' are not the first
          things in a declaration.  According to the C Standard, this
          usage is obsolescent.

        * If `-Wall' or `-Wunused' is also specified, warn about unused
          arguments.

        * A comparison between signed and unsigned values could produce
          an incorrect result when the signed value is converted to
          unsigned.  (But don't warn if `-Wno-sign-compare' is also
          specified.)

        * An aggregate has a partly bracketed initializer.  For
          example, the following code would evoke such a warning,
          because braces are missing around the initializer for `x.h':

               struct s { int f, g; };
               struct t { struct s h; int i; };
               struct t x = { 1, 2, 3 };

        * An aggregate has an initializer which does not initialize all
          members.  For example, the following code would cause such a
          warning, because `x.h' would be implicitly initialized to
          zero:

               struct s { int f, g, h; };
               struct s x = { 3, 4 };

--> gcc -W -S foo.c
foo.c: In function `y':
foo.c:5: warning: comparison of unsigned expression < 0 is always false

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: comparisons..

[Andrew Morton]

Michael Meissner wrote:
> 
> --> gcc -W -S foo.c
> foo.c: In function `y':
> foo.c:5: warning: comparison of unsigned expression < 0 is always false

Drat.  I've wasted your time.  Sorry.

pwold011:/home/morton> gcc -v
Reading specs from /usr/lib/gcc-lib/i686-unknown-linux/2.7.2.3/specs
gcc version 2.7.2.3

Any chance of a backport? :)

Re: comparisons..

[Michael Meissner]

On Thu, Jul 13, 2000 at 06:46:55AM +0000, Andrew Morton wrote:
> Michael Meissner wrote:
> > 
> > --> gcc -W -S foo.c
> > foo.c: In function `y':
> > foo.c:5: warning: comparison of unsigned expression < 0 is always false
> 
> Drat.  I've wasted your time.  Sorry.

I probably shoudn't have been as flip with the fine manual quote, but I assumed
you were using something recent and just didn't bother reading the
documentation...

> pwold011:/home/morton> gcc -v
> Reading specs from /usr/lib/gcc-lib/i686-unknown-linux/2.7.2.3/specs
> gcc version 2.7.2.3
> 
> Any chance of a backport? :)

Considering 2.7.2.3 was released something like 4-5 years ago, I seriously
doubt people would be interested in backporting it.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: comparisons..

[Andrew Morton]

Michael Meissner wrote:
> 
> I probably shoudn't have been as flip with the fine manual quote,
> but I assumed you were using something recent and just didn't
> bother reading the documentation...

Oh that's fine.  RTFM is usually the best response.

> > pwold011:/home/morton> gcc -v
> > Reading specs from /usr/lib/gcc-lib/i686-unknown-linux/2.7.2.3/specs
> > gcc version 2.7.2.3
> >
> > Any chance of a backport? :)
> 
> Considering 2.7.2.3 was released something like 4-5 years ago, I seriously
> doubt people would be interested in backporting it.

Well of course the culprit here is the Linux kernel.  I brought this
issue up earlier today and aviro suggested that it would take "at least
a year of beating" before 3.0 would be anointed as the
compiler-of-choice for the kernel.

This is somewhat at odds with my empirical observations: Linus put out a
kernel the other day which crashed immediately due to a 2.7.2.3 bug and
I think I was the only one who even noticed!

This is an unhappy situation because there is now a very wide spread of
compiler versions being used on the kernel and, to a small extent, it is
costing development/debugging time.

If it were mine I'd say "dammit, we'll use the latest" as this is the
fastest way to get gcc and the kernel up to speed and cooperating.  It's
not a good time in the kernel's life to do this though.

It looks like 2.7.2.3 usage is fading out by default, but in favour of
what, I'm unsure.

Re: comparisons..

[Nick Burrett]

Andrew Morton <andrewm@uow.edu.au> writes:

> Michael Meissner wrote:
> > 
> > Considering 2.7.2.3 was released something like 4-5 years ago, I seriously
> > doubt people would be interested in backporting it.
> 
> Well of course the culprit here is the Linux kernel.  I brought this
> issue up earlier today and aviro suggested that it would take "at least
> a year of beating" before 3.0 would be anointed as the
> compiler-of-choice for the kernel.
> 
> This is somewhat at odds with my empirical observations: Linus put out a
> kernel the other day which crashed immediately due to a 2.7.2.3 bug and
> I think I was the only one who even noticed!

I don't think anybody compiles with 2.7.2.3 any longer.

> It looks like 2.7.2.3 usage is fading out by default, but in favour of
> what, I'm unsure.

egcs-2.91.66 (egcs-1.1.2 release) is now the compiler of choice for
building linux kernels.

gcc-2.95.2 generally works on the later 2.2.x series and on the later 2.3.x
and 2.4.0-test kernels, but there's no guarantee. YMMV


Regards,

Nick.

Re: comparisons..

[Andrew Morton]

Nick Burrett wrote:
> 
> I don't think anybody compiles with 2.7.2.3 any longer.

Looks like you're right, Nick.  I do _like_ 2.7.2.3.  It's fast and it's
well understood.  Plus later compilers make bigger object files (whether
this is due to more aggressive alignment I do not know).  I promised
this list two months ago that I'd characterise this difference fully and
have not yet done so.  Sorry.



Just to show I do read TFM occasionally:


From Documentation/Changes:


You will need at least gcc 2.7.2 to compile the kernel.  You currently
have several options for gcc-derived compilers:  gcc 2.7.2.3, various
versions of egcs, the new gcc 2.95 and upcoming gcc 3.0, and
experimental
compilers like pgcc.  For absolute stability, it is still recommended
that gcc 2.7.2.3 be used to compile your kernel.  egcs 1.12 should also
work.  gcc 2.95 is known to have problems, and using pgcc for your
kernel
is just asking for trouble.

Re: comparisons..

[Joe Buck]

> >From Documentation/Changes:
> 
> You will need at least gcc 2.7.2 to compile the kernel.  You currently
> have several options for gcc-derived compilers:  gcc 2.7.2.3, various
> versions of egcs, the new gcc 2.95 and upcoming gcc 3.0, and
> experimental
> compilers like pgcc.  For absolute stability, it is still recommended
> that gcc 2.7.2.3 be used to compile your kernel.  egcs 1.12 should also
> work.  gcc 2.95 is known to have problems, and using pgcc for your
> kernel
> is just asking for trouble.

But the current gcc is not 2.95, it is 2.95.2.  Are there remaining
problems in 2.95.2 that cause difficulties for the Linux kernel?

Re: comparisons..

[Andi Kleen]

Joe Buck <jbuck@racerx.synopsys.com> writes:

> > >From Documentation/Changes:
> > 
> > You will need at least gcc 2.7.2 to compile the kernel.  You currently
> > have several options for gcc-derived compilers:  gcc 2.7.2.3, various
> > versions of egcs, the new gcc 2.95 and upcoming gcc 3.0, and
> > experimental
> > compilers like pgcc.  For absolute stability, it is still recommended
> > that gcc 2.7.2.3 be used to compile your kernel.  egcs 1.12 should also
> > work.  gcc 2.95 is known to have problems, and using pgcc for your
> > kernel
> > is just asking for trouble.
> 
> But the current gcc is not 2.95, it is 2.95.2.  Are there remaining
> problems in 2.95.2 that cause difficulties for the Linux kernel?

Yes. One function in the Linux/XFS pagebuf code that does a lot of 
long long arithmetic is miscompiled by 2.95.2. It works correctly
with egcs 1.1

-Andi 

Re: comparisons..

[Andrew Morton]

Joe Buck wrote:
> 
> 
> But the current gcc is not 2.95, it is 2.95.2.  Are there remaining
> problems in 2.95.2 that cause difficulties for the Linux kernel?

I don't know, Joe.

Cruising recent postings doesn't give anything very substantive:



From:  Artur Skawina

gcc2.96 miscompiles eg sys_fork(), one workaround is:

  # turn off broken sibling call optimizations
  CFLAGS += $(shell if $(CC) -fno-optimize-sibling-calls -S -o /dev/null
-xc /dev/null >/dev/null 2>&1; then
echo "-fno-optimize-sibling-calls"; fi)

From: Alan Cox

2.96 still fails to get you working x86 kernels although how
much of that is gcc and how much kernel stuff is unknown



I'm not aware of any issues with 2.95.2 though.

Re: comparisons..

[Martin v. Loewis]

> Drat.  I've wasted your time.  Sorry.
> 
> pwold011:/home/morton> gcc -v
> Reading specs from /usr/lib/gcc-lib/i686-unknown-linux/2.7.2.3/specs
> gcc version 2.7.2.3
> 
> Any chance of a backport? :)

mira% kgcc -v             
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs
gcc version 2.7.2.3
mira% kgcc -S -W a.c
a.c: In function `y':
a.c:5: warning: unsigned value < 0 is always 0

What do you get?

Martin

Re: comparisons..

[Andrew Morton]

"Martin v. Loewis" wrote:
> 
> > Drat.  I've wasted your time.  Sorry.
> >
> > pwold011:/home/morton> gcc -v
> > Reading specs from /usr/lib/gcc-lib/i686-unknown-linux/2.7.2.3/specs
> > gcc version 2.7.2.3
> >
> > Any chance of a backport? :)
> 
> mira% kgcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs
> gcc version 2.7.2.3
> mira% kgcc -S -W a.c
> a.c: In function `y':
> a.c:5: warning: unsigned value < 0 is always 0
> 
> What do you get?

Enlightenment :)

The kernel uses -Wall, and this particular warning is not enabled with
-Wall.

Unfortunately using `-W' in the kernel makefiles generates a truckload
of warnings.  Is there a way of unbundling the `if (unsigned < 0)'
warning with a standalone flag?  Like -Wnegative-unsigned?   It appears
not.

The whole reason I brought this up is that someone found an `if
(unsigned < 0)' bug today.  Made my ears prick up.

A useful exercise would be to compile the kernel with `-W' and filter
out all the noise.   I'll do that tonight.

Thanks again.

Re: comparisons..

[Nick Burrett]

Andrew Morton <andrewm@uow.edu.au> writes:

> "Martin v. Loewis" wrote:
> > 
> > > Drat.  I've wasted your time.  Sorry.
> > >
> > > pwold011:/home/morton> gcc -v
> > > Reading specs from /usr/lib/gcc-lib/i686-unknown-linux/2.7.2.3/specs
> > > gcc version 2.7.2.3
> > >
> > > Any chance of a backport? :)
> > 
> > mira% kgcc -v
> > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs
> > gcc version 2.7.2.3
> > mira% kgcc -S -W a.c
> > a.c: In function `y':
> > a.c:5: warning: unsigned value < 0 is always 0
> > 
> > What do you get?
> 
> Enlightenment :)
> 
> The kernel uses -Wall, and this particular warning is not enabled with
> -Wall.
> 
> Unfortunately using `-W' in the kernel makefiles generates a truckload
> of warnings.  Is there a way of unbundling the `if (unsigned < 0)'
> warning with a standalone flag?  Like -Wnegative-unsigned?   It appears
> not.
> 
> The whole reason I brought this up is that someone found an `if
> (unsigned < 0)' bug today.  Made my ears prick up.

RTFM applies here. You'll find a big section on the additional -W options
that'll do what you need.

Will -Wsign-compare or -Wno-sign-compare do the trick ?
 

Nick.

Re: comparisons..

[Andrew Morton]

Nick Burrett wrote:
> 
> RTFM applies here. You'll find a big section on the additional -W options
> that'll do what you need.
> 
> Will -Wsign-compare or -Wno-sign-compare do the trick ?

Not with 2.7.2.3, at least.

Re: comparisons..

[Andrew Morton]

Andrew Morton wrote:
> 
> A useful exercise would be to compile the kernel with `-W' and filter
> out all the noise.   I'll do that tonight.

It was hilarious.  Nailed about sixty kernel bugs, some of them
drop-dead box killers.

Please, give us more granular control over the -W warnings!!

Re: comparisons..

[Joe Buck]

Andrew Morton wrote:

> A useful exercise would be to compile the kernel with `-W' and filter
> out all the noise.   I'll do that tonight.
...
> It was hilarious.  Nailed about sixty kernel bugs, some of them
> drop-dead box killers.
> 
> Please, give us more granular control over the -W warnings!!

Could you be more specific?  Which warnings do you want to enable and
suppress?  There's already a large set of -Wxxx and -Wno-xxx flags.
What's missing?

Re: comparisons..

[Bruce Korb]

Joe Buck wrote:
> > Please, give us more granular control over the -W warnings!!
> 
> Could you be more specific?  Which warnings do you want to enable and
> suppress?  There's already a large set of -Wxxx and -Wno-xxx flags.
> What's missing?

How hard would it be (wondering aloud and not having done 
any research at all)....

to set up an rc-type file at either gcc build time or
gcc run time (or both?) that contained a list of "my" warnings
and allowed someone to merely specify -Wmine on the command
line.  Just wondering....*not* volunteering :-)

Re: comparisons..

[Joe Buck]

> How hard would it be (wondering aloud and not having done 
> any research at all)....
> 
> to set up an rc-type file at either gcc build time or
> gcc run time (or both?) that contained a list of "my" warnings
> and allowed someone to merely specify -Wmine on the command
> line.  Just wondering....*not* volunteering :-)

It's not needed; you already have make.  Just put

CFLAGS=-Wthis -Wno-that -Wthis-one-too -Wno-stupid-warning ...

Folks working together on a free software project can standardize
on a set of warnings they think important and set up their makefiles
accordingly.

Re: comparisons..

[Russ Allbery]

Joe Buck <jbuck@racerx.synopsys.com> writes:
> Andrew Morton wrote:

>> Please, give us more granular control over the -W warnings!!

> Could you be more specific?  Which warnings do you want to enable and
> suppress?  There's already a large set of -Wxxx and -Wno-xxx flags.
> What's missing?

The one that I've specifically noticed is the following:  I want most of
the -W warnings and I want all of the -Wall warnings, but I specifically
don't want warnings about unused function parameters for some code
(particularly code that uses a large table of functions to handle
commands, some of which don't care about their arguments) since it's often
too much bother to tag all the unused parameters with gcc-specific
attributes.  I *do* want warnings about unused variables.

-Wall -W gives warnings about both unused variables and unused function
parameters.  -Wall -W -Wno-unused suppresses both.  I can't find a more
finely grained knob to turn.

(Apologies if this is already fixed in the mainline.)

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: comparisons..

[Philipp Thomas]

* Russ Allbery (rra@stanford.edu) [20000714 00:15]:

> -Wall -W gives warnings about both unused variables and unused function
> parameters.  -Wall -W -Wno-unused suppresses both.  I can't find a more
> finely grained knob to turn.

There presently isn't one. There was a patch posted on gcc-patches that
would make it possible to turn them on/off seperately but AFAIK, that patch
hasn't been reviewed yet for inclusion.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX for PDP 11, /usr/include/sys/param.h

Re: comparisons..

[Nix]

Andrew Morton <andrewm@uow.edu.au> writes:

> Please, give us more granular control over the -W warnings!!

I have patches for 2.95.2 that do most of that. I'll finish them off and
port them forward to the mainline this weekend.


btw, I have at last succeeded in extracting a disclaimer from my
employers (it took two months) after they abruptly changed my terms and
conditions on me to include a truly penal IP clause; essentially
`everything you do is ours'. Accordingly I can get back to doing GCC
stuff without feeling guilty, and I can send in the assignment (and
disclaimer) at last.

-- 
`I can guarantee it's no problem in my network, and if I don't get some
 sleep soon, I'll guarantee it will become a problem in your network.'
     --- Chris `Saundo' Saunderson deals with a late-night phone call

Re: comparisons..

[Gerald Pfeifer]

On Thu, 13 Jul 2000, Andrew Morton wrote:
> Unfortunately using `-W' in the kernel makefiles generates a truckload
> of warnings.  Is there a way of unbundling the `if (unsigned < 0)'
> warning with a standalone flag?

The questions is: Are the other warnings warranted or not? :-)

You already found several bugs in the kernel, perhaps there are further
ones still in there? And, of course, if you receive warnings you consider
inappropriate (bugs in the compiler?), please let us know!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
Have a look at http://petition.eurolinux.org -- it's not about Linux, btw!

Re: comparisons..

[Andrew Morton]

Gerald Pfeifer wrote:
> 
> On Thu, 13 Jul 2000, Andrew Morton wrote:
> > Unfortunately using `-W' in the kernel makefiles generates a truckload
> > of warnings.  Is there a way of unbundling the `if (unsigned < 0)'
> > warning with a standalone flag?
> 
> The questions is: Are the other warnings warranted or not? :-)

It generated nine megs of warnings total!

Yes, a lot were warranted, but not really practical.

The most useful ones were:

comparison of unsigned with zero:
	(unsigned < 0)
	(unsigned >= 0)

The empty `if' check found several of these:
	if (some_condition);
		statement;

comparisons like X<=Y<=Z do not have their mathematical meaning
	This happened rarely and was 100% correlated with wrong code.


> You already found several bugs in the kernel, perhaps there are further
> ones still in there? And, of course, if you receive warnings you consider
> inappropriate (bugs in the compiler?), please let us know!

There are probably some bugs hiding behind "comparison between signed
and unsigned", but I didn't check these - there were many hundreds.

  I'm told that the compiler will warn for this code:

	unsigned int i;
        if (i > 5)      /* 'i' is unsigned, '5' is signed, so warn */

  which makes this warning hard to use more than occasionally.

Re: comparisons..

[Russ Allbery]

Andrew Morton <andrewm@uow.edu.au> writes:

> There are probably some bugs hiding behind "comparison between signed
> and unsigned", but I didn't check these - there were many hundreds.

This is a rather interesting warning.  I've recently gone through the
exercise of making some code free of this warning, and I'm convinced that
it results in higher code quality, but it does require some work.  Most
code that I see plays fairly rough and loose with whether things are
signed or unsigned and gets away with it because the values that it deals
with are never high enough to cause a problem.  To be really correct, code
should care and deal with those boundary cases correctly.

Unfortunately, fixing these warnings often requires a good bit of fiddling
and can have some propagation effects similar to trying to const-ify old
code that makes fixing them all sometimes impractical for old code bases.

I don't think a lot of C programmers pay enough attention to signed vs.
unsigned issues, including a lot of interface designers.  Note, for
example, the interface to write:

  ssize_t write(int fildes, const void *buf, size_t nbyte);

What *do* you return if you can successfully write out as one block more
data than will fit in the range of ssize_t, but that will fit into size_t
(which is normally twice as large on the positive end)?  :)

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: comparisons..

[Michael Meissner]

On Thu, Jul 13, 2000 at 05:30:30PM -0700, Russ Allbery wrote:
> I don't think a lot of C programmers pay enough attention to signed vs.
> unsigned issues, including a lot of interface designers.  Note, for
> example, the interface to write:
> 
>   ssize_t write(int fildes, const void *buf, size_t nbyte);
> 
> What *do* you return if you can successfully write out as one block more
> data than will fit in the range of ssize_t, but that will fit into size_t
> (which is normally twice as large on the positive end)?  :)

-1 with errno set to EINVAL (and do no writing).

In this one small case, I think Microsoft actually got the interface right,
since they separate # of bytes written from the error value, so for example,
you can say that you wrote 2 megabytes of data before the error occurred.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: comparisons..

[Toon Moene]

Andrew Morton wrote:

[ ... This looks a lot like what happened when we first turned on 
      warnings while building gcc ... ]

>   I'm told that the compiler will warn for this code:
> 
>         unsigned int i;
>         if (i > 5)      /* 'i' is unsigned, '5' is signed, so warn */
> 
>   which makes this warning hard to use more than occasionally.

I always wondered whether it would be possible to drop the warning in
case the signed constant has the same value when interpreted as an
unsigned value.  Obviously, it is useful to compare an unsigned variable
against a _positive_ constant, even if it - strictly according to the
rules - should be interpreted as a signed quantity.  Or is this a
promotion-hair issue ?

[ Take this for what it's worth - Fortran doesn't know of unsigned
  quantities, and we're all the happier because of it ;-) ]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: comparisons..

[Richard Henderson]

On Fri, Jul 14, 2000 at 01:14:59PM +0200, Toon Moene wrote:
> I always wondered whether it would be possible to drop the warning in
> case the signed constant has the same value when interpreted as an
> unsigned value.

We do do this.


r~

Re: comparisons..

[Toon Moene]

Richard Henderson wrote:

> On Fri, Jul 14, 2000 at 01:14:59PM +0200, Toon Moene wrote:
> > I always wondered whether it would be possible to drop the warning in
> > case the signed constant has the same value when interpreted as an
> > unsigned value.

> We do do this.

Well, the simple example works, but then why does gcc warn on
loop.c:9839:

             && VARRAY_INT (n_times_set, REGNO (SET_DEST (set))) == 1

?

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: comparisons..

[Richard Henderson]

On Fri, Jul 14, 2000 at 09:01:34PM +0200, Toon Moene wrote:
> Well, the simple example works, but then why does gcc warn on
> 
>              && VARRAY_INT (n_times_set, REGNO (SET_DEST (set))) == 1

Something inside the VARRAY_INT?  Something inside REGNO or SET_DEST,
if you have rtl checking on.


r~

Re: comparisons..

[Toon Moene]

Richard Henderson wrote:

> On Fri, Jul 14, 2000 at 09:01:34PM +0200, Toon Moene wrote:

> > Well, the simple example works, but then why does gcc warn on
> >
> >              && VARRAY_INT (n_times_set, REGNO (SET_DEST (set))) == 1

> Something inside the VARRAY_INT?  Something inside REGNO or SET_DEST,
> if you have rtl checking on.

Oops - I forgot to say:  This is with --disable-checking (both on
i686-pc-linux-gnu and alphaev6-unknown-linux-gnu).

Without checking, there's not much "inside" VARRAY_INT (it's a simple
"accessor macro") ...

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: comparisons..

[Martin v. Loewis]

> I always wondered whether it would be possible to drop the warning in
> case the signed constant has the same value when interpreted as an
> unsigned value.  Obviously, it is useful to compare an unsigned variable
> against a _positive_ constant, even if it - strictly according to the
> rules - should be interpreted as a signed quantity.  Or is this a
> promotion-hair issue ?

The warning is not justified in this case. The integer constant is
converted into an unsigned integer, and standard C guarantees that
there will be no change in value due to this conversion. So writing

  x > 5

is guaranteed to be the same thing as

  x > 5U

Regards,
Martin

Re: comparisons..

[Joe Buck]

Andrew Morton wrote:
> >   I'm told that the compiler will warn for this code:
> > 
> >         unsigned int i;
> >         if (i > 5)      /* 'i' is unsigned, '5' is signed, so warn */
> > 
> >   which makes this warning hard to use more than occasionally.

You were told incorrectly.  Try it.  You will not get a warning.
Perhaps you were thinking of the inverse case:

        int i;
	if (i > 5U) ...

Here you WILL get a warning.  The reason for the warning is that
converting a negative int to unsigned produces a large positive value:

	int i = -1;
	if (i > 5U)
		SURPRISE;

is, indeed, surprising.

There are cases where gcc is too stupid to know that a signed-unsigned
comparison is safe.  A typical example is

int bar (int i, unsigned u)
{
    if (i >= 0 && i > u)
	return 3;
    else
	return 2;
}

we get "warning: comparison between signed and unsigned".  This
comparison is safe because we've already assured that i is non-negative
before comparing to u, but for gcc to know that it would need to implement
some kind of range propagation.  To silence the warning you have to write

    if (i >= 0 && (unsigned)i > u)

Toon writes:
> I always wondered whether it would be possible to drop the warning in
> case the signed constant has the same value when interpreted as an
> unsigned value.

Not only is it possible, but this is how gcc has worked for years.

Re: comparisons..

[Martin v. Loewis]

> unsigned long x;
>  
> int y()
> {
>         return (x < 0);
> }
> 
> This is usually a bug.  Is there a way of getting gcc to warn about it?

GCC knows exactly that the expression is zero; with -O2
-fomit-frame-pointer, it generates

y:
	xorl %eax,%eax
	ret

However, what exactly is the "usual" bug here? That an expression can
be computed statically? 

Regards,
Martin

Re: comparisons..

[Phil Edwards]

Bruce Korb <bkorb@sco.COM>:
> How hard would it be (wondering aloud and not having done 
> any research at all)....
>
> to set up an rc-type file at either gcc build time or
> gcc run time (or both?) that contained a list of "my" warnings
> and allowed someone to merely specify -Wmine on the command
> line.  Just wondering....*not* volunteering :-)

I and some of my coworkers have occasionally created ancilliary 4- and
5-line specs files, and use those to augment the defaults.  Usually we
use them to turn on /boatloads/ of extra warnings, but occasionally we
need some weird -f/-m flags turned on (and we can't modify the makefiles
for other reasons).

Then it's just "gcc -specs=.../philspecs" or "gcc -specs=.../bobspecs"
or, etc.


Phil

Re: comparisons..

[Michael Meissner]

On Thu, Jul 13, 2000 at 01:10:13PM -0400, Phil Edwards wrote:
> 
> Bruce Korb <bkorb@sco.COM>:
> > How hard would it be (wondering aloud and not having done 
> > any research at all)....
> >
> > to set up an rc-type file at either gcc build time or
> > gcc run time (or both?) that contained a list of "my" warnings
> > and allowed someone to merely specify -Wmine on the command
> > line.  Just wondering....*not* volunteering :-)
> 
> I and some of my coworkers have occasionally created ancilliary 4- and
> 5-line specs files, and use those to augment the defaults.  Usually we
> use them to turn on /boatloads/ of extra warnings, but occasionally we
> need some weird -f/-m flags turned on (and we can't modify the makefiles
> for other reasons).
> 
> Then it's just "gcc -specs=.../philspecs" or "gcc -specs=.../bobspecs"
> or, etc.

Or the simple shell script "gcc" that adds the appropriate switches, and then
execs the real gcc, and put that in your path before the real gcc.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482