On Fri, Sep 2, 2022 at 2:03 AM Krister Walfridsson
wrote:
>
> On Thu, 1 Sep 2022, Richard Biener wrote:
>
> > It's generally poorly documented what is considered 'undefined behavior'.
> > We desparately need a section in the internals manual for this.
> > For the {L,R}SHIFT_EXPR case we assume the
On Thu, 1 Sep 2022, Richard Biener wrote:
It's generally poorly documented what is considered 'undefined behavior'.
We desparately need a section in the internals manual for this.
For the {L,R}SHIFT_EXPR case we assume the shift operand is
in range of [0, precision - 1], so in theory value-range
Snapshot gcc-10-20220901 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20220901/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
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
> 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
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
> 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
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 is going to be that the comparisons
>
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 is going to be that the comparisons
seem to be optimised away very easily into their non-signaling versions
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
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
On Thu, Sep 01, 2022 at 10:19:59AM +0200, Jakub Jelinek via Gcc wrote:
> On Thu, Sep 01, 2022 at 10:04:58AM +0200, FX wrote:
> > 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=779
On Mon, 29 Aug 2022 at 11:31, Gerald Pfeifer wrote:
>
> On Wed, 24 Aug 2022, Jonathan Wakely wrote:
> >> a broken link points to
> >>
> >> An introduction to GCC by Brian J. Gough.
> >> . http://www.network-theory.co.uk/gcc/intro/
> > There are much more recent archived copies like
> > https://
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
On Thu, Sep 01, 2022 at 11:04:03AM +0200, FX wrote:
> 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
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
On Thu, Sep 01, 2022 at 10:04:58AM +0200, FX wrote:
> 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 co
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
21 matches
Mail list logo
