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
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=gcc=rev
Log:
Use __restrict for __relocate_object_a
2019-04-27 Marc Glisse
PR
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 *)] = 1;
_3 = apart.D.2494.contam_level;
Second issue is
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=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=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=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
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=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=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
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://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=89809
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89749
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89745
Marc Glisse changed:
What|Removed |Added
Keywords||ABI
--- Comment #3 from Marc Glisse ---
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
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=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=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=89479
Marc Glisse changed:
What|Removed |Added
Keywords||alias, missed-optimization
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=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=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=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 = [(void *)this_5(D) + 16B];
_2
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=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
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=89226
--- Comment #1 from Marc Glisse ---
The optimized dump for copy1 looks like
*to_2(D) = *from_3(D);
so we get essentially memcpy, while copy2 has
_4 = MEM[(const struct foo512 &)from_3(D)].a;
MEM[(struct foo512 *)to_2(D)].a = _4;
_5 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
--- Comment #8 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #7)
> So I guess I could revert r268537 then.
I don't think it was worth spending time on in the first place, but now that
you have written it, it isn't as bad as I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
--- Comment #6 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #5)
> Looking at the standard, the requirements for the push_back call in comment
> 0 are that X is Cpp17CopyInsertable into vector, which is true. The check
> whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #18 from Marc Glisse ---
Author: glisse
Date: Tue Feb 5 09:33:36 2019
New Revision: 268532
URL: https://gcc.gnu.org/viewcvs?rev=268532=gcc=rev
Log:
Rename __is_trivially_relocatable to __is_bitwise_relocatable.
2019-02-05 Marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89192
--- Comment #3 from Marc Glisse ---
On the other hand, it looks like an "easy" case where the front-end could
notice that we are using b as an rvalue before it is initialized and warn about
it without relying on the middle-end. It could fall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89184
--- Comment #1 from Marc Glisse ---
So in high level terms (let's not do asm when we don't need to), you want
((i >> 1) & 3) == 2
replaced with
i & (3 << 1) == (2 << 1)
(as long as (i>>1) and (i>>1)&3 are not used for anything else)
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66459
Marc Glisse changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #5 from Marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89160
--- Comment #2 from Marc Glisse ---
Thanks, yes, that's an exact duplicate that I failed to find despite several
searches in bugzilla :-(
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
A random testcase to illustrate:
[[hahaha]] int i;
$ g++-snapshot a.c -c -std=gnu++2a
a.c:1:16: warning: 'hahaha' attribute directive ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #12 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #11)
> I think there are cases where we set useful range even on other SSA_NAMEs
> than the single one used in the condition, and in some cases it should be
> good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #9 from Marc Glisse ---
--- gimple-ssa-evrp-analyze.c (revision 268474)
+++ gimple-ssa-evrp-analyze.c (working copy)
@@ -217,7 +217,8 @@ evrp_range_analyzer::record_ranges_from_
push_value_range (vrs[i].first,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89155
--- Comment #1 from Marc Glisse ---
Trying 7 -> 9:
7: r87:V4SF=vec_merge(unspec[r86:V4SF] 45,r86:V4SF,0x1)
REG_DEAD r86:V4SF
9: r88:SF=vec_select(r87:V4SF,parallel)
REG_DEAD r87:V4SF
Failed to match this instruction:
(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #5 from Marc Glisse ---
IIUC, EVRP sees if(x!=3)__builtin_unreachable() and adds a range [3,3] on x.
The condition thus gets cleaned up and __builtin_unreachable disappears. This
could be fine, except that x has a single use, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89127
--- Comment #2 from Marc Glisse ---
The warning is not about all comparisons that are always true/false, only about
the case where this is "due to the limited range of the data type" (let me
stress **type**). Only the first of your examples has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
--- Comment #3 from Marc Glisse ---
We already discussed this
https://gcc.gnu.org/ml/libstdc++/2018-09/msg7.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
--- Comment #4 from Marc Glisse ---
This looks like a target issue, gcc does produce a call to sincos here. So
please specify your target precisely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89120
--- Comment #1 from Marc Glisse ---
First there is the issue of iterator vs value, as in your other PR.
The performance of minmax depends a lot on the element type and the
distribution. The standard requires that we perform only 3n/2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89121
--- Comment #2 from Marc Glisse ---
If you write:
auto mins = *std::min_element(f.begin(), f.end());
so that you ask for the value, the benchmark now says the perf is exactly the
same for the 2 versions. I would close this as invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89113
--- Comment #2 from Marc Glisse ---
That seems already fixed in gcc-9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065
--- Comment #1 from Marc Glisse ---
iterator and const_iterator are the same type for std::set, the elements are
always immutable...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88840
--- Comment #9 from Marc Glisse ---
Thank you for handling it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88840
--- Comment #5 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #4)
> And two more similar errors. We need to support incomplete types, so we need
> to delay the evaluation of __relocatable until it's needed.
Sorry, I forgot about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89035
--- Comment #1 from Marc Glisse ---
We already have
int x = x;
for one of those, no? Or just
int x;
but it tends to warn.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #52 from Marc Glisse ---
(In reply to Thomas Koenig from comment #49)
> Argh. Sacrificing performance for the sake of bugware...
But note that in this PR (specifically for avx512 vectors on this cpu), the OP
says that the recip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88828
Marc Glisse changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #33 from Marc Glisse ---
(In reply to Chris Elrod from comment #32)
> (In reply to Marc Glisse from comment #31)
> > What we need to understand is why gcc doesn't try to generate rsqrt
Without -mavx512er, we do not have an expander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88998
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #31 from Marc Glisse ---
(In reply to Chris Elrod from comment #30)
> gcc caclulates the rsqrt directly
No, vrsqrt14ps is just the first step in calculating sqrt here (slightly
different formula than rsqrt). vrcp14ps shows that it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #29 from Marc Glisse ---
The main difference I can see is that clang computes rsqrt directly, while gcc
first computes sqrt and then computes the inverse. Also gcc seems afraid of
getting NaN for sqrt(0) so it masks out this value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #7 from Marc Glisse ---
See PR 55266 (and several others).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
Marc Glisse changed:
What|Removed |Added
Component|libstdc++ |ipa
--- Comment #34 from Marc Glisse ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88926
--- Comment #1 from Marc Glisse ---
With similar changes, I analyzed gcc.dg/vect/pr25413a.c (which we then fail to
vectorize). I expect the issue is similar. In scalar evolution, we get a
polynomial_chrec of type unsigned long wrapped in a
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Starting from gcc.dg/tree-ssa/ivopts-lt-2.c:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-ivopts" } */
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32628
--- Comment #12 from Marc Glisse ---
Nowadays, we consider that we can only access half of the address space, and
you can only add up to PTRDIFF_MAX to a pointer, so in some sense this does
overflow. I am thinking of removing the testcase, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
--- Comment #31 from Marc Glisse ---
Adding "inline" to _M_construct does convince the inliner to proceed, but I
don't know if that would cause too much bloat in other code, it would be best
if IPA somehow guessed that this case is interesting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #35 from Marc Glisse ---
I just noticed that Jonathan has already written such a patch in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590#c28 but didn't commit it
(maybe because is_constant_evaluated was not committed yet, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #33 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #8)
> I think there was a bug report in the last month or so asking for some
> builtin to detect when we're in a constexpr context.
Now that we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #16 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #15)
> @Marc, it only now occurs to me that if libstdc++ uses
> `__is_trivially_relocatable` as its userspace type-trait name, then GCC
> won't be able to use
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
typedef int64_t v64 __attribute__((vector_size(16)));
typedef int32_t v32 __attribute__((vector_size(16)));
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88918
Bug 88918 depends on bug 59071, which changed state.
Bug 59071 Summary: sse2 intrinsics and constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59071
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59071
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
--- Comment #5 from Marc Glisse ---
(In reply to Martin Sebor from comment #2)
> The warning is not specific to C++ but triggers for C code as well
True, but C++ templates somehow make this different. In C, you could use the
preprocessor to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #18 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #17)
> Without the #c11 patch (+ removal of the !INTEGRAL_TYPE_P special case from
> the above committed change + fixing up ptrs_compare_unequal, or something
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88868
Marc Glisse changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88840
--- Comment #3 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #0)
> We could constrain the declaration with SFINAE, but the program would still
> be ill-formed (you still can't ask if the construct() call would throw,
> because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88738
--- Comment #8 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #7)
> Yes, I would guess that clang's "dumb" warning is fine for 99% of cases, and
> the handful of exceptions could use #pragma to disable the warning.
Or an
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
int g (int a, int *v)
{
v[0] = a;
v[1] = 0;
while (v[0]-- > 0)
v[1] += v[0];
return v[1];
}
With -O2, ivopts replaces "if (_18 > 0)" with &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88664
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80517
--- Comment #6 from Marc Glisse ---
(In reply to Matthias Kretz from comment #4)
> A similar test case showing that something is still missing
You don't seem to be passing constants here, so this is unrelated to this PR.
If you file a new one,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80517
--- Comment #5 from Marc Glisse ---
(In reply to Matthias Kretz from comment #3)
> GCC 9 almost resolves this. However, for some reason this extended test case
> is not fully optimized: https://gcc.godbolt.org/z/jRrHth
> i.e. the call to
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
#undef _GLIBCXX_EXTERN_TEMPLATE
#define _GLIBCXX_EXTERN_TEMPLATE 0
#include
__attribute__((flatten))
std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314
--- Comment #3 from Marc Glisse ---
It isn't just with malloc, the following are not optimized either.
int f(){ int a; return =="hello"; }
int g(){ return "bye"=="hello"; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88737
--- Comment #5 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #3)
> Indeed. So it would be
>
> *a = {CLOBBER};
>
> which is of course somewhat difficult since we do not know the size
> of the object pointed to.
One thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88732
--- Comment #1 from Marc Glisse ---
Why not read the documentation for that function?
"If x is 0, the result is undefined."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #4 from Marc Glisse ---
(In reply to Matthias Kretz from comment #3)
> Did you consider the error introduced by scaling with __amax? I made sure
> that the division is without error by zeroing the mantissa bits. Here's a
> motivating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #9 from Marc Glisse ---
(In reply to Devin Hussey from comment #2)
> What I am saying is that I think -flax-vector-conversions should be default,
> or we should only have minimal warnings instead of errors.
>
> That will make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #1 from Marc Glisse ---
It would help if you could write some (very short) functions illustrating the
behavior you are requesting. "convert", "compatible" all depend about the
context in which they appear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88683
--- Comment #1 from Marc Glisse ---
DUP of PR 88173?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88626
--- Comment #5 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> The __builtin_constant_p call itself is "free" but whether guarded code is
> "free" isn't easy to determine. I guess what you want is the computation
> of "b"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
--- Comment #8 from Marc Glisse ---
Created attachment 45306
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45306=edit
ix86_gimple_fold_builtin patch
Like this then?
I realized (because of the testsuite) that we do not currently validate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
--- Comment #6 from Marc Glisse ---
Created attachment 45303
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45303=edit
example patch (untested)
Making the meaning of shuffles visible in GIMPLE could help a bit (although it
wouldn't solve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88626
--- Comment #1 from Marc Glisse ---
In my application (quite a bit bigger than the testcase...), looking at the
optimized dump, I see that the function is inlined without the
__builtin_constant_p code, but when I add the __builtin_constant_p
: missed-optimization
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
void h(int);
inline void f(int n){
#if 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88601
--- Comment #1 from Marc Glisse ---
__builtin_convertvector is a dup of at least PR85052 and PR61731.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88598
--- Comment #1 from Marc Glisse ---
-funroll-loops helps (I expect that's what llvm does).
float j[5] = {}; also helps. We should probably simplify {0,0,...} to {}, but
then we would still be missing the optimization for {1,1,...} where we would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #14 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #12)
> Whether or not to fix as well as whether or not to warn at -O0 are a topic
> of debate. I'm not sure I'm up for re-opening that can of worms right now.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88542
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #10 from Marc Glisse ---
IMO -Wmaybe-uninitialized should not be enabled by -Wall, whatever the
optimization level (even at -O3), it has too many false positives that are all
but impossible to work around (thus violating the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #4 from Marc Glisse ---
(In reply to Jonny Grant from comment #3)
> Updated output I had executed from STL with clear candidate suggestions:
>
> $ g++ -Wall -o stl_string stl_string.cpp
> stl_string.cpp: In function ‘int main()’:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #2 from Marc Glisse ---
As someone who regularly has to debug complicated template code, I think all
the information printed by g++ here is useful. There may be more compact ways
of giving the same information (use a shorthand for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88499
--- Comment #2 from Marc Glisse ---
I don't think using fenv.h with -ffast-math makes much sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88301
--- Comment #3 from Marc Glisse ---
(In reply to Marc Glisse from comment #2)
> Not sure where this [0, 0] range is coming from...
Well, I guess it is EVRP trying to encode __builtin_unreachable for _3!=0 in
the range information of _3, but not
401 - 500 of 2560 matches
Mail list logo
