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.
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
On the following C code
void foo (int i)
{
(void) (((float) 0 + (_Decimal64) 0) +
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Due to missing correct rounding in libc, expressions like sin(x) may give
different values at compile time and at
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
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
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
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)
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.
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
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=108128
--- Comment #1 from Vincent Lefèvre ---
Well, with -pedantic, GCC also warns on "enum { A = 1 << 31 };".
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
int *f (void *q)
{
return __extension__ ({ int *p = q; p; });
}
With GCC 11.3.0 under Debian (Debian package
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).
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html has
-frounding-math
Disable transformations and optimizations that
ty: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With "-O -Wmaybe-uninitialized", I get a spurious "may be used uninitialized"
on the foll
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
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When I run a program compiled with -fprofile-generate, this program creates a
.gcda file, but write/close errors
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
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code from bug 30484:
int f (int a, int b, int c)
{
if (b < 0)
return a + b + c;
e
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
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=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
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
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,
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=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
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
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
--- 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.
: 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 #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
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=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
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.
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=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
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=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 =
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=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
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
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
> (
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
401 - 500 of 529 matches
Mail list logo
