Topic
11 replies Latest Post - ‏2012-05-29T17:06:37Z by SystemAdmin
SystemAdmin
SystemAdmin
196 Posts
ACCEPTED ANSWER

Pinned topic Why does "long long" type not work for bit fields?

‏2012-05-24T11:54:35Z |
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:

1506-159: (E) Bit field type specified for junk is not valid. Type unsigned assumed.
1506-159: (E) Bit field type specified for junk2 is not valid. Type unsigned assumed.
1506-159: (E) Bit field type specified for page is not valid. Type unsigned assumed.
1506-003: (E) Width of a bit field of type "unsigned int" cannot exceed 32.

and results in a 32-bit container field. Temporarily we are using a type of "unsigned long" just on AIX to get around this.
Updated on 2012-05-29T17:06:37Z at 2012-05-29T17:06:37Z by SystemAdmin
  • Michael_Wong
    Michael_Wong
    29 Posts
    ACCEPTED ANSWER

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

    ‏2012-05-24T13:16:10Z  in response to SystemAdmin
    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.

    Thanks.
    • SystemAdmin
      SystemAdmin
      196 Posts
      ACCEPTED ANSWER

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

      ‏2012-05-24T19:10:44Z  in response to Michael_Wong
      Hi, thanks for helping out.

      I have tried just simple "cc -q64 source.c" and this happens. But our large build processes use the following example invocations of the compiler:

      • common CFLAGS = -O2 -DCDN_WORDSIZE=64 -+ -brtl -qcpluscmt -qunwind
      -qdbxextra -qsrcmsg -qmaxmem=-1 -qrtti=all -qobjmodel=ibm -qtbtable=full
      -q64 -bnoquiet
      -qsuppress=1540-0306:1540-0308:1540-0309:1540-010:1540-1639:1500-029:1501-201:1540-0857
      -DDISABLE_STACK_TRACE=1 -qchars=signed -DAIX -DTemplateDefInline -Daix
      -DNDEBUG -qinline -qstaticinline

      /use/vac/bin/xlc -c (common INCFLAGS) (common CFALGS) sourcefile.c

      or

      • common CFLAGS = -O2 -DRELEASE9 -DTDXactivecompaction
      -DCDN_WORDSIZE=64 -+ -brtl -qcpluscmt -qunwind -qdbxextra -qsrcmsg
      -qmaxmem=-1 -qrtti=all -qobjmodel=ibm -qtbtable=full -q64 -bnoquiet
      -qsuppress=1540-0306:1540-0308:1540-0309:1540-010:1540-1639:1500-029:1501-201:1540-0857
      -DDISABLE_STACK_TRACE=1 -qchars=signed -DAIX -DTemplateDefInline -Daix
      -DNDEBUG -qinline -qstaticinline

      /use/vacpp/bin/xlC -c (common INCFLAGS) (common CFLAGS) sourcefile.C

      Thanks again!
      • Dwayne_M
        Dwayne_M
        9 Posts
        ACCEPTED ANSWER

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

        ‏2012-05-24T19:12:53Z  in response to SystemAdmin
        What version of the compiler?
        /usr/vacpp/bin/xlC -qversion
        Dwayne Moore Market Manager, Power & Compilers IBM Corporation | Rational Software
        • SystemAdmin
          SystemAdmin
          196 Posts
          ACCEPTED ANSWER

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

          ‏2012-05-24T19:47:32Z  in response to Dwayne_M
          Here is the version I am seeing:

          ==> /usr/vac/bin/xlc -qversion
          IBM CL C/C++ Enterprise Edition for AIX, V9.0
          Version: 09.00.0000.0009
          ==>
          • SystemAdmin
            SystemAdmin
            196 Posts
            ACCEPTED ANSWER

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

            ‏2012-05-25T20:00:23Z  in response to SystemAdmin
            Hi,

            My IT folks tell me we are supposed to have the compiler version 11 installed on our build machines soon, but that they tried out a test compile using that version and it also has the problem.

            Brion
            • SystemAdmin
              SystemAdmin
              196 Posts
              ACCEPTED ANSWER

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

              ‏2012-05-29T13:22:14Z  in response to SystemAdmin
              Hello, Brion

              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.

              • Raul Silvera
              STSM, Static Compilation Technology, Rational
              IBM
              • SystemAdmin
                SystemAdmin
                196 Posts
                ACCEPTED ANSWER

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

                ‏2012-05-29T14:30:09Z  in response to SystemAdmin
                Hi,

                We also use the C++ compiler. Here is what I get:

                => /usr/vacpp/bin/xlC -qversion
                IBM XL C/C++ Enterprise Edition for AIX, V9.0
                Version: 09.00.0000.0009
                /afs/tda/home/kellerbl/src
                => /usr/vacpp/bin/xlC new64bit.c
                "new64bit.c", line 21.5: 1506-159 (E) Bit field type specified for junk is not valid. Type unsigned assumed.
                "new64bit.c", line 22.5: 1506-159 (E) Bit field type specified for junk2 is not valid. Type unsigned assumed.
                "new64bit.c", line 23.5: 1506-159 (E) Bit field type specified for page is not valid. Type unsigned assumed.
                "new64bit.c", line 23.31: 1506-003 (E) Width of a bit field of type "unsigned int" cannot exceed 32.
                "new64bit.c", line 30.26: 1506-003 (E) Width of a bit field of type "unsigned long" cannot exceed 32.
                "new64bit.c", line 36.6: 1506-159 (E) Bit field type specified for junk is not valid. Type unsigned assumed.
                "new64bit.c", line 37.6: 1506-159 (E) Bit field type specified for junk2 is not valid. Type unsigned assumed.
                "new64bit.c", line 38.6: 1506-159 (E) Bit field type specified for page is not valid. Type unsigned assumed.
                "new64bit.c", line 38.23: 1506-003 (E) Width of a bit field of type "unsigned int" cannot exceed 32.
                /afs/tda/home/kellerbl/src

                which looks to me as if the C++ compiler is also not liking the "unsigned long long" as a bit field type.

                Brion
                • SystemAdmin
                  SystemAdmin
                  196 Posts
                  ACCEPTED ANSWER

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

                  ‏2012-05-29T14:54:42Z  in response to SystemAdmin
                  I made the test program more C++ legal and now see this:

                  => /usr/vacpp/bin/xlc++ new64bit.C
                  "new64bit.C", line 35.25: 1540-1627 (S) The bit field "unsigned long long page" cannot be greater than 32-bits.

                  Brion
                  • SystemAdmin
                    SystemAdmin
                    196 Posts
                    ACCEPTED ANSWER

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

                    ‏2012-05-29T15:28:07Z  in response to SystemAdmin
                    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.
                • SystemAdmin
                  SystemAdmin
                  196 Posts
                  ACCEPTED ANSWER

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

                  ‏2012-05-29T15:18:14Z  in response to SystemAdmin
                  XLC decides whether to treat the source as C or C++ depending on the file extension, not the compiler invocation, so when you run "xlC new64bit.c" you get the C compiler, not the C++ one.

                  You can force the compiler to treat .c files as C++ by adding the -+ option.

                  One quick thing to validate is that if you get messages with the number 1506-XXX, they're from our C front-end component, while messages from the C++ front-end component are of the form 1540-XXX
                  • SystemAdmin
                    SystemAdmin
                    196 Posts
                    ACCEPTED ANSWER

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

                    ‏2012-05-29T17:06:37Z  in response to SystemAdmin
                    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.

                    Thanks for your help!

                    Brion