Bug 4210 - should not warning with dead code
Summary: should not warning with dead code
Status: SUSPENDED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.0.1
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
: 8419 26516 28106 30343 40114 44842 60513 62074 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-09-03 11:36 UTC by gustav
Modified: 2014-08-09 06:09 UTC (History)
13 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-24 19:53:42


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description gustav 2001-09-03 11:36:00 UTC
gcc outputs a warning about shifts >= width of type inside
dead code when that code is dead because of a const
variable. This can easily happen in autogenerated code, or
when you do operations on preprocessor defines.

Release:
GNU C version 3.0.1 20010626 (prerelease) (i386-pc-linux-gnu)

How-To-Repeat:
Compile the following with -Wall -O2:

int rol0(int a)
{
        const int b = 0;
	if (b) {
		a = (a << b) | (a >> (8 * sizeof a - b));
        }
	return a;
}
Comment 1 Wolfgang Bangerth 2002-11-05 07:43:05 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. I may be wrong, but I believe Toon Moene has
    recently filed a similar bug (recently=it's number should be
    in the high 8000s) where the dead code was actually created
    by a template parameter, instead of a plain constant. Whoever
    looks at this one might want to look for the other report
    as well.
Comment 2 Wolfgang Bangerth 2002-11-06 16:12:43 UTC
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c/4210: bad warning with dead code
Date: Wed, 6 Nov 2002 16:12:43 -0600 (CST)

 I was wrong on the name of the originator, the range of numbers, and maybe 
 more of the duplicate I suspected. It had templates in it, though :-)
 
 In any case, the duplicate was c++/8419, which I closed because it is 
 almost an exact duplicate.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
Comment 3 Andrew Pinski 2003-05-24 23:14:41 UTC
stills warns on mainline (20030524).
Comment 4 Andrew Pinski 2003-05-31 12:28:16 UTC
I think the problem is the warning happens before dead code elimation happens.
Comment 5 Andrew Pinski 2003-08-11 12:14:59 UTC
suspending as the problem is that the warning comes before striping of dead code and this will 
not fixed for a while.
Comment 6 Mattias Engdegård 2003-08-11 12:29:57 UTC
Is there a technical reason why the bug is difficult to fix? Otherwise I might
look at it myself.
Comment 7 Andrew Pinski 2003-08-11 12:35:55 UTC
As I said the point at which the shift error happens is before GCC knows that the code is dead code 
at all.  The warning happens when generating the trees while dead code dection happens after 
that.
Comment 8 Mattias Engdegård 2003-08-11 12:51:42 UTC
Fine. Since this is about the only warning that I get from dead code, I assumed
that there was a mechanism already in place that silences other warnings from
removed code, but perhaps this is exactly what is missing :)
Or could the test be moved to a later phase (though it's obviously a frontend
issue)?
I'm just looking for an opportunity to do it myself if it's not too complicated.
Comment 9 Mattias Engdegård 2003-09-02 18:56:41 UTC
In gcc 3.3, warning in dead code also occurs in another case. Testcase:

unsigned f(unsigned x)
{
        if (sizeof x > 4)
                return x >= 1ull << 32 ? 1 : 0;
        return 0;
}

yields:
foo.c:4: warning: comparison is always false due to limited range of data type

This is a regression from 3.2.2. [Should I open a new bug for it?]
Comment 10 Wolfgang Bangerth 2003-09-02 21:08:03 UTC
Subject: Re:  should not warning with dead code

> This is a regression from 3.2.2. [Should I open a new bug for it?]

Yes, always.
W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Comment 11 Andrew Pinski 2003-09-03 11:31:41 UTC
*** Bug 12150 has been marked as a duplicate of this bug. ***
Comment 12 Andrew Pinski 2006-03-01 19:02:05 UTC
*** Bug 26516 has been marked as a duplicate of this bug. ***
Comment 13 joseph@codesourcery.com 2006-03-01 23:01:41 UTC
Subject: Re:  should not warning with dead code

A workaround is to use ? : and statement expressions instead of "if".  
This way, the front-end setting of skip_evaluation disables these 
warnings.  (skip_evaluation can't be set for if (0) because you can jump 
into if (0), whereas jumps into statement expressions are not permitted.  
Thus in general you need to parse the whole function body to tell if the 
if (0) is dead.)

Comment 14 Wolfgang Bangerth 2006-03-01 23:05:45 UTC
But that's
a) clearly a kludge,
b) may not help in the future if our optimizers become more elaborate
c) doesn't work with code where the code guarded by the if(0) is more
   than a single statement.
It would definitely be better to have this fixed in the right place...

W.
Comment 15 joseph@codesourcery.com 2006-03-01 23:22:50 UTC
Subject: Re:  should not warning with dead code

On Wed, 1 Mar 2006, bangerth at dealii dot org wrote:

> c) doesn't work with code where the code guarded by the if(0) is more
>    than a single statement.

It does; I've used it to eliminate all these warnings in glibc's soft-fp 
code.  Use statement expressions, i.e. surround the whole if body with ({ 
}).

Comment 16 Wolfgang Bangerth 2006-03-01 23:25:17 UTC
> It does; I've used it to eliminate all these warnings in glibc's soft-fp 
> code.  Use statement expressions, i.e. surround the whole if body with ({ 
> }).

Ugh. Do we really want to advocate serious code obfuscation to avoid warnings?
W.


Comment 17 Mattias Engdegård 2006-03-02 09:22:28 UTC
We have resorted to case-by-case workarounds, usually a cast which would have been an identity operation had the condition been true. That is,

if (sizeof x == 8)
        return x << 32 | x;

would have its second line mutated to

        return (unsigned long long)x << 32 | x;

The cast is always a no-op unless it occurs in dead code.
Comment 18 Andrew Pinski 2006-06-20 19:05:38 UTC
*** Bug 28106 has been marked as a duplicate of this bug. ***
Comment 19 Andrew Pinski 2007-01-01 19:03:13 UTC
*** Bug 30343 has been marked as a duplicate of this bug. ***
Comment 20 Andrew Pinski 2009-05-12 14:49:49 UTC
*** Bug 40114 has been marked as a duplicate of this bug. ***
Comment 21 Manuel López-Ibáñez 2010-07-06 17:24:00 UTC
*** Bug 44842 has been marked as a duplicate of this bug. ***
Comment 22 Manuel López-Ibáñez 2010-07-06 17:28:11 UTC
The way Clang gets this right is to perform some very-fast bitmap common constant propagation in the FE. I personally think this would be helpful if implemented correctly, even if it slows down the FE a little. But do not wait for a fix soon because this is not trivial to fix and no one has both the desire and the free time to work on fixing this.
Comment 23 Andrew Pinski 2014-03-13 02:10:05 UTC
*** Bug 60513 has been marked as a duplicate of this bug. ***
Comment 24 Andrew Pinski 2014-08-09 06:09:14 UTC
*** Bug 62074 has been marked as a duplicate of this bug. ***