Pinned topicWhy does "long long" type not work for bit fields?

Sorry for the re-post - I wanted to make this a question and knew no other way to do it.

The long long integer type defines 64 bit integers on all current platforms (AIX, LINUX, Solaris, etc.). In most 64-bit systems a long integer type is now also a 64-bit integer. To correctly define a structure that is stored in binary files and needs to be accessed by disparate systems, we have tried to use long long type when we want to ensure a 64-bit integer field within a structure. However, defining bit fields within such 64-bit fields is not working with the AIX XL C/C++ compilers because, unlike what the documentation says, long long types are not being allowed to have bit fields within them. For example:

typedef struct {

unsigned long long junk :8;
unsigned long long junk2 :8;
unsigned long long page :48;

} struct2;

This works fine on linux and Solaris and the documentation for AIX's XL C/C++ compiler indicates bit field containers can have types of long long, but on XL C the compiler complains and we don't get the desired result - it doesn't point to the bit field length as the problem, but the "long long" type itself. We find that we can use just unsigned long and still get a 64-bit field on 64-bit AIX, but this specification doesn't work on 32-bit platforms. We are trying to use "long long" to be more widely compatible across all 32-bit and 64-bit platforms. Since the compiler documentation says bit field types of "long long" are allowed, why is this failing with the messages:

Re: Why does "long long" type not work for bit fields?

Hi, thanks for this query. I believe this should work and I just tested to make sure and the following progam does compile with no errors or warnings.

Can you tell me what the command line is, specfically include any that comes from hidden config files, by using -v. I am checking to see if some option level was included that disable long long as it is an extension or perhaps it is an older level of the compiler (although that is unlikely as it would have to MUCH older) to not have this.

Re: Why does "long long" type not work for bit fields?

Hi, thanks for this query. I believe this should work and I just tested to make sure and the following progam does compile with no errors or warnings.

Can you tell me what the command line is, specfically include any that comes from hidden config files, by using -v. I am checking to see if some option level was included that disable long long as it is an extension or perhaps it is an older level of the compiler (although that is unlikely as it would have to MUCH older) to not have this.

I'm sorry to hear you're facing these issues with XLC. At initial glance this seems to be an issue with our C implementation. As Michael Wong mentioned before, our C++ implementation doesn't have this issue, and will support full 64-bit bitfields.

I see on your command lines that you included -+ for both .c and .C source files. That option causes all source files to be processed as if they were C++, not C, so in principle you should not be hitting this issue. I suspect that you may have some specific .c files that are being compiled without that option. Perhaps it is an option for you to add -+ to all your files, effectively treating all your sources as C++. If that is suitable for your use, it should sidestep this issue completely.

Please let us know if that it suitable for your environment and solves the issue; otherwise we may need to provide you with alternate workarounds while we identify a full solution.

Re: Why does "long long" type not work for bit fields?

I'm sorry to hear you're facing these issues with XLC. At initial glance this seems to be an issue with our C implementation. As Michael Wong mentioned before, our C++ implementation doesn't have this issue, and will support full 64-bit bitfields.

I see on your command lines that you included -+ for both .c and .C source files. That option causes all source files to be processed as if they were C++, not C, so in principle you should not be hitting this issue. I suspect that you may have some specific .c files that are being compiled without that option. Perhaps it is an option for you to add -+ to all your files, effectively treating all your sources as C++. If that is suitable for your use, it should sidestep this issue completely.

Please let us know if that it suitable for your environment and solves the issue; otherwise we may need to provide you with alternate workarounds while we identify a full solution.

I'm surprised to see the C++ compiler not working in this scenario. I've tried it myself with the original code you posted and the exact compiler you're using (9.0.0.9) and it worked for me. Are you using perhaps a different source? Please post the details on the exact scenario.

Also, keep in mind that by default the compiler targets 32-bit mode. I assume you're interested on 64-bit mode, for which you need to add the -q64 option.

That is it. C++ works now when I explicitly specify -q64. I thought that would just make 64-bit pointers and I'm trying to specify structures for a binary file that is accessible from both 64-bit and 32-bit platforms. Note that when I specify -q64 during C compiles, it still gives the error; at least we know why C++ was not working for me.

We have a large base of about half C and half C++ code. I think it will be easier for us to use #ifdef to do something different for AIX than we do for other platforms (i.e. use long instead of long long).

If the C compiler is eventually updated to allow long long types with bit fields, we can change back.