gcc 3.3: long long bug?

[A.R. Ashok Kumar]

Hi,

> I think gcc 3.2 (which didn't give me any errors)
> behaves more properly, automatically converting 
> rvalue to lvalue. Such behavior also solves
> "long long long ..." problems.

  Have you obtained correct result? 

  For me, the following program gives wrong result(using gcc 2.7.2 on
  sparc-sun-solaris2.3).

------
const long long n = 34359738368LL;
int  main() {
        printf("%ld\n", n);
}
------

 Obtained Result: 8
 Expected Result: 34359738368

- AshokA-

> > -----Original Message-----
> > From: John Love-Jensen [mailto:eljay@adobe.com]
> > Sent: Monday, April 07, 2003 5:01 PM
> > To: Andreas Schwab; Eric Botcazou
> > Cc: Lev Assinovsky; gcc-bugs@gcc.gnu.org; gcc-help@gcc.gnu.org
> > Subject: Re: gcc 3.3: long long bug?
> > 
> > 
> > Hi Andreas,
> > 
> > > |> Append "LL" to the constant.
> > > 
> > > That should not be needed.
> > 
> > The "LL" should be needed, unless a "long long" is the same size as a
> > "long".
> > 
> > The "long long" data type is an extension to the C (ISO 9989) 
> > and C++ (ISO
> > 14882) specs.  As such, automatically sizing a numeric 
> > literal to "long
> > long" (like how a numeric literal that's too big for an "int" 
> > becomes an
> > "unsigned int", and then a "long" and then an "unsigned 
> > long") could cause
> > problems.
> > 
> > Unfortunately, requiring the "LL" suffix causes other headaches.
> > 
> > I wonder when we'll have "long long long" (128-bit) and "long 
> > long long
> > long" (256-bit) numbers.  With accompanying "LLL" and "LLLL" suffixes.
> > *sigh*
> > 
> > --Eljay
> > 
> > 
>