Re: Floating-point comparisons in the middle-end
> See N3047 Annex F for the current bindings (there have been a lot of > changes to the C2x working draft after N3047 in the course of editorial > review, but I don't think any of them affect the IEEE bindings for > comparisons). Thanks for the pointer, it is very helpful. The next thing I need to tackle for Fortran is the implementation of functions that perform maxNum, maxNumMag, minNum, and minNumMag. Am I correct in assuming that maxNum and minNum correspond to fmin and fmax? Are there builtins for maxNumMag and minNumMag? Or does anyone know what the “canonical” way to perform it is? I do not want to mess up corners cases, which is so easy to do… Thanks again, FX
Re: Floating-point comparisons in the middle-end
Hi Joseph, I have a Fortran patch ready to submit, but before I do so I’d like to know: do you support or oppose a __builtin_iseqsig()? Jakub said he was against, but deferred to you on that. For me, it makes the Fortran front-end part slightly simpler, so if it is decided to go that route I’ll propose a middle-end + C patch first. But I do not need it absolutely. Thanks, FX
Re: Floating-point comparisons in the middle-end
For the record, this is now PR 106805 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805 FX
Re: Floating-point comparisons in the middle-end
> Presumably that can be reproduced without depending on the new built-in
> function? In which case it's an existing bug somewhere in the optimizers.
Yes:
$ cat a.c
#include
#include
#include
void foo (void) {
if (fetestexcept (FE_INVALID) & FE_INVALID)
printf("Invalid raised\n");
feclearexcept (FE_ALL_EXCEPT);
}
static inline int iseqsig(float x, float y) { return (x >= y && x <= y); }
int main (void) {
float x = __builtin_nanf("");
float y;
printf("%d\n", iseqsig(__builtin_nanf(""), 1.));
foo();
printf("%d\n", iseqsig(x, __builtin_inff()));
foo();
}
$ ./bin/gcc a.c -lm -fno-unsafe-math-optimizations -frounding-math
-fsignaling-nans -O0 && ./a.out
0
Invalid raised
0
Invalid raised
$ ./bin/gcc a.c -lm -fno-unsafe-math-optimizations -frounding-math
-fsignaling-nans -O1 && ./a.out
0
0
Do you want me to file a bug report?
FX
Re: Floating-point comparisons in the middle-end
Hi,
> Dunno if we really need a builtin for this, especially if it is lowered
> to that x >= y && x <= y early, will defer to Joseph.
I think it’d be nice to have one for consistency, as the other standard
floating-point functions are there. It would also make things slightly easier
for our Fortran implementation, although admittedly we can do without.
A tentative patch is attached, it seems to work well on simple examples, but
for test coverage the hard part is going to be that the comparisons seem to be
optimised away very easily into their non-signaling versions. Basically, if I
do:
float x = __builtin_nanf("");
printf("%d\n", __builtin_iseqsig(__builtin_nanf(""), __builtin_inff()));
printf("%d\n", __builtin_iseqsig(x, __builtin_inff()));
With -O0 -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans: first
one does not raise invalid, second one does.
With -O2 -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans: no
invalid raised at all.
FX
iseqsig.diff
Description: Binary data
Re: Floating-point comparisons in the middle-end
Hi Jakub, >> 2. All the functions are available as GCC type-generic built-ins (yeah!), >> except there is no __builtin_ iseqsig >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77928). Is there a >> fundamental problem with creating one, and could someone help there? > > IMHO until that one is implemented you can just use > tx = x, ty = y, tx>=ty && tx<=ty > (in GENERIC just SAVE_EXPR >= SAVE_EXPR && SAVE_EXPR <= SAVE_EXPR If it’s just that (optimization aside), I probably can create a C built-in. It would need to be: 1. defined in builtins.def 2. lowered in builtins.cc 3. type-checked in c-family/c-common.cc 4. documented in doc/extend.texi 5. tested in fp-test.cc 6. covered in the testsuite Is that right? Thanks, FX PS: I see that reclassify is not covered in fp-test.cc, is that file obsolete?
Floating-point comparisons in the middle-end
Hi, Fortran 2018 introduced intrinsic functions for all the IEEE-754 comparison operations, compareQuiet* and compareSignaling* I want to introduce those into the Fortran front-end, and make them emit the right code. But cannot find the correspondance between IEEE-754 nomenclature and GCC internal representation. I understand that the middle-end representation was mostly created with C in mind, so I assume that the correspondance is that used by the C standard. That helps me to some extent, as I can find draft documents that seem to list the following table (page 8 of https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1615.pdf): compareQuietEqual == compareQuietNotEqual != compareSignalingEqual iseqsig compareSignalingGreater > compareSignalingGreaterEqual >= compareSignalingLess < compareSignalingLessEqual <= compareSignalingNotEqual !iseqsig compareSignalingNotGreater !(x>y) compareSignalingLessUnordered !(x=>y) compareSignalingNotLess !(xhttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=77928). Is there a fundamental problem with creating one, and could someone help there? Thanks, FX
Re: [PATCH] testsuite: avoid analyzer asm failures on non-Linux
Hi David, > Thanks. I extended your patch as follows, which works successfully for > me on x86_64-pc-linux-gnu. > > Does the following look OK for the analyzer asm failures on > x86_64-apple-darwin? Sorry for the late reply… yes it does! FX
Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)
> No, that's "dg-do compile" (as in "compile but don't assemble").
I can confirm that this patch:
diff --git a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
index c235e22fd01..4730255bb3c 100644
--- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
@@ -1,4 +1,4 @@
-/* { dg-do assemble { target x86_64-*-* } } */
+/* { dg-do compile { target x86_64-*-* } } */
/* { dg-require-effective-target lp64 } */
#include "analyzer-decls.h”
fixes the gcc.dg/analyzer/asm-x86-lp64-1.c failure on x86_64-apple-darwin. The
same is true of this one:
diff --git
a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
index e90dccf58dd..4cbf43206dc 100644
---
a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
+++
b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
@@ -1,4 +1,4 @@
-/* { dg-do assemble { target x86_64-*-* } } */
+/* { dg-do compile { target x86_64-*-* } } */
/* { dg-require-effective-target lp64 } */
/* { dg-additional-options "-fsanitize=bounds -fno-analyzer-call-summaries" }
*/
/* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
These other three:
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c
still fail with dg-do compile, as explained, become the error comes from the C
front-end, not the assembler:
/Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
warning: 'asm' operand 6 probably does not match constraints
/Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
error: impossible constraint in 'asm'
FX
Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)
Hi David, > The purpose of these asm tests is to verify that the analyzer doesn't > get confused by various inline assembler directives used in the source > of the Linux kernel. So in theory they ought to work on any host, with > a gcc configured for a suitable target. > > These tests are marked with "dg-do assemble" directives, which I'd > hoped would mean it uses -S for the tests (to make a .s file), but > looking at a log locally, it appears to be using -c (to make a .o > file), so maybe that's what's going wrong for you as well? The tests even compiled with -S still fail: spawn -ignore SIGHUP /Users/fx/ibin/gcc/xgcc -B/Users/fx/ibin/gcc/ exceptions_enabled42475.cc -fdiagnostics-plain-output -S -o excep tions_enabled42475.s FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c -O1 (test for excess errors) Excess errors: /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: warning: 'asm' operand 6 probably does not match constraints /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: error: impossible constraint in 'asm' It’s the same for the other four. gcc.dg/analyzer/asm-x86-lp64-1.c is slightly different, there it’s an assembler error: /var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//cc4b3ybm.s:160:20: error:unexpected token in '.section' directive .pushsection .text ^ /var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//cc4b3ybm.s:162:2: error: unknown directive .type add_asm, @function ^ /var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//cc4b3ybm.s:167:13: error: .popsection without corresponding .pushsection .popsection ^ >>> ## Builtin-related failures >>> >>> Those four cases fail: >>> >>> gcc.dg/analyzer/data-model-1.c >>> gcc.dg/analyzer/pr103526.c >>> gcc.dg/analyzer/taint-size-1.c >>> gcc.dg/analyzer/write-to-string-literal-1.c > > Can you file a bug about this and attach the preprocessed source from > the test (using -E). Done, it is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 FX
Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)
Hi David, May I kindly ping you on that? Or anyone with knowledge of the static analyzer? Thanks, FX > Le 23 déc. 2021 à 22:49, FX a écrit : > > Hi David, hi everone, > > I’m trying to understand how best to fix or silence the several failures in > gcc.dg/analyzer that occur on x86_64-apple-darwin. Some of them, according to > gcc-testresults, also occur on other non-Linux targets. See for example, the > test results at > https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html > > ## gcc.dg/analyzer/torture/asm-x86-linux-*.c > > Are these supposed to be run only on Linux (as the name implies)? Four of > them fail on x86_64-apple-darwin, because they use assembly that is not > supported: > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c > > Should they be restricted to Linux targets? There is another one that has the > same error, as well, although it doesn’t have linux in the name: > > FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c > > > ## Builtin-related failures > > Those four cases fail: > > gcc.dg/analyzer/data-model-1.c > > gcc.dg/analyzer/pr103526.c > gcc.dg/analyzer/taint-size-1.c > gcc.dg/analyzer/write-to-string-literal-1.c > > but pass if the function calls (memset and memcpy) are replaced by the > built-in variant (__builtin_memset and __builtin_memcpy). The reason for that > is the darwin headers, in (included from ) does > this: > > #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__) > #undef memcpy > /* void *memcpy(void *dst, const void *src, size_t n) */ > #define memcpy(dest, ...) \ >__builtin___memcpy_chk (dest, __VA_ARGS__, __darwin_obsz0 > (dest)) > #endif > > where __darwin_obsz0 is defined thusly: > > #define __darwin_obsz0(object) __builtin_object_size (object, 0) > > > Does the analyzer not handle the _chk builtin variants? Should it? > I’m happy to investigate more, but I’m not sure what to do. > > > Best, > FX
Re: Weird behaviour (bug?) of __builtin_nans()
Hi Joseph, > 1. You should use -fsignaling-nans if you want signaling NaNs to work > correctly. Thanks, we’ll compile the libgfortran parts that are IEEE-related with that from now on. Sounds like a good idea, anyway. > 3. There is probably a reasonable case for interpreting such conversions > (including casts) as copy operations instead, including in the absence of > -fsignaling-nans; C23 Annex F leaves that implementation-defined, and > handling such conversions as copy operations is likely to be more > predictable and more useful. I agree that while there may be no guarantee, it sounds like a reasonable expectation in the case I posted. I’ve filed a PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103883 Thanks, FX
Weird behaviour (bug?) of __builtin_nans()
Hi,
I think I’ve found a bug in the handling of __builtin_nans() in GCC, but I am
aware that this is a tricky area, so before claiming so I would like to check
with the experts. Consider the following code:
$ cat v.c
#include
#include
#if 1
typedef double GFC_REAL_8;
#else
#define GFC_REAL_8 double
#endif
GFC_REAL_8 foo (void)
{
return __builtin_nans("");
}
int main (void) {
double x;
x = __builtin_nans ("");
printf("==> %lX\n", *(uint64_t *) &x);
x = foo ();
printf("==> %lX\n", *(uint64_t *) &x);
}
$ gcc v.c -W -Wall && ./a.out
==> 7FF4
==> 7FF8
My expectation is: the x variable should be assigned a signalling NaN, both
times, and therefore the code should output the same value twice. But as you
can see, the second time the NaN is converted to quiet.
What is even more troubling: this behavior only happens if GFC_REAL_8 is
typedef’ed to double. If we use the double type directly (change #if 1 to #if
0) then the output is as expected:
==> 7FF4
==> 7FF4
What is even more worrying is that, if you keep the typedef, but change the
function to go through a variable, then the signalling nan is returned
correctly:
typedef double GFC_REAL_8;
GFC_REAL_8 foo (void)
{
GFC_REAL_8 x = __builtin_nans("");
return x;
}
-
The reason I ended up in this rabbit hole is that I am implementing some
handling of signalling NaNs in libgfortran. Could someone either confirm that
the behavior observed above is a bug, or if not, kindly explain to me why it
happens?
Thanks,
FX
Re: _Float16-related failures on x86_64-apple-darwin
Hi Joseph, > fixincludes is the right place for a fix for this issue. There is a > plausible case for having an architecture-independent > __FLT_EVAL_METHOD___ macro that takes only values defined by > C99 (regardless of -fpermitted-flt-eval-methods), rather than using the > new C23 values such as 16, but if you did have such a macro you'd still > need to fixinclude the system headers - it would just affect exactly what > change fixincludes makes to those headers (if there were such a macro, > fixincludes could change the headers to use it). There is still a difference. If we define a new macro __FLT_EVAL_METHOD_OLDSTYLE__ (however it is named), it means we can make a more robust fixinclude, using that macro. If we fixinclude right now to handle the value of 16, then we might have to update the fixinclude for any new value that comes along in the future. FX
Need for __builtin_issignaling()
Hi, In order to finalize our support for Fortran IEEE modules, we need to have access to a reliable issignaling() macro, that would work across all floating-point types. Some targets (glibc ones, notably) have it, but not all, far from it. Instead of implementing our own, probably buggy, probably not very portable version… I think it would be a great idea for a GCC builtin: __builtin_issignaling() As far as I can see, this macro was proposed in the “ Optional support for Signaling NaNs” WG14 document (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1011.htm#7.12.3.x%20the%20issignaling%20macro). Many other proposed macros from this document are available as GCC builtins, so I wonder: why not __builtin_issignaling()? Is it particularly hard to do? I came across a post in the list archives from Joseph, who said it would be good to have. I’d be willing to try and put something together, unless you think it’s a big project. Any pointers as to how to start would be appreciated. Best, FX
Re: _Float16-related failures on x86_64-apple-darwin
> I’m not sure what the fix should be, either. We could use fixinclude to make
> the darwin headers happy, but we don’t really have a macro to provide the
> right value. Like a __FLT_EVAL_METHOD_OLDSTYLE__ macro.
>
> What should be the float_t and double_t types for FLT_EVAL_METHOD == 16?
> float and double, if I understand right?
This is one possibility, assuming I am right about the types:
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 46e3b8c993a..bea85ef7367 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -1767,6 +1767,18 @@ fix = {
test_text = ""; /* Don't provide this for wrap fixes. */
};
+/* The darwin headers don't accept __FLT_EVAL_METHOD__ == 16.
+*/
+fix = {
+hackname = darwin_flt_eval_method;
+mach = "*-*-darwin*";
+files = math.h;
+select= "^#if __FLT_EVAL_METHOD__ == 0$";
+c_fix = format;
+c_fix_arg = "#if __FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == 16";
+test_text = "#if __FLT_EVAL_METHOD__ == 0";
+};
+
/*
* Fix on Digital UNIX V4.0:
* It contains a prototype for a DEC C internal asm() function,
Sucks to have to fix headers… and we certainly can’t fix people’s code that may
depend on __FLT_EVAL_METHOD__ have well-defined values. So not convinced this
is the right approach.
FX
Re: _Float16-related failures on x86_64-apple-darwin
Hi, > See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=100854 . I found that, indeed, but what I struggle to see is: this behaviour of __FLT_EVAL_METHOD__ has been around for several years now, so why aren’t there more tests failing? I’m not sure what the fix should be, either. We could use fixinclude to make the darwin headers happy, but we don’t really have a macro to provide the right value. Like a __FLT_EVAL_METHOD_OLDSTYLE__ macro. What should be the float_t and double_t types for FLT_EVAL_METHOD == 16? float and double, if I understand right? FX
_Float16-related failures on x86_64-apple-darwin
Hi, Some recently introduced tests have been failing for several weeks on x86_64-apple-darwin. FAIL: gcc.target/i386/cond_op_maxmin__Float16-1.c FAIL: gcc.target/i386/pr102464-copysign-1.c FAIL: gcc.target/i386/pr102464-fma.c FAIL: gcc.target/i386/pr102464-maxmin.c FAIL: gcc.target/i386/pr102464-sqrtph.c FAIL: gcc.target/i386/pr102464-sqrtsh.c FAIL: gcc.target/i386/pr102464-vrndscaleph.c In all cases the symptom is the same: the include of errors out with “Unsupported value of __FLT_EVAL_METHOD__”. It appears that the compile option -mavx512fp16 defines __FLT_EVAL_METHOD__ to have value 16, which is not understood by darwin: > /* Define float_t and double_t per C standard, ISO/IEC 9899:2011 7.12 2, > taking advantage of GCC's __FLT_EVAL_METHOD__ (which a compiler may > define anytime and GCC does) that shadows FLT_EVAL_METHOD (which a > compiler must define only in float.h). > */ > #if __FLT_EVAL_METHOD__ == 0 > typedef float float_t; > typedef double double_t; > #elif __FLT_EVAL_METHOD__ == 1 > typedef double float_t; > typedef double double_t; > #elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1 > typedef long double float_t; > typedef long double double_t; > #else /* __FLT_EVAL_METHOD__ */ > # error "Unsupported value of __FLT_EVAL_METHOD__." > #endif /* __FLT_EVAL_METHOD__ */ Is the use of __FLT_EVAL_METHOD__ set to 16 supposed to be portable across all targets? Or is it linux-only, and should marked as such? Thanks for any help you can give. FX
Many analyzer failures on non-Linux system (x86_64-apple-darwin)
Hi David, hi everone, I’m trying to understand how best to fix or silence the several failures in gcc.dg/analyzer that occur on x86_64-apple-darwin. Some of them, according to gcc-testresults, also occur on other non-Linux targets. See for example, the test results at https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html ## gcc.dg/analyzer/torture/asm-x86-linux-*.c Are these supposed to be run only on Linux (as the name implies)? Four of them fail on x86_64-apple-darwin, because they use assembly that is not supported: FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c Should they be restricted to Linux targets? There is another one that has the same error, as well, although it doesn’t have linux in the name: FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c ## Builtin-related failures Those four cases fail: gcc.dg/analyzer/data-model-1.c gcc.dg/analyzer/pr103526.c gcc.dg/analyzer/taint-size-1.c gcc.dg/analyzer/write-to-string-literal-1.c but pass if the function calls (memset and memcpy) are replaced by the built-in variant (__builtin_memset and __builtin_memcpy). The reason for that is the darwin headers, in (included from ) does this: #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__) #undef memcpy /* void *memcpy(void *dst, const void *src, size_t n) */ #define memcpy(dest, ...) \ __builtin___memcpy_chk (dest, __VA_ARGS__, __darwin_obsz0 (dest)) #endif where __darwin_obsz0 is defined thusly: #define __darwin_obsz0(object) __builtin_object_size (object, 0) Does the analyzer not handle the _chk builtin variants? Should it? I’m happy to investigate more, but I’m not sure what to do. Best, FX
Re: C++11 code in the gcc 10 branch
> If Richard approves the second patch (and you’re stuck for time) - then send
> me the patch(es) as attachments with the commit credits you want, and I can
> apply them for you.
Both patches only needed on gcc-10, if you can commit that’s great, many thanks.
For credits in GCC I’m known as Francois-Xavier Coudert
(and for the record, I do have a copyright assignment in place)
Happy new year to all,
FX
commit 96a9d0950453ca571b3999c2f4d4168da9d770f0
Author: Francois-Xavier Coudert
Date: 2020-12-21 22:06:59 +0100
Fix prototype for aarch64_get_extension_string_for_isa_flags
Patch should be backported in gcc-10 branch
diff --git a/gcc/config/aarch64/driver-aarch64.c
b/gcc/config/aarch64/driver-aarch64.c
index 8840a2d9486..d99834c9989 100644
--- a/gcc/config/aarch64/driver-aarch64.c
+++ b/gcc/config/aarch64/driver-aarch64.c
@@ -27,8 +27,7 @@
#include "tm.h"
/* Defined in common/config/aarch64/aarch64-common.c. */
-std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
- unsigned long);
+std::string aarch64_get_extension_string_for_isa_flags (uint64_t, uint64_t);
struct aarch64_arch_extension
{
commit 3f1b98679eecdaf81ba5702a8de65bcb6b4ab25f
Author: Francois-Xavier Coudert
Date: 2020-12-21 22:06:15 +0100
Remove C++11 constructor
Patch should be backported in gcc-10 branch
diff --git a/gcc/config/aarch64/aarch64-builtins.c
b/gcc/config/aarch64/aarch64-builtins.c
index cba596765ac..184e9095d51 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -1225,8 +1225,9 @@ aarch64_init_memtag_builtins (void)
= aarch64_general_add_builtin ("__builtin_aarch64_memtag_"#N, \
T, AARCH64_MEMTAG_BUILTIN_##F); \
aarch64_memtag_builtin_data[AARCH64_MEMTAG_BUILTIN_##F - \
- AARCH64_MEMTAG_BUILTIN_START - 1] = \
- {T, CODE_FOR_##I};
+ AARCH64_MEMTAG_BUILTIN_START - 1].ftype = T; \
+ aarch64_memtag_builtin_data[AARCH64_MEMTAG_BUILTIN_##F - \
+ AARCH64_MEMTAG_BUILTIN_START - 1].icode =
CODE_FOR_##I;
fntype = build_function_type_list (ptr_type_node, ptr_type_node,
uint64_type_node, NULL);
Re: C++11 code in the gcc 10 branch
> When are you going to apply your fix that Richard S. approved on the
> 21st?
When I remember how to set up gcc’s git with write access, and remember how the
new ChangeLog entries work. The times where I was a regular contributor were
the CVS and SVN times.
I also wanted to ask approval to commit this diff below, fixing
aarch64_get_extension_string_for_isa_flags()’s prototype to align it with the
actual function definition:
diff --git a/gcc/config/aarch64/driver-aarch64.c
b/gcc/config/aarch64/driver-aarch64.c
index 8840a2d9486c..d99834c99896 100644
--- a/gcc/config/aarch64/driver-aarch64.c
+++ b/gcc/config/aarch64/driver-aarch64.c
@@ -27,8 +27,7 @@
#include "tm.h"
/* Defined in common/config/aarch64/aarch64-common.c. */
-std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
- unsigned long);
+std::string aarch64_get_extension_string_for_isa_flags (uint64_t, uint64_t);
struct aarch64_arch_extension
{
Although I admit that’s almost trivial (and it breaks build on aarch64-darwin),
I’d prefer to be sure and ask. Then I’ll commit the two patches, if you think
that’s OK.
FX
Re: GCC 10.2 Released
Hi all, The gcc 10.2 release was 5 months ago today. A lot has happened in the gcc-10 branch since, in particular on aarch64. Could a new release be issued? It would make efforts at maintaining patches on top of the gcc-10 branch easier, in particular in view of the release of aarch64-apple-darwin machines. Cheers, FX
C++11 code in the gcc 10 branch
I’m trying to bootstrap a GCC 10 compiler on macOS with clang, and I am getting
errors in stage 1, because there is C++11 code that is rejected by clang
(because the bootstrap involves compiling stage 1 with -std=gnu++98, online on
master (see top-level configure.ac). These errors are not seen, I believe, when
GCC is the bootstrap compiler, because GCC will issue a warning instead of an
error (as clang does).
One place with such issue is in aarch64-builtins.c, which contains a C++11
constructor. I can fix it with this:
diff --git a/gcc/config/aarch64/aarch64-builtins.c
b/gcc/config/aarch64/aarch64-builtins.c
index cba596765..184e9095d 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -1225,8 +1225,9 @@ aarch64_init_memtag_builtins (void)
= aarch64_general_add_builtin ("__builtin_aarch64_memtag_"#N, \
T, AARCH64_MEMTAG_BUILTIN_##F); \
aarch64_memtag_builtin_data[AARCH64_MEMTAG_BUILTIN_##F - \
- AARCH64_MEMTAG_BUILTIN_START - 1] = \
- {T, CODE_FOR_##I};
+ AARCH64_MEMTAG_BUILTIN_START - 1].ftype = T; \
+ aarch64_memtag_builtin_data[AARCH64_MEMTAG_BUILTIN_##F - \
+ AARCH64_MEMTAG_BUILTIN_START - 1].icode =
CODE_FOR_##I;
fntype = build_function_type_list (ptr_type_node, ptr_type_node,
uint64_type_node, NULL);
but later I am getting further errors:
../../gcc/gcc/config/darwin.c:1357:16: error: no viable conversion from
'poly_uint16' (aka 'poly_int<2, unsigned short>') to 'unsigned int'
unsigned int modesize = GET_MODE_BITSIZE (mode);
^ ~~~
../../gcc/gcc/config/darwin.c:1752:28: error: invalid operands to binary
expression ('poly_uint16' (aka 'poly_int<2, unsigned short>') and 'int')
if (GET_MODE_SIZE (mode) == 8
^ ~
../../gcc/gcc/wide-int.h:3289:19: note: candidate template ignored:
substitution failure [with T1 = poly_int<2, unsigned short>, T2 = int]:
implicit instantiation of undefined template
'wi::int_traits >'
BINARY_PREDICATE (operator ==, eq_p)
^
../../gcc/gcc/wide-int.h:3266:3: note: expanded from macro 'BINARY_PREDICATE'
OP (const T1 &x, const T2 &y) \
^
../../gcc/gcc/config/darwin.c:1757:33: error: invalid operands to binary
expression ('poly_uint16' (aka 'poly_int<2, unsigned short>') and 'int')
else if (GET_MODE_SIZE (mode) == 4
^ ~
../../gcc/gcc/wide-int.h:3289:19: note: candidate template ignored:
substitution failure [with T1 = poly_int<2, unsigned short>, T2 = int]:
implicit instantiation of undefined template
'wi::int_traits >'
BINARY_PREDICATE (operator ==, eq_p)
^
../../gcc/gcc/wide-int.h:3266:3: note: expanded from macro 'BINARY_PREDICATE'
OP (const T1 &x, const T2 &y) \
^
../../gcc/gcc/config/darwin.c:1764:29: error: invalid operands to binary
expression ('poly_uint16' (aka 'poly_int<2, unsigned short>') and 'int')
&& GET_MODE_SIZE (mode) == 16
^ ~~
../../gcc/gcc/wide-int.h:3289:19: note: candidate template ignored:
substitution failure [with T1 = poly_int<2, unsigned short>, T2 = int]:
implicit instantiation of undefined template
'wi::int_traits >'
BINARY_PREDICATE (operator ==, eq_p)
^
../../gcc/gcc/wide-int.h:3266:3: note: expanded from macro 'BINARY_PREDICATE'
OP (const T1 &x, const T2 &y) \
^
I would welcome:
1. confirmation that the C++11 code in aarch64-builtins.c is indeed a bug, and
that a patch for it would be welcome
2. guidance about how to fix that next issue
Thanks,
FX
