Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
#include
#include
#include
#include
int main(){
const long n = 1;
std::vector> vec;
vec.reserv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
--- Comment #8 from Marc Glisse ---
Thank you.
I originally noticed the problem with 11.2.0-18 (Debian), so I believe this
will be needed on that branch as well. 10.3.0 looked ok...
-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
The testcase is essentially the same as in PR105053, but here this is about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105062
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> But since not all of the std::max are recognized as
> MAX_EXPR but some only after loop if-conversion
Ah, I hadn't noticed. I tried replacing std::max with a sim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100929
--- Comment #6 from Marc Glisse ---
(blend is now lowered in gimple)
For the integer case, the mix of vector(int) and vector(char) obfuscates things
a bit, we have
__m256i if_else_int (__m256i x, __m256i y)
{
vector(32) char _4;
vector(32)
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Hello,
with a balanced binary tree, as used for instance in std::set or std::map, it
is relatively easy to perform an operation in parallel on all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105308
--- Comment #2 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #1)
> I'm unclear what the request is.
The list isn't super clear to me either, any sensible specialization of a
standard algorithm for a standard container. Even sim
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(from https://stackoverflow.com/q/73407636/1918193 )
#include
#include
#include
struct Foo {
auto join() const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247
Marc Glisse changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Marc Glisse ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
--- Comment #11 from Marc Glisse ---
(In reply to Segher Boessenkool from comment #8)
> Thanks for the pointer, I'll find Marc's work.
Since I had forgotten where it was, let me write here that it is git branch
/users/glisse/fenv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #2 from Marc Glisse ---
A problematic optimization pointed in the discussion:
(simplify
(cmp @0 REAL_CST@1)
[...]
(if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1))
&& !tree_expr_signaling_nan_p (@1)
&& !tree_expr_mayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
--- Comment #8 from Marc Glisse ---
(simplify
(bit_not (bit_not @0))
@0)
while in an other place we have
(simplify
(bit_and @0 integer_all_onesp)
(non_lvalue @0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
--- Comment #11 from Marc Glisse ---
Did you try adding "non_lvalue" in match.pd? It looks less intrusive. Although
in the long term your approach seems better and the failures should be fixable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
--- Comment #13 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #12)
> Doing it on the match.pd side doesn't look right, there could be many other
> optimizations that result in something similar.
$ grep -c non_lvalue match.pd
1
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
One irritation with warnings like -Wuse-after-free and all the other
optimization-based warnings is how hard they are to track. Yes, it tells me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107184
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> Confirmed - for array-bounds I added some "array-bound warning for %E"
> printing the SSA name/stmt in the dump file.
Sounds good, I'll try that next time the wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54346
--- Comment #6 from Marc Glisse ---
The log says that this breaks tree-ssa/forwprop-19.c, but I don't see any xfail
or anything. Does it only fail because gimple-simplify leaves some dead code
around, so you could update the test to scan the next
: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
This is reduced from valid code (I think) and it still compiles with "g++ -c
-w" or &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #1 from Marc Glisse ---
A different reduction from the same code. This one does not compile with clang
anymore. ICEs with -Wall -W, but not if I remove one of them.
using mp_false = struct mp_identity { using type = void; };
templat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #2 from Marc Glisse ---
And the stack trace for comment #1
Internal compiler error: Error reporting routines re-entered.
0xff6b0d tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:16068
0xff5f6d tsubst(t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #3 from Marc Glisse ---
comment #1 actually reduces to
struct voider {
using type = void;
};
template struct rename : P {};
template using ignore = voider;
template typename ignore::type>::type g(T a) {}
void f() { g(1); }
(st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #4 from Marc Glisse ---
https://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/mybug.cc.xz
(1.7M after compression still exceeds the limit)
With -Wall -Wextra
Internal compiler error: Error reporting routines re-entered.
0xec0348
-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
template
struct L: M {
using M::a;
void p() { this->template a<>; }
};
(accepted by g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104239
--- Comment #2 from Marc Glisse ---
Thanks for fixing that bug, but don't you still have issues with
NO_WARN_X86_INTRINSICS if you rely on __has_include for immintrin.h?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104361
--- Comment #2 from Marc Glisse ---
I looked at this paper for a different project a while ago, and it doesn't seem
like such a good match for C++ in general. While the basic idea looks simple
(use 2 counters, one for the thread that created the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389
--- Comment #6 from Marc Glisse ---
Not this bug, but note that the comment and the code don't match in this
transformation: "a negative value" becomes !tree_expr_maybe_real_minus_zero_p
(@0) which is quite different. I am not sure the path with
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(from a comment in PR 104389)
/* Maybe fold x * 0 to 0. The expressions aren't the
++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Libstdc++ uses __SANITIZE_ADDRESS__ to detect if ASAN is enabled, but with
clang that should be __has_feature(address_sanitizer). This means that
_GLIBCXX_SANITIZE_STD_ALLOCATOR is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653
--- Comment #6 from Marc Glisse ---
(In reply to Andrew Pinski from comment #5)
> Is there anything more to do for this?
Yes. This PR is about having the library reorder the elements of a tuple to
minimize the size, and the current code does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90433
--- Comment #3 from Marc Glisse ---
(In reply to Andrew Pinski from comment #2)
> The trunk we don't vectorize the code any more .
I thought it might be because we found a way to use memcpy instead, which would
have been good, but no, the ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
Marc Glisse changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97868
--- Comment #6 from Marc Glisse ---
(In reply to pavlick from comment #5)
> Why is there false positive and no warning about the unsupported feature
> (atomic_thread_fence)?
You are probably using an old version of gcc. With a recent one, this p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
--- Comment #6 from Marc Glisse ---
(In reply to Andrew Pinski from comment #5)
> Hmm, Did something change in make?
It looks like make now splits -j from other flags in MFLAGS, -wkj becomes -kw
-j, so the old filters probably work now...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102760
--- Comment #3 from Marc Glisse ---
(In reply to Martin Liška from comment #2)
> Likely triggered with r7-821-gc7986356a1ca8e8e.
>From Andrew's comment, it looks like the bug is before that transformation,
since it receives a bit_and_expr of ty
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
In some C++ code I have, it would be convenient if the compiler, possibly with
the help of the standard library, could make the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
--- Comment #5 from Marc Glisse ---
typedef signed char v16qs __attribute__((vector_size(16)));
auto bar(v16qs x) { return x < 48; }
clang does expand it as 48 gt x. Gcc however does its usual change to x <= 47,
which it then tries to expand as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
--- Comment #7 from Marc Glisse ---
(Wilhelm, when you post testcases, please post the full file including the
#include lines)
(In reply to Richard Biener from comment #5)
> Did you try -fstrict-enums?
IIUC, even if optimizations using -fstric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107663
--- Comment #1 from Marc Glisse ---
Gcc often ignores the control flow for alias/escape analysis. v escapes at some
point, and that's enough to prevent gcc from noticing that nothing can have
written to v *before* the use. The same thing also hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
--- Comment #11 from Marc Glisse ---
(In reply to Richard Biener from comment #10)
> Should be fixed in GCC 13.
If I compile the original testcase with -O3, I get for test2:
_1 = this_6(D) + 16;
_2 = &this_6(D)->data1;
if (_1 != _2)
so w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190
--- Comment #6 from Marc Glisse ---
Indeed, this looks like a common issue (at least with the x86 backend): the
memory load is combined with the comparison before we try combining the
comparison with the blend, and this last combination is then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #10 from Marc Glisse ---
(In reply to AK from comment #9)
> can't repro this with gcc 12.1 Seems like this is fixed?
No. As stated in other comments, it still reproduces with a longer string (or
with -D_GLIBCXX_USE_CXX11_ABI=0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101501
--- Comment #2 from Marc Glisse ---
unsigned char a = 55;
int main() {
unsigned char c;
d:
c = a-- * 52;
if (c)
goto d;
__builtin_printf("%d\n", a);
}
outputs 40 at -O3 instead of 255, and already fails with gcc-8. Cunroll seems
co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49908
--- Comment #5 from Marc Glisse ---
(In reply to Andrew Pinski from comment #4)
> GCC builds now with the c++ which means this won't show up.
Just because g++ has an implicit -lm doesn't mean that any random 3rd-party C++
compiler does too.
(I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #25 from Marc Glisse ---
Note that this also affects dynamic linking with -Wl,--as-needed (which some
platforms use by default).
#include
int main(){
std::once_flag o;
std::call_once(o, [](){});
}
$ g++ b.cc -lpthread && ldd ./
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #27
-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
Stealing the example from PR 56873
#define SIZE 32
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56873
Marc Glisse changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101611
--- Comment #5 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #2)
> for arithmetic V[24]DImode >> V[24]DImode
> logical ((x >> y) ^ (0x8000ULL >> y)) - (0x8000ULL
> >> y)
> can be used.
I guess it would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101611
--- Comment #7 from Marc Glisse ---
The same strategy to implement arithmetic shift in terms of logical shift works
not just for vector>>vector but also vector>>scalar and scalar>>scalar. But it
is probably not worth the trouble indeed, especial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91099
Marc Glisse changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 fr
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
bool f(char* p, long n)
{
bool r = true;
for(long i = 0; i < n; ++i)
r &= (p[
++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(adapted from https://stackoverflow.com/q/68517921/1918193)
#ifdef WORK
#include
typedef std::array vec;
#else
typedef char vec __attribute__((vector_size(16)));
#endif
constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659
--- Comment #1 from Marc Glisse ---
I already see some "__glibcxx_assert(this->_M_is_engaged());" in the code,
which IIUC should be enabled by _GLIBCXX_ASSERTIONS (and a fortiori by
_GLIBCXX_DEBUG). Did you actually try it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94356
--- Comment #6 from Marc Glisse ---
(In reply to Andrew Pinski from comment #5)
> Hmm, the following is worse:
That looks like a separate issue. We have fold_comparison for GENERIC, and
match.pd has related patterns for integers, or for pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101795
--- Comment #1 from Marc Glisse ---
Hint: -fno-trapping-math lets it compile.
It should probably be accepted in a manifestly_const_eval context, although
some in the committee wanted to prevent the use of NaN (and sometimes even
infinity!) in co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
--- Comment #17 from Marc Glisse ---
(In reply to Hongtao.liu from comment #15)
> The issue can also be solved by folding __builtin_ia32_shufps to gimple
> VEC_PERM_EXPR,
Didn't you post a patch to do that last year? What happened to it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 57176, which changed state.
Bug 57176 Summary: copy elision with function arguments passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176
Marc Glisse changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116510
--- Comment #7 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> the issue is that with_possible_nonzero_bits2 also supports SSA_NAMEs, so
> @1 cannot be used like this.
It has only 2 cases, and both imply INTEGER_CST, if I in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #26 from Marc Glisse ---
(In reply to CVS Commits from comment #22)
> While the design of these builtins in clang is questionable,
> rather than being say
> unsigned __builtin_addc (unsigned, unsigned, bool, bool *)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119690
--- Comment #3 from Marc Glisse ---
> Originally we compute { 0, +, 1 } here, now in the first iteration
> we do 0 - -2147483648.
Looking only at what you posted, I'd say
_3 is -2147483647
_4 is 0
_7 is computed either as 0 + 1 or -2147483647 -
2501 - 2562 of 2562 matches
Mail list logo
