https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428
--- Comment #5 from Marc Glisse ---
Would it make sense to add a fixit hint that removes "constexpr"? I think that
might make the warning a bit clearer for some users.
On the other hand, if is_constant_evaluated gets removed by P1938, there is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92077
--- Comment #2 from Marc Glisse ---
It is quite natural for the compiler to inline functions that are only called
once (it won't take more space) (although the compiler doesn't actually know
that the function isn't also called in another TU) more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83338
--- Comment #2 from Marc Glisse ---
void f(char**p,char**q,long*r){
for(int i=0;i<1024;i++)
r[i]=p[i]-q[i];
}
with g++ -O3 on x86_64 also ICEs, let's start with that (I don't have access to
SPEC).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83338
--- Comment #5 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #4)
> I believe the bug is that get_vectype_for_scalar_type for the operands of
> POINTER_DIFF_EXPR is vector of unsigned elements, the result of
> POINTER_DIFF_EXPR is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83338
--- Comment #7 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> This works for me, but I'll leave testcase and testing for tomorrow.
You are fast :-)
> @@ -5546,6 +5554,15 @@ vectorizable_operation (gimple *stmt, gi
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83338
Marc Glisse changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81914
--- Comment #10 from Marc Glisse ---
For the particular case of <=> (-1, 0 or 1), I've seen code like (a>b)-(a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80885
--- Comment #2 from Marc Glisse ---
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02233.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83468
--- Comment #1 from Marc Glisse ---
-Wsystem-headers enables the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83517
--- Comment #1 from Marc Glisse ---
(div (mult @0 @1) @1)
Maybe we are missing a :c here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83541
--- Comment #1 from Marc Glisse ---
Yes, it is a known issue, (E)VRP is too conservative.
pushing new range for x_2(D): [2147483647, +INF] EQUIVALENCES: { x_2(D) } (1
elements)
Visiting stmt _4 = x_2(D) + 1;
Visiting statement:
_4 = x_2(D) + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83541
--- Comment #2 from Marc Glisse ---
int test(void)
{
int x = __INT_MAX__;
return x+1;
}
CCP also turns this into INT_MIN, again it could be bolder.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83544
--- Comment #1 from Marc Glisse ---
In one case we optimize super early to
int t = 1 / (int) x <= 0 ? 1 / 0 : 1;
which prevents the VRP optimization from the other case. We almost recover in
isolate-paths, except that Jeff insisted on using __b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83639
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83541
--- Comment #4 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> I've deliberately avoided doing this ... (turning SSA propagator UNDEFINED
> into a random value rather than keeping it effectively VARYING during
> propagation/si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82439
--- Comment #6 from Marc Glisse ---
(In reply to Andrew Pinski from comment #1)
> "(x | y) == x" is simpler than "(y & ~x) == 0" on the tree level. 2 gimple
> vs 3.
We do indeed tend to use the number of stmts to chose canonical forms on
gimple,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83715
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83739
--- Comment #6 from Marc Glisse ---
Without fancy tools, looking at the last few lines of the file:
#include
template void f()
{
std::set x;
auto delegate = [](auto & foo)
{
for (auto bar : foo);
};
delegate(x);
}
int main() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83739
--- Comment #7 from Marc Glisse ---
And to drop the includes:
template void f()
{
int x[2];
auto delegate = [](auto & foo)
{
for (auto bar : foo);
};
delegate(x);
}
int main() {
f();
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83749
--- Comment #1 from Marc Glisse ---
See PR2316. Don't hold your breath for a change, it is more likely that the
standard will eventually be changed to allow the current behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54422
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
(first seen with complex numbers, quite likely a dup of some other vector PR,
could be target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503
--- Comment #18 from Marc Glisse ---
(In reply to Georg-Johann Lay from comment #17)
> Obervation that -fno-wrapv also leads to correct code, hence there is
> somewhere a wrong assumption that signed overflow occurs (which doesn't).
(you probabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503
--- Comment #19 from Marc Glisse ---
Looking at the very first testcase in this PR, assuming 16-bit int, 129*255
overflows and is thus undefined behavior. Multiply by 255u if you want the
multiplication to happen safely in an unsigned type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240
--- Comment #18 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #17)
> Created attachment 43162 [details]
> gcc8-pr61240.patch
>
> The C FE doesn't do this optimization anymore, but c_fully_fold does because
> the generic folding co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83952
--- Comment #4 from Marc Glisse ---
Andrew, the OP had already closed the first PR, and you closed the second as
duplicate of the first. Did you really mean to get to a situation where both
are closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83952
Marc Glisse changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83951
Marc Glisse changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83952
--- Comment #7 from Marc Glisse ---
*** Bug 83951 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81082
--- Comment #9 from Marc Glisse ---
+ (if (! INTEGRAL_TYPE_P (type)
Integer vectors satisfy this condition...
Also, floats need some check (I don't know which one is appropriate).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84056
--- Comment #2 from Marc Glisse ---
Where is the bug? Did you read the documentation for operator[]?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84056
--- Comment #4 from Marc Glisse ---
(In reply to Alper Ce from comment #3)
> I didn't assign anything to my_map(i didn't use assignment operator = ), i
> just used == operator to check value of it.
Again, did you read the doc for operator[]? For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84121
--- Comment #1 from Marc Glisse ---
You can compile with -fsanitize=undefined then run your code, to understand the
issue.
More warnings are always possible, but at some points, hundreds of "I, the
compiler, assume that the code you have written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84121
--- Comment #2 from Marc Glisse ---
(In reply to Marc Glisse from comment #1)
> You can compile with -fsanitize=undefined then run your code, to understand
> the issue.
Oups, sorry, that doesn't show anything for your code, the problem is not wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84121
--- Comment #5 from Marc Glisse ---
What I don't understand is why -fsanitize=undefined does not say anything when
running this program, whether I use gcc or clang...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84121
--- Comment #7 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> It does:
Ah, of course, it prints it only for the first occurrence, and since this
quickly disappears, I missed it. My bad, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172
Marc Glisse changed:
What|Removed |Added
Known to work||7.2.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173
--- Comment #4 from Marc Glisse ---
(In reply to Javier Serrano Polo from comment #3)
> Upstream wants to make multiarch harder; the patch will not be posted here.
As long as the new behavior is optional (not the default), the patch stands a
cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190
--- Comment #2 from Marc Glisse ---
IIRC, the standard provides guarantees for volatile objects. Here, you are
accessing a non-volatile object through a volatile type, and if the compiler
can find out about the underlying object, it can ignore 'v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173
--- Comment #11 from Marc Glisse ---
(In reply to Javier Serrano Polo from comment #10)
> This report is about the patch that will be submitted with multiarch names.
If you intend to send a patch, you can send it directly to
gcc-patc...@gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84280
Marc Glisse changed:
What|Removed |Added
Known to work||5.5.0
Summary|Performance regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84280
--- Comment #9 from Marc Glisse ---
(In reply to Patrik Huber from comment #6)
> I could also upload you the .ii files but they are 5 MB, which the
> bugtracker doesn't allow (1 MB limit).
preprocessed sources are the .ii files (you can use comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89263
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #20 from Marc Glisse ---
TODO: specify __restrict on the arguments of __relocate_object_a. Since one is
initialized and not the other, it should be safe to assume that they are
disjoint, and it helps optimize move+destroy, for instanc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89319
--- Comment #2 from Marc Glisse ---
I expect this is a DUP of bug 55266 and many others. Vector lowering for
unsupported sizes is not done very cleverly...
Not closing in case there are some mitigations you can do in the ppc backend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
--- Comment #3 from Marc Glisse ---
If we avoid changing the type from int16_t to uint16_t, we get 2 calls to
memmove. They don't get expanded, probably because we fail to simplify the size
to 16 in gimple:
_1 = &MEM[(void *)this_5(D) + 16B];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89450
--- Comment #4 from Marc Glisse ---
Would it make sense to have an attribute so this can be specified for each
enum, instead of globally?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89478
--- Comment #1 from Marc Glisse ---
I think the uninitialized variable makes the initialization not constexpr (and
indeed gcc/clang complain if you try to declare test constexpr). Then we hit
the well-known missed optimization that gcc is unable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81009
Marc Glisse changed:
What|Removed |Added
CC||eyalroz at technion dot ac.il
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
Marc Glisse changed:
What|Removed |Added
Keywords||alias, missed-optimization
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
--- Comment #3 from Marc Glisse ---
Hmm indeed they are different (it would have been clearer to omit const in the
initial testcase). I couldn't find an obvious duplicate in bug 49774.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89450
--- Comment #10 from Marc Glisse ---
I still think some __attribute__((exhaustive)) on an enum definition would be
useful for this sort of thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89518
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> We do not have a (a / b) * b + (a % b) simplification rule.
Indeed. That's surprising since we do have for trunc_div
/* X - (X / Y) * Y is the same as X % Y. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68211
--- Comment #8 from Marc Glisse ---
(In reply to Steven Bosscher from comment #7)
> __m128d y = { x, 0 };
> return _mm_cvtsd_f64(_mm_sqrt_round_sd(y, y,
> _MM_FROUND_TO_POS_INF|_MM_FROUND_NO_EXC));
I don't necessarily advocate for optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89745
Marc Glisse changed:
What|Removed |Added
Keywords||ABI
--- Comment #3 from Marc Glisse ---
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89749
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89809
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459
Marc Glisse changed:
What|Removed |Added
Summary|[8/9 Regression] Larger |[8 Regression] Larger code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809
--- Comment #3 from Marc Glisse ---
(In reply to Alexander Monakov from comment #0)
> Therefore I suggest we don't use rep-scasb for inline strlen anymore by
> default (we currently do at -Os).
According to https://stackoverflow.com/q/55563598/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #16 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #15)
> I certainly do see that.
Uh, indeed. I don't remember what I may have tested where we failed to set a
range, or maybe I just got confused, better ignore my comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #11 from Marc Glisse ---
The original testcase also shows a small, unrelated regression: DSE3 used to be
able to remove the initialization of sum to 0 when there were 2 statements
(setting each element to 0). Now that we vectorize so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073
--- Comment #5 from Marc Glisse ---
Looking at the attached asm, the main issue is PR 55266 (there should be no
copying), and how exactly the copies are done (64/128/256 bits) is almost a
detail...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
--- Comment #10 from Marc Glisse ---
"Forward progress [intro.progress]
The implementation may assume that any thread will eventually do one of the
following:
(1.1) — terminate,
(1.2) — make a call to a library I/O function,
(1.3) — perform an ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #3 from Marc Glisse ---
(In reply to Frederico Lamberti Pissarra from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > It is <0 when sqrt is called and it is due setting errno. Not a bug.
>
> Hu... interesting. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90202
--- Comment #1 from Marc Glisse ---
IIRC this is a tuning decision made on purpose. If you use just -mavx512f
instead of the -march, you get the code you expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90203
Marc Glisse changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90217
--- Comment #1 from Marc Glisse ---
Please always attach your testcases to bugzilla.
I took a look at the .optimized dump.
First issue is that we fail to simplify
MEM[(union ._1 *)&apart] = 1;
_3 = apart.D.2494.contam_level;
Second issue i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #21 from Marc Glisse ---
Author: glisse
Date: Sat Apr 27 14:09:20 2019
New Revision: 270624
URL: https://gcc.gnu.org/viewcvs?rev=270624&root=gcc&view=rev
Log:
Use __restrict for __relocate_object_a
2019-04-27 Marc Glisse
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
#ifndef EASY
typedef std::unique_ptr T;
#else
typedef int* T;
#endif
void f(T*__restrict a,T*__restrict b){
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90269
--- Comment #1 from Marc Glisse ---
--- tree-loop-distribution.c(revision 270624)
+++ tree-loop-distribution.c(working copy)
@@ -3033,20 +3033,23 @@ find_seed_stmts_for_distribution (struct
the loop. */
if (!stmt_h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90269
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> Otherwise the patch looks sensible, mind to test/post it?
It bootstrapped and regtested fine, I'll send it later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90269
--- Comment #4 from Marc Glisse ---
Author: glisse
Date: Fri May 3 13:41:36 2019
New Revision: 270852
URL: https://gcc.gnu.org/viewcvs?rev=270852&root=gcc&view=rev
Log:
Let ldist ignore clobbers
2019-05-03 Marc Glisse
PR tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90269
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
I was investigating missed loop distribution opportunities probably related to
aliasing, and hit this case where gcc seems a bit too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90349
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90353
--- Comment #2 from Marc Glisse ---
(from https://stackoverflow.com/q/55977431/1918193)
Thanks.
except.c (initialize_handler_parm) says:
/* Make sure we mark the catch param as used, otherwise we'll get a
warning about an unused ((anonym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328
--- Comment #1 from Marc Glisse ---
dr_may_alias_p says a and b cannot alias because:
(gdb) p addr_a->base.u.dependence_info
$13 = {clique = 2, base = 0}
(gdb) p addr_b->base.u.dependence_info
$14 = {clique = 2, base = 1}
which comes from
http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90377
--- Comment #1 from Marc Glisse ---
What kind of obfuscator did this go through?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90377
--- Comment #3 from Marc Glisse ---
(In reply to Andrew Pinski from comment #2)
> Most likely used creduce to reduce the failure.
creduce didn't use to produce such awful code. Part is because of -fpermissive,
but part seems to be because the re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90377
--- Comment #5 from Marc Glisse ---
Thanks. The unreduced file does not reproduce for me. But anyway, we warn for
things like
int a[1];
void f(int n){
for(int i=0;i
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
I am picking a random code that gets vectorized to illustrate the issue
#include
#include
#include
inline void* operator new(std::size_t n){return malloc(n);}
inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90435
--- Comment #3 from Marc Glisse ---
(In reply to 庞庆源 from comment #2)
> gcc pmalloc.c -O2 -o ppp -ldl -fno-tree-loop-distribute-patterns
> -fno-strict-aliasing
> Still not work.
-fno-builtin (the malloc+memset -> calloc is not part of loop dist
: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(split from bug 87544)
#include
void f(std::vector&v){v.push_back(42);}
Compiled with -O3 -fdump-tree-optimized, one can see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #20 from Marc Glisse ---
I created bug 90436 about the excessive checking so it does not distract from
the warning that this bug is about (and doesn't get lost either).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
--- Comment #1 from Marc Glisse ---
Adding
if(size()>max_size())__builtin_unreachable())
sometimes helps, depending where you add it and in what exact form.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
bool f(unsigned a, unsigned b, unsigned*c){
if(a>10)__builtin_unreachable();
if(b>10)__builtin_unreachable();
*c =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90492
--- Comment #1 from Marc Glisse ---
> copy's use only sse-registers and never higher
What do you mean by that? Do you want AVX? Then you should let the compiler
know that they are available (for instance -march=native).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90492
--- Comment #2 from Marc Glisse ---
Ah, I see, this is a DUP or PR 89226 then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90521
--- Comment #1 from Marc Glisse ---
And what do you expect std::string::basic_string means?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89713
--- Comment #4 from Marc Glisse ---
Related:
PR 89134
PR 82776
PR 67809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90447
--- Comment #2 from Marc Glisse ---
Looking at f3, in combine, for -2, we manage to match
(plus:SI (plus:SI (ltu:SI (reg:CCC 17 flags)
(const_int 0 [0]))
(reg:SI 91))
(const_int -2 [0xfffe])))
whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
--- Comment #10 from Marc Glisse ---
Author: glisse
Date: Mon May 20 14:53:29 2019
New Revision: 271422
URL: https://gcc.gnu.org/viewcvs?rev=271422&root=gcc&view=rev
Log:
[i386] Fold __builtin_ia32_shufpd to VEC_PERM_EXPR
2019-05-20 Marc Gliss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #34 from Marc Glisse ---
(In reply to Richard Biener from comment #33)
> (In reply to Stefan Vigerske from comment #32)
> > Is there any hope this could actually be improved?
> > Now, 10 years later, the FENV_ACCESS pragma seems to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #37 from Marc Glisse ---
(In reply to Richard Biener from comment #36)
> Created attachment 46396 [details]
> poor mans solution^Whack
>
> So this is what a hack looks like, basically sprinkling those asm()s
> throughout the code aut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #38 from Marc Glisse ---
(In reply to Marc Glisse from comment #37)
> If you protect even constants, the current effects of -frounding-math become
> redundant.
Oops, forget that, the hack is too late for this sentence to be true, som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600
--- Comment #3 from Marc Glisse ---
Intel documents that it uses "unsigned __int64" but I don't see where they
document what __int64 is. We could take a "void *out" argument and cast it
inside the function, but that would lose useful diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600
Marc Glisse changed:
What|Removed |Added
Keywords|ssemmx |
--- Comment #5 from Marc Glisse ---
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #12 from Marc Glisse ---
(In reply to Qi Feng from comment #11)
> I tried 2 patterns for the following test
>
> /* 1. x > y && x != 0 --> x > y */
> /* 2. y < x && x != 0 --> y < x */
> /* 3. x != 0 &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #16 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #15)
> It can matter because we might have gimplified the && to
> control flow.
Indeed. You want to look at the forwprop1 dump to see what gimple-match would
need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628
Marc Glisse changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
1001 - 1100 of 2562 matches
Mail list logo
