Re: Should we move the --param documention to gccint?
On Fri, 8 Nov 2024, Richard Sandiford via Gcc wrote: > We changed one of the AArch64-specific --params for GCC 14. > Unfortunately, it seems that a lot of people were relying on the > previous behaviour. Umpf. > Every --param is documented in the user-facing manual, so it's not > surprising that people picked it up. The documentation of --param > itself starts with: : > So we can point at the last paragraph above and say "nyah, nyah, told you so". > But that isn't helpful. The disclaimer is at the head of a huge table, > and anyone interested in tuning things is likely to find the specific > params that interest them by searching for keywords, rather than by > reading the whole text from beginning to end. Besides, the documentation > is supposed to be there to help people, rather than be something to hit > them over the head with. I like your attitude. And I like your suggestion: > But to avoid confusion, how about moving the documentation of the > individual --params from the user-facing manual to gccint (with a link)? In fact, I was going to suggest the same approach until, re-reading your mail more carefully, realized this was actually your proposal already. :-) So, okay, unless someone fiercly objects in which case we need to have a deeper conversation. Gerald
Re: Complex arithmetic in Fortran
On Wed, Nov 13, 2024 at 3:05 PM Thomas Koenig wrote: > > Hello world, > > J3, the US Fortran standards committee, has passed > https://j3-fortran.org/doc/year/24/24-179.txt > which states (with a bit of an overabundance of > clarity) that, in Fortran, it is possible special-case > complex multiplication when one of the numbers is known > to have a zero component, for example when promoting > a real to complex for complex multiplication. For > example, multiplying a complex variable b with a real > variable a can be done with c%re = b%re * a, c%im = b%im * a, > without considering NaNs and infinities. Apparently, other > Fortran compilers do this. > > They also stated that ISO/IEC 60559:2020 (aka IEEE 754) does > not specify complex arithmetic (I wouldn't know, because it is a > paywalled standard). > > How do we want to deal with this? Do we want to implement this > (it's an obvious speed advantage)? Should it be the default? > Do we want to include this in -fcx-fortran-rules? The middle-end complex lowering pass does this already, irrespective of NaNs, same for some degenerate cases with division. Richard. > Best regards > > Thomas > >
Re: Complex arithmetic in Fortran
Am 13.11.24 um 15:55 schrieb Toon Moene: Since the Fortran 95 Standard it does (in the current Standard: 7.4.3.2 Real type): The real type includes a zero value. Processors that distinguish between positive and negative zeros shall treat them as mathematically equivalent • in all intrinsic relational operations, and • as actual arguments to intrinsic procedures other than those for which it is explicitly specified that negative zero is distinguished. [Note that "processor" in Fortran standardese means everything (combined) from the compiler down to the actual hardware]. So we have to comb through the Standard to see where bullet 2 applies ... I looked through the current standard, and the only mention of positive and negative zero I could find were in the IEEE intrinsics. So, I think we could ignore signed zeros (from the Fortran standard perspective) - for complex arithmetic, always - for real arithmetic, if none of the IEEE modules is USEd Best regards Thomas
Re: Complex arithmetic in Fortran
> So, I think we could ignore signed zeros (from the Fortran standard > perspective) > > - for complex arithmetic, always > - for real arithmetic, if none of the IEEE modules is USEd That seems like a very backward-incompatible change to introduce :( I might break a lot of existing codes. FX
Re: Complex arithmetic in Fortran
On Wed, Nov 13, 2024 at 05:33:20PM +0100, Thomas Koenig wrote: > Am 13.11.24 um 15:55 schrieb Toon Moene: > > > > Since the Fortran 95 Standard it does (in the current Standard: 7.4.3.2 > > Real type): > > > > The real type includes a zero value. Processors that distinguish between > > positive and negative zeros shall treat them as mathematically > > equivalent > > • in all intrinsic relational operations, and > > • as actual arguments to intrinsic procedures other than those for which > > it is explicitly specified that negative zero is distinguished. > > > > [Note that "processor" in Fortran standardese means everything > > (combined) from the compiler down to the actual hardware]. > > > > So we have to comb through the Standard to see where bullet 2 applies ... > > I looked through the current standard, and the only mention of positive > and negative zero I could find were in the IEEE intrinsics. > > So, I think we could ignore signed zeros (from the Fortran standard > perspective) > > - for complex arithmetic, always > - for real arithmetic, if none of the IEEE modules is USEd > Possibly ending up on the wrong Riemann sheet seems like a good idea to me. If you're going to revisit complex multication and division, then I believe the -fcx-fortran-rules option should be removed. It states Complex multiplication and division follow Fortran rules. There are no special rules for Fortran. The rules for Fortran are (24-007r1.pdf, p162) The two operands of numeric intrinsic binary operations may be of different numeric types or different kind type parameters. Except for a value of type real or complex raised to an integer power, if the operands have different types or kind type parameters, the effect is as if each operand that differs in type or kind type parameter from those of the result is converted to the type and kind type parameter of the result before the operation is performed. So, (1) r*z = (r+I0)*(x+Iy), which is gfortran's current behavior. Once the interpretation of a numeric intrinsic operation is established, the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated. (There are implicit parentheses above, but let's let that go.) (2) r*z = r*x + Ir*y This appears to be mathematically equivalent, except they are not. +-0 and +-inf are fundamental to the foundations of calculus and branch cuts in complex plane. gfortran does (1) by default. Users can get (2) if they use -ffast-math, -Ofast or -fno-cx-fortran-rules. J3 threw a red herring and cop out into the interpretation by making a statement that IEEE754 does consider complex number. Of course, it would not! IEEE754 deals with mapping real numbers to a finite set of floating point numbers. J3 should have considered Annex G, "IEC 60559-compatible complex arithmetic" from C23; specially, G.5.1 "Multiplicative operators". -- Steve
Complex arithmetic in Fortran
Hello world, J3, the US Fortran standards committee, has passed https://j3-fortran.org/doc/year/24/24-179.txt which states (with a bit of an overabundance of clarity) that, in Fortran, it is possible special-case complex multiplication when one of the numbers is known to have a zero component, for example when promoting a real to complex for complex multiplication. For example, multiplying a complex variable b with a real variable a can be done with c%re = b%re * a, c%im = b%im * a, without considering NaNs and infinities. Apparently, other Fortran compilers do this. They also stated that ISO/IEC 60559:2020 (aka IEEE 754) does not specify complex arithmetic (I wouldn't know, because it is a paywalled standard). How do we want to deal with this? Do we want to implement this (it's an obvious speed advantage)? Should it be the default? Do we want to include this in -fcx-fortran-rules? Best regards Thomas
Re: Complex arithmetic in Fortran
On 11/13/24 15:12, Richard Biener wrote: On Wed, Nov 13, 2024 at 3:05 PM Thomas Koenig wrote: Hello world, J3, the US Fortran standards committee, has passed https://j3-fortran.org/doc/year/24/24-179.txt which states (with a bit of an overabundance of clarity) that, in Fortran, it is possible special-case complex multiplication when one of the numbers is known to have a zero component, for example when promoting a real to complex for complex multiplication. For example, multiplying a complex variable b with a real variable a can be done with c%re = b%re * a, c%im = b%im * a, without considering NaNs and infinities. Apparently, other Fortran compilers do this. They also stated that ISO/IEC 60559:2020 (aka IEEE 754) does not specify complex arithmetic (I wouldn't know, because it is a paywalled standard). How do we want to deal with this? Do we want to implement this (it's an obvious speed advantage)? Should it be the default? Do we want to include this in -fcx-fortran-rules? The middle-end complex lowering pass does this already, irrespective of NaNs, same for some degenerate cases with division. Are you sure ? For this code: $ cat complex.f90 complex function p(c, r) complex, intent(in) :: c real, intent(in):: r p = c * r end I definitely see a difference between $ gfortran -O2 -S complex.f90 and $ gfortran -O2 -ffast-math -S complex.f90 -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Complex arithmetic in Fortran
On 11/13/24 15:40, Richard Biener wrote:
On Wed, Nov 13, 2024 at 3:21 PM Toon Moene wrote:
On 11/13/24 15:12, Richard Biener wrote:
On Wed, Nov 13, 2024 at 3:05 PM Thomas Koenig wrote:
Hello world,
J3, the US Fortran standards committee, has passed
https://j3-fortran.org/doc/year/24/24-179.txt
which states (with a bit of an overabundance of
clarity) that, in Fortran, it is possible special-case
complex multiplication when one of the numbers is known
to have a zero component, for example when promoting
a real to complex for complex multiplication. For
example, multiplying a complex variable b with a real
variable a can be done with c%re = b%re * a, c%im = b%im * a,
without considering NaNs and infinities. Apparently, other
Fortran compilers do this.
They also stated that ISO/IEC 60559:2020 (aka IEEE 754) does
not specify complex arithmetic (I wouldn't know, because it is a
paywalled standard).
How do we want to deal with this? Do we want to implement this
(it's an obvious speed advantage)? Should it be the default?
Do we want to include this in -fcx-fortran-rules?
The middle-end complex lowering pass does this already, irrespective
of NaNs, same for some degenerate cases with division.
Are you sure ?
For this code:
$ cat complex.f90
complex function p(c, r)
complex, intent(in) :: c
real, intent(in):: r
p = c * r
end
I definitely see a difference between
$ gfortran -O2 -S complex.f90
and
$ gfortran -O2 -ffast-math -S complex.f90
Ah. This is because of
static int
some_nonzerop (tree t)
{
int zerop = false;
/* Operations with real or imaginary part of a complex number zero
cannot be treated the same as operations with a real or imaginary
operand if we care about the signs of zeros in the result. */
if (TREE_CODE (t) == REAL_CST && !flag_signed_zeros)
zerop = real_identical (&TREE_REAL_CST (t), &dconst0);
so the -ffast-math result can be obtained with just -fno-signed-zeros (I assumed
fortran doesn't have signed zeros?)
Since the Fortran 95 Standard it does (in the current Standard: 7.4.3.2
Real type):
The real type includes a zero value. Processors that distinguish between
positive and negative zeros shall treat them as mathematically equivalent
• in all intrinsic relational operations, and
• as actual arguments to intrinsic procedures other than those for which
it is explicitly specified that negative zero is distinguished.
[Note that "processor" in Fortran standardese means everything
(combined) from the compiler down to the actual hardware].
So we have to comb through the Standard to see where bullet 2 applies ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Complex arithmetic in Fortran
On Wed, Nov 13, 2024 at 3:21 PM Toon Moene wrote:
>
> On 11/13/24 15:12, Richard Biener wrote:
>
> > On Wed, Nov 13, 2024 at 3:05 PM Thomas Koenig wrote:
> >>
> >> Hello world,
> >>
> >> J3, the US Fortran standards committee, has passed
> >> https://j3-fortran.org/doc/year/24/24-179.txt
> >> which states (with a bit of an overabundance of
> >> clarity) that, in Fortran, it is possible special-case
> >> complex multiplication when one of the numbers is known
> >> to have a zero component, for example when promoting
> >> a real to complex for complex multiplication. For
> >> example, multiplying a complex variable b with a real
> >> variable a can be done with c%re = b%re * a, c%im = b%im * a,
> >> without considering NaNs and infinities. Apparently, other
> >> Fortran compilers do this.
> >>
> >> They also stated that ISO/IEC 60559:2020 (aka IEEE 754) does
> >> not specify complex arithmetic (I wouldn't know, because it is a
> >> paywalled standard).
> >>
> >> How do we want to deal with this? Do we want to implement this
> >> (it's an obvious speed advantage)? Should it be the default?
> >> Do we want to include this in -fcx-fortran-rules?
> >
> > The middle-end complex lowering pass does this already, irrespective
> > of NaNs, same for some degenerate cases with division.
>
> Are you sure ?
>
> For this code:
>
> $ cat complex.f90
> complex function p(c, r)
> complex, intent(in) :: c
> real, intent(in):: r
> p = c * r
> end
>
> I definitely see a difference between
>
> $ gfortran -O2 -S complex.f90
>
> and
>
> $ gfortran -O2 -ffast-math -S complex.f90
Ah. This is because of
static int
some_nonzerop (tree t)
{
int zerop = false;
/* Operations with real or imaginary part of a complex number zero
cannot be treated the same as operations with a real or imaginary
operand if we care about the signs of zeros in the result. */
if (TREE_CODE (t) == REAL_CST && !flag_signed_zeros)
zerop = real_identical (&TREE_REAL_CST (t), &dconst0);
so the -ffast-math result can be obtained with just -fno-signed-zeros (I assumed
fortran doesn't have signed zeros?)
Richard.
> --
> Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: -Wfloat-equal and comparison to zero
Hello, On Tue, 12 Nov 2024, Thomas Koenig via Gcc wrote: > Am 12.11.24 um 17:25 schrieb Michael Matz via Gcc: > > > If you think of float as > > approximated reals, then yes, division by zero is undefined (not > > somewhat undefined!). > > Depends on how you look at it. > > IEEE 754-2008, for example, says in 7.3 When you regard floats (I meant IEEE floats) as approximated reals (I meant R) then IEEE 754 doesn't enter the picture. In R division by zero is undefined. Of course in IEEE division is completey defined, as I also said. Ciao, Michael.
Re: -Wfloat-equal and comparison to zero
On Tue, 12 Nov 2024 18:12:50 +0100 David Brown via Gcc wrote: > Under what circumstances would you have code that : ... > d) Would be perfectly happy with "x" having the value 2.225e-307 (or > perhaps a little larger) and doing the division with that. > > I think what you really want to check is if "x" is a reasonable value > - checking only for exactly 0.0 is usually a lazy and useless attempt > at such checks. In quantitative research, "x" may be initialized from a database. Yesterday that database might have been fine, and today there's a row with a zero in it. If it's a problem, it's better to report the problem as "x is 0 for foo" than as a divide-by-zero error later on. In fact, division might not be the issue. A coefficient of zero might indicate, say, an error upstream in the model parameter output. It's also not unusual to start with "x" statically initialized to zero, and use that as an indication to invoke the initialization routine. When we have floating point numbers initialized from small integer constants, comparison with == is both valid and safe. Whether 0 itself is the concern, or near-zeroes like 2.225e-307, is depends on context, something the programmer knows and the compiler does not. --jkl
Re: -Wfloat-equal and comparison to zero
On Mon, 11 Nov 2024 21:14:43 + (UTC)
Joseph Myers via Gcc wrote:
> On Sat, 9 Nov 2024, Sad Clouds via Gcc wrote:
>
> > Even though there is nothing unsafe here and comparison to floating
> > point 0.0 value is well defined.
>
> The point of the warning is that *if you are writing code that thinks
> of floating-point values as being approximations to real numbers*
> then such comparisons are suspect. If you are writing code that
> thinks of floating-point values as exactly represented members of
> their type ... then you should not use that warning option for such
> code.
You could be right. But IMO -Wfloat-equal is an example of solving the
wrong problem.
I do not think warnings from the C compiler should extend to valid
numerical constructs. It is the programmer's job to understand how
floating point works. If he does not, there's precious little the
compiler can do for him.
Here's a bogus function that compiles without diagnostic using -Wall:
int f( double g ) {
double gs[10];
for( double *pg = gs; pg < gs + 12; pg++ ) {
*pg = 2 * g;
g = *pg;
}
return g;
}
We have UB, a fencepost error on an array of known size using a bound of
known size. The returned value might or might not be representable as
an int, depending on the initial value of g. I'm not sure what happens
if INT_MAX < g.
Everyone reading this sees the problems, but the compiler does not. If
10 and 12 are named constants, some of the obviousness goes away. So
does the integer conversion if the return type uses a typedef.
But we do have a warning about comparing g as equal to something, in
case *that* helps.
Granted, "it's the programmer's job" extends to everything. You should
get your fprintf format strings correct, say. And no one is forced to
use -Wfloat-equal.
There are at least 2^53 exact values that a double can be initialized
to and compared against. This diagnostic might help the occasional
1st-year programmer learn something about C. But it's too
simple-minded to be much use beyond that.
--jkl
Re: Handling C2Y zero-length operations on null pointers
> On Nov 12, 2024, at 01:51, Martin Uecker wrote:
>
> Am Montag, dem 07.10.2024 um 15:14 + schrieb Qing Zhao:
>>
>>> On Oct 7, 2024, at 10:13, Jakub Jelinek via Gcc wrote:
>>>
>>> On Fri, Oct 04, 2024 at 12:42:24AM +0200, Florian Weimer wrote:
* Joseph Myers:
> The real question is how to achieve optimal warnings in the absence of
> the
> attribute. Should we have a variant of the nonnull attribute that warns
> for NULL arguments but without optimizing based on them?
I think attribute access already covers part of it:
#include
void read_array (void *, size_t) __attribute__ ((access (read_only, 1,
2)));
void
f (void)
{
read_array (NULL, 0); // No warning.
read_array (NULL, 1); // Warning.
}
It does not work for functions like strndup that support both string
arguments (of any length) and array arguments of a specified size.
The read_only variant requires an initialized array of the specified
length.
>>>
>>> access attribute can't deal with various other things.
>>>
>>> Consider the qsort case. My understanding was that the paper is making
>>> typedef int (*cmpfn) (const void *, const void *);
>>> qsort (NULL, 0, 1, (cmpfn) NULL);
>>> valid (but is
>>> qsort (NULL, 1, 0, (cmpfn) NULL);
>>> still invalid?).
>>> How do you express that with access attribute, which can only have 1 size
>>> argument? The accessed memory for the read/write pointee of the first
>>> argument has nmemb * size parameter bytes size.
>>
>> For the other attribute “alloc_size”, we have two forms,
>> A. alloc_size (position)
>> and
>> B. alloc_size (position-1, position-2)
>>
>> The 2nd form is used to represent nmemb * size.
>>
>> Is it possible that we extend the attribute “access” similarly?
>>
>> Then we can use the attribute “access” consistently for this purpose?
>
> We also miss sanitizer support.
>
> How about letting "access" only be about access range
> and instead have separate attribute that can be used to
> express more complicated preconditions?
Sounds reasonable to me.
Yes, it’s not a good idea to mix them together with one attribute.
Qing
>
> void* foo(void *p, size_t mmemb, size_t size)
> [[precondition((p == NULL) == (mmemb * size == 0)]];
>
> (not saying this is the right condition for any function
> in the standard library)
>
> Martin
>
>>
>> Qing
>>
>>> And using access attribute for function pointers doesn't work, there is
>>> no data to be read/written there, just code.
>>>
>>> Guess some of the nonnull cases could be replaced by access attribute
>>> if we clarify the documentation that if SIZE_INDEX is specified and that
>>> argument is non-zero then the pointer has to be non-NULL, and teach
>>> sanitizers etc. to sanitize those.
>>>
>>> For the rest, perhaps we need some nonnull_if_nonzero argument
>>> which requires that the parameter identified by the first attribute
>>> argument must be pointer which is non-NULL if the parameter identified
>>> by the second attribute argument is non-zero.
>>> And get clarified the qsort/bsearch cases whether it is about just
>>> nmemb == 0 or nmemb * size == 0.
>>>
>>> Jakub
