On Jan 23, 2020, Jonathan Wakely wrote:
> On 23/01/20 00:20 -0300, Alexandre Oliva wrote:
>> On Jan 22, 2020, Jonathan Wakely wrote:
>>
>>> Isn't allowing arithmetic on function pointers a GNU extension?
>>
>> Does that matter? This test is only supposed to be compiled by GCC.
> Maybe if som
On 23/01/20 00:20 -0300, Alexandre Oliva wrote:
On Jan 22, 2020, Jonathan Wakely wrote:
Isn't allowing arithmetic on function pointers a GNU extension?
Does that matter? This test is only supposed to be compiled by GCC.
Maybe if somebody was crazy enough to build GCC with -pedantic-errors
On Jan 22, 2020, Andreas Schwab wrote:
> On Dez 25 2019, Alexandre Oliva wrote:
>> +dnl # Different versions and execution modes implement different
>> +dnl # subsets of these functions. Instead of hard-coding, test for C
>> +dnl # declarations in headers. The C primitives could be defined as
>
On Jan 22, 2020, Jonathan Wakely wrote:
> Isn't allowing arithmetic on function pointers a GNU extension?
Does that matter? This test is only supposed to be compiled by GCC.
> I think just adding the #undef to what you had originally is the best
> version.
'k, thanks, will adjust, test, post
On Dez 25 2019, Alexandre Oliva wrote:
> +dnl # Different versions and execution modes implement different
> +dnl # subsets of these functions. Instead of hard-coding, test for C
> +dnl # declarations in headers. The C primitives could be defined as
> +dnl # macros, in which case the tests might
On 21/01/20 21:50 -0300, Alexandre Oliva wrote:
On Jan 3, 2020, Jonathan Wakely wrote:
+#include
+#ifdef HAVE_IEEEFP_H
+# include
+#endif
+], [
+ void (*f)(void) = (void (*)(void))$1;
I wondered whether using ($1) here instead of just $1 would give any
benefit. It would mean that functi
On Jan 3, 2020, Jonathan Wakely wrote:
>> +#include
>> +#ifdef HAVE_IEEEFP_H
>> +# include
>> +#endif
>> +], [
>> + void (*f)(void) = (void (*)(void))$1;
> I wondered whether using ($1) here instead of just $1 would give any
> benefit. It would mean that function-like macros are ignored.
Th
On 25/12/19 03:40 -0300, Alexandre Oliva wrote:
When cross-building for vxworks, test for declarations of long double
functions in math.h. We don't normally test for these functions when
cross compiling, because link tests don't work, or ever really, but
not defining them as available causes re
When cross-building for vxworks, test for declarations of long double
functions in math.h. We don't normally test for these functions when
cross compiling, because link tests don't work, or ever really, but
not defining them as available causes replacements to be defined in
ways that may cause d
