Boost C++ Libraries: Ticket #3548: Comeau C++ reports global scope has no int64_t

Sun, 25 Oct 2009 12:37:11 GMT

I think I have managed to reproduce the problem with minimal program. I'm not sure where is the problem, either in Boost.Integer or libcomo36 I use with my installation of Comeau C/C++ compiler.

Simple test which do not compile

$ cat cstdint.cpp
#include <iostream>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t i64 = -2;
    boost::uint64_t ui64 = 2;
    boost::uint64_t d = ui64 - i64;
    std::cout << d << std::endl;
    return 0;
}
$ como -I/home/mloskot/dev/boost/_svn/trunk cstdint.cpp
Comeau C/C++ 4.3.10.1 (May  7 2008 12:23:21) for LINUX_INTEL_ELF_Beta
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:non-strict warnings C++ noC++0x_extensions
"/home/mloskot/dev/boost/_svn/trunk/boost/cstdint.hpp", line 111: error: the
          global scope has no "int64_t"
    using ::int64_t;
            ^
"cstdint.cpp", line 5: error: namespace "boost" has no member "int64_t"
      boost::int64_t i64 = -2;
             ^
2 errors detected in the compilation of "cstdint.cpp".

The same simple test but with #include directives reordered and now it does compile

$ cat cstdint.cpp
#include <boost/cstdint.hpp>
#include <iostream>
int main()
{
    boost::int64_t i64 = -2;
    boost::uint64_t ui64 = 2;
    boost::uint64_t d = ui64 - i64;
    std::cout << d << std::endl;
    return 0;
}
$ como -I/home/mloskot/dev/boost/_svn/trunk cstdint.cpp
Comeau C/C++ 4.3.10.1 (May  7 2008 12:23:21) for LINUX_INTEL_ELF_Beta
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:non-strict warnings C++ noC++0x_extensions
$ ./a.out
4

I'd appreciate if somebody could confirm if this is Boost problem or not.

Fri, 13 Nov 2009 01:09:40 GMT

I have made yet another test trying to compile examples of accumulators library from current trunk r57618 and the ::uint64_t error is still being thrown. It looks like a stopper preventing compilation of most libraries.

Sat, 14 Nov 2009 23:37:33 GMT

Thanks it como's option --list, I confirmed that in the first case that fails to compile uint64_t is not defined indeed. Preprocessed source of the program shows that first header /usr/include/sys/types.h is included and it consits of this:

/* These types are defined by the ISO C99 header <inttypes.h>. */
# ifndef __int8_t_defined
#  define __int8_t_defined
typedef	char int8_t;
typedef	short int int16_t;
typedef	int int32_t;
#  if __WORDSIZE == 64
typedef long int int64_t;
#  elif __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int int64_t;
#  endif
# endif

causing the following effects:

WORDSIZE == 64 is false, so uint64_t is not defined
_ _ GLIBC_HAVE_LONG_LONG is not defined, so second try to define uint64_t is not performed
_ _ int8_t_defined is eventually defined

Next, /usr/include/stdint.h is included and it consits some repeated definitions from sys/types.h, but with slight difference:

/* There is some amount of overlap with <sys/types.h> as known by inet code */
#ifndef __int8_t_defined
# define __int8_t_defined
typedef signed char		int8_t;
typedef short int		int16_t;
typedef int			int32_t;
# if __WORDSIZE == 64
typedef long int		int64_t;
# else
__extension__
typedef long long int		int64_t;
# endif
#endi
# endif

However, these definitions are not enabled because _ _ int8_t_defined has been already defined by sys/types.h, so, what's most important here, int64_t type is not defined.

The slight difference I mentioned above seems to be important:

#  elif __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int int64_t;
#  endif

versus

# else
__extension__
typedef long long int		int64_t;
# endif

To summary, if stdint.h would get first, int64_t was defined.

Also, the slight difference in testing vs no testing _ _ GLIBC_HAVE_LONG_LONG seems to be an inconsistency in standard headers and may look like a bug, so I'm going to try to confirm it.

Sun, 15 Nov 2009 00:09:56 GMT

Following my last comment, here is are minimal programs to reproduce the problem using Comeau C/C++ compiler:

This version does not compile

$ cat bad.cpp
#include <sys/types.h>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t a(0);
    return 0;
}
$ como -I/home/mloskot/dev/boost/_svn/trunk bad.cpp
Comeau C/C++ 4.3.10.1 (May  7 2008 12:23:21) for LINUX_INTEL_ELF_Beta
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:non-strict warnings C++ noC++0x_extensions
"/home/mloskot/dev/boost/_svn/trunk/boost/cstdint.hpp", line 111: error: the
          global scope has no "int64_t"
    using ::int64_t;
            ^
"bad.cpp", line 5: error: namespace "boost" has no member "int64_t"
      boost::int64_t a(0);
             ^

This version does compile

$ cat good.cpp
#include <stdint.h>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t a(0);
    return 0;
}
$ como -I/home/mloskot/dev/boost/_svn/trunk good.cpp
Comeau C/C++ 4.3.10.1 (May  7 2008 12:23:21) for LINUX_INTEL_ELF_Beta
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:non-strict warnings C++ noC++0x_extensions
"good.cpp", line 5: warning: variable "a" was declared but never referenced
      boost::int64_t a(0);
                     ^

I've also tried to find open GCC bugs related to this issue, but the only I found that mentions stdint.h file and preprocessor define _ _ int8_t_defined is Bug 448 - <stdint.h>-related issues (C99 issues), however it was reported to old GCC 2.96.

anonymous — Fri, 20 Nov 2009 00:42:04 GMT

It looks that in my last comment, I mixed names uint64_t vs int64_t in my explanations, however the code examples present everything correctly. I hope it does not confuse much.

Fri, 20 Nov 2009 01:05:19 GMT

I have consulted this issue with Comeau C/C++ team and the difference in both definitions of int64_t type looks odd and potentially like a bug in GNU C Library. I will keep in touch with Comeau team regarding this.

In the meantime, due to the odd difference in definition, I (tentatively) decided to submit bug report to GNU C Library to get the issue analysed by their camp. Here it is:

Bug 10990 - Inconsistent definition of int64_t in sys/types and stdint.h

cc set

John Maddock — Sun, 22 Nov 2009 17:43:53 GMT

cc John Maddock added

Can you please try the attached patch?

attachment set

John Maddock — Sun, 22 Nov 2009 17:44:40 GMT

attachment → commeau.diff

Sun, 22 Nov 2009 20:50:48 GMT

John,

I can confirm that the simple test bad.cpp which uses <boost/cstdint.hpp> does compile with your patch:

mloskot@vb-ubuntu904:~/dev/boost/tickets/3548$ cat bad.cpp
#include <sys/types.h>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t a(0);
    return 0;
}
mloskot@vb-ubuntu904:~/dev/boost/tickets/3548$ como -I/home/mloskot/dev/boost/_svn/trunk bad.cpp
Comeau C/C++ 4.3.10.1 (May  7 2008 12:23:21) for LINUX_INTEL_ELF_Beta
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:non-strict warnings C++ noC++0x_extensions
"bad.cpp", line 5: warning: variable "a" was declared but never referenced
      boost::int64_t a(0);
                     ^

Also, big thanks for your comment to the glibc bugzilla. I will forward Ulrich's explanation about requirement of _ _ GLIBC_HAVE_LONG_LONG to Comeau team as it may be of their interest indeed.

So, do you think it's possible to apply your patch to the Boost trunk? It would make it possible to move forward with testing Boost using Comeau.

Thanks you!

status changed; resolution set

John Maddock — Mon, 23 Nov 2009 09:51:27 GMT

status new → closed
resolution → fixed

(In [57858]) Fix for Comeau compiler - does not define GLIBC_HAVE_LONG_LONG which in turn causes GLIBC's stdint.h to misbehave. Fixes #3548.

attachment set

michaelsheppa1469@… — Fri, 17 Mar 2017 02:35:58 GMT

attachment → commeau.2.diff

I want to view my account history> manage my services talk & text history> talk & text history: past 2 months