[Bug tree-optimization/85143] Loop limit prevents (auto)vectorization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85143 --- Comment #5 from Marc Glisse --- The test becomes _1 = n_15(D) <= i_46; _2 = i_46 > 1336; _3 = _1 | _2; However, in match.pd, we only handle the AND case. The corresponding IOR transformation should be handled similarly.

[Bug target/85048] [missed optimization] vector conversions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048 --- Comment #4 from Marc Glisse --- See PR77399.

[Bug c++/85052] Implement support for clang's __builtin_convertvector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85052 --- Comment #2 from Marc Glisse --- Dup of PR61731.

[Bug tree-optimization/63734] [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734 --- Comment #10 from Marc Glisse --- (In reply to Eric Gallager from comment #9) > (In reply to Marc Glisse from comment #8) > > (In reply to Eric Gallager from comment #7) > > > 5 branch is closed > > > > You closed the PR, so does that mean

[Bug tree-optimization/63734] [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734 --- Comment #8 from Marc Glisse --- (In reply to Eric Gallager from comment #7) > 5 branch is closed You closed the PR, so does that mean you checked and it is fixed at least on trunk?

[Bug c++/84824] DCE fails to remove dead code of std::function constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84824 --- Comment #4 from Marc Glisse --- Probably related to PR59948, PR81000, etc. (I didn't look closely)

[Bug target/84756] Multiplication done twice just to get upper and lower parts of product

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84756 --- Comment #1 from Marc Glisse --- We immediately narrow "return (Longer)a*b;" to "return a*b;" which makes it hard to CSE later. If you can, it would be better to write the code as: Longer mul = (Longer)a*b; ... use mul twice ... Not sure

[Bug c/84755] GCC 4.6.0 build error with GCC-4.8.5 in Ubuntu 16.04 LTS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84755 --- Comment #3 from Marc Glisse --- gcc 4.6 and 4.8 branches are old and not supported anymore. Besides, trying 4.6.0 (with unidentified patches!) instead of 4.6.N with the largest possible N is just asking for trouble (the problem may already

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 --- Comment #5 from Marc Glisse --- That's not how you use a different glibc. If you look at the include order printed by -v, it has to remain in that order (libstdc++ before glibc, in particular), whereas you are adding your glibc in front.

[Bug target/84719] gcc's __builtin_memcpy performance with certain number of bytes is terrible compared to clang's

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84719 --- Comment #10 from Marc Glisse --- (In reply to Richard Biener from comment #9) > So with 2 bytes we get Try 3 bytes (the worst case). > Are you sure performance isn't dominated by the > first init loop (both GCC and clang vectorize it).

[Bug tree-optimization/84712] Missed evaluating to constant at tree level

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84712 --- Comment #1 from Marc Glisse --- We unroll quite late (cunroll) and there aren't any passes (like FRE) after that to do the propagation. Adding #pragma GCC unroll 16 before the loop lets it optimize.

[Bug c++/66944] ICE on static thread_local member in class template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944 Marc Glisse changed: What|Removed |Added Last reconfirmed|2015-12-16 00:00:00 |2018-2-28 --- Comment #8 from Marc Glisse

[Bug c++/84604] False positive "may be used uninitialized in this function" due to variable initialization eliminated as dead code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84604 --- Comment #1 from Marc Glisse --- (In reply to Craig Schroeder from comment #0) > this->~S(); > a=b+2; What do you expect this to do? You destruct the object, then access its member b...

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 --- Comment #19 from Marc Glisse --- (In reply to Aldy Hernandez from comment #16) > It seems tree-ssa-reassoc.c avoids reassociating most non-bit expressions by > design (because of signed overflows): [...] > So instead of whacking

[Bug c++/84599] following code gives different output for normal compilation and -O2 compiler.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84599 --- Comment #1 from Marc Glisse --- Did you try -fsanitize=undefined before reporting?

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #7 from Marc Glisse --- Unless vectors count as aggregates (more or less), in which case we can ignore my previous comment.

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #6 from Marc Glisse --- (In reply to Jakub Jelinek from comment #5) > (In reply to Marc Glisse from comment #3) > > Workaround: define a typedef for double with > > __attribute__((__aligned__(1))), and use _mm_set_sd(*(newtype*)p),

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #3 from Marc Glisse --- Copying from https://gcc.gnu.org/ml/gcc-help/2017-12/msg00031.html "The way _mm_load_sd is currently implemented in gcc, yes, sanitizers are right to complain. Intel could have named the thing _mm_loadu_sd if

[Bug tree-optimization/84470] test for address of member being null not eliminated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84470 --- Comment #1 from Marc Glisse --- I can't see the difference between the 2 cases? clang gives for both: warning: comparison of array 'p->a' equal to a null pointer is always false [-Wtautological-pointer-compare]

[Bug c++/84436] Missed optimization with switch on enum constants returning the same value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436 --- Comment #4 from Marc Glisse --- Note that this is good for identity, but we could also turn a map 0->3, 1->4, 5->8 into x->x+3, or generally any map (with an unreachable default case) into a polynomial (or some other simple function), the

[Bug target/84361] Fails to use vfmaddsub* for complex multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84361 Marc Glisse changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug tree-optimization/84334] [8 Regression] Stack overflow with -Ofast -frounding-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84334 --- Comment #1 from Marc Glisse --- With -frounding-math, CCP produces things like: _465 = 9.99974752427078783512115478515625e-7 + 4.99873689375817775726318359375e-6; Guessing: When we have cst1+cst2+cst3, the transformation gives

[Bug target/84280] [6/7/8 Regression] Performance regression in g++-7 with Eigen for non-AVX2 CPUs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84280 --- Comment #9 from Marc Glisse --- (In reply to Patrik Huber from comment #6) > I could also upload you the .ii files but they are 5 MB, which the > bugtracker doesn't allow (1 MB limit). preprocessed sources are the .ii files (you can use

[Bug target/84280] [6/7/8 Regression] Performance regression in g++-7 with Eigen for non-AVX2 CPUs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84280 Marc Glisse changed: What|Removed |Added Known to work||5.5.0 Summary|Performance

[Bug c/84173] Support glibc multiarch interpreter names

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #11 from Marc Glisse --- (In reply to Javier Serrano Polo from comment #10) > This report is about the patch that will be submitted with multiarch names. If you intend to send a patch, you can send it directly to

[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #2 from Marc Glisse --- IIRC, the standard provides guarantees for volatile objects. Here, you are accessing a non-volatile object through a volatile type, and if the compiler can find out about the underlying object, it can ignore

[Bug c/84173] Support glibc multiarch interpreter names

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #4 from Marc Glisse --- (In reply to Javier Serrano Polo from comment #3) > Upstream wants to make multiarch harder; the patch will not be posted here. As long as the new behavior is optional (not the default), the patch stands a

[Bug target/84172] option "-O3" create slower code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84172 Marc Glisse changed: What|Removed |Added Known to work||7.2.0 Known to fail|

[Bug c/84121] optimizer breaks code without -frwapv, but -Wall -Wextra show no warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84121 --- Comment #7 from Marc Glisse --- (In reply to Jakub Jelinek from comment #6) > It does: Ah, of course, it prints it only for the first occurrence, and since this quickly disappears, I missed it. My bad, thanks.

[Bug c/84121] optimizer breaks code without -frwapv, but -Wall -Wextra show no warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84121 --- Comment #5 from Marc Glisse --- What I don't understand is why -fsanitize=undefined does not say anything when running this program, whether I use gcc or clang...

[Bug c/84121] optimizer breaks code without -frwapv, but -Wall -Wextra show no warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84121 --- Comment #2 from Marc Glisse --- (In reply to Marc Glisse from comment #1) > You can compile with -fsanitize=undefined then run your code, to understand > the issue. Oups, sorry, that doesn't show anything for your code, the problem is not

[Bug c/84121] optimizer breaks code without -frwapv, but -Wall -Wextra show no warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84121 --- Comment #1 from Marc Glisse --- You can compile with -fsanitize=undefined then run your code, to understand the issue. More warnings are always possible, but at some points, hundreds of "I, the compiler, assume that the code you have written

[Bug libstdc++/84056] map insertes a pair when check a value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84056 --- Comment #4 from Marc Glisse --- (In reply to Alper Ce from comment #3) > I didn't assign anything to my_map(i didn't use assignment operator = ), i > just used == operator to check value of it. Again, did you read the doc for operator[]?

[Bug libstdc++/84056] map insertes a pair when check a value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84056 --- Comment #2 from Marc Glisse --- Where is the bug? Did you read the documentation for operator[]?

[Bug tree-optimization/81082] [8 Regression] Failure to vectorise after reassociating index computation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81082 --- Comment #9 from Marc Glisse --- + (if (! INTEGRAL_TYPE_P (type) Integer vectors satisfy this condition... Also, floats need some check (I don't know which one is appropriate).

[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop

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

[Bug rtl-optimization/83951] [missed optimization] difference calculation for floats vs ints in a loop

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

[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop

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

[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83952 --- Comment #4 from Marc Glisse --- Andrew, the OP had already closed the first PR, and you closed the second as duplicate of the first. Did you really mean to get to a situation where both are closed?

[Bug c/61240] [6/7/8 Regression] Incorrect warning "integer overflow in expression" on pointer-pointer subtraction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240 --- Comment #18 from Marc Glisse --- (In reply to Jakub Jelinek from comment #17) > Created attachment 43162 [details] > gcc8-pr61240.patch > > The C FE doesn't do this optimization anymore, but c_fully_fold does because > the generic folding

[Bug tree-optimization/57503] [6/7/8 Regression] Wrong extension of multiply operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 --- Comment #19 from Marc Glisse --- Looking at the very first testcase in this PR, assuming 16-bit int, 129*255 overflows and is thus undefined behavior. Multiply by 255u if you want the multiplication to happen safely in an unsigned type.

[Bug tree-optimization/57503] [6/7/8 Regression] Wrong extension of multiply operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 --- Comment #18 from Marc Glisse --- (In reply to Georg-Johann Lay from comment #17) > Obervation that -fno-wrapv also leads to correct code, hence there is > somewhere a wrong assumption that signed overflow occurs (which doesn't). (you

[Bug rtl-optimization/83827] New: vector load/store with struct in registers

Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* (first seen with complex numbers, quite likely a dup of some other vector PR, could be target

[Bug tree-optimization/54422] Merge adjacent stores of elements of a vector (or loads)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54422 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Known to work|

[Bug c++/83749] Types with different language linkage are treated as equivalent types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83749 --- Comment #1 from Marc Glisse --- See PR2316. Don't hold your breath for a change, it is more likely that the standard will eventually be changed to allow the current behavior.

[Bug c++/83739] [8 Regression] error: range-based 'for' expression of type 'auto' has incomplete type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83739 --- Comment #7 from Marc Glisse --- And to drop the includes: template void f() { int x[2]; auto delegate = [](auto & foo) { for (auto bar : foo); }; delegate(x); } int main() { f(); }

[Bug c++/83739] [8 Regression] error: range-based 'for' expression of type 'auto' has incomplete type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83739 --- Comment #6 from Marc Glisse --- Without fancy tools, looking at the last few lines of the file: #include template void f() { std::set x; auto delegate = [](auto & foo) { for (auto bar : foo); }; delegate(x); } int main() {

[Bug tree-optimization/83715] Missed optimization in math expression: optimize double comparing

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

[Bug target/82439] Missing (x | y) == x simplifications

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82439 --- Comment #6 from Marc Glisse --- (In reply to Andrew Pinski from comment #1) > "(x | y) == x" is simpler than "(y & ~x) == 0" on the tree level. 2 gimple > vs 3. We do indeed tend to use the number of stmts to chose canonical forms on

[Bug tree-optimization/83541] Missed optimization with int overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83541 --- Comment #4 from Marc Glisse --- (In reply to Richard Biener from comment #3) > I've deliberately avoided doing this ... (turning SSA propagator UNDEFINED > into a random value rather than keeping it effectively VARYING during >

[Bug c++/83639] Vector element address problem after push_back

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

[Bug tree-optimization/83544] Missed optimization opportunity for constant folding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83544 --- Comment #1 from Marc Glisse --- In one case we optimize super early to int t = 1 / (int) x <= 0 ? 1 / 0 : 1; which prevents the VRP optimization from the other case. We almost recover in isolate-paths, except that Jeff insisted on using

[Bug tree-optimization/83541] Missed optimization with int overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83541 --- Comment #2 from Marc Glisse --- int test(void) { int x = __INT_MAX__; return x+1; } CCP also turns this into INT_MIN, again it could be bolder.

[Bug tree-optimization/83541] Missed optimization with int overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83541 --- Comment #1 from Marc Glisse --- Yes, it is a known issue, (E)VRP is too conservative. pushing new range for x_2(D): [2147483647, +INF] EQUIVALENCES: { x_2(D) } (1 elements) Visiting stmt _4 = x_2(D) + 1; Visiting statement: _4 = x_2(D) +

[Bug tree-optimization/83517] Missed optimization in math expression: (x+x)/x == 2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83517 --- Comment #1 from Marc Glisse --- (div (mult @0 @1) @1) Maybe we are missing a :c here.

[Bug c++/83468] -Wuninitialized warning not emitted when it should

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83468 --- Comment #1 from Marc Glisse --- -Wsystem-headers enables the warning.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80885 --- Comment #2 from Marc Glisse --- https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02233.html

[Bug middle-end/81914] [7/8 Regression] gcc 7.1 generates branch for code which was branchless in earlier gcc version

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81914 --- Comment #10 from Marc Glisse --- For the particular case of <=> (-1, 0 or 1), I've seen code like (a>b)-(a

[Bug lto/83338] [8 Regression] SPEC CPU2017 510.parest_r ICE

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

[Bug lto/83338] [8 Regression] SPEC CPU2017 510.parest_r ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83338 --- Comment #7 from Marc Glisse --- (In reply to Jakub Jelinek from comment #6) > This works for me, but I'll leave testcase and testing for tomorrow. You are fast :-) > @@ -5546,6 +5554,15 @@ vectorizable_operation (gimple *stmt, gi >

[Bug lto/83338] [8 Regression] SPEC CPU2017 510.parest_r ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83338 --- Comment #5 from Marc Glisse --- (In reply to Jakub Jelinek from comment #4) > I believe the bug is that get_vectype_for_scalar_type for the operands of > POINTER_DIFF_EXPR is vector of unsigned elements, the result of > POINTER_DIFF_EXPR is

[Bug lto/83338] [8 Regression] SPEC CPU2017 510.parest_r ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83338 --- Comment #2 from Marc Glisse --- void f(char**p,char**q,long*r){ for(int i=0;i<1024;i++) r[i]=p[i]-q[i]; } with g++ -O3 on x86_64 also ICEs, let's start with that (I don't have access to SPEC).

[Bug middle-end/83312] [8 regression] bogus -Warray-bounds warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83312 --- Comment #1 from Marc Glisse --- Ironically, it seems to be the same pass, VRP1, that warns that some piece of code accesses pd_threads[j] for some negative j and later notices that the corresponding path is dead. I don't know if we can shift

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83164 --- Comment #11 from Marc Glisse --- (In reply to Jakub Jelinek from comment #9) > Created attachment 42810 [details] > gcc8-pr83164.patch Sorry, I shouldn't have taken this long. > So like this? It makes no sense to call types_compatible_p

[Bug tree-optimization/83299] result of pointer addition can be assumed to be less than or equal to PTRDIFF_MAX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83299 --- Comment #1 from Marc Glisse --- As an implementation detail, the argument to POINTER_PLUS is always unsigned... (maintainers are in favor of changing that, but someone needs to do the work) Also, we now quickly simplify p-q to -i, which

[Bug tree-optimization/83296] missing -Wstringop-overflow due to missing range info for MAX_EXPR

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83296 --- Comment #1 from Marc Glisse --- Note that -fdump-tree-optimized-all includes the range information in the dump. Normally, we know how to derive a range for MAX_EXPR, but in this case the MAX_EXPR only appears in phiopt3, later than VRP2. On

[Bug tree-optimization/79119] absolute value of a pointer difference can be assumed to be less than or equal to PTRDIFF_MAX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79119 --- Comment #2 from Marc Glisse --- With POINTER_DIFF_EXPR, things may be easier. One of the things I suggested when introducing it was that VRP could always use a range of [ -PTRDIFF_MAX, PTRDIFF_MAX ] for them. If you had written

[Bug tree-optimization/83262] SELECT CASE slower than IF/ELSE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262 --- Comment #1 from Marc Glisse --- What version of gcc, and what platform? With gcc-8 on x86_64 (skylake), I get GOTO costs totally 0.904 (s) SELECT CASE costs totally 0.704 (s) IF-Goto costs totally 0.706

[Bug tree-optimization/82103] spurious stringop-overflow warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82103 --- Comment #3 from Marc Glisse --- This warning is "less wrong" than the other related ones. If frame_size is 0, this does call memset(,,-1). And there is an explicit test for frame_size == 0 in the function, which makes it look like 0 is not

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239 --- Comment #4 from Marc Glisse --- (In reply to Marc Glisse from comment #1) > In the mean time, we fail to find some VRP optimizations that might help > with the warning. > > _1 = _186 + 18446744073709551614; > if (_1 > _186) > > _186:

[Bug target/83240] x86_64 vectorized sqrt of denormal yields -inf when DAZ=0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83240 --- Comment #4 from Marc Glisse --- (this PR is vaguely related to PR 57974) Unrelated, but I am surprised we don't end up computing at compile-time in this example. We vectorize sqrt before unrolling the first loop and getting the constants.

[Bug tree-optimization/83247] New: simplify (int)a_long < 0 when we know a_long fits in int

ion Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- This code is based on basic_string_view::_S_compare, which should probably be impro

[Bug c++/83239] False positive from -Wstringop-overflow on simple std::vector code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239 --- Comment #1 from Marc Glisse --- It is strongly related to the other PRs. IMO, all warnings like maybe-uninitialized should move from Wall to Wextra, but that's going to be a hard sell. In the mean time, we fail to find some VRP

[Bug tree-optimization/81165] [8 Regression] Regression in GCC-8.0.0's optimizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165 --- Comment #6 from Marc Glisse --- (In reply to Richard Biener from comment #5) > we miss to optimize (int)((short int)((unsigned short) x1.1_4 ^ 8) & 1) to > (int)(x1.1_4 & 1) as well. (untested) +/* (X |^ 8) & 1 --> X & 1 */ +(for op

[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073 --- Comment #3 from Marc Glisse --- (In reply to Richard Biener from comment #2) > The "proper" result for [MIN,MAX] | 1 is of course a set of every odd > number... Sadly, while we track may-be-nonzero bits in CCP (maybe with the VRP reorg

[Bug tree-optimization/83194] Possibly missed simplification with strcmp(s, t) == strcmp(t, s)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83194 --- Comment #2 from Marc Glisse --- What if strcmp returns INT_MIN?

[Bug c++/83165] [8 regression] cannot convert ‘GPrivate’ {aka ‘_GPrivate’} to ‘GPrivate*’ {aka ‘_GPrivate*’} in return

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83165 --- Comment #1 from Marc Glisse --- Could you explain why this code should be accepted, to save time?

[Bug c++/83166] [8 regression] error: type mismatch in pointer diff expression internal compiler error: verify_gimple failed

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

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

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

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83164 --- Comment #2 from Marc Glisse --- Does it work if you remove the verification || !types_compatible_p (rhs1_type, rhs2_type) from tree-cfg.c? useless_type_conversion_p says that converting a function pointer to char* is useless

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

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

[Bug target/83158] [8 regression] gcc.target/i386/pr78057.c fail

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

[Bug fortran/79929] [7/8 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 --- Comment #25 from Marc Glisse --- (In reply to Dominique d'Humieres from comment #24) > The following variant does not give the warning That's because the code has become obfuscated enough that we don't have the simplification l-(l+5)

[Bug fortran/79929] [7/8 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 --- Comment #23 from Marc Glisse --- (In reply to Harald Anlauf from comment #3) > subroutine gfcbug138 (yerrmsg) > character(kind=1,len=*) :: yerrmsg > yerrmsg = 1_"bug: " // yerrmsg > end subroutine gfcbug138 [...] > gfcbug138

[Bug target/83133] Superflous x86 test instructions in generated assembly.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #19 from Marc Glisse --- (In reply to Uroš Bizjak from comment #17) > (In reply to Marc Glisse from comment #15) > > Gcc's RTL internal representation sees the same thing for your code and for > > > > int diff = (unsigned)a -

[Bug target/83133] Superflous x86 test instructions in generated assembly.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #15 from Marc Glisse --- Gcc's RTL internal representation sees the same thing for your code and for int diff = (unsigned)a - (unsigned)b; llvm represents both differently and generates different code for the two.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80792 --- Comment #3 from Marc Glisse --- It seems that clang have fixed their ABI to generate code similar to gcc. Any objection to closing this?

[Bug sanitizer/82802] Potential UBSAN error with pointer difference (32-bits mode)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82802 --- Comment #3 from Marc Glisse --- This seems fixed on trunk, and impossible to backport.

[Bug tree-optimization/83104] [8 Regression] ICE: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83104 --- Comment #4 from Marc Glisse --- Author: glisse Date: Wed Nov 22 16:44:46 2017 New Revision: 255068 URL: https://gcc.gnu.org/viewcvs?rev=255068=gcc=rev Log: Avoid two_valued_val_range_p for pointers. 2017-11-22 Marc Glisse

[Bug tree-optimization/83104] [8 Regression] ICE: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83104 --- Comment #2 from Marc Glisse --- two_valued_val_range_p doesn't work on pointers, it uses vrp_val_min on the type of the arguments. Probably: --- vr-values.c (revision 255021) +++ vr-values.c (working copy) @@ -4091,7 +4091,7 @@

[Bug tree-optimization/83072] Late VRP optimization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072 --- Comment #3 from Marc Glisse --- (In reply to Richard Biener from comment #2) > The issue is that when EVRP records value-ranges that only hold temporarily > it doesn't update SSA_NAME_RANGE_INFO but only the internal lattice while > if the

[Bug tree-optimization/83073] New: Range for VR_VARYING | [1, 1]

Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Before r254954, for x | 1 where x is VR_VARYING, we would deduce a VR_ANTI_RANGE ~[0, 0]. Since then, we deduce [-INT_MAX, INT_MAX]. Both make sense, but it is strange that we get

[Bug tree-optimization/83072] New: Late VRP optimization

Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Before r254954, cmpmul-1.c was optimized during EVRP: int f(int a, int b, int c){ c |= 1; a *= c; b *= c; return a == b; } After that revision, the range deduced for c|1 contains

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

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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82951 --- Comment #4 from Marc Glisse --- Author: glisse Date: Mon Nov 20 13:26:39 2017 New Revision: 254954 URL: https://gcc.gnu.org/viewcvs?rev=254954=gcc=rev Log: VRP: x+1 and -x cannot be INT_MIN 2017-11-20 Marc Glisse

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82951 --- Comment #3 from Marc Glisse --- (In reply to Richard Biener from comment #2) > Hmm, on RTL signs do not matter. I'd say strip the bogus cases from the > existing tests and "duplicate" them into new variants using -fwrapv? Thus > only apply

[Bug middle-end/83032] Copy elision for returning subobject

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83032 --- Comment #1 from Marc Glisse --- I don't think that's one of the cases where the C++ standard allows elision, and I am not sure how that would work in practice. The idea for the return slot optimization is that the caller reserves enough

[Bug tree-optimization/83022] malloc & memset -> calloc is not always an optimization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022 --- Comment #4 from Marc Glisse --- (In reply to Nathan Sidwell from comment #2) > I noticed the crazy default probabilities during investigating this. I > think that's really a second-order problem. It's just that comparing the frequencies

[Bug tree-optimization/53805] combine_comparisons changes trapping behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805 --- Comment #11 from Marc Glisse --- (In reply to Richard Biener from comment #3) > > I am happy to relabel this bug (or file a new one if you prefer) as a missed > > optimization. > > I'd say open a new one. For reference, that's PR 53806.

[Bug middle-end/83022] malloc & memset -> calloc is not always an optimization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022 --- Comment #1 from Marc Glisse --- I am pretty sure this was discussed when the patch was reviewed. IIRC the original patch was specifically pattern-matching if(p!=0) (with p the result of malloc) as the only acceptable condition between malloc

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