This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: gcc 3.3: long long bug?
- From: "Lev Assinovsky" <LAssinovsky at algorithm dot aelita dot com>
- To: "John Love-Jensen" <eljay at adobe dot com>,"Andreas Schwab" <schwab at suse dot de>,"Eric Botcazou" <ebotcazou at libertysurf dot fr>
- Cc: <gcc-bugs at gcc dot gnu dot org>,<gcc-help at gcc dot gnu dot org>
- Date: Mon, 7 Apr 2003 17:13:32 +0400
- Subject: RE: gcc 3.3: long long bug?
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.
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: John Love-Jensen [mailto:eljay at adobe dot com]
> Sent: Monday, April 07, 2003 5:01 PM
> To: Andreas Schwab; Eric Botcazou
> Cc: Lev Assinovsky; gcc-bugs at gcc dot gnu dot org; gcc-help at gcc dot gnu dot 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
>
>