http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56020
Bug #: 56020
Summary: FE_INVALID flag not set on comparison with NAN
(unordered)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #20 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
I suppose that for any 54-bit[*] odd integer multiplied by a power of two with
a large exponent (in absolute value), some decimal numbers close to this value
will be affected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #21 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Paolo Carlini from comment #19)
If I change fold_builtin_logarithm to pass a true as last argument to
do_mpfr_arg1 (thus 0 is accepted) and do_mpfr_ckconv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #22 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Paolo Carlini from comment #20)
Thus I clearly realize something: if we do better for mpfr, the issue
remains that if we do *not* optimize and constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #21 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #20)
Richard Biener's approach to the default is the one that matches the C
standard and Vincent Lefèvre is mistaken.
No, I'm correct
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
With:
* gcc-4.8 (Debian 4.8.2-5) 4.8.2
* gcc (Debian 20131021-1) 4.9.0 20131021 (experimental) [trunk revision 203899]
It seems that -Wmaybe-uninitialized works
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
--- Comment #18 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
This seems to be fixed in the trunk.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
With:
* gcc-4.8 (Debian 4.8.2-5) 4.8.2
* gcc (Debian 20131021-1) 4.9.0 20131021 (experimental) [trunk revision 203899]
xvii:~ cat tst1.c
int foo (int x)
{
int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
--- Comment #22 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Manuel López-Ibáñez from comment #19)
(In reply to Vincent Lefèvre from comment #18)
This seems to be fixed in the trunk.
Is there an XPASS for gcc.dg/uninit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
--- Comment #23 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
BTW, I suppose that in this test, -Wuninitialized should be changed to
-Wuninitialized -Wmaybe-uninitialized in case it is decided later that
-Wuninitialized no longer enables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
--- Comment #26 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Manuel López-Ibáñez from comment #25)
I don't see any reason for -Wuninitialized to not enable
-Wmaybe-uninitialized.
I can see 3 kinds of use:
1. Users who
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54615
Bug #: 54615
Summary: unclear documentation on -fomit-frame-pointer for -O
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145
--- Comment #8 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-11-04
23:43:44 UTC ---
(In reply to comment #7)
Here are different internal values from the same input:
32-bit long: 1.57079632679489661925640447970309310221637133509
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #12 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-11-05
00:16:32 UTC ---
(In reply to comment #11)
Really I'd consider this just a variant on bug 21718 (real.c rounding not
perfect). That would ideally be fixed by using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #14 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-11-05
08:12:08 UTC ---
Otherwise, how about taking code from the glibc implementation of
strtof/strtod/strtold? Code in strtod was recently fixed. I don't know about
strtold...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56281
Bug #: 56281
Summary: missed VRP optimization from undefined left shift in
ISO C99
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56281
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #16 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2013-04-17
08:40:09 UTC ---
(In reply to comment #3)
A way to tell gcc a variable is not uninitialized is to perform
self-initialization like
int i = i;
this will cause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #20 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2013-04-17
11:17:14 UTC ---
(In reply to comment #18)
In fact, we should have removed the i=i idiom a long time ago. The correct
thing to do (as Linus says) is to initialize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #23 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2013-04-17
12:24:56 UTC ---
(In reply to comment #21)
When an unrecognized warning option is requested (e.g., -Wunknown-warning),
GCC
will emit a diagnostic stating
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #24 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2013-04-17
12:34:40 UTC ---
BTW, since with the latest GCC versions (such as Debian's GCC 4.7.2), the
warning is no longer issued with -Wno-maybe-uninitialized, perhaps the bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57029
Bug #: 57029
Summary: GCC doesn't set the inexact flag on inexact
compile-time int-to-float conversion
Classification: Unclassified
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57029
--- Comment #3 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2013-04-22
13:32:10 UTC ---
(In reply to comment #2)
There is -ftrapping-math, which I think is supposed to have an effect here.
And
if this was implemented properly, I hope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52639
--- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-04-24
13:22:08 UTC ---
Same problem here under Debian/unstable (x86_64), with:
gcc-snapshot -O3 -march=native -std=gnu99 -c ice-setf.i
and the testcase below, using:
gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52639
--- Comment #8 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-04-24
23:58:06 UTC ---
I confirm that rebuilding gcc-snapshot with the patch
http://gcc.gnu.org/viewcvs?view=revisionrevision=186272 for PR
tree-optimization/52870 solves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53182
Bug #: 53182
Summary: GNU C: attributes without underscores should be
discouraged / no longer be documented e.g. as examples
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
Bug #: 53232
Summary: No warning for main() without a return statement with
-std=c99
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-05-04
15:44:04 UTC ---
(In reply to comment #4)
IMHO this isn't a bug because in C99 it's well-defined what happens if you
fall
off the end of main,
Only at program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #8 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-05-04
19:58:01 UTC ---
(In reply to comment #6)
Yes, and in each case some people want it and some don't. I'm pointing out to
Manu the reasons not everyone wants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
--- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-06-25
22:37:22 UTC ---
But what if a recent glibc version isn't used?
Would GCC still be able to compile the following code?
int main (void)
{
#if __STDC_VERSION__ = 201112L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
--- Comment #4 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-06-26
05:17:31 UTC ---
(In reply to comment #3)
Such a test is not meaningful for documented incomplete support; in the
absence of claims of conformance, __STDC_VERSION__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789
Bug #: 53789
Summary: ICE in gen_reg_rtx, at emit-rtl.c:864/865 when
compiling GNU MPFR on parisc
Classification: Unclassified
Product: gcc
Version: 4.4.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789
--- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-07-05
14:55:52 UTC ---
(In reply to comment #1)
Please try with a version of GCC that is still maintained.
This is currently not possible due to bug 53270.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789
--- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-07-07
00:30:40 UTC ---
(In reply to comment #1)
Please try with a version of GCC that is still maintained.
I can't reproduce the bug with GCC trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915
Bug #: 53915
Summary: gcov -f rounding problem
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915
--- Comment #1 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-07-10
14:27:28 UTC ---
The problem is probably in gcc/gcov.c, function format_gcov, which has:
float ratio = bottom ? (float)top / bottom : 0;
int ix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915
--- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-07-10
14:46:28 UTC ---
Actually this should not be the problem, because if top = bottom = 9, then the
division is done exactly anyway; moreover percent = limit - 1; won't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Summary|gcov -f rounding problem|gcov can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #12 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Marc Glisse from comment #9)
I believe there are far fewer special cases (and thus
risks) with MPFR, but that would indeed require a suitable testsuite for all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #13 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
A difference that may occur in the future if the C library adds a rsqrt
function (based on the IEEE 754-2008 rSqrt function) or constant folding is
used on builtins: in MPFR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #4 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
I can see the same problem under Linux (gcc110.fsffrance.org).
According to the C standard (C99 and C11), the *_EPSILON values are the
difference between 1 and the least value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Vincent Lefèvre from comment #4)
I can see the same problem under Linux (gcc110.fsffrance.org).
In case this wasn't clear, the architecture is also a PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #7 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
Certainly not: IRIX isn't PowerPC but MIPS!
OK, that wasn't clear because the original but report mentioned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #15 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
If GCC intends to handle Bessel functions j0, j1, jn, y0, y1, yn (POSIX), there
may be differences with GNU MPFR. See my messages and bug report:
http://permalink.gmane.org
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
On gcc110.fsffrance.org:
$ cat ./decimal64.c
#include stdio.h
int main(void)
{
_Decimal64 x = 1;
if (x != x)
{
printf (Error
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
When I build GMP with
GNU MP config.status 5.1.2
configured by ./configure, generated by GNU Autoconf 2.69,
with options '--disable-shared' 'CC=gcc-snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58485
--- Comment #1 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
I forgot:
Version: GNU MP 5.1.2
Host type: coreinhm-unknown-linux-gnu
ABI: 64
Install prefix:/usr/local
Compiler: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58485
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #17 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
I confirm that it is an architecture-dependent bug. I can't reproduce any error
with your test program on
http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786
--- Comment #11 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Manuel López-Ibáñez from comment #10)
So what is missing here? Can we close this or not yet?
I've tested that -fno-sanitize-recover works correctly with gcc
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
The current -fdelete-null-pointer-checks documentation is:
Assume that programs cannot safely dereference null pointers, and that no
code or data element
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
When writing int d = some_signed_constant;, one expects a -Woverflow warning
if some_signed_constant INT_MAX, but one actually gets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #24 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #23)
If __STDC_IEC_559__ is unset or does not have the value 1, setting
STDC FENV_ACCESS to on is undefined behaviour (see 6.10.8.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #26 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #25)
3.4.3 says:
undefined behavior
behavior, upon use of a nonportable or erroneous program construct
or of erroneous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #28 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #27)
On Jan 14 2014, vincent-gcc at vinc17 dot net wrote:
The FENV_ACCESS pragma provides a means to inform the implementation when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #30 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #29)
It is not an explicit definition of BEHAVIOR (my emphasis),
The pragma is just a directive. It has no additional behavior, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59753
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59753
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59753
--- Comment #6 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Manuel López-Ibáñez from comment #5)
(In reply to Vincent Lefèvre from comment #4)
There's still an inconsistency without -Wpedantic, which is the point
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
With:
gcc (Debian 20140111-1) 4.9.0 20140111 (experimental) [trunk revision 206552]
I get the following inconsistency in the warnings:
ypig% cat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
Well, the code paths in question do not necessarily exist (you could say the
same thing with -O2, where the function is not inlined: there may be some code
paths for which fn1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Jakub Jelinek from comment #3)
The code path exists in the code,
It exists *only* if fn2() can return 0. But the fact is that in the reality,
this can never
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #7 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Jakub Jelinek from comment #6)
How can the compiler know that fn2 never returns 0, without inlining (not in
this case), some attribute (not provided, gcc right
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #14 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Marc Glisse from comment #9)
The definition of a function changes with inlining ;-)
It shouldn't: what happens at run time isn't changed by inlining.
f(i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #15 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Manuel López-Ibáñez from comment #10)
Now, I agree that ideally, GCC should warn for your last testcase. But I
guess in that case inlining either doesn't happen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59301
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
CC||vincent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #4 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
Alternatively you should say that:
* these minimal versions should be used with GCC only, and should not be
installed on the system;
* bugs related to them should be reported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #3 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Eric Botcazou from comment #1)
It's common practice to list the minimally required versions of dependencies
for software packages, so I'm not sure why we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #6 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Eric Botcazou from comment #5)
But, again, other software packages don't do that so I'm not sure why GCC
should do it
I'm not aware of other software packages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
CC||vincent
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
On PowerPC, which uses the IBM long double format for the type long double, one
gets:
LDBL_MANT_DIG = 106 (this is the precision of the FP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
--- Comment #1 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Vincent Lefèvre from comment #0)
One may choose to keep the behavior, i.e. consider that the high double is
the value rounded to double precision, but this means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
--- Comment #3 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
The variable precision is unavoidable with this format (this is even a feature,
despite the drawbacks). But the fact that the variable precision is problematic
by itself isn't
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
When I try to build GCC from a SVN working copy with:
$ autoreconf2.64 -i
$ mkdir gcc-build
$ cd gcc-build
$ ../gcc/configure --enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61485
--- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
Sorry, bad copy-paste of a command. The problem can still be reproduced:
$ autoreconf2.64 -i
$ mkdir gcc-build
$ cd gcc-build
$ ../configure --enable-maintainer-mode
$ touch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61485
--- Comment #3 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Richard Biener from comment #1)
Why would you do autoreconf?
With most projects, this is needed with svn working copies, otherwise some
files may become obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61485
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|RESOLVED
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Created attachment 32932
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32932action=edit
testcase
On x86_64, x - 0.0 is optimized to x in the asm code when compiling with -O
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
On PowerPC, which uses the IBM long double format (double-double arithmetic),
the conversion of floating constants of long double type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51679
Bug #: 51679
Summary: spurious parenthesis for -fassociative-math in manual
and man page
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51721
Bug #: 51721
Summary: -Warray-bounds false positives and inconsistencies
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51721
--- Comment #1 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2011-12-31
01:50:59 UTC ---
Oops, gcc-snapshot was not GCC 4.6.2. Anyway, I get the same warnings with GCC
4.6.2 and gcc-snapshot, which is:
gcc (Debian 20111210-1) 4.7.0 20111210
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #11 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2011-03-11
15:15:16 UTC ---
(In reply to comment #10)
If you don't want this warning, please contribute a testcase to
gcc-patc...@gcc.gnu.org, so this warning won't reappear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52106
Bug #: 52106
Summary: missing -Wunused-but-set-variable warning with the a =
b = ... construct
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52106
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51834
--- Comment #4 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-04-19
15:06:58 UTC ---
(In reply to comment #3)
(i++, i) + i is undefined. The sequence point only orders i++ and i inside
the
parens, but not the operands
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Created attachment 34066
-- https://gcc.gnu.org/bugzilla
: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
I get failures when building and testing MPFR with:
gcc (Debian 20141209-1) 5.0.0 20141209 (experimental) [trunk revision 218514]
on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64255
--- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
Created attachment 34242
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34242action=edit
testcase part 1 (tst1.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64255
--- Comment #3 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
Created attachment 34243
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34243action=edit
testcase part 2 (tst2.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64255
--- Comment #4 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Marek Polacek from comment #1)
Without the standalone test case we can't do much, unfortunately. Would you
have at least the preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #197 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Manuel López-Ibáñez from comment #196)
Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general)
is seriously lacking info and outdated. From
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
cpp currently supports multiarch search paths for /usr/local and /usr, but not
for directories supplied via environment
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With Debian's gcc-snapshot 20150722-1 on the following program, I get an
incorrect warning array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|NEW |RESOLVED
: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Created attachment 36807
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36807=edit
example of C program based on the STDC FP_CONTRACT pra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68499
--- Comment #1 from Vincent Lefèvre ---
Well, actually the pragma is ignored in all cases. The fix was to set the
default to OFF in the standard modes. So, currently, one should get a warning
in non-standard modes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68499
Vincent Lefèvre changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 495 matches
Mail list logo
