Bruno Haible writes:
> Sam James wrote:
>> > It's good if you have the time to test not-yet-released compiler versions.
>> > I don't have that time, and therefore will prefer to wait until the
>> > clang release is out.
>>
>> OK. You've appreciated reports in the past (even quite recently), I
Sam James wrote:
> > It's good if you have the time to test not-yet-released compiler versions.
> > I don't have that time, and therefore will prefer to wait until the
> > clang release is out.
>
> OK. You've appreciated reports in the past (even quite recently), I can
> avoid making them in futur
Bruno Haible writes:
> Sam James wrote:
>> it's still going to be an issue if (as
>> planned) Clang flips '-Wincompatible-pointer-types' to error out by
>> default unless they carve out an exception for qualifiers here.
>>
>> I'll advocate that they do, of course. I just came across it while
>
Paul Eggert wrote:
> We can conform to standard C without a cast with something like the
> attached (which I haven't installed).
Looks good to me. Please install it; likewise in m4/frexpf.m4.
> (I assume the 'volatile' is there because of the funky things compilers
> do with x86 double)
It
Sam James wrote:
> it's still going to be an issue if (as
> planned) Clang flips '-Wincompatible-pointer-types' to error out by
> default unless they carve out an exception for qualifiers here.
>
> I'll advocate that they do, of course. I just came across it while
> checking for configure changes
On 2023-12-01 21:52, Bruno Haible wrote:
There is nothing wrong with this code (m4/frexp.m4:159, m4/frexpf.m4:83).
Isn't there? I thought that the C standard doesn't let you access a
'double volatile' object via a 'void *' or 'void const *' pointer. It'd
need to be 'void volatile *' or 'void
Sam James writes:
> Bruno Haible writes:
>
>> Hi Sam,
>
> Hi Bruno,
>
>>
>>> The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
>>> a Clang warning/error when Clang is passed
>>> -Werror=incompatible-pointer-types.
>>
>> Gnulib does not support CC or CPPFLAGS or CFLAGS value
Bruno Haible writes:
> Hi Sam,
Hi Bruno,
>
>> The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
>> a Clang warning/error when Clang is passed
>> -Werror=incompatible-pointer-types.
>
> Gnulib does not support CC or CPPFLAGS or CFLAGS values with -Werror at
> configure time
Hi Sam,
> The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
> a Clang warning/error when Clang is passed
> -Werror=incompatible-pointer-types.
Gnulib does not support CC or CPPFLAGS or CFLAGS values with -Werror at
configure time. Neither with gcc nor with clang.
The reason i
Hi,
The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
a Clang warning/error when Clang is passed
-Werror=incompatible-pointer-types.
This _isn't_ an issue with GCC 14, as it doesn't consider the lost
const to be a problem, like so:
/tmp/foo.c: In function ‘main’:
/tmp/foo.c:5
10 matches
Mail list logo
