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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #4 from Vincent Lefèvre ---
I actually find it more confusing the fact that constants are not evaluated in
extended precision while everything else is evaluated in extended precision.
The real solution to avoid confusion would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
Vincent Lefèvre changed:
What|Removed |Added
Summary|With FLT_EVAL_METHOD = 2, |With FLT_EVAL_METHOD = 2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #1 from Vincent Lefèvre ---
There is the same issue with constant floating-point expressions.
Consider the following program given at
https://github.com/llvm/llvm-project/issues/89128
#include
#include
static double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #17 from Vincent Lefèvre ---
(In reply to Jonathan Wakely from comment #13)
> -fexcess-precision does affect constants.
Indeed, and this is a bug, as -fexcess-precision=fast was not meant to make
general programs less accurate (but
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
-fexcess-precision was added to resolve bug 323, so that with
-fexcess-precision=standard, after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #16 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #15)
> There is no bug, the compiler implements what the standard says for the
> FLT_EVAL_METHOD == 2 case.
I agree. I meant this *invalid* bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #14 from Vincent Lefèvre ---
This bug is about "double/float constant evaluation" (and it has been marked as
a duplicate of a bug precisely on this subject), not about the rules that are
applied *after* this evaluation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #48 from Vincent Lefèvre ---
(In reply to Alexander Cherepanov from comment #35)
> DR 260 allows one to argue that representation of these pointers could
> change right between the checks but IMHO this part of DR 260 is just wrong
>
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
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code:
#include
int main (void)
{
volatile char *t;
t = malloc (4);
for (int i = 0; i <= 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #12 from Vincent Lefèvre ---
(In reply to Segher Boessenkool from comment #11)
> Sure. If people want the pain, they can have it. But it is never okay to
> cause other people to have -Werror -- they may have a different compiler
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #6 from Vincent Lefèvre ---
BTW, note that some code may be generated (instead of being written by a
human). So having some code style being an error by default would be very bad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #5 from Vincent Lefèvre ---
Note that -Wall -Werror seem to be fine in general when they are used alone,
but this combination can be very problematic when other options are used, such
as -std=c90 -pedantic, and other warnings. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=576
--- Comment #7 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #6)
> That is because the code is GNU C90 and not C++ .
I've used gcc, not g++. But this fails even with -std=gnu90.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=576
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112463
--- Comment #3 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #2)
> One problem with -Wsign-conversion is that it is not enabled with
> -Wextra/-Wall .
However, I don't understand why -Wsign-compare is enabled by -Wextra but
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
-Wsign-compare is described in the man page as follows:
-Wsign-compare
Warn when a comparison between signed and unsigned values could
produce an incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56281
--- Comment #6 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #1)
> Given the amount of code in the wild that assumes 1 << 31 etc. work, I think
> it would be a bad idea to try to optimize this for C99, especially when it
> is
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
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 "*[0]" instead of "t[0]":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95057
--- Comment #6 from Vincent Lefèvre ---
Well, for the ++, --, +=, -=, *=, etc. operators, that's PR44677 (though it is
unclear on what it should cover).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95057
--- Comment #5 from Vincent Lefèvre ---
FYI, Clang 16 does not warn either on the testcases provided in comment 0 (bug
report).
But contrary to GCC (tested with master r14-1713-g6631fe419c6 - Debian
gcc-snapshot package 20230613-1), Clang 15
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101090
--- Comment #2 from Vincent Lefèvre ---
On Debian, I get a warning from GCC 9 to GCC 12 (Debian 12.3.0-6), but neither
with GCC 13 (Debian 13.1.0-8) nor with 14.0.0 20230612 (Debian 20230613-1).
So, has this bug been fixed (and where)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #228 from Vincent Lefèvre ---
PR64410 and PR68180 should also be removed from "See Also".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #227 from Vincent Lefèvre ---
In "See Also", there are several bugs that are related only to vectorization
optimizations. What is the relation with this bug?
For instance, PR89653 is "GCC (trunk and all earlier versions) fails to
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],
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
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
>
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With -pedantic, on
int f(int n; int n) { return n; }
I get:
tst.c:1:1: warning: ISO C forbids forward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155
--- Comment #12 from Vincent Lefèvre ---
Here's a similar, simpler testcase:
int f1 (void);
void f2 (int);
long f3 (long);
void tst (void)
{
int badDataSize[3] = { 1, 1, 1 };
for (int i = 0; i < 3; i++)
{
int emax;
if (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011
--- Comment #4 from Vincent Lefèvre ---
(In reply to Kewen Lin from comment #3)
> Thanks for reporting, this exposes one issue that: when encoding KFmode
> constant into toc, it uses the format for the current long double, it could
> be wrong
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
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
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 ();
sprintf (s, "%
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
--- Comment #4 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #3)
> Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed
> later on that GCC didn't realize divide could trap.
OK, thanks, I can see your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
--- Comment #2 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #1)
> We don't removing code before undefined behavior ...
> That is GCC does not know that printf does not have side effects.
Then GCC is incorrect in bug 29968,
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
This is about the opposite of the invalid bug 29968:
#include
int f (int i, int k)
{
if (k == 0)
printf ("k = 0\n");
return i/k;
}
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745
--- Comment #14 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #13)
> GCC removed the pedwarning on purpose (between GCC 4.1 and 4.4), see PR
> 14331 and PR 68994.
No, PR 14331 was just asking to remove the warning by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68994
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #7 from Vincent Lefèvre ---
On https://godbolt.org/z/Yx7b1d this still fails with "x86-64 gcc (trunk)".
Moreover, several releases are affected: 11.1, 11.2, 11.3, 12.1, 12.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108700
--- Comment #2 from Vincent Lefèvre ---
And there's the same issue with "inline" instead of "_Noreturn" (these are the
only two function specifiers).
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With gcc-12 (Debian 12.2.0-14) 12.2.0 (but this error was already present in
GCC 4.8):
cventin% echo 'int _Noreturn does_not_return (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #18 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #17)
> Yeah, but warnings with high false positivity rates at least shouldn't be in
> -Wall.
Well, there already is -Wunused, which is included in -Wall (such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #16 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #15)
> But much more often it is intentional than unintentional.
That's the same thing for many kinds of warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #14 from Vincent Lefèvre ---
Anyway, as I said initially, the warning would be interesting even in C99+
mode, because the lack of a return statement may be unintentional. For
instance, the developer may have forgotten a "return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #11 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #8)
> (In reply to comment #6)
> > Er, if you want to find portability problems for people not using C99 then
> > don't use -std=c99. Then -Wreturn-type warns
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code, derived from MPFR's sub1sp.c (where the issue
occurred since at least GCC 4.9.4
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With gcc-12 (Debian 12.2.0-14) 12.2.0, the -Wmaybe-uninitialized warning
location depends on the declared type. This is inconsistent.
To reproduce, consider a tst.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #8 from Vincent Lefèvre ---
Isn't it the same as PR56020, which is due to the fact that the STDC
FENV_ACCESS pragma is not implemented and assumed to be OFF (PR34678)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108128
--- Comment #1 from Vincent Lefèvre ---
Well, with -pedantic, GCC also warns on "enum { A = 1 << 31 };".
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following C program:
#include
enum { A = 1 << 31 };
int main (void)
{
printf ("%d\n", A);
printf ("%d\n", 1 << 31);
printf ("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
--- Comment #3 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #2)
> it's loop invariant motion that hoists the v + v compute out of the loop
> and thus outside of its controlling condition. You can see it's careful
> to not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #12 from Vincent Lefèvre ---
(In reply to Jeffrey A. Law from comment #11)
> As I said in my previous comment, the best way forward is to get those two
> new instances filed as distinct bugs in BZ.
See PR107838 and PR107839.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155
--- Comment #10 from Vincent Lefèvre ---
A similar bug (all uses of the variable are under some condition) with a
simpler testcase I've just reported: PR107839.
D
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
int f (int);
void g (int c)
{
int v;
if (c)
v = f(0);
while (1)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
int f(void);
void g(int *t)
{
int i, v;
for (i = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106754
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #10 from Vincent Lefèvre ---
(In reply to Jeffrey A. Law from comment #9)
> These warnings are certainly sensitive to all kinds of things, so it's
> possible it's just gone latent. The only way to be sure would be to bisect
> all
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=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
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 #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
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=106165
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
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
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
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
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
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 #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:
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
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
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
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=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=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,
: 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=31178
--- Comment #19 from Vincent Lefèvre ---
(In reply to rguent...@suse.de from comment #18)
> Sure, if that's what the precision is used for. The message from Andrew
> sounded like 'I want the precision for the shift operand but let me
> just use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
--- Comment #17 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #16)
> Note for shifts the precision of the shift operand does not have to match
> that of the shifted operand. In your case you have vector << scalar, so you
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56281
--- Comment #5 from Vincent Lefèvre ---
I've clarified the bug title to say that this is a range on the first operand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
--- Comment #21 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #16)
> As for constant folding, even with double double gcc is able to fold some
> constant arithmetics in that format, but because the emulation is only
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104690
--- Comment #2 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #1)
> It requires that the callee tells the caller that it reached end of non-void
> function without return and the callee checks if the value is actually used
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
Severity: normal
Priority: P3
Component: sanitizer
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104677
Vincent Lefèvre changed:
What|Removed |Added
Summary|With -fprofile-arcs, the|Please update documentation
Priority: P3
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: ---
Under Debian/unstable, if I do "gcc foo.c -o foo2 -fprofile-arcs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #18 from Vincent Lefèvre ---
I'm wondering whether it is possible to check on actual code what is needed.
For instance, assume that you have a program that produces always the same
results, e.g. by running it over a fixed dataset.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #14 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #11)
> And also take into account different rounding modes if
> user wants that to be honored.
And that would eliminate the need to consider the possibility of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #10 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #9)
> Subnormals might also need to be considered as special cases: "Whether and
> in what cases subnormal numbers are treated as zeros is implementation
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #9 from Vincent Lefèvre ---
(In reply to Aldy Hernandez from comment #6)
> As I've mentioned, I'm hoping some floating expert can take this across to
> goal line, as my head will start spinning as soon as we start talking about
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93902
--- Comment #3 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #2)
> foo3 is more complex because x86 does not have an unsigned long 64bit to
> double so it has to do some more complex.
But the point is that GCC shouldn't do
1 - 100 of 496 matches
Mail list logo
