This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.1.1
- From: Simon Shapiro <shimon at nomis-storage dot com>
- To: Jack Lloyd <lloyd at acm dot jhu dot edu>
- Cc: Toon Moene <toon at moene dot indiv dot nluug dot nl>, gcc at gcc dot gnu dot org, shimon at simon-shapiro dot com
- Date: Thu, 27 Jun 2002 18:32:13 +0100
- Subject: Re: GCC 3.1.1
Thanx.
This a subtle ``user error'' for which I will assume responsibility.
Since the code was written and submitted by a combined experience of
over 40 years, and over 16 hours of engineering, I would dare suggest
that
perhaps the compiler should have emitted some warning.
Thanx to all who cared to elaborate and explain our ignorance.
Simon
-------------------
> On Thu, 27 Jun 2002, Toon Moene wrote:
>
> > Mark Mitchell wrote:
> >
> > > We have now got a pretty long list of regressions that we need to
fix
> > > before GCC 3.1.1.
> >
> > This is at least partly because Ordinary Users can set High Priority
> > bugs (again) in GNATS.
> >
> > Consider 7139 for instance. I'm not a C Guru, but shifting 1 over
64
> > bits seems like invoking undefined behaviour to me (i.e., a User
Error).
>
> The problem in this code is that it is assuming promotion from 1
(which
> IIRC, will be an int) to long long if the shift larger than #bits of
int.
> It seems so reasonable to expect, too. :( There is no warning because
the
> shift is a loop variable, 0...63
>
> Basically:
>
> unsigned long long x;
> x = 1 << 32;
>
> results in x == 0 rather than 0x100000000 as the code expects.
>
> Simon: Changing "1 << i" to "(unsigned long long)1 << i" seems to fix
the
> problem you're having. Here is the output of your program when i = 32
with
> those casts in:
>
> yuck(32): y = 1ffffffff, a[0] = ffffffff, a[1] = 1
> fooie(32): y = 100000000, a[0] = 0, a[1] = 1
>
> which looks to be what you were expecting.
>
> -Jack
>
Sincerely,
Simon Shapiro, CEO
Nomis