> It's also not unusual to start with "x" statically initialized to zero,
> and use that as an indication to invoke the initialization routine.
This is exactly what I have. In my case, if the value remains 0.0 it
means the calculations for those metrics are not applicable.
The suggestion to u
On Tue, 12 Nov 2024 17:25:14 +0100 (CET)
Michael Matz wrote:
> Other values for the divisor will also produce Inf. If your goal was to
> avoid getting Inf, then checking for equality with zero _won't_ do:
Yes you are correct, there are many different ways to overflow and
underflow a floating p
On Mon, 11 Nov 2024 21:14:43 + (UTC)
Joseph Myers wrote:
> I don't think this has anything to do with whether one operand of the
> comparison is a constant. It's still the case when comparing with 0.0
> that it's OK if your algorithm is designed such that the other operand is
> exact, and
On Sun, 10 Nov 2024 09:45:41 +
Jonathan Wakely wrote:
> Does clang only have a special case for 0.0, or for any literal value?
>
It looks like clang can detect which floating point literals can be
represented exactly and does not generate any warnings for those.
$ cat test.c
#include
int
On Sat, 9 Nov 2024 11:49:56 -0800
Andrew Pinski wrote:
> You can use the diagnostic pragma to disable it directly for the statement.
Thanks for the tip. After a quick search, I came across this page,
which explains it:
https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
> But I will not
Hello, I don't know if this is a known GCC bug or intentional design,
but code like this:
double value = 0.0;
...
if (value == 0.0)
{
...
}
Results in the following warning with gcc-12.2.0:
"... warning: comparing floating-point with ‘==’ or ‘!=’ is unsafe"
Even though there is nothing
On Wed, 29 May 2024 10:33:16 +0100
Jonathan Wakely wrote:
> > 1. Some GCC binaries hardcode RUNPATH and use
>
> Binaries, or just libraries?
>
I meant GCC shared library binaries. The actual executables under bin/
do not use RUNPATH with GCC default build behaviour.
I think FreeBSD GCC compil
On Wed, 29 May 2024 09:05:50 +0200
Richard Biener wrote:
> If you build an executable to pick up libstdc++ via a RUNPATH that apps
> RUNPATH
> should apply to libgcc as well. If you use LD_LIBRARY_PATH the story
> is the same.
>
> So what's your actual failure mode?
Hello, the concern I have
Hello, I'm noticing some issues with libstdc++ after building GCC from
sources and installing into /opt/gcc-14.1.0. Specifically:
$ objdump -x /opt/gcc-14.1.0/lib/libstdc++.so.6 | grep RUNPATH
$ ldd /opt/gcc-14.1.0/lib/libstdc++.so.6
/opt/gcc-14.1.0/lib/libstdc++.so.6:
libm.so.5 => /lib/l
