[Bug tree-optimization/81388] Incorrect code generation with -O1 -fno-strict-overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81388 --- Comment #3 from Marc Glisse --- (it helps to describe in what way the code is wrong, for instance in a way that makes the testcase abort) Apparently ivcanon thinks the number of iterations is constant, as it would be for the condition dst !=

[Bug tree-optimization/81346] Missed constant propagation into comparison

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346 --- Comment #6 from Marc Glisse --- (In reply to Jakub Jelinek from comment #5) > Untested WIP patch. Still no idea how to handle the build_range_check stuff > at GIMPLE, that function is pretty huge. Shall I just always generate the > cast to

[Bug middle-end/81376] unnecessary cast before comparison

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81376 --- Comment #1 from Marc Glisse --- Good timing, Yuri Gribov is working on PR57371 (the case where one side is a constant), he might be interested.

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908 --- Comment #8 from Marc Glisse --- (In reply to Yuri Gribov from comment #7) > Hm, I've just tried r249806 both with -ftree-loop-distribution and > -fno-tree-loop-distribution on top of flags above without any changes in > output. This may

[Bug c++/81371] Too many C++ templates output in build error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81371 --- Comment #5 from Marc Glisse --- Related to PR14912 (and some others). Tools like STLFilt perform this transformation for standard types (including std::string). Possibly also related to the recent work on printing template diffs.

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908 --- Comment #6 from Marc Glisse --- (In reply to Yuri Gribov from comment #5) > Well, as we all know there are a lot of missing optimizations in GCC :) I > think the real question is whether it's ever going to be fixed if there's no > standard

[Bug target/81365] [7/8 Regression] GCC miscompiles swap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81365 Marc Glisse changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908 --- Comment #4 from Marc Glisse --- (In reply to Yuri Gribov from comment #3) > As noted in comments, this is more about adding new API to Glibc than GCC > (they have corresponding > https://sourceware.org/bugzilla/show_bug.cgi?id=19920 about

[Bug driver/81358] libatomic not automatically linked with C11 code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 --- Comment #1 from Marc Glisse --- That seems similar to using sqrt, which requires explicitly linking with libm.

[Bug tree-optimization/81297] [8 Regression] ICE in get_single_symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81297 --- Comment #3 from Marc Glisse --- Ah, no, only the gimple code drops overflow, the generic code doesn't :-( I am still convinced the fix will not be in match.pd.

[Bug tree-optimization/81297] [8 Regression] ICE in get_single_symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81297 --- Comment #2 from Marc Glisse --- Strange, gimple_resimplify2 already calls drop_tree_overflow, and I am calling it myself everywhere else in this transformation... I'll have to check how exactly that OVF flag appears.

[Bug testsuite/57301] bit rotation is optimized in c but not c++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/41244] "[i] - data" isn't converted to "i"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244 --- Comment #5 from Marc Glisse --- If we write [i] - [0] instead of [i] - data, we hit the special case in fold_binary_loc /* Fold [i] - [j] to i-j. */ which leads to fold_addr_of_array_ref_difference.

[Bug c++/55203] No unused warning for variables of non-trivial types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #17 from Marc Glisse --- I wonder if attributes unused / warn_unused should be automatically inherited by classes when a member or base has it (with various rules, maybe unused has priority over warn_unused). For a tuple of locks or

[Bug c++/81250] C++ warnings about unused stl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81250 --- Comment #6 from Marc Glisse --- See PR 55203.

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81196 --- Comment #7 from Marc Glisse --- (In reply to amker from comment #6) > But below is necessary, right? > > /* { dg-require-effective-target vect_perm_short } */ Yes. Cool, I didn't remember we had exactly the right test :-) Or you could

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81196 --- Comment #5 from Marc Glisse --- (In reply to amker from comment #4) > Hmm, the function can only be vectorized with "-march=skylake"? Er, it also vectorizes without any -march on x86_64 (with shorter vectors).

[Bug tree-optimization/81196] New: Number of iterations found for p!=q but not for p

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81196 Bug ID: 81196 Summary: Number of iterations found for p!=q but not for p

[Bug tree-optimization/81181] [7/8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2410

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81181 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/79489] Strange static branch prediction for n != 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79489 --- Comment #9 from Marc Glisse --- I think we can close it, you fixed the main issue (thanks!). Were you leaving it open so someone might investigate alternate versions of the nonzero predictor?

[Bug tree-optimization/80519] if(p)free(p) with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80519 Marc Glisse changed: What|Removed |Added CC||izaberina at gmail dot com --- Comment #6

[Bug c/81166] no need to check if the pointer you pass to free is NULL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81166 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/81145] bogus "dereferencing type-punned pointer will break strict-aliasing rules" diagnostic with incomplete class type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81145 Marc Glisse changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Marc

[Bug jit/81144] New: jit.dg/test-operator-overloading.cc, initial compilation

Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- As seen for instance in https://gcc.gnu.org/ml/gcc-testresults/2017-06/msg01884.html In function 'void create_code

[Bug middle-end/40748] simple switch/case, if/else and arithmetics result in different code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40748 --- Comment #3 from Marc Glisse --- We also miss the even simpler case that should be optimized to "return n;" int foo(int n){ switch(n){ case 0: return 0; case 1: return 1; case 2:

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887 --- Comment #11 from Marc Glisse --- I haven't thought of anything significantly better than adding a counter to bound the recursion depth of calls to gimple_simplify or gimple_resimplify2. We could try to explicitly detect loops, storing in

[Bug c/81049] no warning for simple uninitialized variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81049 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/18501] [5/6/7/8 Regression] Missing 'used uninitialized' warning (CCP)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Marc Glisse changed: What|Removed |Added CC||luc.vanoostenryck at gmail dot com ---

[Bug ipa/81000] std::any improvement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81000 --- Comment #4 from Marc Glisse --- (In reply to Marc Glisse from comment #2) > (Of course, a different implementation of std::any might be easier to > optimize) >From a quick test, if instead of storing a pointer to _S_manage we store a

[Bug ipa/81000] std::any improvement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81000 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/80894] [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80894 --- Comment #8 from Marc Glisse --- Hopefully the issue is the same as in PR 80974, which does have a testcase.

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974 --- Comment #6 from Marc Glisse --- The conditions and location are probably not right, but at least the testcase passes, so this gives an idea of where the problem is. --- tree-ssa-sccvn.c(revision 248859) +++ tree-ssa-sccvn.c(working

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974 --- Comment #5 from Marc Glisse --- scc_vn_restore_ssa_info is called at the end of PRE, but we would need some form of restoration after any iteration cycle at least (or maybe we shouldn't have modified the information for h_11, I don't know).

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974 --- Comment #4 from Marc Glisse --- During iteration 1 on some loop, we get Setting value number of i_10 to h_11 (changed) which becomes Setting value number of i_10 to i_10 (changed) in later iterations. But the call to

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974 --- Comment #3 from Marc Glisse --- According to the previous dump (crited1): # RANGE [1, 9] NONZERO 15 h_11 = h_43 + 1; but when we call get_nonzero_bits on h_11 in PRE, we get 7 ???

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974 --- Comment #2 from Marc Glisse --- Ah good, a testcase, thanks. Maybe we'll understand what was breaking spec now. Transformation happens during PRE.

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887 --- Comment #10 from Marc Glisse --- Before FRE, we have the following. I marked with comments the SSA_NAMEs that are value numbered as something other than themselves. f () { unsigned int t2; unsigned int t1; int a; unsigned int u;

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887 --- Comment #9 from Marc Glisse --- C testcase that ICEs (when the patch is installed): int pos; void f(){ ++pos; unsigned u=(unsigned)pos-1; int a = pos; unsigned t1=a-1; unsigned t2=(unsigned)a-2; } where again, during FRE1,

[Bug tree-optimization/80944] redundant memcpy/memset with non-constant size not eliminated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80944 --- Comment #1 from Marc Glisse --- (In reply to Martin Sebor from comment #0) > struct S { char *s; unsigned n; }; > > void f (struct S *s) > { > __builtin_memset (s->s, 0, s->n); > __builtin_free (s->s); > __builtin_memset (s, 0, sizeof

[Bug tree-optimization/80933] redundant bzero/bcopy calls not eliminated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80933 --- Comment #2 from Marc Glisse --- I am surprised, I thought we used to canonicalize bzero to memcpy...

[Bug middle-end/80917] missed bit information propagation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80917 --- Comment #2 from Marc Glisse --- For this special case, we could simplify a_6 = a_5(D) + 4; _2 = a_6 & 2; to _2 = a_5(D) & 2; I believe we already have a similar transform with | 4 instead of + 4.

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887 --- Comment #8 from Marc Glisse --- Created attachment 41431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41431=edit Updated version of the reverted patch Here is an updated version of the reverted patch, which fixes the vector issues

[Bug tree-optimization/80898] wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80898 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/80894] [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80894 --- Comment #3 from Marc Glisse --- I built the latest version of hmmer from upstream on x86_64-linux and make check succeeded. I did it again with -O2 -ffast-math -funsigned-char in CFLAGS, and got a single failure in sse-utest both with my

[Bug tree-optimization/80894] [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80894 --- Comment #2 from Marc Glisse --- Is there a way I can reproduce that? I don't think I have access to SPEC. Would using a regular upstream hmmer work? Is that just running make test? Or do you have before/after dumps?

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887 --- Comment #5 from Marc Glisse --- (I am adding -gnatwA -gnatyN to the command line to let the reduced version compile, and -m32 is fundamental) Maybe simplifying (sizetype)_26 to _3 is fine, but it isn't fine to keep valueizing _3 and redoing

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887 --- Comment #4 from Marc Glisse --- Created attachment 41427 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41427=edit Reduced version of s-regpat.ad[bs]

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887 --- Comment #3 from Marc Glisse --- Seems to me that it is FRE valueization doing something strange. We have (not in a loop) _26 = CHAIN.23_25(D)->parse_pos; _28 = _26 + 1; CHAIN.23_25(D)->parse_pos = _28; _30 =

[Bug target/80885] New: Do not use the opaque _mm256_cmp_ps to produce -1

: target Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* Hello, in avx2intrin.h, I see a lot of __v8sf __src = _mm256_setzero_ps (); __v8sf __mask = _mm256_cmp_ps (__src, __src, _CMP_EQ_OQ

[Bug target/80862] [x86] Wrong rounding results for some test cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80862 --- Comment #1 from Marc Glisse --- Related to PR 73350.

[Bug target/68211] Free __m128d subreg of double

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68211 --- Comment #6 from Marc Glisse --- (In reply to Jakub Jelinek from comment #4) > If the upper bits of the register can contain arbitrary garbage, then > keeping it there might result in e.g. floating point exceptions being raised > (it could be

[Bug c/80852] Optimisation missed for loop with condition that is always true

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80852 --- Comment #1 from Marc Glisse --- I don't think the test on x%2 is relevant, gcc eliminates it without problem. I thought gcc had some code to recognize 1+2+3+...+n and similar patterns, but apparently not this one.

[Bug sanitizer/80847] UBSAN: yet another false positive (part2)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80847 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313 Marc Glisse changed: What|Removed |Added CC||babokin at gmail dot com --- Comment #14

[Bug testsuite/64221] contrib/compare_tests confused by c-c++-common/ubsan/shift-5.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64221 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/80821] New: genmatch conflicting predicates

Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Here is an artificial .pd file to demonstrate the issue: (match (p1 @0) INTEGER_CST@0) (match (p2 @0) REAL_CST@0) (simplify (convert (p1 @0)) @0) (simplify (convert (p2 @0)) @0

[Bug target/80817] [missed optimization][x86] relaxed atomics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80817 --- Comment #2 from Marc Glisse --- (In reply to Alexander Monakov from comment #1) > void f(volatile int *p) > { > ++*p; > } That's PR 50677 for instance. Some targets do handle it, there have been discussions in the past, this seems to

[Bug libstdc++/80811] out-of-line string members less efficient than they could be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80811 --- Comment #4 from Marc Glisse --- When user specializations are allowed, who knows what might happen. As an experiment, namespace std { extern template __attribute__((pure)) int string::compare(const char*)const; } seems to work. I think

[Bug libstdc++/80811] out-of-line string members less efficient than they could be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80811 --- Comment #2 from Marc Glisse --- Reminds me of PR 59048 and some others, except that in that one adding "pure" was not sufficient. Is "pure" true for all legal template parameters of basic_string?

[Bug c++/80792] worse code generated compared to clang when using std::tuple

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80792 --- Comment #1 from Marc Glisse --- There seems to be an ABI issue here, clang returns the tuple in a register, but (according to PR 71301) it shouldn't, with current libstdc++ code (and g++ doesn't).

[Bug c/80787] gcc -Wmaybe-uninitialized false negative when compiling Emacs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80787 --- Comment #1 from Marc Glisse --- This is a DUP of many other PRs, -fno-tree-ccp -fno-tree-vrp gives you the warning, but otherwise gcc optimises cond?value:undef to value.

[Bug target/80782] Feature request: use the llvm/clang assembler on Mac

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80782 --- Comment #3 from Marc Glisse --- (In reply to Andrew Pinski from comment #1) > The support is already there ... So, what is the correct configure option to let gcc use it by default?

[Bug tree-optimization/80740] New: Aliasing with the return value

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- struct A { int i; A():i(0){} A(A const):i(a.i){} }; A f(A){ A ret; ret.i=a.i; return ret; } We do not manage to remove

[Bug tree-optimization/80738] New: dead first stmt in a=0;a=b;b=0 whatever the aliasing

: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- In C++, with move/swap, we regularly see the following appear void f(int,int){ a=0; a=b; b=0

[Bug c++/80712] mention the name of the attribute being ignored

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80712 Marc Glisse changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #1 from Marc Glisse --- I am not sure what you expect from this PR exactly. If you have issues about glibc's implementation of malloc, please see about it with glibc (here is for gcc only). They already know about the performance

[Bug c++/80652] Union conversion between __m128d and double array does not work under 5.0 through 6.2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80652 --- Comment #1 from Marc Glisse --- I didn't study the testcase (a bit long), but I am getting the same output with any version of gcc or clang I tried, at any level of optimization. Are you certain about your example? What is the expected

[Bug target/79709] Subobtimal code with -mavx and explicit vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79709 --- Comment #7 from Marc Glisse --- Created attachment 41331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41331=edit recognize a VEC_CONCAT from a constructor (not clean) One piece of the issue is v4di = { v2di, v2di } where we

[Bug target/80527] SSE4 Compiling issue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80527 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #11 from Marc Glisse --- (In reply to Jonathan Wakely from comment #8) > Something like __builtin_unreachable() to say "trust me" would be nice, but > I can't think how to do it. Some __builtin_unreachable() in _M_get might (?) be

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #7 from Marc Glisse --- The warning comes from _Z3setiD.6701 (maybe_a$D6763$m_dummy_6); which is protected by _9 = VIEW_CONVERT_EXPR(maybe_a$4_7); if (_9 != 0) with # maybe_a$D6763$m_dummy_6 = PHI

[Bug c++/80641] Warning with std::vector resize in loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641 --- Comment #1 from Marc Glisse --- If I (very hackishly) enable A + CST CMP A -> A CMP' CST' without single_use, and (unsigned long)x==0 --> x==0, we simplify quite a bit more and the warning disappears. (and there would still be some

[Bug libstdc++/54924] Warn for std::string constructor with wrong size

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54924 --- Comment #11 from Marc Glisse --- (In reply to Jonathan Wakely from comment #10) > I'm starting to think we should just make libstdc++ headers 100% > warning-free and stop marking them as system headers with the pragmas. When > they're

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #3 from Marc Glisse --- If you mark "get" as noexcept, the warning disappears. If get throws an exception, you can very well end up running the destructor without having initialized the members. The warning seems correct to me.

[Bug target/80634] strangely missed vectorization optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80634 --- Comment #3 from Marc Glisse --- Did you also try to benchmark it? Last time I checked a similar example, both versions had similar performance.

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80617 --- Comment #4 from Marc Glisse --- MEM[(void * &)a_2(D)] = 0B; MEM[(void * &)b_3(D)] = 0B; _7 = MEM[(void * &)a_2(D)]; Indeed.

[Bug tree-optimization/80625] gcc fails to notice strdup does not modify it's argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80625 --- Comment #1 from Marc Glisse --- s might be a global variable, that foo modifies.

[Bug c/80616] Slow vector multiply compared to icc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80616 --- Comment #3 from Marc Glisse --- Intel defaults to the equivalent of -ffast-math, did you try with that?

[Bug c++/80561] Missed optimization: std::array data is aligned if array is aligned

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561 --- Comment #6 from Marc Glisse --- (In reply to rguent...@suse.de from comment #5) > I'm sure a microbench would show that makes a difference. A micro-benchmark on skylake with -march=native (using just -mavx2 is worse for gcc without

[Bug c++/80599] -Wuseless-cast triggers for inherited constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80599 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/70844] spurious -Wuseless-cast warning with inherited constructors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70844 --- Comment #2 from Marc Glisse --- *** Bug 80599 has been marked as a duplicate of this bug. ***

[Bug libstdc++/79349] unused std::string is not optimized away in presense of a call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79349 --- Comment #4 from Marc Glisse --- With the call to foo(), this is an issue of alias analysis. Gcc wrongly believes that the string escapes (probably because we store a pointer to the string inside the string itself, with the small string

[Bug c++/80561] Missed optimization: std::array data is aligned if array is aligned

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561 --- Comment #4 from Marc Glisse --- Cool, that matches pretty much exactly the analysis I had posted on stackoverflow ;-) A separate issue from whether we can somehow propagate the alignment information is what we do without the alignment

[Bug tree-optimization/80588] GCC can't simplify static inline function with xor/xnor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80588 --- Comment #1 from Marc Glisse --- Thanks. Let me copy what I had in the other PR: we have an old optimization in fold_unary (like other "do ... if ... simplifies" it is not straightforward to move it to match.pd) and thus it only applies when

[Bug tree-optimization/80574] GCC fail to optimize nested ternary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574 --- Comment #4 from Marc Glisse --- (In reply to SztfG from comment #3) > Georg-Johann Lay, GCC not always do things better if use static inline > function instead macro. He did not claim it was always better... > For example, this code:

[Bug middle-end/80584] New: Combine some float tests using bit ops

Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* Some (ieee) float tests amount to bit operations, and some of the usual optimizations on bit operations

[Bug target/80582] New: Missing intrinsics _mm256_set_m128*

Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* Apparently, Intel and clang have added a few intrinsics that we do not have, like _mm256_set_m128. See http://lists.llvm.org/pipermail/cfe-commits/Week

[Bug libstdc++/80579] std::vector::reserve should not require T to be moveable.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80579 --- Comment #2 from Marc Glisse --- I think there were discussions a couple years (?) ago in the committee about extending std::vector for types that do not satisfy its current requirements. I remember roughly 3 options: - relax restrictions on

[Bug tree-optimization/80574] GCC fail to optimize nested ternary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574 --- Comment #1 from Marc Glisse --- With -fdump-tree-original, the signed case looks perfect: return MAX_EXPR , a1>, a3>, a2>, a1>; (which reassoc eventually simplifies) while in the unsigned case, we fail to recognize the innermost max:

[Bug tree-optimization/80487] redundant memset/strncpy calls not eliminated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80487 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/80487] redundant memset/strncpy calls not eliminated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80487 --- Comment #3 from Marc Glisse --- Author: glisse Date: Sat Apr 29 14:39:25 2017 New Revision: 247408 URL: https://gcc.gnu.org/viewcvs?rev=247408=gcc=rev Log: Add st[pr]ncpy to stmt_kills_ref_p 2017-04-29 Marc Glisse

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80553 --- Comment #3 from Marc Glisse --- __has_trivial_destructor(Foo) returns true for Foo which has a deleted destructor (clang, gcc and the standard agree on this). That's bound to confuse people forever, but I guess there's nothing we can do

[Bug c++/80527] SSE4 Compiling issue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80527 --- Comment #2 from Marc Glisse --- 4.8 is not maintained anymore, and I think this is already fixed in 4.9. Can you check with a newer compiler?

[Bug tree-optimization/80519] if(p)free(p) with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80519 --- Comment #3 from Marc Glisse --- A warning would be quite a different thing. You would want it in the front-end, to detect when a user literally wrote if(p)free(p). What I am interested in is an optimization that detects when, possibly after

[Bug tree-optimization/80520] [7/8 Regression] Performance regression from missing if-conversion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80520 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/80519] New: if(p)free(p) with -Os

Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- It is quite common to end up with a call to free protected by a check that the pointer is not 0. This can be done because of old implementations

[Bug target/80517] [missed optimization] constant propagation through Intel intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80517 --- Comment #1 from Marc Glisse --- Several of those intrinsics are implemented using vector extensions and constant propagation works fine on those. What seems to be missing here is constant folding of the very specific

[Bug c/80515] __attribute__ ((__noreturn__)) false alarm for 'main'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80515 --- Comment #2 from Marc Glisse --- The implicit "return 0;" is only in C++ IIRC. I vaguely remember discussions advertising the use of noreturn on main to indicate that the compiler does not need to emit the cleanup/exit code for global

[Bug tree-optimization/80511] [8 Regression] gcc.dg/Wstrict-overflow-18.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80511 --- Comment #1 from Marc Glisse --- https://gcc.gnu.org/viewcvs/gcc?view=revision=247123

[Bug tree-optimization/80511] New: [8 Regression] gcc.dg/Wstrict-overflow-18.c

: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- I will soon commit a patch that breaks (and xfails) gcc.dg/Wstrict-overflow-18.c, see https://gcc.gnu.org/ml/gcc-patches/2017-04

<    5   6   7   8   9   10   11   12   13   14   >