https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99707
Bug ID: 99707
Summary: missing -Woverflow in floating-point to integer
conversion for known but non-constant value
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99707
--- Comment #3 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #1)
> Gcc does not know that x will be negative.
Actually, the code should have been (without the volatile):
#include
int main (void)
{
double x = -1.0;
unsig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #16 from Vincent Lefèvre ---
(In reply to Martin Uecker from comment #15)
> I do not think the C standard can be read in a way where reading a variable
> can yield a different value each time (except if the access is UB). For
> unspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99944
Bug ID: 99944
Summary: incorrect maybe-uninitialized warning on variable
defined as an array
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99945
Bug ID: 99945
Summary: missing maybe-uninitialized warning when using a
cleanup function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777
--- Comment #16 from Vincent Lefèvre ---
Well, concerning the initial testcase (and its cleaned-up version), the issue
is either fixed or hidden by another bug, which I've just reported: PR99944.
Indeed, I now get a maybe-uninitialized warning, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99945
--- Comment #2 from Vincent Lefèvre ---
Unless you consider that bug 83382 is actually 2 bugs, this is not a dup. Bug
83382 is about a false positive -Werror=uninitialized error. Do you mean that
it also has a missing -Werror=maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99945
--- Comment #3 from Vincent Lefèvre ---
Note that with gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, I get the same
behavior.
But with gcc-9 (Debian 9.3.0-22) 9.3.0, the warning is missing in the 4 cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99944
--- Comment #2 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #1)
> What's not correct with the diagnostic? The obfuscated printing of f[0]?
Hmm... for the *(unsigned int *)(&f[0]) case, it is correct after all, though
it sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #6 from Vincent Lefèvre ---
On the test on godbolt, this is still failing with:
gcc (Compiler-Explorer-Build) 12.0.0 20210420 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97568
Bug ID: 97568
Summary: -fanalyzer assumes that an extern const pointer is
NULL
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97568
--- Comment #1 from Vincent Lefèvre ---
The bug has been introduced by commit af66094d037793773eb8a49597866457f2f6a104.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97608
Bug ID: 97608
Summary: -Wanalyzer-malloc-leak false positive when returning
p+1 instead of p
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97608
--- Comment #4 from Vincent Lefèvre ---
Thanks. There's no longer any issue when testing GNU MPFR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
Bug ID: 97939
Summary: ICE on sparc64 with UBsan for "i + 4096" on long:
unrecognizable insn during RTL pass: vregs
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #1 from Vincent Lefèvre ---
I forgot: That's a Debian sid machine with
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc64-linux-gnu/10/lto-wrapper
Target: sparc64-linux-gnu
Configured with: ../src/configur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #7 from Vincent Lefèvre ---
For i + 4095:
add %g1, 4095, %g1
For i + 4096:
sub %g1, -4096, %g1
For i + 4097:
sethi %hi(4195328), %g1
srlx%g1, 10, %g1
add %g2, %g1, %g1
SP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #8 from Vincent Lefèvre ---
But note that there is no issue with -fsanitize=undefined on
return i - (-4096);
So the cause is the transformation of i + 4096 to i - (-4096).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98029
Bug ID: 98029
Summary: volatile triggers incorrect "warning: right-hand
operand of comma expression has no effect
[-Wunused-value]"
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
Bug ID: 98447
Summary: incorrect -Wanalyzer-shift-count-overflow warning
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #1 from Vincent Lefèvre ---
This is probably due to commit 5e00ad3ffbfb4df7242c313a0d836f5b538eb2fb (where
this warning was introduced, as requested by PR97424).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97424
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #2 from Vincent Lefèvre ---
Note: The warning occurs when the compiler knows that b < 63 in the "if" case
(it occurs up to "n = r % 64", but not with "n = r % 65") so that the condition
"b + 1 >= 64" is always false. I suppose that th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #3 from Vincent Lefèvre ---
And the warning is triggered with the initial "b = 63", but not "b = 62" and
smaller values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #4 from Vincent Lefèvre ---
So this can be simplified to
void f (unsigned long *p, int r, int i)
{
int b = 64, n = r % 64;
while (i >= 0 && b >= 0)
{
if (b <= n)
p[i--] = 1UL << b;
b -= n;
}
}
Here,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #5 from Vincent Lefèvre ---
This is still failing (trunk). The test on godbolt:
https://godbolt.org/z/Yx7b1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60759
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60759
--- Comment #7 from Vincent Lefèvre ---
(In reply to Manuel López-Ibáñez from comment #6)
> I believe this is on purpose to avoid too much noise. The warning in GCC
> needs to be smarter about types and macros and avoid early folding.
Well, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99014
Bug ID: 99014
Summary: -Werror -Wno-foo with foo unrecognized results in an
error if another warning is emitted
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713
--- Comment #2 from Vincent Lefèvre ---
This also works with: gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101090
Bug ID: 101090
Summary: incorrect -Wunused-value warning on remquo with
constant values
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101125
Bug ID: 101125
Summary: warn when a construct would become invalid if a
function were replaced by a function-like macro
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101125
--- Comment #2 from Vincent Lefèvre ---
Even though GCC support fast inline functions, some libraries may still use
function-like macros. In particular, this is still the case with glibc (e.g.
pthread_cleanup_pop).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #26 from Vincent Lefèvre ---
(In reply to Matthias Kretz (Vir) from comment #25)
> (In reply to Piotr Engelking from comment #24)
> > It would be nice if the compiler noticed that rhs is always within
> > 0..SHRT_MAX, so the compariso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #28 from Vincent Lefèvre ---
(In reply to Matthias Kretz (Vir) from comment #27)
> Fair enough. But how can the compiler be certain that the developer realized
> u and u % 100 is unsigned? Maybe when (s)he wrote the code the expectati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #30 from Vincent Lefèvre ---
(In reply to Matthias Kretz (Vir) from comment #29)
> Right. But if that's the case wouldn't a warning about the unexpected
> promotion be useful? (which -Wsign-compare happens to provide)
Yes, and FYI, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #8 from Vincent Lefèvre ---
Isn't it the same as PR56020, which is due to the fact that the STDC
FENV_ACCESS pragma is not implemented and assumed to be OFF (PR34678)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108466
Bug ID: 108466
Summary: inconsistent -Wmaybe-uninitialized warning location
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108467
Bug ID: 108467
Summary: false positive -Wmaybe-uninitialized warning at -O1 or
higher
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #11 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #8)
> (In reply to comment #6)
> > Er, if you want to find portability problems for people not using C99 then
> > don't use -std=c99. Then -Wreturn-type warns abou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #14 from Vincent Lefèvre ---
Anyway, as I said initially, the warning would be interesting even in C99+
mode, because the lack of a return statement may be unintentional. For
instance, the developer may have forgotten a "return err;".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #16 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #15)
> But much more often it is intentional than unintentional.
That's the same thing for many kinds of warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #18 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #17)
> Yeah, but warnings with high false positivity rates at least shouldn't be in
> -Wall.
Well, there already is -Wunused, which is included in -Wall (such warni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108700
Bug ID: 108700
Summary: false _Noreturn error with
-Werror=old-style-declaration
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108700
--- Comment #2 from Vincent Lefèvre ---
And there's the same issue with "inline" instead of "_Noreturn" (these are the
only two function specifiers).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #7 from Vincent Lefèvre ---
On https://godbolt.org/z/Yx7b1d this still fails with "x86-64 gcc (trunk)".
Moreover, several releases are affected: 11.1, 11.2, 11.3, 12.1, 12.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104677
Bug ID: 104677
Summary: With -fprofile-arcs, the name of the .gcda file is
incorrect
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104677
Vincent Lefèvre changed:
What|Removed |Added
Summary|With -fprofile-arcs, the|Please update documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104690
Bug ID: 104690
Summary: UBSan does not detect undefined behavior on function
without a specified return value
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104690
--- Comment #2 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #1)
> It requires that the callee tells the caller that it reached end of non-void
> function without return and the callee checks if the value is actually used
> th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
--- Comment #21 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #16)
> As for constant folding, even with double double gcc is able to fold some
> constant arithmetics in that format, but because the emulation is only
> approxima
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56281
--- Comment #5 from Vincent Lefèvre ---
I've clarified the bug title to say that this is a range on the first operand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
--- Comment #17 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #16)
> Note for shifts the precision of the shift operand does not have to match
> that of the shifted operand. In your case you have vector << scalar, so you
> de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
--- Comment #19 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #18)
> Sure, if that's what the precision is used for. The message from Andrew
> sounded like 'I want the precision for the shift operand but let me
> just use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106165
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93902
--- Comment #3 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #2)
> foo3 is more complex because x86 does not have an unsigned long 64bit to
> double so it has to do some more complex.
But the point is that GCC shouldn't do the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #9 from Vincent Lefèvre ---
(In reply to Aldy Hernandez from comment #6)
> As I've mentioned, I'm hoping some floating expert can take this across to
> goal line, as my head will start spinning as soon as we start talking about
> NANs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #10 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #9)
> Subnormals might also need to be considered as special cases: "Whether and
> in what cases subnormal numbers are treated as zeros is implementation
> defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #14 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #11)
> And also take into account different rounding modes if
> user wants that to be honored.
And that would eliminate the need to consider the possibility of doub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #18 from Vincent Lefèvre ---
I'm wondering whether it is possible to check on actual code what is needed.
For instance, assume that you have a program that produces always the same
results, e.g. by running it over a fixed dataset. GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #13 from Vincent Lefèvre ---
If the default state of these pragmas (at least with options like -std=c11) is
respectively "off", "on", "off", then changing the pragma state can safely be
ignored by the implementation, as implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103123
Bug ID: 103123
Summary: incorrect or misleading warning "floating constant
exceeds range of ..." in ISO C11 and C17
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103123
--- Comment #4 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #1)
> This is warning and can be turned off, -Woverflow is on by default.
The warning can be turned off, but there are 2 issues:
1. The message "floating constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103123
--- Comment #5 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #3)
> Clang produces:
> :4:10: warning: magnitude of floating-point constant too large for
> type 'double'; maximum is 1.7976931348623157E+308 [-Wliteral-range]
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #15 from Vincent Lefèvre ---
(In reply to Pavel M from comment #14)
> The "warning: ignoring '#pragma STDC FENV_ACCESS' [-Wunknown-pragmas]"
> probably needs to be generated by default
Getting the warning on "#pragma STDC FENV_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #17 from Vincent Lefèvre ---
(In reply to Pavel M from comment #16)
> Note: The #pragma STDC FENV_ACCESS is unknown and ignored (leading to FP
> issues), however, the __STDC_IEC_559__ is defined to 1. Confused.
Yes, and IMHO, with __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186
--- Comment #6 from Vincent Lefèvre ---
OK, so I think there is a bug in the autotools, which use -I instead of
-isystem (unless this has changed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
Bug ID: 102126
Summary: Wrong optimization of multiplication by 1 and -1 with
-ftrapping-math when an underflow is possible
Product: gcc
Version: 11.2.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #1 from Vincent Lefèvre ---
Division by 1 and -1 is affected too (as being equivalent to multiplication).
Note that F.9.2 "Expression transformations" in ISO C17 says:
1 × x and x/1 → x The expressions 1 × x, x/1, and x are e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #2 from Vincent Lefèvre ---
In the testcase, I forgot
#pragma STDC FP_CONTRACT OFF
Anyway, it is currently ignored by GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #4 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #3)
> You can use -ffp-contract=off but I don't think these transforms are
> affected.
I confirm that the test behaves in the same way with -ffp-contract=off too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129
Bug ID: 102129
Summary: -ftrapping-math is broken or badly documented
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129
--- Comment #1 from Vincent Lefèvre ---
Additional surprising behavior...
On the following C code:
void g (void);
double f (void)
{
double x = 0.0, y = 0.0;
double r = x / y;
g ();
return r;
}
one can see with -ftrapping-math (the def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129
--- Comment #3 from Vincent Lefèvre ---
Implementation details about trap enablement is outside the scope of ISO C, but
the existence of traps is explicitly allowed by Annex F (when supported). F.8
says: "It includes also IEC 60559 dynamic round
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #7 from Vincent Lefèvre ---
According to the current documentation, -f(no-)trapping-math is only about
traps, not flags.
And Glibc provides functions feenableexcept and fedisableexcept to enable and
disable traps, so that their poss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #12 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #11)
> x86 has _addcarry_u64 which gets it mostly (see PR 97387).
>
> The clang builtins __builtin_*_overflow are there but not the __builtin_add*
> builtins.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102475
Bug ID: 102475
Summary: incorrect definition of "normal" long doubles in
libgcc/config/rs6000/ibm-ldouble-format
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498
--- Comment #1 from Vincent Lefèvre ---
A testcase without printf:
#include
#define X 0xc.90fdaa22168c235p-2l
#define Y 0xc.90fdaa22168c234p-2l
int main (void)
{
volatile long double x, y;
fesetround (FE_TOWARDZERO);
x = X;
y = Y;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498
--- Comment #3 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 51512 [details]
> gcc12-pr102498.patch
I could test that this fixes the issue on my testcase at Comment 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498
--- Comment #5 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #4)
> A regression since GCC 3.2 (r0-47863-g881b2a9652748ad).
Always reproducible with GCC 5. But with GCC 4.7 to 4.9, it seems that one
needs -O1 to get fldpi gene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498
--- Comment #7 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #6)
> Here is a testcase which shows it can be reproduced all the back to GCC
> 4.1.2 even:
[...]
> f(0);
> }
OK, with "return" before "f(0);".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87447
--- Comment #3 from Vincent Lefèvre ---
This is probably related to the == operator (and other ones), since gcc warns
on the following codes:
double foo (void)
{
double x = (1ULL << 63) + 1;
return x;
}
and
double foo (void)
{
return (1U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87447
--- Comment #4 from Vincent Lefèvre ---
After some tests, only the comparison operators seem to be affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102924
Bug ID: 102924
Summary: incorrect output for error "cannot mix operands of
decimal floating and other floating types"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
Bug ID: 102930
Summary: equal values appear to be different due to missing
correct rounding in libc
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
--- Comment #1 from Vincent Lefèvre ---
I forgot some information: Debian unstable currently has libc6 2.32-4, where
IBM's code for correct rounding was disabled some time ago. This bug might be
unreproducible with other glibc versions (or other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
--- Comment #3 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #2)
> I think there is nothing that can be done about this, and something like
> this has been there since forever. While perhaps some double routines in
> glibc us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95148
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105499
--- Comment #5 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #4)
> __extension__ disables all compatibility warnings.
>
> This is by design really as headers sometimes needs to be written using C
> code and need to turn off t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105499
--- Comment #6 from Vincent Lefèvre ---
To be clear... I'm not sure about what kind of compatibility warnings one can
get, but it is OK to silence valid extensions, i.e. those that will not give an
error. But invalid extensions, i.e. those that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105499
--- Comment #8 from Vincent Lefèvre ---
It is bad that __extension__ does two completely different things:
1. Disable warnings associated with GNU extensions, like ({ ... }).
2. Disable compatibility warnings that do not correspond to GNU extens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #8 from Vincent Lefèvre ---
Indeed, compared to GCC 12.2.0, the trunk no longer warns on the simple
testcase I provided. However, I cannot see any change of the warnings on my
original file (to myself: tmd/binary32/hrcases.c), except
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #10 from Vincent Lefèvre ---
(In reply to Jeffrey A. Law from comment #9)
> These warnings are certainly sensitive to all kinds of things, so it's
> possible it's just gone latent. The only way to be sure would be to bisect
> all the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106754
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107838
Bug ID: 107838
Summary: spurious "may be used uninitialized" warning on
variable initialized at the first iteration of a loop
Product: gcc
Version: 13.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
Bug ID: 107839
Summary: spurious "may be used uninitialized" warning while all
uses are under "if (c)"
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155
--- Comment #10 from Vincent Lefèvre ---
A similar bug (all uses of the variable are under some condition) with a
simpler testcase I've just reported: PR107839.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #12 from Vincent Lefèvre ---
(In reply to Jeffrey A. Law from comment #11)
> As I said in my previous comment, the best way forward is to get those two
> new instances filed as distinct bugs in BZ.
See PR107838 and PR107839.
1 - 100 of 212 matches
Mail list logo
