Re: Need for __builtin_issignaling()

On Wed, 29 Dec 2021, FX via Gcc wrote: > 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

Re: [PATCH] PR fortran/50549 - should detect different type parameters in structure constructors

On Mon, 28 Mar 2022, Harald Anlauf via Gcc-patches wrote: > Hi Tobias, > > sorry for replying to myself now, but > > Am 28.03.22 um 22:03 schrieb Harald Anlauf via Fortran: > > All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use > > 'sprintf', and I did not find any other use of %w

Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+

On Mon, 27 Jun 2022, Jakub Jelinek via Gcc-patches wrote: > On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote: > > I don’t like the _Float128 vs __float128 business, it’s confusing. > > And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html > > they seem to be basicall

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > 1. Is this list normative, and was it modified later (I have only found > a 2012 draft)? 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 thin

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > 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: Presumably

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, Marc Glisse via Gcc wrote: > On Thu, 1 Sep 2022, Joseph Myers wrote: > > > On Thu, 1 Sep 2022, FX via Gcc wrote: > > > > > A tentative patch is attached, it seems to work well on simple examples, > > > but for test coverage the hard part

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > Do you want me to file a bug report? Yes. -- Joseph S. Myers jos...@codesourcery.com

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > 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()? I support having such a built-in function. -- Joseph S. Myers jos...@codesourcery.com

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > 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? Yes (note that maxNum and minNum were r

Re: [PATCH 1/5] c: Set the locus of the function result decl

On Sun, 13 Nov 2022, Bernhard Reutner-Fischer via Gcc-patches wrote: > Bootstrapped and regtested on x86_86-unknown-linux with no regressions. > Ok for trunk? > > Cc: Joseph Myers > --- > gcc/c/ChangeLog: > > * c-decl.cc (start_function): Set the result decl so

Re: [ping] driver: Forward '-lgfortran', '-lm' to offloading compilation

On Tue, 13 Jun 2023, Thomas Schwinge wrote: > Hi! > > On 2023-06-05T14:25:18+0200, I wrote: > > OK to push the attached > > "driver: Forward '-lgfortran', '-lm' to offloading compilation"? > > (We didn't have a PR open for that, or did we?) > > Ping. OK. -- Joseph S. Myers jos...@codesourcery

Re: [Patch] OpenMP: Add iterator support to Fortran's depend; add affinity clause

On Thu, 27 May 2021, Tobias Burnus wrote: > @Joseph: I CC'ed you in case you have comments regarding > c-parser.c's c_parser_check_balanced_raw_token_sequence (comment update) > and c_parser_check_tight_balanced_raw_token_sequence (new); the latter > is essentially cp_parser_skip_balanced_tokens w

Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h

On Sun, 5 Sep 2021, Sandra Loosemore wrote: > Unless the aarch64 maintainers think it is a bug that __float128 is not > supported, I think the right solution here is the one I was thinking of > previously, to fix the Fortran front end to tie the C_FLOAT128 kind to > _Float128 rather than __float12

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

On Tue, 14 Sep 2021, Andreas Schwab wrote: > On Sep 14 2021, Jakub Jelinek wrote: > > > But, wonder why it didn't work with the float.h include then, because > > https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h > > seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Mon, 4 Oct 2021, Jakub Jelinek via Gcc wrote: > One problem with that is that I think IEEE quad long double support relies > on glibc 2.32 or later, so not sure what exactly would be done if gcc is > built against older glibc when it needs to call libm routines. Perhaps > convert to __ibm128,

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Mon, 4 Oct 2021, Segher Boessenkool wrote: > Some current Power GCC targets support neither. Some support only > double-double. Making IEEE QP float work on those (that is, those that > are < power8) will require some work still: it should use libquadmath or > similar, but that needs to be pu

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote: > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > We can emulate it everywhere (using libquadmath for example). This can > > magically make -msoft-float work as well everywhere, btw. > > Emulation is one thing, but another

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, 6 Oct 2021, Segher Boessenkool wrote: > Soft float is not described in any formal ABI btw (well, except the > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair. It's fully documented in the unified 32-bit ABI document (under ATR-SOFT-FLOAT conditionals). There's still

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, 6 Oct 2021, Segher Boessenkool wrote: > > There's still some code in the compiler for a very old soft-float ABI for > > binary128 long double (passing by reference, using _q_* libcall names). I > > don't really think it makes much sense to use that for future _Float128 > > support for

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, 6 Oct 2021, Segher Boessenkool wrote: > With "not in any" I mean: not for other architectures either! All archs > that do not say anything about floating point in their machine > description get a working sofware floating point (for binary32 and > binary64 currently). Any architecture th

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Fri, 8 Oct 2021, Segher Boessenkool wrote: > But many CPUs do not have hardware floating point in any variant, and > their ABIs / calling conventions do not mention floating point at all. > Still, this works with GCC just fine: it passes floats and doubles the > same as 32-bit resp. 64-bit inte

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Fri, 15 Oct 2021, Bill Schmidt via Gcc wrote: > Beyond ABI and compiler support, glibc would also need to support IEEE > QP for these other targets. Currently we only have support for > powerpc64le. And that would involve new syntax in glibc Versions files, as discussed in

Re: On pull request workflows for the GNU toolchain

On Mon, 23 Sep 2024, enh via Gcc wrote: > it doesn't make the patch _management_ problem better ("now i have two > problems"), but https://github.com/landley/toybox takes the "why not both?" > approach --- you can use pull requests if you grew up with/adapted to > git/github, or you can use the ma

Re: *PING* [PATCH v3 10/10] fortran: Add -finline-intrinsics flag for MINLOC/MAXLOC [PR90608]

On Fri, 13 Sep 2024, Mikael Morin wrote: > *PING* > > Joseph, could you take a quick look at the handling of the new option? > > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661267.html Individual new options like this are expected to be reviewed by maintainers / reviewers for the rel