[Python-Dev] bitfields - short - and xlc compiler
Andrew Barnert
abarnert at yahoo.com
Fri Mar 18 00:57:38 EDT 2016
On Mar 17, 2016, at 18:35, MRAB <python at mrabarnett.plus.com> wrote:
>
>> 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.
Yeah, C99 (6.7.2.1) allows "a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type", and same for C11. This means that a compiler could easily allow an implementation-defined type that's identical to and interconvertible with short, say "i16", to be used in bitfields, but not short itself.
And yet, gcc still allows short "even in strictly conforming mode" (4.9), and it looks like Clang and Intel do the same.
Meanwhile, MSVC specifically says it's illegal ("The type-specifier for the declarator must be unsigned int, signed int, or int") but then defines the semantics (you can't have a 17-bit short, bit fields act as the underlying type when accessed, alignment is forced to a boundary appropriate for the underlying type). They do mention that allowing char and long types is a Microsoft extension, but still nothing about short, even though it's used in most of the examples on the page.
Anyway, is the question what ctypes should do? If a platform's compiler allows "short M: 1", especially if it has potentially different alignment than "int M: 1", ctypes on that platform had better make ("M", c_short, 1) match the former, right?
So it sounds like you need some configure switch to test that your compiler doesn't allow short bit fields, so your ctypes build at least skips that part of _ctypes_test.c and test_bitfields.py, and maybe even doesn't allow them in Python code.
>> 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.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/abarnert%40yahoo.com
More information about the Python-Dev
mailing list