[Bug testsuite/82951] gcc.c-torture/execute/20040409-1.c undefined behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82951 --- Comment #1 from Marc Glisse --- Or I should just add -fwrapv since those tests were added to test an RTL transformation ( https://gcc.gnu.org/ml/gcc-patches/2004-04/msg00615.html ).

[Bug testsuite/82951] New: gcc.c-torture/execute/20040409-1.c undefined behavior

Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- While testing a VRP patch, I had failures for gcc.c-torture/execute/20040409-[1-3].c. If I run them with -fsanitize=undefined, I get 20040409-1.c:27:12: runtime

[Bug bootstrap/82948] New: [8 Regression] prefix.c:202:15: error: 'char* strncpy(char*, const char*, size_t)' destination unchanged after copying no bytes [-Werror=stringop-truncation]

=stringop-truncation] Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot

[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #1 from Marc Glisse --- Is that during stage 1 or in a later stage?

[Bug target/82935] Unnecessary "sub rsp, 8", "call" and "add rsp, 8" instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82935 --- Comment #4 from Marc Glisse --- We keep *a1_2(D) = *a2_3(D); and only at expansion time turn it into a call to memcpy, so the gimple pass that detects tail calls doesn't have a chance to notice this case.

[Bug middle-end/82898] Aliasing knowledge is not used to replace memmove with memcpy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898 --- Comment #1 from Marc Glisse --- At least in the gcc model, the type of a pointer is meaningless as long as you do not dereference it using that type, so I am not sure what can be done here.

[Bug c++/82888] terrible code generation for initialization of POD array members vs. clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82888 --- Comment #4 from Marc Glisse --- The front-end internally uses VEC_INIT_EXPR, and gimplifies it to a loop. I believe we should end up with an empty CONSTRUCTOR instead.

[Bug middle-end/82885] memcpy does not propagate aliasing knowledge

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82885 --- Comment #1 from Marc Glisse --- gcc (illegally) generates some calls to memcpy(p,q,n) where p and q may be the same pointer, although they mustn't overlap in any more complicated way. That makes such an optimization problematic (although

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #11 from Marc Glisse --- (In reply to Wilco from comment #9) > It works for any C where (divisor*C) MOD 2^32 == 1 (or -1). For x%3==0, i.e. z==0 for x==3*y+z with 0<=y<5556 and 0<=z<3. Indeed, x*0xaaab==y+z*0xaaab is in

[Bug target/82858] __builtin_add_overflow() generates suboptimal code with unsigned types on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858 --- Comment #4 from Marc Glisse --- unsigned c; unsigned d = __builtin_add_overflow(a, b, )?-1:0; return c|d; gives the expected asm. Ideally phiopt would recognize a saturing add pattern, but we have nothing to model it in gimple.

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #7 from Marc Glisse --- Is that a special case of a more generic transformation, which might apply for other values of 3, 0, == etc, or is this meant only literally for x%3==0?

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

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

[Bug c/82845] -ftree-loop-distribute-patterns creates recursive loops on function called "memset"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82845 Marc Glisse changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Marc Glisse

[Bug c/82845] -ftree-loop-distribute-patterns creates recursive loops on function called "memset"

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

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Marc Glisse changed: What|Removed |Added CC||david at westcontrol dot com --- Comment

[Bug middle-end/82839] missing -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839 --- Comment #1 from Marc Glisse --- You can simplify the function to int ts; g(); *t = ts; h(); Part of the analysis is not flow-sensitive: we see that ts escapes, we deduce that g() can write to it, so ts might be initialized and we

[Bug target/82830] New: short rotate with truncated length

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* #include unsigned short f(unsigned short x,int n){ return _rotwl(x,n&15); } andl$15,

[Bug c++/82818] Bad Codegen, delete does not check for nullptrs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82818 --- Comment #3 from Marc Glisse --- Please read the documentation for -flifetime-dse, your code is invalid.

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776 --- Comment #8 from Marc Glisse --- At some point, we could also think of taking advantage of what the C++ standard (for instance) says: "[intro.progress] The implementation may assume that any thread will eventually do one of the following:

[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82781 Marc Glisse changed: What|Removed |Added Known to work||5.4.0 Target Milestone|---

[Bug c++/82781] Vector extension operators return wrong result in constexpr

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

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776 --- Comment #1 from Marc Glisse --- That could be because gcc sadly refuses to optimize away infinite loops (happens for other cases, and cddce2 dump (the pass that removes the whole thing when the macro is defined) says "can not prove

[Bug c++/82760] Incorrect code generated for aligned new

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82760 --- Comment #2 from Marc Glisse --- In cp/call.c: - (**args)[0] = *size; + const_cast((*cand->args)[0]) = *size; since in the aligned case we are using a copy align_args of the arguments. Of course it should be done in

[Bug c++/82760] Incorrect code generated for aligned new

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

[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735 --- Comment #3 from Marc Glisse --- Actually, what CSE1 does might be fine, and it is LRA that should have noticed that the register it assigned was clobbered, so it should have spilled (or better rematerialized). Assuming the i386 backend does

[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers

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

[Bug tree-optimization/82732] malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732 --- Comment #2 from Marc Glisse --- If you use size_t consistently (for size and i), then the resulting code is a call to calloc.

[Bug tree-optimization/82732] malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732 --- Comment #1 from Marc Glisse --- We do recognize the memset early enough. What we fail to recognize is that the size argument to malloc is the same as the length of the memset: _1 = (long unsigned int) size_8(D); _2 = _1 * 4; p_11 =

[Bug inline-asm/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 --- Comment #3 from Marc Glisse --- On x86, by default, the compiler already assumes that flags are clobbered. That's explained in a comment in GMP's longlong.h at least.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #32 from Marc Glisse --- (In reply to Misty De Meo from comment #31) > For what it's worth, Apple's response was: "We analyzed the issue and > determined the problem to be a latent bug in gcc’s build system that is > revealed by

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #30 from Marc Glisse --- (In reply to Francois-Xavier Coudert from comment #29) > The result of "make -d --trace -j8 all-target-libstdc++-v3", in a build > where x86_64-apple-darwin17.0.0/libstdc++-v3 was entirely removed, can be >

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #28 from Marc Glisse --- I am also failing to see how this can happen without a bug in make or macos. The failing command is the recipe for ${pch1b_output}. That rule has ${allstamped} as a dependency, which includes stamp-bits-sup,

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80511 Marc Glisse changed: What|Removed |Added Summary|[8 Regression] |[8 Regression]

[Bug target/82498] Missed optimization for x86 rotate instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498 --- Comment #10 from Marc Glisse --- f1...f6 already have a LROTATE_EXPR in the .original dump. The others don't get one until forwprop1, which is after einline, so there is a small chance of inlining causing other optimizations that mess with

[Bug target/82498] Missed optimization for x86 rotate instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498 --- Comment #7 from Marc Glisse --- (In reply to Uroš Bizjak from comment #6) > You can use __rol{b,w,d,q} and __ror{b,w,d,q} (and their aliases) from > ia32intrin.h. These are standardized; you have to include x86intrin.h header. Some of those

[Bug target/82498] Missed optimization for x86 rotate instruction

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

[Bug c++/82505] g++ -O3 -funroll-loops generates weird code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82505 --- Comment #2 from Marc Glisse --- dest/src might alias anything (even themselves), so the compiler can't really optimize much.

[Bug middle-end/82504] Optimize away exception allocation and throws handled by catch(...){}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82504 --- Comment #3 from Marc Glisse --- Dup of PR53294?

[Bug libstdc++/82470] Structured bindings don't work with std::tuple if a type has a get member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470 --- Comment #3 from Marc Glisse --- As with all the issues caused by the EBCO in std::tuple, I believe the answer is PR 63579 (I think it can be done in a way that preserves the layout of tuple).

[Bug ipa/82476] C++: Inlining fails for a simple function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82476 --- Comment #2 from Marc Glisse --- What is the point of inlining it? It isn't a hot call (called once from main). And unless you are using something like -flto of -fwhole-program (which would turn the function static), it has to be emitted as a

[Bug tree-optimization/82434] -fstore-merging does not work reliably.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82434 --- Comment #2 from Marc Glisse --- -Dbool=char lets it merge the stores, I guess this is because bool has precision < bitsize.

[Bug target/82418] Division on a constant is suboptimal because of not using imul instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418 Marc Glisse changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED

[Bug target/82418] Division on a constant is suboptimal because of not using imul instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418 --- Comment #4 from Marc Glisse --- (In reply to Alexander Monakov from comment #3) > it's likely that your test measured something else, You are right, my test was bogus and clang's version is faster.

[Bug target/82418] Division on a constant is suboptimal because of not using imul instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418 --- Comment #1 from Marc Glisse --- If I time it, gcc's code is several times faster than clang's on skylake. Why is clang's version supposed to be better?

[Bug libstdc++/82417] Macros from defined in C++11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82417 --- Comment #3 from Marc Glisse --- (In reply to Jonathan Wakely from comment #2) > Thinking about this further, I think we must not include at all > for strict -std=c++1* modes, Yes. Can we get a #warning in that case which explains that

[Bug libstdc++/82417] Macros from defined in C++11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82417 --- Comment #1 from Marc Glisse --- (In reply to Jonathan Wakely from comment #0) > The C++11 standard says that should just include the C++ > header and completely ignore the C library's header. I am very surprised that nobody has cared

[Bug c++/82394] Pointer imposes an optimization barrier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82394 --- Comment #1 from Marc Glisse --- What compiler flags? At -O3 we do optimize both the same.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79709 --- Comment #8 from Marc Glisse --- Thomas, the code generated by gcc has changed (after some patches by Jakub IIRC). Do you consider the issue fixed or is the generated asm still problematic? .L13: vpextrq $1, %xmm2, %rax testq

[Bug target/68924] No intrinsic for x86 `MOVQ m64, %xmm` in 32bit mode.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68924 --- Comment #2 from Marc Glisse --- Does anything bad happen if you remove the #ifdef/#endif for _mm_cvtsi64_si128? (2 files in the testsuite would need updating for a proper patch)

[Bug target/82261] x86: missing peephole for SHLD / SHRD

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

[Bug target/82242] x86_64 bad optimization with -march

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82242 --- Comment #2 from Marc Glisse --- Nothing gets vectorized :-( Note that to fill the vector, this would be better std::vector array(size, 1e-9); In the reduction, we seem to do strange things with the accumulator. addsd (%rax),

[Bug middle-end/82223] Incorrect optimization for lossy round trips of arithmetic types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82223 --- Comment #2 from Marc Glisse --- (float)INT_MAX gets rounded to 2^31. When you try to convert it to int, it doesn't fit, so the compiler is at liberty to return INT_MAX if it likes. clang's -fsanitize=undefined does complain on your code (not

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346 --- Comment #18 from Marc Glisse --- (In reply to Gergö Barany from comment #17) > the division used to be replaced by a shift that updated the condition code > register (again, on ARM; r250337): (just my opinion) At a high level (gimple),

[Bug target/82170] gcc optimizes int range-checking poorly on x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170 --- Comment #2 from Marc Glisse --- Note that n==(int)n (gcc documents that this must work) may work with more gcc versions and is more readable.

[Bug c++/82146] if () is always true error

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

[Bug tree-optimization/82135] Missed constant propagation through possible unsigned wraparound, with std::align() variable pointer, constant everything else.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82135 --- Comment #1 from Marc Glisse --- This PR is a bit messy, please minimize your examples... Looking at the dse2 dump (before reassoc messes things up): __intptr_2 = (const long unsigned int) voidp_9(D); _3 = __intptr_2 + 63; __aligned_4

[Bug lto/82027] [5/6/7/8 Regression] wrong code with -O3 -flto

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

[Bug c++/82021] Unnecessary null pointer check in global placement new (and also in any class-specific placement new operator declared as noexcept)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82021 --- Comment #3 from Marc Glisse --- You can search for "Ville Voutilainen", the patch was this year, not long before the release so maybe March.

[Bug c++/82021] Unnecessary null pointer check in global placement new (and also in any class-specific placement new operator declared as noexcept)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82021 --- Comment #1 from Marc Glisse --- Did you try with -std=c++1z? (if that solves your issue, this is a DUP, it should be enabled in all mode, but it isn't yet)

[Bug c++/82000] Missed optimization of char_traits::length() on constant string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82000 --- Comment #3 from Marc Glisse --- (In reply to Louis Dionne from comment #2) > > Downloading the one from godbolt, we simplify it to: [...] > > I have no idea what this is and how you feed that to GCC, but I'm curious. That's what

[Bug c++/82000] Missed optimization of char_traits::length() on constant string

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

[Bug c++/69433] missing -Wreturn-local-addr assigning address of a local to a static

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69433 --- Comment #3 from Marc Glisse --- f3: the inliner silently removes s (and the assignment to it) as write-only. You need to add a function that reads s (we don't warn in that case either, of course, but that's a first step). f2: the (atomic)

[Bug tree-optimization/81948] New: vectorize exp2 using exp

Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Using -Ofast -mavx2 and a recent glibc, g++ vectorizes #include void f(double*d){ d=(double*)__builtin_assume_aligned(d,256); for(int i

[Bug libstdc++/81912] std::distance not constexpr in C++17 mode

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

[Bug c++/81944] constexpr std::distance

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

[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #8 from Marc Glisse --- (In reply to Vadim Zeitlin from comment #5) > Perhaps you could consider this as a QoI issue, but it would be really great > if gcc could give a warning if the code tries to use fesetround() without >

[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

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

[Bug libstdc++/81905] New: partial_sort slower than sort

: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- (from https://stackoverflow.com/q/45455345/1918193 ) std::partial_sort of half an array can be slower than std::sort of the whole array

[Bug target/81904] New: FMA and addsub instructions

: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* (asked in https://stackoverflow.com/questions/45298855/how-to-write-portable-simd-code-for-complex-multiplicative

[Bug c/81389] _mm_cmpestri segfault on -O0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81389 --- Comment #13 from Marc Glisse --- (In reply to rockeet from comment #7) > @Marc @Jakub @Martin > Intel CPU document says: operand of _mm_cmpestri can be memory or mm > register, when the operand is memory, it does not require alignment.

[Bug c/81630] powl returns values with insufficient accuracy

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

[Bug tree-optimization/81607] Conditional operator: "type mismatch in shift expression" error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 Marc Glisse changed: What|Removed |Added Keywords||ice-checking

[Bug c++/81606] A small program works as expected with -O0 but fails with -O1 on all tested gcc versions

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

[Bug c++/81597] returns link to temporary value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81597 --- Comment #3 from Marc Glisse --- -Werror=return-local-addr (we cannot reject those programs by default, if the caller ignores what the function returns, the program may be valid)

[Bug c++/81597] returns link to temporary value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81597 --- Comment #1 from Marc Glisse --- Sorry, what change are you asking for? Compiling with current gcc, we get plenty of warnings, and at runtime: int && zsh: segmentation fault ./a.out

[Bug tree-optimization/81555] Wrong code at -O1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81555 --- Comment #3 from Marc Glisse --- (In reply to Dmitry Babokin from comment #2) > Hmmm, but this one is triggered at -O1, another only at -O2. -fno-tree-reassoc should help both. It is often a combination of optimizations that causes the bug.

[Bug tree-optimization/81555] Wrong code at -O1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81555 --- Comment #1 from Marc Glisse --- Same reassoc issue as PR 81556 it seems.

[Bug tree-optimization/81556] Wrong code at -O2

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

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81503 --- Comment #4 from Marc Glisse --- if (a + b * -2) c = (b-1073741824)*-2; might let you find an earlier culprit.

[Bug tree-optimization/81503] Wrong code at -O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81503 --- Comment #1 from Marc Glisse --- Looks like SLSR does an overflow-unsafe transformation, then VRP2 takes advantage of it. Maybe.

[Bug middle-end/81502] In some cases the data is moved to memory unnecessarily [partial regression]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81502 Marc Glisse changed: What|Removed |Added Keywords||missed-optimization

[Bug tree-optimization/81396] [7/8 Regression] Optimization of reading Little-Endian 64-bit number with portable code has a regression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396 --- Comment #9 from Marc Glisse --- Should we open a separate PR for the transformation you suggested in comment 4, or does that seem not useful enough now, or will be part of bitfield gimple lowering when that lands?

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 --- Comment #17 from Marc Glisse --- (In reply to Jonathan Wakely from comment #14) > The advantage of doing it as in comment 13, rather than: > [comment #11] > is that when inserting the inputrange causes reallocations we only have to >

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 --- Comment #11 from Marc Glisse --- Or one could (not legal) directly start a new allocation, copy the beginning of the vector, append the range, then append the end of the vector. Or a combination of all that: first try appending the range to

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 --- Comment #10 from Marc Glisse --- Inserting an InputRange (not even Forward) at the beginning of a vector is really a misuse of vector. It is true that we can do better than what libstdc++ currently does, though we shouldn't encourage the

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346 --- Comment #13 from Marc Glisse --- (In reply to Jakub Jelinek from comment #12) > Created attachment 41781 [details] > gcc8-pr81346-2.patch > > Further optimization from build_range_check. I wonder if "1" is that special, this optimization

[Bug target/81389] _mm_cmpestri segfault on -O0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81389 --- Comment #4 from Marc Glisse --- (In reply to rockeet from comment #3) > @Martin Liška Yes, my use case is: > > __m128i key128 = { key }; // key is an unsigned char > int idx = _mm_cmpestri(key128, 1, > *(const __m128i*)(data), // don't

[Bug lto/78795] LTO causes undefined reference errors when linking with GMP "make check"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795 --- Comment #12 from Marc Glisse --- (In reply to Vincent Lefèvre from comment #11) > On Debian, after path canonicalization, this is /usr/lib/bfd-plugins, but > only packages should manage files under /usr/lib (unlike /usr/local, for >

[Bug middle-end/81445] Dynamic stack allocation not optimized into static allocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445 --- Comment #6 from Marc Glisse --- (In reply to Wilco from comment #5) > Also it doesn't support these simple cases: > > void vla2(int x) > { > if (x == 10) > { > int arr[x]; > t (arr); > } > } Again, try something smaller. When

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346 --- Comment #10 from Marc Glisse --- (In reply to Jakub Jelinek from comment #9) > (In reply to Marc Glisse from comment #8) > > I think always using an unsigned type for the range check would be simpler. > > If we try to check that x>=INT_MIN+2

[Bug middle-end/81445] Dynamic stack allocation not optimized into static allocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445 --- Comment #4 from Marc Glisse --- (In reply to Wilco from comment #2) > I don't see it happen for the simplest case in current trunk: 400 bytes is too large, try again with something smaller. (I'm with you if you want to increase the

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346 --- Comment #8 from Marc Glisse --- I think always using an unsigned type for the range check would be simpler. If we try to check that x>=INT_MIN+2 && x<=INT_MAX-2 with -fwrapv, int is still not a suitable type in which to do

[Bug middle-end/81445] Dynamic stack allocation not optimized into static allocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445 --- Comment #1 from Marc Glisse --- Note that we already do it for VLA (aka BUILT_IN_ALLOCA_WITH_ALIGN) in CCP.

[Bug tree-optimization/81396] [7/8 Regression] Optimization of reading Little-Endian 64-bit number with portable code has a regression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396 --- Comment #6 from Marc Glisse --- (In reply to Jakub Jelinek from comment #5) > Or both this bswap change and the match.pd addition. Doing both sounds good to me :-)

[Bug bootstrap/81425] Bootstrap broken since r250158

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81425 --- Comment #1 from Marc Glisse --- Isn't that already fixed? https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00614.html

[Bug c++/81410] [5/6/7/8 Regression] -O3 breaks code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81410 --- Comment #5 from Marc Glisse --- Seems related to vectorization. These lines look suspicious: vect__37.14_78 = MEM[(long int *)_30]; vect__37.15_72 = MEM[(long int *)_30 + 16B]; vect__37.16_70 = MEM[(long int *)_30 + 32B];

[Bug tree-optimization/81409] Inefficient loops generated from range-v3 code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81409 --- Comment #1 from Marc Glisse --- The most obvious thing I notice is [100.00%] [count: INV]: # it$_M_current_23 = PHI _20 = _7 == it$_M_current_23; _5 = _20 | _53; if (_5 != 0) goto ; [7.36%]

[Bug tree-optimization/81403] [8 Regression] wrong code at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81403 --- Comment #3 from Marc Glisse --- /* x & C -> x if we know that x & ~C == 0. */ Not clear where it is getting the bogus range/nonzero information from, I thought we had fixed all the places reusing SSA_NAMEs with stale information.

[Bug tree-optimization/81403] wrong code at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81403 --- Comment #1 from Marc Glisse --- PRE losing "& 10393" at -O3 but not -O2 (the previous dumps are identical) @@ -611,6 +639,7 @@ ;;6 [100.0%] (FALLTHRU,EXECUTABLE) # .MEM_21 = PHI <.MEM_26(5), .MEM_25(6)> #

[Bug tree-optimization/81396] [7/8 Regression] Optimization of reading Little-Endian 64-bit number with portable code has a regression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396 --- Comment #2 from Marc Glisse --- bswap was happy dealing with _2 = MEM[(const unsigned char *)]; _3 = (uint64_t) _2; _4 = MEM[(const unsigned char *) + 1B]; _5 = (uint64_t) _4; _6 = _5 << 8; _8 = MEM[(const unsigned char *) +

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