Re: Need help with incompatible pointer types on i686
On 2/16/24 16:58, Orion Poplawski wrote: On 2/16/24 01:29, Michael J Gruber wrote: Am Fr., 16. Feb. 2024 um 07:15 Uhr schrieb Elliott Sales de Andrade : On Thu, Feb 15, 2024 at 11:39 PM Orion Poplawski wrote: We're hitting this with h5py on i686: /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function ‘__pyx_f_4h5py_4defs_H5Dread_chunk’: /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error: passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type [-Wincompatible-pointer-types] 14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id, __pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf); | ^~~ | | | __pyx_t_5numpy_uint32_t * {aka long unsigned int *} In file included from /usr/include/hdf5.h:25, from /builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27, from /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246: /usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’ {aka ‘long unsigned int *’} 1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const hsize_t *offset, uint32_t *filters, | ~~^~~ /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function ‘__pyx_f_4h5py_4defs_H5Pget_driver_info’: /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 31935 | __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id); | ^ It seems that numpy is defining a uint32_t type as long unsigned int on i686, while glibc(?) is defining it as unsigned int. Yes, looking at NumPy's header [1], it appears to check `long` first, then `long long`, then `int`, then `short`, and assigns the first one that matches to the matching bit-length. So it should pick unsigned long for npy_uint32 before unsigned int if they are both 4 bytes wide. Now what puzzles me a little is that on i686 aren't these both 4-byte integers and no not incompatible at all? Yes, I think they are the same size, as demonstrated on a 32-bit mock: They are the same (bit size, signedness, general type) but not equal (long int vs int), and with gcc14 this became an error. I"m sure it always warned about that before. What should be done here? I guess that depends on how glibc sets things up, but perhaps it would work better if NumPy checked from smallest to largest as defined in C (short -> int -> long -> long long)? [1] https://github.com/numpy/numpy/blob/308273e94bcf49980be9d5ded2b0ff5b4dd3a897/numpy/_core/include/numpy/npy_common.h#L488 numpy definitely needs to fix this. You cannot just go by bitsize and signedness. You never could and now you can't ;) I'm surprised this didn't come up during our "gcc 14 ride". Michael Could you or someone else knowledgeable here file a bug with numpy? I'm sick at the moment and not sure I can articulate what needs to get done. Thank you! I have filed https://github.com/numpy/numpy/issues/25869 I'm also exploring just using libc.stdint for the types in h5py. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Need help with incompatible pointer types on i686
Michael J Gruber wrote: > numpy definitely needs to fix this. You cannot just go by bitsize and > signedness. You never could and now you can't ;) You actually had to before C99, where stdint.h was introduced. On some platforms or compilers, such as MSVC, you still cannot use C99, only C89/C90. (They support new C++ standards, but not new C standards.) So auto- detecting one's own uint32_t is still the only way there. Of course, what the software SHOULD do is to check for stdint.h and use that if it exists, only defining its own type if it does not. But it is still not a good idea for GCC to make this typically harmless warning an error by default (and I have already complained about that, pointing out exactly this use case, when the Change was discussed; sadly, my objection was dismissed). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Need help with incompatible pointer types on i686
On 2/16/24 01:29, Michael J Gruber wrote: Am Fr., 16. Feb. 2024 um 07:15 Uhr schrieb Elliott Sales de Andrade : On Thu, Feb 15, 2024 at 11:39 PM Orion Poplawski wrote: We're hitting this with h5py on i686: /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function ‘__pyx_f_4h5py_4defs_H5Dread_chunk’: /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error: passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type [-Wincompatible-pointer-types] 14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id, __pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf); | ^~~ | | | __pyx_t_5numpy_uint32_t * {aka long unsigned int *} In file included from /usr/include/hdf5.h:25, from /builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27, from /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246: /usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’ {aka ‘long unsigned int *’} 1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const hsize_t *offset, uint32_t *filters, | ~~^~~ /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function ‘__pyx_f_4h5py_4defs_H5Pget_driver_info’: /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 31935 | __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id); | ^ It seems that numpy is defining a uint32_t type as long unsigned int on i686, while glibc(?) is defining it as unsigned int. Yes, looking at NumPy's header [1], it appears to check `long` first, then `long long`, then `int`, then `short`, and assigns the first one that matches to the matching bit-length. So it should pick unsigned long for npy_uint32 before unsigned int if they are both 4 bytes wide. Now what puzzles me a little is that on i686 aren't these both 4-byte integers and no not incompatible at all? Yes, I think they are the same size, as demonstrated on a 32-bit mock: They are the same (bit size, signedness, general type) but not equal (long int vs int), and with gcc14 this became an error. I"m sure it always warned about that before. What should be done here? I guess that depends on how glibc sets things up, but perhaps it would work better if NumPy checked from smallest to largest as defined in C (short -> int -> long -> long long)? [1] https://github.com/numpy/numpy/blob/308273e94bcf49980be9d5ded2b0ff5b4dd3a897/numpy/_core/include/numpy/npy_common.h#L488 numpy definitely needs to fix this. You cannot just go by bitsize and signedness. You never could and now you can't ;) I'm surprised this didn't come up during our "gcc 14 ride". Michael Could you or someone else knowledgeable here file a bug with numpy? I'm sick at the moment and not sure I can articulate what needs to get done. Thank you! -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Need help with incompatible pointer types on i686
On Fri, 2024-02-16 at 14:01 +0100, Florian Weimer wrote: > * Orion Poplawski: > > > It seems that numpy is defining a uint32_t type as long unsigned > > int > > on i686, while glibc(?) is defining it as unsigned int. Now what > > puzzles me a little is that on i686 aren't these both 4-byte > > integers > > and no not incompatible at all? > > The types int and long are distinct according to C rules. > > The problem seems to be in h5py/api_types_ext.pxd: > > from numpy cimport int8_t, uint8_t, int16_t, uint16_t, int32_t, > uint32_t, int64_t, uint64_t > > I think it should use the types from instead, at least in > the > global scope. For certain Numpy functions, it may be required to > reference them as numpy.uint32_t etc. this is over complicated to me , we can disable this check with: %global build_type_safety_c 0 > Thanks, > Florian > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Need help with incompatible pointer types on i686
* Orion Poplawski: > It seems that numpy is defining a uint32_t type as long unsigned int > on i686, while glibc(?) is defining it as unsigned int. Now what > puzzles me a little is that on i686 aren't these both 4-byte integers > and no not incompatible at all? The types int and long are distinct according to C rules. The problem seems to be in h5py/api_types_ext.pxd: from numpy cimport int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t I think it should use the types from instead, at least in the global scope. For certain Numpy functions, it may be required to reference them as numpy.uint32_t etc. Thanks, Florian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Need help with incompatible pointer types on i686
Am Fr., 16. Feb. 2024 um 07:15 Uhr schrieb Elliott Sales de Andrade : > > On Thu, Feb 15, 2024 at 11:39 PM Orion Poplawski wrote: > > > > We're hitting this with h5py on i686: > > > > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function > > ‘__pyx_f_4h5py_4defs_H5Dread_chunk’: > > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error: > > passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type > > [-Wincompatible-pointer-types] > > 14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id, > > __pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf); > >| > > ^~~ > >| > > | > >| > > __pyx_t_5numpy_uint32_t * {aka long unsigned int *} > > In file included from /usr/include/hdf5.h:25, > > from > > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27, > > from > > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246: > > /usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka > > ‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’ > > {aka ‘long unsigned int *’} > > 1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const > > hsize_t *offset, uint32_t *filters, > >| > > ~~^~~ > > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function > > ‘__pyx_f_4h5py_4defs_H5Pget_driver_info’: > > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning: > > assignment discards ‘const’ qualifier from pointer target type > > [-Wdiscarded-qualifiers] > > 31935 | __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id); > >| ^ > > > > > > It seems that numpy is defining a uint32_t type as long unsigned int on > > i686, while glibc(?) is defining it as unsigned int. > > Yes, looking at NumPy's header [1], it appears to check `long` first, > then `long long`, then `int`, then `short`, and assigns the first one > that matches to the matching bit-length. So it should pick unsigned > long for npy_uint32 before unsigned int if they are both 4 bytes wide. > > > Now what puzzles > > me a little is that on i686 aren't these both 4-byte integers and no not > > incompatible at all? > > Yes, I think they are the same size, as demonstrated on a 32-bit mock: They are the same (bit size, signedness, general type) but not equal (long int vs int), and with gcc14 this became an error. I"m sure it always warned about that before. > > What should be done here? > > > > I guess that depends on how glibc sets things up, but perhaps it would > work better if NumPy checked from smallest to largest as defined in C > (short -> int -> long -> long long)? > > [1] > https://github.com/numpy/numpy/blob/308273e94bcf49980be9d5ded2b0ff5b4dd3a897/numpy/_core/include/numpy/npy_common.h#L488 numpy definitely needs to fix this. You cannot just go by bitsize and signedness. You never could and now you can't ;) I'm surprised this didn't come up during our "gcc 14 ride". Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Need help with incompatible pointer types on i686
On Thu, Feb 15, 2024 at 11:39 PM Orion Poplawski wrote: > > We're hitting this with h5py on i686: > > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function > ‘__pyx_f_4h5py_4defs_H5Dread_chunk’: > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error: > passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type > [-Wincompatible-pointer-types] > 14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id, > __pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf); >| > ^~~ >| > | >| > __pyx_t_5numpy_uint32_t * {aka long unsigned int *} > In file included from /usr/include/hdf5.h:25, > from > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27, > from > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246: > /usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka > ‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’ > {aka ‘long unsigned int *’} > 1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const > hsize_t *offset, uint32_t *filters, >| > ~~^~~ > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function > ‘__pyx_f_4h5py_4defs_H5Pget_driver_info’: > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning: > assignment discards ‘const’ qualifier from pointer target type > [-Wdiscarded-qualifiers] > 31935 | __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id); >| ^ > > > It seems that numpy is defining a uint32_t type as long unsigned int on > i686, while glibc(?) is defining it as unsigned int. Yes, looking at NumPy's header [1], it appears to check `long` first, then `long long`, then `int`, then `short`, and assigns the first one that matches to the matching bit-length. So it should pick unsigned long for npy_uint32 before unsigned int if they are both 4 bytes wide. > Now what puzzles > me a little is that on i686 aren't these both 4-byte integers and no not > incompatible at all? Yes, I think they are the same size, as demonstrated on a 32-bit mock: ``` #include #include int main(void) { printf("npy_uint32: %u\nunsigned int: %u\nunsigned long: %u\nunsigned long long: %u\n", sizeof(npy_uint32), sizeof(unsigned int), sizeof(unsigned long), sizeof(unsigned long long)); return 0; } ``` prints out: ``` npy_uint32: 4 unsigned int: 4 unsigned long: 4 unsigned long long: 8 ``` > What should be done here? > I guess that depends on how glibc sets things up, but perhaps it would work better if NumPy checked from smallest to largest as defined in C (short -> int -> long -> long long)? [1] https://github.com/numpy/numpy/blob/308273e94bcf49980be9d5ded2b0ff5b4dd3a897/numpy/_core/include/numpy/npy_common.h#L488 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Need help with incompatible pointer types on i686
We're hitting this with h5py on i686: /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function ‘__pyx_f_4h5py_4defs_H5Dread_chunk’: /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error: passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type [-Wincompatible-pointer-types] 14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id, __pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf); | ^~~ | | | __pyx_t_5numpy_uint32_t * {aka long unsigned int *} In file included from /usr/include/hdf5.h:25, from /builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27, from /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246: /usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’ {aka ‘long unsigned int *’} 1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const hsize_t *offset, uint32_t *filters, | ~~^~~ /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function ‘__pyx_f_4h5py_4defs_H5Pget_driver_info’: /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 31935 | __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id); | ^ It seems that numpy is defining a uint32_t type as long unsigned int on i686, while glibc(?) is defining it as unsigned int. Now what puzzles me a little is that on i686 aren't these both 4-byte integers and no not incompatible at all? What should be done here? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue