RE: gcc 3.3: long long bug?

RE: gcc 3.3: long long bug?

[Lev Assinovsky]

No I meant MSVC 6.2 on Windows.
Yes, it works without any suffixes 
with 3.2 on Unix.
Also this:
const long long n =  100000000 * 1000000000;

works with 3.3 on Unix either. 

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: A.R. Ashok Kumar [mailto:ashokar@sankhya.com]
> Sent: Monday, April 07, 2003 5:35 PM
> To: Lev Assinovsky
> Cc: Andreas Schwab; Eric Botcazou; gcc-help@gcc.gnu.org
> Subject: RE: gcc 3.3: long long bug?
> 
> 
> Hi,
> 
> > No, what was the reason to change the behavior of 3.2?
> > We developing the portable application which should work
> > in Windows 2000 also.
> > There is an automatic recognition of long long constants in 
> MSVC though you can 
> > add i64 suffix.
> > With 3.3 I have to write:
> > const long long n =
> > #ifdef WIN32
> > 34359738368
> > #else
> > 34359738368LL
> > #endif
> > ;
> > 
> > Not nice, right?
> 
>   Is gcc3.3 for Win32 gives error for the following statement?
> 
>     const long long n = 34359738368LL;
> 
>   If so, it is not nice behaviour. Does it work for gcc 3.2 ?
> 
> - AshokA -
> 
> 
> 

Re: gcc 3.3: long long bug?

[Andreas Schwab]

"Lev Assinovsky" <LAssinovsky@algorithm.aelita.com> writes:

|> No I meant MSVC 6.2 on Windows.
|> Yes, it works without any suffixes 
|> with 3.2 on Unix.
|> Also this:
|> const long long n =  100000000 * 1000000000;
|> 
|> works with 3.3 on Unix either. 

Whatever you mean with "works".  This is invoking undefined behaviour if
LONG_MAX < 100000000000000000, or INT_MAX >= 1000000000 and INT_MAX <
100000000000000000.  The limits of long long are irrelevant here.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc 3.3: long long bug?

[Ben Davis]

What a great thread. Lots of confused replies :) But yeah, it seems to me 
(after doing a test or two of my own with GCC 3.2) that GCC has lost the 
ability to automatically recognise huge integer constants as 'long long'. 
Whether this change was made by accident, or to conform to a new standard, or 
for some deep reasons that have something to do with "it's harder to go 
wrong"-type flame wars, I have no idea ...

On Monday 07 April 2003 2:30 pm, Lev Assinovsky wrote:
> With 3.3 I have to write:
> const long long n =
> #ifdef WIN32
> 34359738368
> #else
> 34359738368LL
> #endif
> ;

I recommend you check for the __GNUC__ symbol instead. There are builds of GCC 
for Windows ( http://www.mingw.org/ ), and there are other compilers that 
won't recognise the LL suffix.

In this case, though, you should probably use the following for clarity:

   const long long n = (long long)1 << 35;

This will be evaluated at compile time. Note that the cast applies only to the 
1, not to the whole expression.

Incidentally, I didn't know MSVC supported 'long long' as a type - I thought 
you had to use __int64. I suppose it's new in the latest version or 
something, since 'long long' is in the C99 standard (I think). It's certainly 
an improvement :)

Ben

PS. Hi Eric :)

Re: gcc 3.3: long long bug?

[Andreas Schwab]

"Lev Assinovsky" <LAssinovsky@algorithm.aelita.com> writes:

|> 100000000 * 1000000000 is calculated during compilation, right?

This is irrelevant.  The type of an expression is determined statically.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc 3.3: long long bug?

[Andreas Schwab]

"A.R. Ashok Kumar" <ashokar@sankhya.com> writes:

|> Hi,
|> 
|> On 7 Apr 2003, Anders [ISO-8859-1] Ã…dland wrote:
|> 
|> > I don't know anything about C standards, but why do we have to add the
|> > 'LL' suffix? Is it giving any additional information to the compiler?
|> 
|>   If you didn't specify 'L' or 'LL' suffix, then gcc will consider it
|>   as "integer" type (4 bytes). 

This is wrong.  The type of the constant will be the first to fit, using a
particular order.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: gcc 3.3: long long bug?

[Lev Assinovsky]

How comes it works fine in gcc 3.2?

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: A.R. Ashok Kumar [mailto:ashokar@sankhya.com]
> Sent: Monday, April 07, 2003 6:37 PM
> To: Anders Adland
> Cc: Andreas Schwab; Eric Botcazou; Lev Assinovsky; 
> gcc-help@gcc.gnu.org
> Subject: Re: gcc 3.3: long long bug?
> 
> 
> Hi,
> 
> On 7 Apr 2003, Anders [ISO-8859-1] Ådland wrote:
> 
> > I don't know anything about C standards, but why do we have 
> to add the
> > 'LL' suffix? Is it giving any additional information to the 
> compiler?
> 
>   If you didn't specify 'L' or 'LL' suffix, then gcc will consider it
>   as "integer" type (4 bytes). 
> 
> -AshokA-
> 
> > On Mon, 2003-04-07 at 15:07, A.R. Ashok Kumar wrote:
> > > Hi,
> > > 
> > > > |>    You can check the size of "long long" type in 
> your system, by printing
> > > > |>    sizeof(long long). 
> > > > 
> > > > On my system sizeof(long) is 8.
> > > 
> > >   Since 8 bytes are too small to hold 35-bit numbers, the 
> error occurred.
> > > 
> > >   Please use 'LL' suffix, to solve the problem.
> > > 
> > >    i.e  const long long n = 34359738368LL;
> > > 
> > > - AshokA -
> > > 
> > 
> > 
> 
> 
> 

RE: gcc 3.3: long long bug?

[Lev Assinovsky]

100000000 * 1000000000 is calculated during compilation, right?
So the compiler is able to manage long long constants internally.
I guess all this issue occurs because of new gcc 3.3 parser 
where long long literals are not recognized properly unless
"LL" suffix is presented.
May be I am wrong. May be there are another explanations 
of the different long long processing in 3.3 vs. 3.2.
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: Andreas Schwab [mailto:schwab@suse.de]
> Sent: Monday, April 07, 2003 6:13 PM
> To: Lev Assinovsky
> Cc: A.R. Ashok Kumar; Eric Botcazou; gcc-help@gcc.gnu.org
> Subject: Re: gcc 3.3: long long bug?
> 
> 
> "Lev Assinovsky" <LAssinovsky@algorithm.aelita.com> writes:
> 
> |> No I meant MSVC 6.2 on Windows.
> |> Yes, it works without any suffixes 
> |> with 3.2 on Unix.
> |> Also this:
> |> const long long n =  100000000 * 1000000000;
> |> 
> |> works with 3.3 on Unix either. 
> 
> Whatever you mean with "works".  This is invoking undefined 
> behaviour if
> LONG_MAX < 100000000000000000, or INT_MAX >= 1000000000 and INT_MAX <
> 100000000000000000.  The limits of long long are irrelevant here.
> 
> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> 

Re: gcc 3.3: long long bug?

[A.R. Ashok Kumar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 797 bytes --]

Hi,

On 7 Apr 2003, Anders [ISO-8859-1] Ådland wrote:

> I don't know anything about C standards, but why do we have to add the
> 'LL' suffix? Is it giving any additional information to the compiler?

  If you didn't specify 'L' or 'LL' suffix, then gcc will consider it
  as "integer" type (4 bytes). 

-AshokA-

> On Mon, 2003-04-07 at 15:07, A.R. Ashok Kumar wrote:
> > Hi,
> > 
> > > |>    You can check the size of "long long" type in your system, by printing
> > > |>    sizeof(long long). 
> > > 
> > > On my system sizeof(long) is 8.
> > 
> >   Since 8 bytes are too small to hold 35-bit numbers, the error occurred.
> > 
> >   Please use 'LL' suffix, to solve the problem.
> > 
> >    i.e  const long long n = 34359738368LL;
> > 
> > - AshokA -
> > 
> 
> 

Re: gcc 3.3: long long bug?

[Andreas Schwab]

Anders Ã…dland <aaadland@atmel.no> writes:

|> I don't know anything about C standards, but why do we have to add the
|> 'LL' suffix? Is it giving any additional information to the compiler?

Yes.  It tells the compiler that the constant is supposed to be of type
long long if it fits, and not of any narrower type (even if the constant
would fit there).  The type of an expression is determined only by looking
at the expression itself, ignoring the context.  The context can then
instruct the compiler to insert some conversions, but that happens only
afterwards.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc 3.3: long long bug?

[Anders Ådland]

I don't know anything about C standards, but why do we have to add the
'LL' suffix? Is it giving any additional information to the compiler?

Anders

On Mon, 2003-04-07 at 15:07, A.R. Ashok Kumar wrote:
> Hi,
> 
> > |>    You can check the size of "long long" type in your system, by printing
> > |>    sizeof(long long). 
> > 
> > On my system sizeof(long) is 8.
> 
>   Since 8 bytes are too small to hold 35-bit numbers, the error occurred.
> 
>   Please use 'LL' suffix, to solve the problem.
> 
>    i.e  const long long n = 34359738368LL;
> 
> - AshokA -
> 

Re: gcc 3.3: long long bug?

[A.R. Ashok Kumar]

Hi,

> > ------
> > const long long n = 34359738368LL;
> > int  main() {
> >       printf("%ld\n", n);
> > }
> > ------
> 
> Are you sure the format is supposed to be "%ld\n"?  Or is it supposed to be
> "%lld\n" or "%Ld\n"?
> 
> The "%ld" format is for date type "signed long int", and a "long long" is
> (usually) NOT the same data type and printf type format.

  Yes, it works fine for "%lld" format. Thanks!

- AshokA -

Re: gcc 3.3: long long bug?

[Andreas Schwab]

"A.R. Ashok Kumar" <ashokar@sankhya.com> writes:

|> 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);

Undefined behaviour.  %ld expects long, but n is long long.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: gcc 3.3: long long bug?

[Lev Assinovsky]

No, what was the reason to change the behavior of 3.2?
We developing the portable application which should work
in Windows 2000 also.
There is an automatic recognition of long long constants in MSVC though you can 
add i64 suffix.
With 3.3 I have to write:
const long long n =
#ifdef WIN32
34359738368
#else
34359738368LL
#endif
;

Not nice, right?

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: A.R. Ashok Kumar [mailto:ashokar@sankhya.com]
> Sent: Monday, April 07, 2003 5:17 PM
> To: Andreas Schwab
> Cc: Eric Botcazou; Lev Assinovsky; gcc-help@gcc.gnu.org
> Subject: Re: gcc 3.3: long long bug?
> 
> 
> Hi,
> 
> > |> > |>    You can check the size of "long long" type in 
> your system, by printing
> > |> > |>    sizeof(long long). 
> > |> > 
> > |> > On my system sizeof(long) is 8.
> > |> 
> > |>   Since 8 bytes are too small to hold 35-bit numbers, 
> the error occurred.
> > 
> > ??? 8*8 = 64.
> 
>   Yes, It should work for 35-bit numbers
> 
> - Ashok -
> 
> > Andreas Schwab, SuSE Labs, schwab@suse.de
> > SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 NЭrnberg
> > Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> > "And now for something completely different."
> > 
> 
> 

RE: 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
> > 
> > 
> 

Re: gcc 3.3: long long bug?

[John Love-Jensen]

Hi Ashok,

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

Are you sure the format is supposed to be "%ld\n"?  Or is it supposed to be
"%lld\n" or "%Ld\n"?

The "%ld" format is for date type "signed long int", and a "long long" is
(usually) NOT the same data type and printf type format.

Sincerely,
--Eljay

RE: gcc 3.3: long long bug?

[A.R. Ashok Kumar]

Hi,

> No, what was the reason to change the behavior of 3.2?
> We developing the portable application which should work
> in Windows 2000 also.
> There is an automatic recognition of long long constants in MSVC though you can 
> add i64 suffix.
> With 3.3 I have to write:
> const long long n =
> #ifdef WIN32
> 34359738368
> #else
> 34359738368LL
> #endif
> ;
> 
> Not nice, right?

  Is gcc3.3 for Win32 gives error for the following statement?

    const long long n = 34359738368LL;

  If so, it is not nice behaviour. Does it work for gcc 3.2 ?

- AshokA -

RE: gcc 3.3: long long bug?

[Lev Assinovsky]

#include <iostream>
using namespace std;
const long long n = 34359738368LL; // 2^35
 
int main()
{
    cout << "Printed:" << n << endl;
}

Printed:34359738368

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: A.R. Ashok Kumar [mailto:ashokar@sankhya.com]
> Sent: Monday, April 07, 2003 5:26 PM
> To: Lev Assinovsky
> Cc: John Love-Jensen; Andreas Schwab; Eric Botcazou;
> gcc-bugs@gcc.gnu.org; gcc-help@gcc.gnu.org
> Subject: RE: gcc 3.3: long long bug?
> 
> 
> 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
> > > 
> > > 
> > 
> 
> 

Re: gcc 3.3: long long bug?

[A.R. Ashok Kumar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 571 bytes --]

Hi,

> |> > |>    You can check the size of "long long" type in your system, by printing
> |> > |>    sizeof(long long). 
> |> > 
> |> > On my system sizeof(long) is 8.
> |> 
> |>   Since 8 bytes are too small to hold 35-bit numbers, the error occurred.
> 
> ??? 8*8 = 64.

  Yes, It should work for 35-bit numbers

- Ashok -

> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> 

Re: gcc 3.3: long long bug?

[Andreas Schwab]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

|> > That should not be needed.
|> 
|> Then there is some confusion on the compiler's side as to which constants 
|> should be accepted in which mode because there is no warning with -std=c99.

Note that the OP talked about C++, which does not have long long
officially.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: gcc 3.3: long long bug?

[Lev Assinovsky]

8 bytes = 64 bits.
I have UltraSpars 64 bits.

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: A.R. Ashok Kumar [mailto:ashokar@sankhya.com]
> Sent: Monday, April 07, 2003 5:07 PM
> To: Andreas Schwab
> Cc: Eric Botcazou; Lev Assinovsky; gcc-help@gcc.gnu.org
> Subject: Re: gcc 3.3: long long bug?
> 
> 
> Hi,
> 
> > |>    You can check the size of "long long" type in your 
> system, by printing
> > |>    sizeof(long long). 
> > 
> > On my system sizeof(long) is 8.
> 
>   Since 8 bytes are too small to hold 35-bit numbers, the 
> error occurred.
> 
>   Please use 'LL' suffix, to solve the problem.
> 
>    i.e  const long long n = 34359738368LL;
> 
> - AshokA -
> 
> 

RE: gcc 3.3: long long bug?

[Lev Assinovsky]

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@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
> 
> 

RE: gcc 3.3: long long bug?

[A.R. Ashok Kumar]

Hi,

> No, sizeof (long long) is 8 in my system.

  In that case, you may not handle more that 2^32.

  If you specify "LL", then it will compile. But you can get only
  the truncated result.

- AshokA -
  
> > > |> > const long long n = 34359738368; // 2^35
> > > |> >
> > > |> > Got:
> > > |> > max.cpp:1: error: integer constant is too large for "long" type
> > > |> 
> > > |> Append "LL" to the constant.
> > > 
> > > That should not be needed.
> > 
> >    Size for type "long long" may be only 32-bit in your 
> > system. Since it
> >    is 35-bit number, it gives error.
> > 
> >    You can check the size of "long long" type in your system, 
> > by printing
> >    sizeof(long long). 
> > 
> > Best Wishes,
> > AshokA
> > 
> > 
> 

Re: gcc 3.3: long long bug?

[Andreas Schwab]

"A.R. Ashok Kumar" <ashokar@sankhya.com> writes:

|> Hi,
|> 
|> > |>    You can check the size of "long long" type in your system, by printing
|> > |>    sizeof(long long). 
|> > 
|> > On my system sizeof(long) is 8.
|> 
|>   Since 8 bytes are too small to hold 35-bit numbers, the error occurred.

??? 8*8 = 64.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc 3.3: long long bug?

[Andreas Schwab]

John Love-Jensen <eljay@adobe.com> writes:

|> 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".

ITYM unless LONG_MAX >= 2^35.

|> 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.

C99 already specifies the needed rules to make LL unnecessary.  You are
right in that long long does not exist in Standard C++, but IMHO the
default for GNU C++ should be consistent with GNU C.

|> 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*

You can probably find big threads about that subject in the comp.std.c
archives.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc 3.3: long long bug?

[Eric Botcazou]

> That should not be needed.

Then there is some confusion on the compiler's side as to which constants 
should be accepted in which mode because there is no warning with -std=c99.

-- 
Eric Botcazou

Re: gcc 3.3: long long bug?

[A.R. Ashok Kumar]

Hi,

> |>    You can check the size of "long long" type in your system, by printing
> |>    sizeof(long long). 
> 
> On my system sizeof(long) is 8.

  Since 8 bytes are too small to hold 35-bit numbers, the error occurred.

  Please use 'LL' suffix, to solve the problem.

   i.e  const long long n = 34359738368LL;

- AshokA -

RE: gcc 3.3: long long bug?

[Lev Assinovsky]

No, sizeof (long long) is 8 in my system.

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: A.R. Ashok Kumar [mailto:ashokar@sankhya.com]
> Sent: Monday, April 07, 2003 4:30 PM
> To: Andreas Schwab
> Cc: Eric Botcazou; Lev Assinovsky; gcc-help@gcc.gnu.org
> Subject: Re: gcc 3.3: long long bug?
> 
> 
> Hi,
> 
> > |> > const long long n = 34359738368; // 2^35
> > |> >
> > |> > Got:
> > |> > max.cpp:1: error: integer constant is too large for "long" type
> > |> 
> > |> Append "LL" to the constant.
> > 
> > That should not be needed.
> 
>    Size for type "long long" may be only 32-bit in your 
> system. Since it
>    is 35-bit number, it gives error.
> 
>    You can check the size of "long long" type in your system, 
> by printing
>    sizeof(long long). 
> 
> Best Wishes,
> AshokA
> 
> 

Re: gcc 3.3: long long bug?

[John Love-Jensen]

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

Re: gcc 3.3: long long bug?

[Andreas Schwab]

"A.R. Ashok Kumar" <ashokar@sankhya.com> writes:

|> Hi,
|> 
|> > |> > const long long n = 34359738368; // 2^35
|> > |> >
|> > |> > Got:
|> > |> > max.cpp:1: error: integer constant is too large for "long" type
|> > |> 
|> > |> Append "LL" to the constant.
|> > 
|> > That should not be needed.
|> 
|>    Size for type "long long" may be only 32-bit in your system. Since it
|>    is 35-bit number, it gives error.

That has no significance here, because the error message explicitly
mentions "long", not "long long".

|>    You can check the size of "long long" type in your system, by printing
|>    sizeof(long long). 

On my system sizeof(long) is 8.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc 3.3: long long bug?

[A.R. Ashok Kumar]

Hi,

> |> > const long long n = 34359738368; // 2^35
> |> >
> |> > Got:
> |> > max.cpp:1: error: integer constant is too large for "long" type
> |> 
> |> Append "LL" to the constant.
> 
> That should not be needed.

   Size for type "long long" may be only 32-bit in your system. Since it
   is 35-bit number, it gives error.

   You can check the size of "long long" type in your system, by printing
   sizeof(long long). 

Best Wishes,
AshokA

Re: gcc 3.3: long long bug?

[Andreas Schwab]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

|> > const long long n = 34359738368; // 2^35
|> >
|> > Got:
|> > max.cpp:1: error: integer constant is too large for "long" type
|> 
|> Append "LL" to the constant.

That should not be needed.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc 3.3: long long bug?

[Eric Botcazou]

> const long long n = 34359738368; // 2^35
>
> Got:
> max.cpp:1: error: integer constant is too large for "long" type

Append "LL" to the constant.

-- 
Eric Botcazou

gcc 3.3: long long bug?

[Lev Assinovsky]

Hi all!
Took gcc-20030331 snap.
Compile max.cpp:

const long long n = 34359738368; // 2^35

Got:
max.cpp:1: error: integer constant is too large for "long" type

gcc3.2 doesn't give any errors.

Is that an error of gcc 3.3 or mine?

Thanks, 
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909