Re: Need help with incompatible pointer types on i686

2024-02-21 Thread Orion Poplawski 

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

2024-02-17 Thread Kevin Kofler via devel 
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

2024-02-16 Thread Orion Poplawski 

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

2024-02-16 Thread Sérgio Basto 
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

2024-02-16 Thread Florian Weimer 
* 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

2024-02-16 Thread Michael J Gruber 
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

2024-02-15 Thread 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:
```
#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

2024-02-15 Thread Orion Poplawski 

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