[Python-Dev] bitfields - short - and xlc compiler

[MRAB]

On 2016-03-18 00:56, Michael Felt wrote:
> Update:
> Is this going to be impossible?
>
 From what I've been able to find out, the C89 standard limits bitfields 
to int, signed int and unsigned int, and the C99 standard added _Bool, 
although some compilers allow other integer types too. It looks like 
your compiler doesn't allow those additional types.

> test_short fails om AIX when using xlC in any case. How terrible is this?
>
> ======================================================================
> FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>     File
> "/data/prj/aixtools/python/python-2.7.11.2/Lib/ctypes/test/test_bitfields.py",
> line 48, in test_shorts
>       self.assertEqual((name, i, getattr(b, name)), (name, i,
> func(byref(b), name)))
> AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1)
>
> First differing element 2:
> -1
> 1
>
> - ('M', 1, -1)
> ?          -
>
> + ('M', 1, 1)
>
> ----------------------------------------------------------------------
> Ran 440 tests in 1.538s
>
> FAILED (failures=1, skipped=91)
> Traceback (most recent call last):
>     File "./Lib/test/test_ctypes.py", line 15, in <module>
>       test_main()
>     File "./Lib/test/test_ctypes.py", line 12, in test_main
>       run_unittest(unittest.TestSuite(suites))
>     File
> "/data/prj/aixtools/python/python-2.7.11.2/Lib/test/test_support.py",
> line 1428, in run_unittest
>       _run_suite(suite)
>     File
> "/data/prj/aixtools/python/python-2.7.11.2/Lib/test/test_support.py",
> line 1411, in _run_suite
>       raise TestFailed(err)
> test.test_support.TestFailed: Traceback (most recent call last):
>     File
> "/data/prj/aixtools/python/python-2.7.11.2/Lib/ctypes/test/test_bitfields.py",
> line 48, in test_shorts
>       self.assertEqual((name, i, getattr(b, name)), (name, i,
> func(byref(b), name)))
> AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1)
>
> First differing element 2:
> -1
> 1
>
> - ('M', 1, -1)
> ?          -
>
> + ('M', 1, 1)
>
>
>
>
> On 17-Mar-16 23:31, Michael Felt wrote:
>> a) hope this is not something you expect to be on -list, if so - my
>> apologies!
>>
>> Getting this message (here using c99 as compiler name, but same issue
>> with xlc as compiler name)
>> c99 -qarch=pwr4 -qbitfields=signed -DNDEBUG -O -I. -IInclude
>> -I./Include -I/data/prj/aixtools/python/python-2.7.11.2/Include
>> -I/data/prj/aixtools/python/python-2.7.11.2 -c
>> /data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c
>> -o
>> build/temp.aix-5.3-2.7/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.o
>> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c",
>> line 387.5: 1506-009 (S) Bit field M must be of type signed int,
>> unsigned int or int.
>> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c",
>> line 387.5: 1506-009 (S) Bit field N must be of type signed int,
>> unsigned int or int.
>> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c",
>> line 387.5: 1506-009 (S) Bit field O must be of type signed int,
>> unsigned int or int.
>> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c",
>> line 387.5: 1506-009 (S) Bit field P must be of type signed int,
>> unsigned int or int.
>> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c",
>> line 387.5: 1506-009 (S) Bit field Q must be of type signed int,
>> unsigned int or int.
>> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c",
>> line 387.5: 1506-009 (S) Bit field R must be of type signed int,
>> unsigned int or int.
>> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c",
>> line 387.5: 1506-009 (S) Bit field S must be of type signed int,
>> unsigned int or int.
>>
>> for:
>>
>> struct BITS {
>>     int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9;
>>     short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7;
>> };
>>
>> in short xlC v11 does not like short (xlC v7 might have accepted it,
>> but "32-bit machines were common then". I am guessing that 16-bit is
>> not well liked on 64-bit hw now.
>>
>> reference for xlC v7, where short was (apparently) still accepted:
>> http://www.serc.iisc.ernet.in/facilities/ComputingFacilities/systems/cluster/vac-7.0/html/language/ref/clrc03defbitf.htm
>>
>>
>> I am taking this is from xlC v7 documentation from the URL, not
>> because I know it personally.
>>
>> So - my question: if "short" is unacceptable for POWER, or maybe only
>> xlC (not tried with gcc) - how terrible is this, and is it possible to
>> adjust the test so - the test is accurate?
>>
>> I am going to modify the test code so it is
>> struct BITS {
>>    signed  int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9;
>>    unsigned int M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7;
>> };
>>
>> And see what happens - BUT - what does this have for impact on python
>> - assuming that "short" bitfields are not supported?
>>
>> p.s. not submitting this a bug (now) as it may just be that "you"
>> consider it a bug in xlC to not support (signed) short bit fields.
>>
>> p.p.s. Note: xlc, by default, considers bitfields to be unsigned. I
>> was trying to force them to signed with -qbitfields=signed - and I
>> still got messages. So, going back to defaults.
>>