[Bug tree-optimization/71206] [7 Regression] ICE on valid code at all optimization levels in both 32-bit and 64-bit modes on x86_64-linux-gnu. (verify_gimple failed)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71206 --- Comment #6 from Marc Glisse --- (In reply to Ilya Enkovich from comment #5) > Could you please also check if it is a dup of PR71079? Cf https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01598.html ;-)

[Bug tree-optimization/71206] [7 Regression] ICE on valid code at all optimization levels in both 32-bit and 64-bit modes on x86_64-linux-gnu. (verify_gimple failed)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71206 --- Comment #4 from Marc Glisse --- I am starting a bootstrap+regtest with: /* (X ^ Y) ^ (X ^ Z) -> Y ^ Z */ (simplify (bit_xor (convert1? (bit_xor:c @0 @1)) (convert2? (bit_xor:c @0 @2))) (if (tree_nop_conversion_p (type, TREE_TYPE

[Bug tree-optimization/71206] [7 Regression] ICE on valid code at all optimization levels in both 32-bit and 64-bit modes on x86_64-linux-gnu. (verify_gimple failed)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71206 --- Comment #2 from Marc Glisse --- With -O: int f(int d, unsigned b) { int i2 = b ^ 1; int i4 = d ^ 1; return i2 ^ i4; } An extra (convert ...) should do it I guess.

[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #9 from Marc Glisse --- (In reply to rguent...@suse.de from comment #8) > Not that I like this proposal at all (given it changes function arg > evaluation order on x86_64). Does it? "the function is evaluated before all its

[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #7 from Marc Glisse --- (In reply to Richard Biener from comment #6) > C11 6.5.16/3 suggests that the LHS "operand" is evaluated in unspecified > order. It seems that C++ is moving towards specifying the order

[Bug tree-optimization/71034] abs(f) u>= 0. is always true

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71034 --- Comment #2 from Marc Glisse --- (In reply to Andrew Pinski from comment #1) > I think this is the optimizations that should be done: > abs(x) < 0 -> x != x for x=NaN, abs(x) is NaN, and NaN<0 is false. So the current simplification to false

[Bug tree-optimization/71034] New: abs(f) u>= 0. is always true

P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- A very simple missed optimization, we optimize abs(x)<0 to false (in forwprop, haven't found the exact place yet) but not abs(x) u>=

[Bug c++/71029] large fold expressions compile slowly with -Wall

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029 Marc Glisse changed: What|Removed |Added Keywords||compile-time-hog

[Bug tree-optimization/68105] optimizing repeated floating point addition to multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68105 --- Comment #3 from Marc Glisse --- (In reply to zboson from comment #0) > In addition, the following equations are always true even without > associative math. > > 2*a = a + a > 3*a = a + a + a > 4*a = a + a + a + a > 5*a = a +

[Bug libstdc++/70898] Stateful Compare objects are very slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70898 --- Comment #4 from Marc Glisse --- (In reply to Jonathan Wakely from comment #3) > This is being tracked as PR 51965 PR 51965 seems to be about extra copies of the values, while this one is more about extra copies of compare objects (then

[Bug libstdc++/70898] Stateful Compare objects are very slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70898 --- Comment #2 from Marc Glisse --- I think you are supposed to use std::reference_wrapper as comparator if you don't want to copy it around. We did talk about reducing the number of copies (mostly in the context of sorting), but nobody has

[Bug tree-optimization/70841] reassoc fails to handle FP division

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

[Bug c/70812] New: Delay folding in C front-end

: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Hello, gcc.dg/gomp/loop-1.c recently gained a few xfails https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01417.html Those happen because the C front-end folds i+=i to i*=2 before the OMP code has

[Bug tree-optimization/70777] x*x pessimised to pow(x,2) with -Og -ffast-math

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

[Bug c++/70767] std::numeric_limits::digits is wrong unless --std=c++11 used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70767 --- Comment #1 from Marc Glisse --- http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559 It has status CD1, I don't remember if that means it applies retroactively or not. (by the way, the 4.8 branch is not maintained anymore)

[Bug c/70742] Support div as a builtin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #8 from Marc Glisse --- "The div, ldiv, and lldiv functions return a structure of type div_t, ldiv_t, and lldiv_t, respectively, comprising both the quotient and the remainder. The structures shall contain (in either order) the

[Bug c/70742] Support div as a builtin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #5 from Marc Glisse --- It seems to me that the reason we don't already have div as a builtin is that we need to know the layout of div_t. In a header, you don't really need inline asm: inline div_t div(int a, int b){ div_t q;

[Bug target/70734] __builtin_add_overflow emits poor code on x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70734 --- Comment #7 from Marc Glisse --- (In reply to Richard Biener from comment #3) > It's not unused, it's stored to memory. Of course, I read the testcase too quickly and thought *r was a throw-away local variable... Sorry about that.

[Bug target/70734] __builtin_add_overflow emits poor code on x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70734 --- Comment #2 from Marc Glisse --- (In reply to Marc Glisse from comment #1) > movl%edi, (%rdx) Looks like we fail to notice that the result of the addition is unused and keep this dead store...

[Bug target/70734] __builtin_add_overflow emits poor code on x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70734 --- Comment #1 from Marc Glisse --- gcc-6 produces .cfi_startproc addl%esi, %edi movl%edi, (%rdx) jo .L9 rep ret .L9: pushq %rax .cfi_def_cfa_offset 16 callabort

[Bug tree-optimization/70731] With -Ofast, reorder floating-point and integer operands to minimize conversions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70731 --- Comment #3 from Marc Glisse --- (In reply to Josh Triplett from comment #2) > That's a fair point. Perhaps it should go into a separate optimization > option, then, though it still seems in the spirit of -Ofast. (If overflow > is a

[Bug tree-optimization/70731] With -Ofast, reorder floating-point and integer operands to minimize conversions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70731 --- Comment #1 from Marc Glisse --- That... seems dangerous to me. With floats, unsafe operations tend to change the low bits. With integers, an overflow gets the high bits wrong. If you call test(INT_MAX,0,1,0) for instance, the result would be

[Bug c++/70723] Missed optimization opportunity for lambda converted to fun-ptr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70723 --- Comment #3 from Marc Glisse --- (In reply to Richard Biener from comment #1) > There is no pass in GCC that would try to turn the runtime initialization > into static init again (optimizing the runtime initializers and parsing > them back to

[Bug target/70721] Suboptimal code generated when using _mm_min_sd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70721 --- Comment #2 from Marc Glisse --- There were already a number of discussions on gcc-patches in 2012 (Oct, Nov, Dec) with title "[i386] scalar ops that preserve the high part of a vector" (see also PR54855). In particular, around this message,

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708 --- Comment #15 from Marc Glisse --- (In reply to H.J. Lu from comment #13) > (In reply to Marc Glisse from comment #11) > > Since for MyMinV1 we generate no move at all, then that code should also be > > valid for MyMinV2 (no issue with sNaN in

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708 --- Comment #14 from Marc Glisse --- (In reply to H.J. Lu from comment #12) > (In reply to Marc Glisse from comment #11) > > As I told you in the other PR, movq is *NOT* what the PRs are asking for, it > > See the subject of this PR. 1) I know

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

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

[Bug target/68211] Free __m128d subreg of double

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68211 --- Comment #2 from Marc Glisse --- (In reply to H.J. Lu from comment #1) > When the patch for PR 70708, I got > > vmovq %xmm0, %xmm0 > vsqrtsd {ru-sae}, %xmm0, %xmm0, %xmm0 > ret Note that the goal of both PRs is to get

[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483 --- Comment #9 from Marc Glisse --- __builtin_memcpy (_30, &._82, 12); _31 = MEM[(const int &)_30]; looks like something we should be able to optimize, and there is indeed code in vn_reference_lookup_3 to that effect, but the code doesn't

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708 --- Comment #6 from Marc Glisse --- (In reply to Petr from comment #3) > Is there any workaround guys? > > I was looking for some built-in that would allow me just cast `double` to > `__m128d` without going through `_mm_set_sd()`, but leaving

[Bug c++/70708] Suboptimal code generated when using _mm_set_sd (X64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708 --- Comment #1 from Marc Glisse --- Looks complicated. _mm_set_sd(x) returns {x,0}, and I don't think the calling convention guarantees anything about the unused part of SSE registers. _mm_min_sd uses the high part of its first argument. So we

[Bug tree-optimization/70701] incomplete value numbering when memcpy-ing from array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70701 --- Comment #1 from Marc Glisse --- Er, sorry, a "const" disappeared when I posted. const int a[]={1,2,3}; int f(){ int*b=__builtin_malloc(12); __builtin_memcpy(b,a,12); return b[0]; } this fails to optimize (without forwprop). int

[Bug tree-optimization/70701] New: incomplete value numbering when memcpy-ing from array

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Looking at PR58483 (seems more relevant than PR62156), I tried this simple testcase: int a[]={1,2,3}; int f

[Bug libstdc++/70607] The return type of std::conj must be std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70607 --- Comment #1 from Marc Glisse --- http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137

[Bug tree-optimization/70600] Missed tree optimization with multiple additions in different types.

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

[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70547 --- Comment #3 from Marc Glisse --- In this case, the code was deliberately written this way, presumably to avoid the branching in &&. Using & would be better (and that's what I am suggesting we optimize it to), but * doesn't seem nonsensical to

[Bug tree-optimization/70547] New: Optimize multiplication of booleans to bit_and

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- int f(int a,int b,int c,int d){ return (a<b)*(c<d); } produces _3 = a_1(D) < b_2(D); _4 = (int) _3;

[Bug tree-optimization/70546] New: ifconvert if(cond) ++count; to count += cond;

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* In the example from http://stackoverflow.com/q/36414959/1918193 we fail to vectorize f0

[Bug tree-optimization/70527] Missed fold for "(long int) x * 12 - (long int)(x + 1) * 12"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70527 --- Comment #2 from Marc Glisse --- (In reply to amker from comment #0) > Seems "(long int) x * 12 - (long int)(x + 1) * 12" is missed in > generic-simplify. Interestingly, we manage just fine if 12 is replaced with a variable. The issue seems

[Bug rtl-optimization/70526] GCC 6 miscompiles Firefox JIT compiler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 --- Comment #2 from Marc Glisse --- (In reply to Markus Trippelsdorf from comment #1) > -Wstrict-aliasing=2 warns: > > markus@x4 tmp % g++ -O2 -Wstrict-aliasing=2 test_fire.cpp > test_fire.cpp: In instantiation of ‘const T*

[Bug target/54700] Optimize away x<0 as mask argument of a blend.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54700 --- Comment #1 from Marc Glisse --- This was missing a simple testcase, but now we can write one (in C++): typedef int vec __attribute__((vector_size(32))); vec f(vec x){ return x<0?2:1; } vpxor %xmm1, %xmm1, %xmm1 vpcmpgtd

[Bug tree-optimization/70509] wrong code with extract from a v64qi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70509 --- Comment #6 from Marc Glisse --- (In reply to Zdenek Sojka from comment #5) > It also fixes several wrong-code testcases that I failed to reduce to a > reasonable size, thus were unreported. Nice. While you are looking at those values that

[Bug tree-optimization/70509] wrong code with extract from a v64qi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70509 --- Comment #3 from Marc Glisse --- (In reply to Zdenek Sojka from comment #2) > (In reply to Zdenek Sojka from comment #0) > > First broken dump seems to be .forwprop, where is: > > .forwprop4 , that is. The problem might be that

[Bug tree-optimization/23471] a*a (for signed ints with -fno-wrapv) is always postive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23471 --- Comment #3 from Marc Glisse --- The case a*a has been handled for a while, both in fold-const.c (tree_binary_nonnegative_warnv_p) and in VRP. However, the case a*a*a*a*a*a is not handled. In the .optimized dump at -O3, we still have: b_3

[Bug c++/70444] Optimizer removes expression template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70444 --- Comment #2 from Marc Glisse --- This code is likely broken, it looks like the last example in https://gmplib.org/manual/C_002b_002b-Interface-Limitations.html The temporary expression for v1+v2 dies before the next line, and you have a

[Bug c++/70441] vector<__float128> crashes on two push_back calls with -mavx

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70441 --- Comment #1 from Marc Glisse --- C++ does not support dynamic allocation of over-aligned types (usually SIMD vectors, but also __float128 on x86 for instance). C++17 will partially support it (operator new), but still not fix the std::vector

[Bug c++/70438] result type of vector operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70438 --- Comment #1 from Marc Glisse --- The result of a comparison is an "opaque" vector type, which can be converted much more freely than a regular vector type, in case the guessed return type doesn't exactly match the user's choice (it quickly

[Bug rtl-optimization/70432] New: Move operation across function call to reduce save / restore

Severity: enhancement Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- I have no idea how one would do such a transformation, and there is likely a dup

[Bug c++/70430] Incorrect result for logical "and" operation with mixed vector and scalar

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

[Bug tree-optimization/42046] missed optimization (a?b|1:b&~1) where b is a load from memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42046 --- Comment #3 from Marc Glisse --- (a?b|1:b&~1) could also be turned into (b&~1)+(a!=0) or (b|1)-(a==0) (or with ^ instead of +-, or | instead of +, etc) but it is quite possible that none of those are a win.

[Bug tree-optimization/70251] Wrong code with -O3 -march=skylake-avx512.

5) > > > On Wed, 16 Mar 2016, glisse at gcc dot gnu.org wrote: > > > > A + (B vcmp C ? 1 : 0) -> A - (B vcmp C ? -1 : 0) > > > I think that would be an odd transform. > > > > As far as I understand, since the bool vector changes, this is cur

[Bug tree-optimization/70317] [6 Regression] folding x<=x to true for large vectors, ignoring nans

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70317 --- Comment #6 from Marc Glisse --- (In reply to Marc Glisse from comment #5) > Do double and long long always have the same size? Ah, it doesn't matter since the result of <= is an opaque vector type and can thus be implicitly cast even to a

[Bug tree-optimization/70317] [6 Regression] folding x<=x to true for large vectors, ignoring nans

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70317 --- Comment #5 from Marc Glisse --- Yes, that looks good, thanks. Do double and long long always have the same size (on platforms that support NaN)?

[Bug tree-optimization/70317] [6 Regression] folding x<=x to true for large vectors, ignoring nans

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70317 --- Comment #3 from Marc Glisse --- I'll get to it, but it may take a few days (hard to predict).

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728 --- Comment #20 from Marc Glisse --- Does the latest GMP snapshot from https://gmplib.org/download/snapshot/ work for you? I moved NO_ASM to config.h, so GCC's approach of overriding CFLAGS should not break it anymore.

[Bug c++/70318] `std::sqrt(int)` Produces -Wfloat-conversion Warning, Erroneous After C++11.

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

[Bug tree-optimization/70317] New: [6 Regression] folding x<=x to true for large vectors, ignoring nans

ode Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- typedef double vecf __attribute__((vector_size(256))); auto f(vecf x){ return x &

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728 --- Comment #19 from Marc Glisse --- (In reply to Marc Glisse from comment #18) > I think this issue was already described in another PR. Ah, that was PR 69134 for MPFR. https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00127.html

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728 --- Comment #18 from Marc Glisse --- Ah, I managed to reproduce. GMP has a nice "CFLAGS= -g -DNO_ASM" in its Makefile, but gcc overrides it by calling make CFLAGS=-g. Not much we can do from the GMP side (and ISL is innocent). Well, maybe the

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728 --- Comment #17 from Marc Glisse --- (In reply to Andrew Roberts from comment #15) > not entirely clear what you mean by reproducing the issue without > downloading mpfr, mpc, isl etc. Do you mean the missing symbol in GMP or the > issues with

[Bug target/70314] New: AVX512 not using kandw to combine comparison results

: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* This comes from PR 68714 (comment 7), there are more details and suggestions there. typedef

[Bug tree-optimization/70251] Wrong code with -O3 -march=skylake-avx512.

reply to rguent...@suse.de from comment #5) > On Wed, 16 Mar 2016, glisse at gcc dot gnu.org wrote: > > A + (B vcmp C ? 1 : 0) -> A - (B vcmp C ? -1 : 0) > I think that would be an odd transform. As far as I understand, since the bool vector changes, this is curr

[Bug tree-optimization/70310] [6 Regression] wrong code with vector compare at -O0

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

[Bug c++/70301] missing diagnostic on taking the address of a temporary

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

[Bug tree-optimization/70251] Wrong code with -O3 -march=skylake-avx512.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251 --- Comment #4 from Marc Glisse --- (In reply to Ilya Enkovich from comment #2) > Here is a responsible match.pd pattern: > > /* A + (B vcmp C ? 1 : 0) -> A - (B vcmp C), since vector comparisons >return all-1 or all-0 results. */ Since

[Bug target/70290] New: -mavx512vl breaks parsing of C++ vector comparison

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* typedef int vec __attribute__((vector_size(32))); vec f(vec x,vec y){return (x<y)?1:0;} Usin

[Bug target/70290] -mavx512vl breaks parsing of C++ vector condition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70290 Marc Glisse changed: What|Removed |Added Summary|-mavx512vl breaks parsing |-mavx512vl breaks parsing

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728 --- Comment #14 from Marc Glisse --- Note that I don't think we ever got a proper bug report for GMP. Verified instructions on how to reproduce the issue with just the latest version of GMP (without having to download the sources of mpfr, mpc,

[Bug c++/70121] [5/6 Regression] spurious warning and crash when returning a reference from lambda

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

[Bug c/70085] False positive -Wmisleading-indentation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70085 --- Comment #1 from Marc Glisse --- I think David changed that a couple days ago (PR 68187), could you try a more recent snapshot?

[Bug c++/70065] Add a new option to suppress a warnings about operators priority

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065 --- Comment #7 from Marc Glisse --- Before your patch, the code uses warning(OPT_Wparentheses,...), and -Wno-parentheses inhibits the warning just fine (this is done in diagnostic.c). If you replace OPT_Wparentheses with OPT_Wwhatever,

[Bug c++/70065] Add a new option to suppress a warnings about operators priority

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065 --- Comment #1 from Marc Glisse --- Patches should be sent to gcc-patc...@gcc.gnu.org for review. Please avoid unrelated whitespace changes in your patch. The test "if (warn_precedence)" seems redundant with the use of OPT_Wprecedence.

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68714 --- Comment #7 from Marc Glisse --- I find it strange that we do all operations on masks and not on "booleans" for vectors. typedef int T; T f(T a,T b,T c,T d){ return (a

[Bug c++/69892] Missing -Wuninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69892 --- Comment #4 from Marc Glisse --- The example in comment #3 shows a missed optimization: if (valid_3(D) != 0) could be optimized to if(true) or if(false), whichever is most convenient (__builtin_unreachable() might also be a possibility).

[Bug c++/69892] Missing -Wuninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69892 --- Comment #2 from Marc Glisse --- (In reply to Marc Glisse from comment #1) > On the other hand, pass_early_warn_uninitialized is before that, and should > have warned, not sure why it failed... Ah, no, it is only the late pass that looks at

[Bug c++/69892] Missing -Wuninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69892 --- Comment #1 from Marc Glisse --- : # valid_1 = PHI if (valid_1 != 0) goto ; else goto ; : valid_3 = 0; goto ; CCP notices that valid_1 is either undefined or 0 and simplifies it to 0. There

[Bug middle-end/69845] [5/6 Regression] Expression getting incorrectly optimized after being rewritten by compiler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69845 --- Comment #3 from Marc Glisse --- Probably extract_muldiv... It does check TREE_OVERFLOW, but for some reason only aborts if the result is INT_MIN.

[Bug tree-optimization/69556] [6 Regression] forwprop4/match.pd undoing work from recip

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556 --- Comment #5 from Marc Glisse --- (In reply to rguent...@suse.de from comment #4) > I think there is a misunderstanding. A replacement is still allowed if it > is a single operation as that replaces at least one other (the one we are >

[Bug tree-optimization/45216] Rotate expressions not recognized at tree level

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216 --- Comment #14 from Marc Glisse --- (In reply to Bernd Schmidt from comment #12) > It looks like a patch was committed - can this be closed? There is still PR62263, so not all cases are handled, but if all those mentioned in this PR are fixed,

[Bug target/69441] pandn implemented as pand within asm

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

[Bug target/69441] pandn implemented as pand within asm

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

[Bug tree-optimization/69336] New: Constant value not detected

: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Created attachment 37384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37384=edit testcase This code was posted on the boost

[Bug tree-optimization/69308] ifcombine joins together floating point expression with side effects

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

[Bug libstdc++/60637] --fast-math breaks std::signbit function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60637 --- Comment #5 from Marc Glisse --- (In reply to Jonathan Wakely from comment #4) > I think we can fix the C++98 std::signbit(_Tp) with: > > typedef typename __gnu_cxx::__promote<_Tp>::__type __type; > return sizeof(__type) ==

[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 --- Comment #15 from Marc Glisse --- (In reply to Joost VandeVondele from comment #13) > Shouldn't disabling this be language dependent ? I.e. in Fortran this > transformation is always valid (as integers in conforming programs are > always in

[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 --- Comment #17 from Marc Glisse --- (In reply to Jakub Jelinek from comment #16) > I think it doesn't. Plus, am not sure if it would be safe to use it > everywhere in the middle-end (plus, what about LTO, e.g. when you mix > C/C++/... and

[Bug libstdc++/68984] error: ‘constexpr bool std::isinf(double)’ conflicts with a previous declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68984 --- Comment #1 from Marc Glisse --- This is really a dup of PR60407, PR48891, but it is true that the error message looks a bit different when you write things this way.

[Bug libstdc++/63218] More compact std::bitset for small n

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63218 --- Comment #3 from Marc Glisse --- (In reply to H.J. Lu from comment #2) > X32 also wants long long. Is there a good way to ask for the longest of the integer types that are fast? stdint.h has things like int_fastN_t (btw, I don't like some of

[Bug libstdc++/69152] _GLIBCXX_BITSET_BITS_PER_WORD is wrong for x32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69152 --- Comment #1 from Marc Glisse --- This macro is about the typedef _WordT in bitset (currently "long", so __SIZEOF_LONG__ is exactly what we want), not about the compiler notion of "word". Using "long" for that typedef is suboptimal on x32, but

[Bug libstdc++/69092] basic_string constructor and throwing iterators

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

[Bug middle-end/67797] builtin functions should be able to know when their first argument is returned

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67797 --- Comment #2 from Marc Glisse --- Note that gcc knows about it, thanks to the "fn spec" attribute (see also ERF_RETURNS_ARG), it just doesn't try hard enough to take advantage of it.

[Bug tree-optimization/16107] missed optimization with some math function builtins

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

[Bug tree-optimization/55180] Missed optimization abs(-x) -> abs(x)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55180 Bug 55180 depends on bug 16107, which changed state. Bug 16107 Summary: missed optimization with some math function builtins https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16107 What|Removed |Added

[Bug tree-optimization/57600] Turn 2 comparisons into 1 with the min

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

[Bug libstdc++/61347] std::distance(list.first(),list.end()) in O(1)

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 57600, which changed state. Bug 57600 Summary: Turn 2 comparisons into 1 with the min https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57600 What|Removed |Added

[Bug tree-optimization/63185] Improve DSE with branches

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185 --- Comment #6 from Marc Glisse --- In addition to the issues already described, it seems that we generate better code if I replace the VLAs with calls to alloca. Indeed, we assume that alloca returns 16-aligned memory, while with

[Bug inline-asm/59181] constraint "+xt" rejected: output constraint 0 must specify a single register

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

[Bug libstdc++/68877] [6 Regression] swap for multidimensional array of int ill-formed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68877 --- Comment #2 from Marc Glisse --- I suggest (this is not a joke) that the right fix is to implement noexcept(auto) as an extension (possibly available only in system headers for now), and use it inside the library.

[Bug c++/68049] [5/6 Regression] template instantiation involving may_alias defines symbol twice

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

<    8   9   10   11   12   13   14   15   16   17   >