GNU bug report logs - #766
23.0.60; interesting warning during compilation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 766 in the body.
You can then email your comments to 766 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 11:00:28 +0200

Hello!

The warning from gcc 4.0.1 is:

	dired.c:1003: warning: right shift count >= width of type

      /* To allow inode numbers beyond 32 bits, separate into 2 24-bit
	 high parts and a 16-bit bottom part.  */
      EMACS_INT high_ino = s.st_ino >> 32;
      EMACS_INT low_ino  = s.st_ino & 0xffffffff;


Mac OS X 10.4.11, CVS update yesterday.

--
Greetings

  Pete

A blizzard is when it snows sideways.

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>, 766 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 17:10:50 +0300

> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Sat, 23 Aug 2008 11:00:28 +0200
> Cc: 
> 
> The warning from gcc 4.0.1 is:
> 
> 	dired.c:1003: warning: right shift count >= width of type
> 
>        /* To allow inode numbers beyond 32 bits, separate into 2 24-bit
> 	 high parts and a 16-bit bottom part.  */
>        EMACS_INT high_ino = s.st_ino >> 32;
>        EMACS_INT low_ino  = s.st_ino & 0xffffffff;

This happens on any system whose st_ino is 32 bits or less, because
this code needs to cater to systems whose st_ino is wider than 32
bits.

If someone has suggestions how to avoid this warning without making
code ugly and unreadable, and preferably without system-dependent
#ifdef's, I'm all ears.

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 766 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 16:58:20 +0200

Am 23.08.2008 um 16:10 schrieb Eli Zaretskii:

> This happens on any system whose st_ino is 32 bits or less, because
> this code needs to cater to systems whose st_ino is wider than 32
> bits.

Could it work to type-cast the variable first into a type wider than  
32 bits?

--
Greetings

  Pete

No project was ever completed on time and within budget.
				– Cheops Law

Message #30 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 766 <at> debbugs.gnu.org, Peter Dyballa <Peter_Dyballa <at> Freenet.DE>,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 19:33:22 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> If someone has suggestions how to avoid this warning without making
> code ugly and unreadable, and preferably without system-dependent
> #ifdef's, I'm all ears.

EMACS_INT high_ino = s.st_ino >> 31 >> 1;

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #35 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 766 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 20:34:27 +0300

> Cc: 766 <at> emacsbugs.donarmstrong.com,
>  bug-gnu-emacs <at> gnu.org
> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Sat, 23 Aug 2008 16:58:20 +0200
> 
> Could it work to type-cast the variable first into a type wider than  
> 32 bits?

It could, if we could be sure that 64-bit wide integer types are
supported on all platforms.  I don't know if they are; does anyone
know?

(It looks like we use "long long" etc. vary sparingly and only on
platform-specific files, where there's no problem knowing whether it
is supported.)

Message #50 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 766 <at> debbugs.gnu.org, Peter_Dyballa <at> Freenet.DE,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 21:18:19 +0300

> From: Andreas Schwab <schwab <at> suse.de>
> Cc: 766 <at> emacsbugs.donarmstrong.com,
> 	Peter Dyballa <Peter_Dyballa <at> Freenet.DE>, bug-gnu-emacs <at> gnu.org
> Date: Sat, 23 Aug 2008 19:33:22 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If someone has suggestions how to avoid this warning without making
> > code ugly and unreadable, and preferably without system-dependent
> > #ifdef's, I'm all ears.
> 
> EMACS_INT high_ino = s.st_ino >> 31 >> 1;

Thanks.  Can we be reasonably sure that GCC will not become smart
enough some day to flag this as well?

Message #60 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 766 <at> debbugs.gnu.org, Peter_Dyballa <at> Freenet.DE,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 20:56:38 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andreas Schwab <schwab <at> suse.de>
>> EMACS_INT high_ino = s.st_ino >> 31 >> 1;
>
> Thanks.  Can we be reasonably sure that GCC will not become smart
> enough some day to flag this as well?

What do you mean with "smart enough"?  There is nothing to flag here.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #70 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 766 <at> debbugs.gnu.org, Peter_Dyballa <at> Freenet.DE,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 22:06:12 +0300

> From: Andreas Schwab <schwab <at> suse.de>
> Cc: 766 <at> emacsbugs.donarmstrong.com, Peter_Dyballa <at> Freenet.DE,
> 	bug-gnu-emacs <at> gnu.org
> Date: Sat, 23 Aug 2008 20:56:38 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab <at> suse.de>
> >> EMACS_INT high_ino = s.st_ino >> 31 >> 1;
> >
> > Thanks.  Can we be reasonably sure that GCC will not become smart
> > enough some day to flag this as well?
> 
> What do you mean with "smart enough"?

Maybe that was a polite way of saying "silly enough".

> There is nothing to flag here.

I meant the warning about shifting by too many bits.  31+1 = 32, and
even a compiler can realize that.

Please don't get me wrong: I will gladly make the change as you
suggested, I just don't want us to bump into this again a few GCC
upgrades down the road.

Message #80 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 766 <at> debbugs.gnu.org, Peter_Dyballa <at> Freenet.DE,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 22:03:31 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I meant the warning about shifting by too many bits.  31+1 = 32, and
> even a compiler can realize that.

That's not how the shift operator is defined.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #90 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 766 <at> debbugs.gnu.org, Peter_Dyballa <at> Freenet.DE,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sat, 23 Aug 2008 23:50:18 +0300

> From: Andreas Schwab <schwab <at> suse.de>
> Cc: 766 <at> emacsbugs.donarmstrong.com, Peter_Dyballa <at> Freenet.DE,
> 	bug-gnu-emacs <at> gnu.org
> Date: Sat, 23 Aug 2008 22:03:31 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I meant the warning about shifting by too many bits.  31+1 = 32, and
> > even a compiler can realize that.
> 
> That's not how the shift operator is defined.

Andreas, it's late and I'm tired.  Could you please answer my
question, which is: what is the danger, if any, that GCC in some
future version will produce the same warning for the code you
suggested?

Thanks in advance.

Message #100 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 766 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sun, 24 Aug 2008 00:23:29 +0200

Am 23.08.2008 um 19:34 schrieb Eli Zaretskii:

>> Could it work to type-cast the variable first into a type wider than
>> 32 bits?
>
> It could, if we could be sure that 64-bit wide integer types are
> supported on all platforms.  I don't know if they are; does anyone
> know?


There aren't so many (elderly) systems left ... Besides, isn't the  
long long, a data type of at least 64 bits, defined in C, ANSI C99 to  
be exact? Actually, I think, it's sad that no compiler needs to  
follow this option!

Another option is to check whether the size of the variable is bigger  
than four bytes.

--
Greetings

  Pete

Rain is saved up in cloud banks.

Message #110 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 766 <at> debbugs.gnu.org, Peter_Dyballa <at> Freenet.DE,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sun, 24 Aug 2008 01:12:55 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Andreas, it's late and I'm tired.  Could you please answer my
> question, which is: what is the danger, if any, that GCC in some
> future version will produce the same warning for the code you
> suggested?

I have already answered that question.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #120 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 766 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sun, 24 Aug 2008 06:13:12 +0300

> Cc: 766 <at> emacsbugs.donarmstrong.com,
>  bug-gnu-emacs <at> gnu.org
> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Sun, 24 Aug 2008 00:23:29 +0200
> 
> Another option is to check whether the size of the variable is bigger  
> than four bytes.

If you mean with sizeof, then the problem is that sizeof is not a
preprocessing-time operator, so it cannot prevent the compiler from
seeing the offending code.

Message #125 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 766 <at> debbugs.gnu.org, Peter_Dyballa <at> Freenet.DE,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sun, 24 Aug 2008 06:14:58 +0300

> From: Andreas Schwab <schwab <at> suse.de>
> Cc: 766 <at> emacsbugs.donarmstrong.com, Peter_Dyballa <at> Freenet.DE,
> 	bug-gnu-emacs <at> gnu.org
> Date: Sun, 24 Aug 2008 01:12:55 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Andreas, it's late and I'm tired.  Could you please answer my
> > question, which is: what is the danger, if any, that GCC in some
> > future version will produce the same warning for the code you
> > suggested?
> 
> I have already answered that question.

In that case, I didn't understand it.  Just for me, could you please
translate it into a simple YES or NO: is there a danger that GCC will
in the future produce the same warning for your suggested code?

Thanks.

Message #140 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 766 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sun, 24 Aug 2008 09:27:16 +0200

Am 24.08.2008 um 05:13 schrieb Eli Zaretskii:

> If you mean with sizeof, then the problem is that sizeof is not a
> preprocessing-time operator, so it cannot prevent the compiler from
> seeing the offending code.

You mean

	if (sizeof (s.st_ino) > 4)

introducing the shift operation will fail to keep the compiler from  
emitting the warning?


Anyway, I think Andreas Schwab's proposition to split the one wide  
shift into two shorter ones is better. And the original code relies  
on an undefined behaviour of every compiler, which might change.

--
Greetings

  Pete

No project was ever completed on time and within budget.
				– Cheops Law

Message #150 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 766 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Sun, 24 Aug 2008 21:12:02 +0300

> Cc: 766 <at> emacsbugs.donarmstrong.com,
>  bug-gnu-emacs <at> gnu.org
> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Sun, 24 Aug 2008 09:27:16 +0200
> 
> 
> Am 24.08.2008 um 05:13 schrieb Eli Zaretskii:
> 
> > If you mean with sizeof, then the problem is that sizeof is not a
> > preprocessing-time operator, so it cannot prevent the compiler from
> > seeing the offending code.
> 
> You mean
> 
> 	if (sizeof (s.st_ino) > 4)
> 
> introducing the shift operation will fail to keep the compiler from  
> emitting the warning?

Yes, it will fail.  Please try compiling this toy program on a 32-bit
machine, and you will see the same warning.

    int foo (int a)
    {
      if (sizeof (a) > 4)
	return a >> 32;
      else
	return 0;
    }

> Anyway, I think Andreas Schwab's proposition to split the one wide  
> shift into two shorter ones is better.

I agree, I just wanted to be sure that this won't bring the same
warning back at some future time.

Message #160 received at 766-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: 766-done <at> debbugs.gnu.org
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Wed, 27 Aug 2008 15:05:59 -0400

I've checked in Andreas' fix.

Message #165 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 766 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> suse.de>,
        bug-gnu-emacs <at> gnu.org, Peter_Dyballa <at> Freenet.DE
Subject: Re: bug#766: 23.0.60; interesting warning during compilation
Date: Wed, 03 Sep 2008 14:47:14 -0400

>> > If someone has suggestions how to avoid this warning without making
>> > code ugly and unreadable, and preferably without system-dependent
>> > #ifdef's, I'm all ears.
>> 
>> EMACS_INT high_ino = s.st_ino >> 31 >> 1;

> Thanks.  Can we be reasonably sure that GCC will not become smart
> enough some day to flag this as well?

I don't think anybody can guarantee it, but usually it's a bad idea to
output warnings about post-optimization code, so you may hope that GCC
will optimize "x >> 31 >> 1" to "x >> 32" without ever outputing
a warning about the silliness of the end result.

Then again, the present code shows that even outputting a warning about
"x >> 32" is already borderline annoying, so there's no guarantee gcc
won't become more annoying in the future.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.