> 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 nee
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
For the record, this is now PR 106805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
FX
> 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");
f
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 For
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
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 inte
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
> 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.
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
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
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
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_
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 su
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, probab
> 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?
> flo
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
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
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/piper
> 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 Fra
> 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 com
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-dar
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,
23 matches
Mail list logo
