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=108128
Bug ID: 108128
Summary: missing -Wshift-overflow warning
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
A
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 };".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105499
Bug ID: 105499
Summary: inconsistency between -Werror=c++-compat and g++ in
__extension__ block
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105499
--- Comment #2 from Vincent Lefèvre ---
(In reply to Eric Gallager from comment #1)
> This is probably another one of those issues with how the preprocessor works
> in C++ mode in general; see for example bug 71003 and bug 87274
Note, however,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498
--- Comment #13 from Vincent Lefèvre ---
Strange. I still get this bug with gcc-11 (Debian 11.3.0-1) 11.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498
--- Comment #14 from Vincent Lefèvre ---
Sorry, I wasn't using -frounding-math (which matters to have the optimization
disabled).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105548
Bug ID: 105548
Summary: -frounding-math description contains an misleading
sentence
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155
Bug ID: 106155
Summary: [12/13 Regression] spurious "may be used
uninitialized" warning
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155
--- Comment #1 from Vincent Lefèvre ---
I detected the issue on tests/tfpif.c with the upgrade of Debian's package
gcc-snapshot from 1:20220126-1 to 1:20220630-1 (it doesn't occur on
tests/tfpif.c with gcc-snapshot 1:20220126-1). However, the si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #21 from Vincent Lefèvre ---
I have a similar issue under Debian/unstable with GCC old of a few months,
where in x86_64-pc-linux-gnu/libstdc++-v3/po, msgfmt fails with an error like
/usr/bin/msgfmt:
/home/vlefevre/software/gcc-build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #26 from Vincent Lefèvre ---
(In reply to Jonathan Wakely from comment #23)
> (In reply to Vincent Lefèvre from comment #21)
> > I suppose that LD_LIBRARY_PATH is set because it is needed in order to use
> > built libraries.
>
> It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #33 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #32)
> The runpath won't work because the libraries are installed yet.
This is what libtool does for GNU MPFR, and this works fine. For instance, when
building tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #35 from Vincent Lefèvre ---
And since the title of this bug was changed to mention that this is related to
the GNU gold linker, there is a runpath bug in this linker that might affect
libtool (perhaps causing it to use LD_LIBRARY_PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #36 from Vincent Lefèvre ---
An alternative solution: for programs that are known to potentially fail due to
built libraries and LD_LIBRARY_PATH, GCC could define wrappers that clean up
LD_LIBRARY_PATH before executing the real progr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #39 from Vincent Lefèvre ---
(In reply to Jonathan Wakely from comment #38)
> (In reply to Vincent Lefèvre from comment #35)
> > (I reported it in 2012, with Jonathan Nieder's patch to fix it, but after 10
> > years, there is still n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
--- Comment #9 from Vincent Lefèvre ---
An update after all these years: As Joseph S. Myers said in the gcc-help list
in February 2005, "even -ffloat-store only deals with assignment, not casts":
https://gcc.gnu.org/pipermail/gcc-help/2005-Februa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
Bug ID: 101773
Summary: errors when writing to .gcda file are not checked
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #2 from Vincent Lefèvre ---
An immediate exit() might yield other files, the terminal, etc. in a bad state.
IMHO, the best thing to do is to stop attempting to write to the file (possibly
attempt to remove it, but this might fail), a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #4 from Vincent Lefèvre ---
GCOV_EXIT_AT_ERROR is not documented in the man page.
Anyway, it doesn't seem to work:
$ export GCOV_EXIT_AT_ERROR=1
$ printenv GCOV_EXIT_AT_ERROR
1
$ gcc-test -O -fprofile-generate=dir tst.c
$ ./a.out
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #6 from Vincent Lefèvre ---
Created attachment 51259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51259&action=edit
added missing error check on fclose in gcc/gcov-io.c
Well, not all errors are detected. There is a missing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #8 from Vincent Lefèvre ---
(In reply to Martin Liška from comment #7)
> May I please install the patch on your behalf?
Yes. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
--- Comment #11 from Vincent Lefèvre ---
In addition to the maximum exponent issue, for LDBL_MAX following the defect
report, instead of
0x1.f78p+1023
I would expect
0x1.f7cp+1023 = DBL_MAX +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
--- Comment #13 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #12)
> That isn't representable in the GCC internal representation, which pretends
> the type has fixed 106 bit precision
[...]
So, if I understand correctly, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
--- Comment #12 from Vincent Lefèvre ---
(In reply to Joseph S. Myers from comment #10)
> There is still a bug for the -fwrapv case, where clearly both INT_MIN / -1
> and INT_MIN % -1 should be well defined, but probably the extra checks
> if imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
--- Comment #14 from Vincent Lefèvre ---
Well, you could change the definition of -fwrapv in the same way that the
standard has changed. I mean that the intent of making INT_MIN / -1 undefined
was *only* for a performance reason (not for a mathem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
--- Comment #16 from Vincent Lefèvre ---
The issue is that the source code assuming -fno-wrapv may be more complex, thus
giving slower generated code. Here's an example, which consists in adding 3
signed integers, for which the user knows that th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102032
Bug ID: 102032
Summary: missed optimization on 2 equivalent expressions when
-fwrapv is not used
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
--- Comment #18 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #16)
> int f (int a, int b, int c)
> {
> if (b < 0)
> return a + b + c;
> else
> return a + c + b;
> }
>
> The generated code with -O3 has 6 instructi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
--- Comment #19 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #17)
> True. The user could have written the following though:
>
> int f (int a, int b, int c)
> {
> return (unsigned)a + b + c;
> }
This code is incorrect,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90411
--- Comment #4 from Vincent Lefèvre ---
For other discussions about this issue, which is the same as in grep:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456943
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15444 (which I already gave in
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=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=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=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=116581
Bug ID: 116581
Summary: incorrect -Wfloat-conversion warnings for int to
_Decimal64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
P
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
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=116690
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
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=68994
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
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=109578
Bug ID: 109578
Summary: fail to remove dead code due to division by zero
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
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=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=114050
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
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=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=114746
Bug ID: 114746
Summary: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast
reduces the precision of floating-point constants
Product: gcc
Version: 14.0
Status: UNCONFIRME
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
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=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 #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
--- 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 #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=112463
Bug ID: 112463
Summary: ternary operator / -Wsign-compare inconsistency
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=576
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Commen
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=109979
Bug ID: 109979
Summary: [12 Regression] -Wformat-overflow false positive for
%d and non-basic expression
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Sever
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011
Bug ID: 110011
Summary: -mfull-toc yields incorrect _Float128 constants on
power9
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Pr
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
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=110374
Bug ID: 110374
Summary: slightly incorrect warning text "ISO C forbids forward
parameter declarations"
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
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
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 #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=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=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=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=106264
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
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=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=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=44677
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
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=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 #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=113540
Bug ID: 113540
Summary: missing -Warray-bounds warning with malloc and a
simple loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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
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=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=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=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=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
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
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=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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117981
Bug ID: 117981
Summary: -Wc11-c23-compat does not warn for bool, false and
true
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
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
--- 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 #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=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
101 - 200 of 212 matches
Mail list logo
