https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #42 from Vincent Lefèvre ---
(In reply to Alexander Cherepanov from comment #40)
> Sure, one possibility is make undefined any program that uses f(x) where x
> could be a zero and f(x) differs for two zeros. But this approach make
> p
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
The IBM long double format (double-double) is specified in
libgcc/config/rs6000/ibm-ldouble-format, which says
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #44 from Vincent Lefèvre ---
(In reply to Alexander Cherepanov from comment #43)
> GCC on x86-64 uses the binary encoding for the significand.
In general, yes. This includes the 32-bit ABI under Linux. But it seems to be
different un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777
--- Comment #14 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #1)
> I've cleaned up the testcase:
>
> int d;
> int h(void);
> void e(void)
> {
> int f[2];
> int g = 0;
> if (d)
> g++;
> if (d == 1)
> f[g++] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #46 from Vincent Lefèvre ---
(In reply to Alexander Cherepanov from comment #45)
> (In reply to Vincent Lefèvre from comment #44)
> > (In reply to Alexander Cherepanov from comment #43)
> > > GCC on x86-64 uses the binary encoding for
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following example.
#include
struct s1
{
int a;
};
struct s2
{
int a, b;
};
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94337
--- Comment #2 from Vincent Lefèvre ---
Why not having a level with no false positives? This would avoid to disable the
warning globally.
IMHO, using it when a union is involved is likely to generate false positives.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #5 from Vincent Lefèvre ---
I can reproduce the issue on my Debian machine. Do you know which values are
passed to MPC?
I've tried with
mpc_init2 (x, 24);
mpc_init2 (y, 24);
mpc_set_ui_ui (x, 1, 1, MPC_RNDNN);
mpc_ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #7 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #6)
> I guess there's only one limb, the rest looks garbage.
Yes, and 1125899906842624 with _mpfr_exp = 14 corresponds to 1 as
expected (1125899906842624000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #8 from Vincent Lefèvre ---
The exponent range is important. With ltrace, I can see:
3472505 mpfr_set_emin(0x7f22, 0xbf92, 0xbf92, 46) = 0
3472505 mpfr_set_emax(0x8002, 0xbf92, 0x7fb7c2c9c420, 46) = 0
(BTW, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #10 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #9)
> It's likely by us doing
>
> mpfr_set_emin (-32990);
> mpfr_set_emax (32766);
>
> during startup to work around a similar bug in MPC (IIRC it also
> was t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #11 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #10)
> Paul Zimmermann says that this bug is fixed in the MPC development version.
I could check that the bug is actually fixed, but the does not solve the GCC
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #12 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #11)
> (In reply to Vincent Lefèvre from comment #10)
> > Paul Zimmermann says that this bug is fixed in the MPC development version.
>
> I could check that the b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #43 from Vincent Lefèvre ---
Note that the effect of changing the rounding mode after a computation, whether
-frounding-math is used or not, is not just that the change of rounding mode
may not be honored. If can yield inconsistencies
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Test with: gcc-10 (Debian 10-20200418-1) 10.0.1 20200418 (experimental) [master
revision 27c171775ab:4c277008be0:c5bac7d127f288fd2f8a1f15c3f30da5903141c6]
Consider:
void f1
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Test with: gcc-10 (Debian 10-20200418-1) 10.0.1 20200418 (experimental) [master
revision 27c171775ab
onent: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Created attachment 48360
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48360&action=edit
testcase
Test with: gcc-10 (Debian 10-20200418-1) 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94732
--- Comment #1 from Vincent Lefèvre ---
Here's the corresponding simple testcase:
typedef struct { int *a; } S;
int *f (void);
static void g (S *x)
{
int *p = x->a;
p[0] = 0;
}
void h (void)
{
S x[1];
x->a = f ();
g (x);
}
$ gcc-10 -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94773
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #33 from Vincent Lefèvre ---
(In reply to Niels Möller from comment #32)
> 4. I also wonder what happens if, for some reason, a constant invalid shift
> count is passed through all the way to code generation? Most architectures
> would
ty: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
On the following program (obtained after simplifying Mutt's imap/message.c)
struct _IO_FILE;
typedef struct _IO_FIL
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With -Wunused-but-set-variable, GCC does not warn in the following cases:
int f (int i)
{
int j;
j = i + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95057
--- Comment #2 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #1)
> That is something this warning can't warn about.
> The warning is a simple FE warning that uses two bits, one for whether
> certain decl was used and one whethe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95057
--- Comment #4 from Vincent Lefèvre ---
OK, so the work (for this warning or a new one) should be done later, but early
enough not to be affected by optimizations.
One of the goals would be to detect a missing check of a return value of a
functi
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code on x86_64 (written for a 64-bit long), compiled
with -O2.
With gcc-9 (Debian 9.3.0-13) 9.3.0, I get:
0
1
1
With gcc-10 (Debian 10.1.0-3) 10.1.0, I get:
0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699
--- Comment #5 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #4)
> I'm inclined to close as WONTFIX or INVALID. There are several other PRs
> which
> show "surprising" behavior with respect to __builtin_constant_p and jump
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699
--- Comment #8 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #6)
> I don't see why that should be considered a bug.
> All the tests are using __builtin_constant_p in a way that it wasn't
> designed for, where it changes the beh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96044
--- Comment #6 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #5)
> Vincent, any guidance on that? I guess the actual runtime implementation in
> glibc may be "fast" because it's not accurate (evaluating takes 0.00s with
> gli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96044
--- Comment #10 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #8)
> The issue with timeouts (as in wall-clock) is that it makes builds
> dependent on CPU speed which is something we generally avoid. For ISL
> computations whe
: 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:
int main (void)
{
volatile double x = 0.0;
volatile _Decimal128 i = x;
return i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96173
--- Comment #2 from Vincent Lefèvre ---
IMHO, the implementation is highly inefficient. Even with all these functions
(which are similar, thus should share most code), 3 MB seems a lot to me.
In particular, some user complained that the size of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
--- Comment #16 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #14)
> Fixed for GCC 8.
With gcc-8 (Debian 8.3.0-24) 8.3.0, it is not fixed (OK with -O1, not with
-O3). And there does not seem to be a reference to this bug in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
--- Comment #17 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #12)
> Fixed on the trunk.
I tested with
gcc (Debian 20191008-1) 10.0.0 20191008 (experimental) [trunk revision 276697]
and the bug still occurs. Maybe another re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82123
--- Comment #16 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #15)
> Fixed in GCC 8.
I can still reproduce the bug with:
gcc-8 (Debian 8.3.0-24) 8.3.0
However, I can no longer reproduce it with:
gcc-9 (Debian 9.2.1-19) 9.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #14 from Vincent Lefèvre ---
(In reply to Segher Boessenkool from comment #11)
> Do you have examples of perfectly fine code where you get a warning?
In addition to Daniel's example, I would say that one can have types that are
signe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #17 from Vincent Lefèvre ---
(In reply to Segher Boessenkool from comment #15)
> A much better fix is
>
> void f1(long s, unsigned long u) { unsigned long su = s; if (su == u) g(); }
But what if s is some arbitrary integer type, e.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #22 from Vincent Lefèvre ---
(In reply to Segher Boessenkool from comment #21)
> If, as I said, the user uses explicit casts, that's not good. Much better
> already is to use implicit casts, as I said;
There's no such thing as impli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
--- Comment #7 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #5)
> Lack of direct float and double arithmetic requires FLT_EVAL_METHOD == 2
No, FLT_EVAL_METHOD could also be negative, in which case GCC would be allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
nt: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With GCC 9.2.1 under Debian/unstable (x86_64):
cventin% cat tst.c
int main (void)
{
_Decimal64 x = 1;
return x != 1;
}
cventin% gcc-9 tst.c -o tst
cventin%
but
cventin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93410
--- Comment #3 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #2)
> But that's not the sort of change we make on past release branches.
OK, but note that the GCC manual does not mention any limitation of this kind.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #215 from Vincent Lefèvre ---
According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think that
the correct one is CONFIRMED.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #13 from Vincent Lefèvre ---
(In reply to Rich Felker from comment #12)
> [...] and making the floating point results even more semantically incorrect
> (double-rounding all over the place, mismatching FLT_EVAL_METHOD==2)
No problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318
--- Comment #8 from Vincent Lefèvre ---
(In reply to Rich Felker from comment #7)
> Note that such an option would be nice to have anyway, for arbitrary
> functions, since it's necessary for being able to call code that was
> compiled with -fexce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #15 from Vincent Lefèvre ---
(In reply to Rich Felker from comment #14)
> It sounds like you misunderstand the standard's requirements on, and GCC's
> implementation of, FLT_EVAL_METHOD==2/excess-precision. The availability of
> regis
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
There should be a warning for duplicate macro definition (i.e. with the same
value), such as
#define FOO 1
#define FOO 1
Such code is valid, but a duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #27 from Vincent Lefèvre ---
(In reply to Rich Felker from comment #25)
> I think standards-conforming excess precision should be forced on, and added
> to C++; there are just too many dangerous ways things can break as it is
> now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #4 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #3)
> with -funsafe-math-optimizations you get the 1 + x != 1 -> x != 0
> optimization which is unsafe because a rounding step is removed.
> But you asked for that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #7 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #5)
> From below I implicitely assume you say that "1. + x != 1." -> "x != 0."
> isn't "rearranging at the source level".
No, it depends on how you do that. If i
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following C code:
void foo_aux (int);
void foo (void)
{
int i;
int *p = &i;
foo_aux (p[1]);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #9 from Vincent Lefèvre ---
(In reply to Alexander Cherepanov from comment #8)
> A similar problem happens with -fno-signed-zeros -fno-trapping-math. Not
> sure if a separate PR should be filed...
Concerning -fno-signed-zeros, your c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #11 from Vincent Lefèvre ---
(In reply to Rich Felker from comment #10)
> I don't think it's at all clear that -fno-signed-zeros is supposed to mean
> the programmer is promising that their code has behavior independent of the
> sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #13 from Vincent Lefèvre ---
(In reply to Rich Felker from comment #12)
> To me the meaning of internal consistency is very clear: that the semantics
> of the C language specification are honored and that the only valid
> transformati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #15 from Vincent Lefèvre ---
Note that there are very few ways to be able to distinguish the sign of zero.
The main one is division by zero. Other ones are:
* Conversion to a character string, e.g. via printf(). But in this case, if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #20 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #18)
> GCC indeed happily evaluates a floating-point expression multiple times,
> for example for
>
> void foo(float a, float b, float *x, float *y)
> {
> flo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #8 from Vincent Lefèvre ---
Concerning the STDC FP_CONTRACT pragma, implementing it would not be
sufficient. GCC would also need to restrict how it does contraction, as it
currently does not contract only expressions, but also sequenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #22 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #21)
> Note that GCC does FP contraction across stmt boundaries so
> even s = a * b; t = s + c; is contracted. If that is already
> a bug in your eyes then of c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #23 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #22)
> Note that if one adds "if (s == u)" (which is true, and noticed by GCC)
Sorry, this is not noticed by GCC (I used an incorrect command line).
Anyway, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #2 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #1)
> Hmm, but as you say there isn't an actual access and taking the address of
> one-after the array is allowed. With p[2] it appropriately warns.
No, what I'm s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #4 from Vincent Lefèvre ---
Perhaps this was not the intent of the standard (and this is far from being
clear because this might affect optimizations -- there are already many things
that are forbidden with pointers though they could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #6 from Vincent Lefèvre ---
bar_aux can be any function. It doesn't need to do any thing. As soon as p[1]
is evaluated, one has undefined behavior, just like in function foo.
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Optimizations that are done with conversions from 32-bit unsigned int to double
are no longer done with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #27 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #26)
> I wouldn't be surprised if such a test could be constructed in the absence
> of -funsafe-math-optimizations, that does a single conversion of an
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #28 from Vincent Lefèvre ---
A slightly modified version of the example, showing the issue with GCC 5 to 7
(as the noipa attribute directive has been added in GCC 8):
#include
int main (void)
{
volatile double d = 50.0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #29 from Vincent Lefèvre ---
And with unsigned too (this should be a bit more readable):
#include
int main (void)
{
volatile double d = -1.0;
double x = d;
unsigned int i = x;
printf ("%u\n", i);
if (x == -1.0)
print
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #30 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #28)
> A slightly modified version of the example, showing the issue with GCC 5 to
> 7 (as the noipa attribute directive has been added in GCC 8):
Correction: Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53182
--- Comment #8 from Vincent Lefèvre ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Vincent Lefèvre from comment #6)
> > Also, note that identifiers that are not reserved should not be used,
> > because they could be defined as m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #33 from Vincent Lefèvre ---
I couldn't find a failing test with FP contraction, but this seems to be
because GCC doesn't optimize as much as it could. Still, the following example
could be interesting in the future or as a non-regres
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following example.
#include
typedef double T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681
--- Comment #4 from Vincent Lefèvre ---
Instead of "-m32 -march=i686", one can also compile with "-mfpmath=387". This
is useful if one does not have the 32-bit libs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #35 from Vincent Lefèvre ---
(In reply to Alexander Cherepanov from comment #34)
> (In reply to Vincent Lefèvre from comment #13)
> > In C without Annex F, division by 0 is undefined behavior (really undefined
> > behavior, not an uns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #37 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #36)
> We're actually careful about the sign of zero here when recording
> requivalences for propagation.
But shouldn't the use of -fno-signed-zeros imply that
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
In floating point, when x is not 0 (and not sNaN when supported), x + 0 can be
optimized to x. GCC misses this optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94031
--- Comment #3 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #1)
> This needs something like VRP for floating point types.
Thus this is related in some way to PR24021 and PR68097.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #3 from Vincent Lefèvre ---
But note that the optimization should be modified or disabled in contexts where
floating-point exceptions need to be honored, as the i+=0.1f will sometimes
trigger the inexact exception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #39 from Vincent Lefèvre ---
So I wonder whether -fno-signed-zeros should be removed. It seems too
dangerous. The -ffinite-math-only option is fine because the programmer may be
able to prove that Inf and NaN never occur in his code (
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: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56281
Vincent Lefèvre changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #16 from Vincent Lefèvre 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 no code generation but i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #20 from Vincent Lefèvre 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 the variable to a sensible val
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #23 from Vincent Lefèvre 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 that the option is not recognized.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #24 from Vincent Lefèvre 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
severity could be lowered to "e
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 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 it would be turned off by de
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 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
> Input:
> 1.5707963267
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #12 from Vincent Lefèvre 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 MPFR for this in GCC ...
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #14 from Vincent Lefèvre 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=57994
--- Comment #12 from Vincent Lefèvre ---
(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
> functions for which we enab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #13 from Vincent Lefèvre ---
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, mpfr_rec_sqrt on -0 gives +Inf,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #4 from Vincent Lefèvre ---
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 greater than 1 that is repres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #5 from Vincent Lefèvre ---
(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. The
double-double format comes f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #7 from Vincent Lefèvre ---
(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:
"gcc.target/powerpc/rs6000-ldouble-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #15 from Vincent Lefèvre ---
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/gmane.comp.standards.posix.aust
: 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
int main(void)
{
_Decimal64 x = 1;
if (x != x)
{
printf ("Err
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' &
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58485
--- Comment #1 from Vincent Lefèvre ---
I forgot:
Version: GNU MP 5.1.2
Host type: coreinhm-unknown-linux-gnu
ABI: 64
Install prefix:/usr/local
Compiler: gcc-snapshot -std=gnu99
Static libr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58485
Vincent Lefèvre changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 529 matches
Mail list logo
