RetroSearch Browse

Thu Mar 17 20:56:51 EDT 2016 · https://mail.python.org/pipermail/python-dev/2016-March/143542.html

Update:
Is this going to be impossible?

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/register%40felt.demon.nl
>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2016-March/143542.html below:

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