https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677
--- Comment #19 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #18)
> *** Bug 119544 has been marked as a duplicate of this bug. ***
The example in this bug was
extern char* str;
void foo(void)
{
int i = 0;
while (*s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #24 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #23)
> IMHO -fexcess-precision=16 (at least on x86_64 64-bit and with -mfpmath=sse
> -msse2 32-bit too) are completely conformant modes,
If this is the intent, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #22 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #21)
> What C23 documents applies *only* when -fexcess-precision=standard, as this
> is the only -fexcess-precision value for which GCC is documented to be
> conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #21 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #20)
> C23 documents it in detail, and so does float.h:
[...]
> So, only __FLT_EVAL_METHOD_TS_18661_3__ should be possibly 16 for
> -fexcess-precision=16.
What C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #19 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Vincent Lefèvre from comment #17)
> > 2 is more accurate. Note that -1 would not make GCC conforming with
> > -fexcess-precision=fast.
>
> -fex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #17 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #16)
> 2 is of course the right value for -fexcess-precision=standard -m32 on x86
So, it is not meant to affect __FLT_EVAL_METHOD__. FYI, -fexcess-precision has
be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #15 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Vincent Lefèvre from comment #13)
> > -fexcess-precision is not meant to have an effect on __FLT_EVAL_METHOD__,
>
> No, -fexcess-precision= is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #13 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #7)
> Though, I think we should predefine __FLT_EVAL_METHOD__ to 16 rather than 0
> for -fexcess-precision=16.
-fexcess-precision is not meant to have an effect on
: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/cpp/Macros.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681
--- Comment #5 from Vincent Lefèvre ---
Note that this is also reproducible with:
--
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static double opaqu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #15 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #14)
> (In reply to Jakub Jelinek from comment #4)
> > If you want to compare against all ones time_t, just use ~(time_t)0 or
> > similar.
>
> This one is a bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #14 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #4)
> If you want to compare against all ones time_t, just use ~(time_t)0 or
> similar.
This one is a bad idea as it may have issues with signed types (when not in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #11 from Vincent Lefèvre ---
(In reply to Alejandro Colomar from comment #10)
[about i + 1 == 0 instead of i == -1]
> But this causes readability issues. For error-handling, programmers are
> used to writing ==-1, and doing +1==0 wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #12 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #9)
> The reason for extended precision by default for _Float16 (and __bf16) on
> x86 (and most of other targets, I think RISC-V is an exception) is lack of
> hw su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #8 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #6)
> I don't think that is true.
Indeed, it seems that I did some mistake when searching the standard, which is
a bit contradictory about the case FLT_EVAL_METHOD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117981
--- Comment #1 from Vincent Lefèvre ---
Actually this might not be the goal of this option. It is documented as
Warn about features not present in ISO C11, but present in ISO C23.
Here, the issue is due to a feature not present in ISO C11, b
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
int f (void)
{
int bool = 3;
int false = 4;
int true = 5;
return bool + false + true;
}
Compiling with "-Wc11-c23-comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94337
--- Comment #4 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #3)
> * If the effective type remains the same (a union), then using any pointer
> cast to another type would be invalid, but this could be unintuitive and
> break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94337
--- Comment #3 from Vincent Lefèvre ---
Hmm... The code might actually be invalid, but I'm not sure. In all the
accesses, the effective type is the union type. But the C standard does not say
what happens when one takes the member of a union type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116885
--- Comment #11 from Vincent Lefèvre ---
(In reply to Jaroslav Fojtík from comment #9)
> Accessing to an incompatible type throug pointer is not clean in general.
> But I need here to do a dirty job to flip endianity of double type. There
> are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116885
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
--- Comment #22 from Vincent Lefèvre ---
(In reply to Florian Weimer from comment #21)
> (In reply to Jakub Jelinek from comment #20)
> > It is not that easy. __STDC_NO_THREADS__ is a predefined macro, so it would
> > mean (at least on targets w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
--- Comment #19 from Vincent Lefèvre ---
(In reply to Florian Weimer from comment #18)
> (In reply to Vincent Lefèvre from comment #17)
> > (In reply to Jonathan Wakely from comment #16)
> > > As explained above, this is not something that can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
--- Comment #17 from Vincent Lefèvre ---
(In reply to Jonathan Wakely from comment #16)
> As explained above, this is not something that can be fixed in GCC.
I'm wondering why this bug was marked as FIXED, then. This is misleading.
> The macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104690
--- Comment #3 from Vincent Lefèvre ---
Well, I can understand that this may be difficult in some cases. For instance:
static int f (void) { if (complex_condition_1) return 1; }
and used with
if (complex_condition_2)
printf ("%d\n", f (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116690
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116581
--- Comment #2 from Vincent Lefèvre ---
And the warnings disappear if I change 1 to 1.0 in the testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116581
--- Comment #1 from Vincent Lefèvre ---
I forgot: gcc-snapshot is currently:
gcc (Debian 20240829-1) 15.0.0 20240829 (experimental) [master
r15-3282-g4ff4875a79c]
This bug was still present in GCC 8.4.0 (same messages). With GCC 4.9, 5 and 6,
I
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
GCC emits incorrect -Wfloat-conversion warnings for int to _Decimal64 (this
makes the configure script of GNU MPFR fail when using
-Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60846
--- Comment #11 from Vincent Lefèvre ---
Note that passing 128-bit types or larger is already supported on 32-bit arch:
a struct or a union is such a type, and there's also _Decimal128 for the
128-bit size. So, isn't the ABI already defined? (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108467
--- Comment #4 from Vincent Lefèvre ---
(In reply to Sam James from comment #3)
> For 14/15, it seems gone with -O2, but I see it with -Og.
The warning still occurs with -O1 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #7 from Vincent Lefèvre ---
BTW, in /usr/include/math.h from the GNU libc 2.37:
# define M_PI 3.14159265358979323846 /* pi */
i.e. M_PI is defined with 21 digits in base 10, which corresponds to about 70
digits in base 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #6 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #5)
> FLT_EVAL_METHOD = 0 is on some hw like the pre-SSE2 ia32 extremely
> expensive, far more so than even the very expensive -ffloat-store. That is
> certainly no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #4 from Vincent Lefèvre ---
I actually find it more confusing the fact that constants are not evaluated in
extended precision while everything else is evaluated in extended precision.
The real solution to avoid confusion would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
Vincent Lefèvre changed:
What|Removed |Added
Summary|With FLT_EVAL_METHOD = 2, |With FLT_EVAL_METHOD = 2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #1 from Vincent Lefèvre ---
There is the same issue with constant floating-point expressions.
Consider the following program given at
https://github.com/llvm/llvm-project/issues/89128
#include
#include
static double const_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #17 from Vincent Lefèvre ---
(In reply to Jonathan Wakely from comment #13)
> -fexcess-precision does affect constants.
Indeed, and this is a bug, as -fexcess-precision=fast was not meant to make
general programs less accurate (but
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
-fexcess-precision was added to resolve bug 323, so that with
-fexcess-precision=standard, after an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #16 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #15)
> There is no bug, the compiler implements what the standard says for the
> FLT_EVAL_METHOD == 2 case.
I agree. I meant this *invalid* bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #14 from Vincent Lefèvre ---
This bug is about "double/float constant evaluation" (and it has been marked as
a duplicate of a bug precisely on this subject), not about the rules that are
applied *after* this evaluation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #48 from Vincent Lefèvre ---
(In reply to Alexander Cherepanov from comment #35)
> DR 260 allows one to argue that representation of these pointers could
> change right between the checks but IMHO this part of DR 260 is just wrong
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113540
--- Comment #2 from Vincent Lefèvre ---
Thanks for the explanations, but why in the following case
void foo (void)
{
volatile char t[4];
for (int i = 0; i <= 4; i++)
t[i] = 0;
return;
}
does one get the warning (contrary to the use o
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code:
#include
int main (void)
{
volatile char *t;
t = malloc (4);
for (int i = 0; i <= 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #12 from Vincent Lefèvre ---
(In reply to Segher Boessenkool from comment #11)
> Sure. If people want the pain, they can have it. But it is never okay to
> cause other people to have -Werror -- they may have a different compiler
> (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #6 from Vincent Lefèvre ---
BTW, note that some code may be generated (instead of being written by a
human). So having some code style being an error by default would be very bad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #5 from Vincent Lefèvre ---
Note that -Wall -Werror seem to be fine in general when they are used alone,
but this combination can be very problematic when other options are used, such
as -std=c90 -pedantic, and other warnings. So defa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=576
--- Comment #7 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #6)
> That is because the code is GNU C90 and not C++ .
I've used gcc, not g++. But this fails even with -std=gnu90.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=576
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112463
--- Comment #3 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #2)
> One problem with -Wsign-conversion is that it is not enabled with
> -Wextra/-Wall .
However, I don't understand why -Wsign-compare is enabled by -Wextra but n
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
-Wsign-compare is described in the man page as follows:
-Wsign-compare
Warn when a comparison between signed and unsigned values could
produce an incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56281
--- Comment #6 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #1)
> Given the amount of code in the wild that assumes 1 << 31 etc. work, I think
> it would be a bad idea to try to optimize this for C99, especially when it
> is n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102032
--- Comment #4 from Vincent Lefèvre ---
Note that as said in PR111560 comment 6, re-association may break CSE, e.g. if
there are also a + b + d and a + c + e with my example. So, re-association for
global optimal CSE, in addition to being diffic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981
--- Comment #9 from Vincent Lefèvre ---
Note, however, that there is a small regression in GCC 11: the warning for t is
output as expected, but if -fsanitize=undefined is given, the message for t is
suboptimal, saying "*&t[0]" instead of "t[0]":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95057
--- Comment #6 from Vincent Lefèvre ---
Well, for the ++, --, +=, -=, *=, etc. operators, that's PR44677 (though it is
unclear on what it should cover).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95057
--- Comment #5 from Vincent Lefèvre ---
FYI, Clang 16 does not warn either on the testcases provided in comment 0 (bug
report).
But contrary to GCC (tested with master r14-1713-g6631fe419c6 - Debian
gcc-snapshot package 20230613-1), Clang 15 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101090
--- Comment #3 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #2)
> So, has this bug been fixed (and where)?
This seems to be a particular case of PR106264, which was fixed in commit
r13-1741-g40f6e5912288256ee8ac41474f2dce7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101090
--- Comment #2 from Vincent Lefèvre ---
On Debian, I get a warning from GCC 9 to GCC 12 (Debian 12.3.0-6), but neither
with GCC 13 (Debian 13.1.0-8) nor with 14.0.0 20230612 (Debian 20230613-1).
So, has this bug been fixed (and where)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #228 from Vincent Lefèvre ---
PR64410 and PR68180 should also be removed from "See Also".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #227 from Vincent Lefèvre ---
In "See Also", there are several bugs that are related only to vectorization
optimizations. What is the relation with this bug?
For instance, PR89653 is "GCC (trunk and all earlier versions) fails to
vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #32 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #31)
> (In reply to Vincent Lefèvre from comment #30)
> > (In reply to Jakub Jelinek from comment #29)
> > > I mean that if the compiler can't see it is in [0, 1], i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #30 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #29)
> (In reply to Vincent Lefèvre from comment #28)
> > What do you mean by "the first additions will be less optimized"? (If you
> > don't know anything about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #28 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #27)
> Given that the builtins exist for 10 years already, I think changing it for
> them is too late, though they don't seem to take backwards compatibility as
> se
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With -pedantic, on
int f(int n; int n) { return n; }
I get:
tst.c:1:1: warning: ISO C forbids forward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155
--- Comment #12 from Vincent Lefèvre ---
Here's a similar, simpler testcase:
int f1 (void);
void f2 (int);
long f3 (long);
void tst (void)
{
int badDataSize[3] = { 1, 1, 1 };
for (int i = 0; i < 3; i++)
{
int emax;
if (i =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011
--- Comment #4 from Vincent Lefèvre ---
(In reply to Kewen Lin from comment #3)
> Thanks for reporting, this exposes one issue that: when encoding KFmode
> constant into toc, it uses the format for the current long double, it could
> be wrong if
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Note: I selected version 8.3.1, because this is what I had for my tests, but at
least 13.1.0 is still affected (see below).
We got a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979
--- Comment #5 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #1)
> The warning should happen for both ...
OK (as the documentation says "[...] that might overflow the destination
buffer).
(In reply to Richard Biener from com
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
#include
void f (int *);
void g (void)
{
int e;
char s[4];
f (&e);
sprintf (s, &qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699
--- Comment #12 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #11)
> Since GCC 11 which is correct now.
I confirm.
> That changed after r11-1504-g2e0f4a18bc978 for the improved minmax
> optimization.
The bug has been resolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
--- Comment #4 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #3)
> Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed
> later on that GCC didn't realize divide could trap.
OK, thanks, I can see your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
--- Comment #2 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #1)
> We don't removing code before undefined behavior ...
> That is GCC does not know that printf does not have side effects.
Then GCC is incorrect in bug 29968,
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
This is about the opposite of the invalid bug 29968:
#include
int f (int i, int k)
{
if (k == 0)
printf ("k = 0\n");
return i/k;
}
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745
--- Comment #14 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #13)
> GCC removed the pedwarning on purpose (between GCC 4.1 and 4.4), see PR
> 14331 and PR 68994.
No, PR 14331 was just asking to remove the warning by default,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68994
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
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=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).
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With gcc-12 (Debian 12.2.0-14) 12.2.0 (but this error was already present in
GCC 4.8):
cventin% echo 'int _Noreturn does_not_return
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=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 #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 #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
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code, derived from MPFR's sub1sp.c (where the issue
occurred since at least GCC 4.9.4 an
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With gcc-12 (Debian 12.2.0-14) 12.2.0, the -Wmaybe-uninitialized warning
location depends on the declared type. This is inconsistent.
To reproduce, consider a tst.c
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=108128
--- Comment #1 from Vincent Lefèvre ---
Well, with -pedantic, GCC also warns on "enum { A = 1 << 31 };".
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following C program:
#include
enum { A = 1 << 31 };
int main (void)
{
printf ("%d\n", A);
printf ("%d\n", 1 << 31);
printf ("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
--- Comment #3 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #2)
> it's loop invariant motion that hoists the v + v compute out of the loop
> and thus outside of its controlling condition. You can see it's careful
> to not i
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.
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.
D
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
int f (int);
void g (int c)
{
int v;
if (c)
v = f(0);
while (1)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
int f(void);
void g(int *t)
{
int i, v;
for (i = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106754
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
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
1 - 100 of 529 matches
Mail list logo
