[Bug rtl-optimization/44675] Inefficient code to return a large struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44675 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2010-07-03 00:23:14 |2021-8-7 Severity|normal |enhancement
[Bug rtl-optimization/43226] simplify_binary_operation_1 MINUS x const_int issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43226 --- Comment #1 from Andrew Pinski --- This changed over to wide_int (well poly_wide_int but for most targets it is just wide_int). I have not looked to see if that fixes the issue here though.
[Bug rtl-optimization/40480] Inefficient code on insn with fixed hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40480 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Keywords||missed-optimization, ra --- Comment #1 from Andrew Pinski --- Fixed at least in 4.8.0 as the forcing to the register was removed with r0-118679.
[Bug rtl-optimization/39350] MOVE_BY_PIECES_P is used by rtl optimizers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39350 --- Comment #2 from Andrew Pinski --- This area has changed a lot really. In r5-4585, it is now a target hook.
[Bug target/37124] ICE with attribute(option("no-mmx"))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37124 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|rtl-optimization|target Target Milestone|--- |4.6.0 Resolution|--- |FIXED Known to fail||4.5.3 Keywords||ice-on-valid-code Known to work||4.6.4, 4.7.1, 4.8.5, 5.1.0 --- Comment #1 from Andrew Pinski --- Fixed a long time ago. Also __option__ became target.
[Bug c++/94953] A lot of false maybe-uninitialized warnings with O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94953 --- Comment #3 from Andrew Pinski --- So there looks like there are two issues. First warning for each template instantiation. The second problem is SLP is introducing some uses that was not in the original IR.
[Bug c++/91290] pragma maybe-uninitialized does not propagate to lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91290 --- Comment #2 from Andrew Pinski --- I suspect this is fixed on the trunk with r12-1805.
[Bug c++/89478] missed optimization for lambda expression when variable is uninitialized when declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89478 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |c++ Blocks||54367 --- Comment #4 from Andrew Pinski --- For the original testcase except for test4, it is optimized for C++20 and not C++17. Most likely because lambdas are considered constexpr if they can be such. In test4 I suspect the uninit variable is making it not considered constexpr. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 [Bug 54367] [meta-bug] lambda expressions
[Bug tree-optimization/59908] Incorrect uninit warning with -fsanitize=address caused by LIM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59908 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |4.9.2 Status|NEW |RESOLVED --- Comment #9 from Andrew Pinski --- Fixed for GCC 5 with r5-2621 and 4.9.2 with g:5456720833910e . Basically The inlining of the ASAN_CHECK later on fixes the issue.
[Bug tree-optimization/60279] Incorrect column number for -Wuninitialized in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60279 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0 Status|NEW |RESOLVED Keywords||diagnostic Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- trunk : In function 'f': :5:19: warning: 's' is used uninitialized [-Wuninitialized] 5 | return g(s); | ^~~~ 7: : In function 'f': :5:19: warning: 's' is used uninitialized in this function [-Wuninitialized] return g(s); ^~~~ 5: : In function 'f': :5:19: warning: 's' is used uninitialized in this function [-Wuninitialized] return g(s); ^ So fixed in GCC 5. For the C++ front-end: 8: : In function 'int f()': :5:20: warning: 's' is used uninitialized in this function [-Wuninitialized] return g(s); ~^~~ 7: : In function 'int f()': :5:22: warning: 's' is used uninitialized in this function [-Wuninitialized] return g(s); ^
[Bug tree-optimization/82585] missing -Warray-bounds calling strlen on a member at out-of-bounds offfset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82585 --- Comment #3 from Andrew Pinski --- Hmm, at -O0 we get the warning for both functions now. But at -O1 we only get it for the first one.
[Bug tree-optimization/80406] Reduced false positive test case for -Warray-bounds with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80406
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|--- |8.0
Status|NEW |RESOLVED
--- Comment #3 from Andrew Pinski ---
GCC before 8, is execusively unrolling:
for (j=i; j < npts; j++) {
k[j] = k[j+1]; /* False positive -Warray-bounds issued here */
}
Fixed most likely by r8-5008.
[Bug middle-end/63213] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63213 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |8.0 Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- This was just execusive unrolling of the two loops: while(p[ps1-1].y == cury) ps1--; while(p[ps2+1].y == cury) ps2++; That was fixed in GCC 8.
[Bug middle-end/61957] Wrong -Warray-bounds warning depending on parameter types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61957 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.9.3 Keywords||diagnostic Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- So this was fixed by r5-6842 which was backported for GCC 4.9.3 also.
[Bug tree-optimization/61277] Incorrect -Warray-bounds warning with 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61277 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.3 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- So this was fixed by r5-6842 which was backported for GCC 4.9.3 also.
[Bug bootstrap/59979] mpc configure does not check for non-gnu compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59979 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- You should report this to the MPC folks (http://www.multiprecision.org/mpc/) since GCC does not control MPC.
[Bug target/101816] New: slight missed optimization with __builtin_add_overflow with ^1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101816
Bug ID: 101816
Summary: slight missed optimization with __builtin_add_overflow
with ^1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-linux-gnu
Take:
void f(unsigned long long *x, unsigned long long y, unsigned long long z)
{
int d = __builtin_add_overflow (*x,y,x);
x[1] += z + !d;
}
Right now we produce:
xorl%eax, %eax
addq(%rdi), %rsi
setc%al
movq%rsi, (%rdi)
xorq$1, %rax
addq%rdx, %rax
addq%rax, 8(%rdi)
ret
But the setc and xor could be combined into:
setnc %al
[Bug tree-optimization/85143] Loop limit prevents (auto)vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85143 Andrew Pinski changed: What|Removed |Added CC||josh.m.conner at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 56352 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/56352] Simplify testing of related conditions in for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56352 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |RESOLVED Known to fail||8.1.0, 8.5.0 Resolution|--- |DUPLICATE Known to work||10.1.0, 9.1.0, 9.4.0 --- Comment #2 from Andrew Pinski --- GCC9+ does the correct thing: .L5: movl%ebx, %edi addl$1, %ebx callf(int) cmpl%ebx, %ebp jg .L5 GCC 8.5 had: _9 = b_5(D) <= i_7; _8 = a_4(D) <= i_7; _10 = _8 | _9; This was fixed by r9-104. Note there is some issues with mixing constants and non-constants but that is still recorded in PR 85143. And really this is a dup of bug 85143. *** This bug has been marked as a duplicate of bug 85143 ***
[Bug tree-optimization/56352] Simplify testing of related conditions in for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56352
--- Comment #1 from Andrew Pinski ---
Testcase:
int f(int);
void g(int a, int b)
{
int i;
for (i = 0; i < a; i++)
{
if (i >= b)
break;
f(i);
}
}
[Bug c++/56090] Injected-class-name treated as constructor name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56090 --- Comment #4 from Andrew Pinski --- GCC, clang, ICC and MSVC all say this is not a bug and the name is a constructor name in this context.
[Bug sanitizer/55739] asan doesn't work on common symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #14 from Andrew Pinski --- Note -fno-common is default since r10-4867 so I think it is best if we close this as won't fix.
[Bug target/55600] excessive size of vectorized code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55600 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Keywords||missed-optimization Component|tree-optimization |target --- Comment #4 from Andrew Pinski --- So here is what the current state for this. GCC vectorizers it and unroll it fully at 128 and 64 clang keeps it as **scalars** but unrolls the loop 4 times at 128 and fully at 64 ICC vectorizers it and unrolls it half way (that is 32 times) at 128 and fully at 64 MSVC keeps it as **scalars** but unrolls it half way (that is 32 times) at 128 So it looks all compilers do stuff hugely different here really.
[Bug tree-optimization/55760] scalar code non using rsqrtss and rcpss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55760 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=47989 Keywords||documentation --- Comment #7 from Andrew Pinski --- See PR 47989 for the reason why this option is not enabled for scalar code and why it was only enabled for vectorized code.
[Bug tree-optimization/27109] Simplify "a - 10 > 150" into "a > 160" when range of a is known (in VRP or somewhere else)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
--- Comment #6 from Andrew Pinski ---
Another testcase which shows up via the autovectorizer aliasing checks
int g(unsigned int a)
{
if (a == 0) __builtin_unreachable();
unsigned int t = a;
a += -1;
return a > 3u;
}
[Bug tree-optimization/27109] Simplify "a - 10 > 150" into "a > 160" when range of a is known (in VRP or somewhere else)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109 --- Comment #5 from Andrew Pinski --- *** Bug 101815 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/101815] unsigned + -1u > 3 is not optimzied to unsigned > 4 if unsigned range is known not to include 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101815 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 27109 :). This is what I get for not looking up on my own bugs too. *** This bug has been marked as a duplicate of bug 27109 ***
[Bug tree-optimization/101815] unsigned + -1u > 3 is not optimzied to unsigned > 4 if unsigned range is known not to include 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101815 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=50756 --- Comment #1 from Andrew Pinski --- And yes this actually shows up in real code, mostly with the autovectorizer, see PR 50756.
[Bug tree-optimization/101815] New: unsigned + -1u > 3 is not optimzied to unsigned > 4 if unsigned range is known not to include 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101815
Bug ID: 101815
Summary: unsigned + -1u > 3 is not optimzied to unsigned > 4 if
unsigned range is known not to include 0
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
int f(unsigned int a)
{
if (a == 0) return 0;
unsigned int t = a;
a += 4294967295;
return a > 3u;
}
int g(unsigned int a)
{
if (a == 0) __builtin_unreachable();
unsigned int t = a;
a += -1;
return a > 3u;
}
Both of these should produce:
_7 = a_3(D) > 4;
# RANGE [0, 1] NONZERO 1
_4 = (intD.6) _7;
But only f does.
f is able to be optimized in reassoc1.
[Bug tree-optimization/50756] request to better handle non-constant distance vectors to avoid unnecessary alias check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50756 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-07 --- Comment #1 from Andrew Pinski --- Confirmed, still happens.
[Bug rtl-optimization/50898] Register allocation depends on function return expression on x86 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50898 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |4.8.0 Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.9.1 --- Comment #1 from Andrew Pinski --- Looks like it was fixed in GCC 4.8.0
[Bug c++/101209] [10/11/12 Regression] ICE with trailing return type on a conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101209 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-07 Target Milestone|--- |9.5 Summary|ICE with trailing return|[10/11/12 Regression] ICE |type on a conversion|with trailing return type |operator|on a conversion operator Known to work||7.1.0, 9.1.0, 9.4.0 Known to fail||10.1.0 --- Comment #2 from Andrew Pinski --- Confirmed, a regression from 9.x.
[Bug c++/88577] misleading error message with template and auto return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88577 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=20665, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=16189 Last reconfirmed||2021-08-07 --- Comment #1 from Andrew Pinski --- Confirmed. Related to the old PR 16189 which was fixed. Only the auto case looks need to be fixed.
[Bug c++/69632] No error issued for declaring a parameter having a late-specified return type without the 'auto' type specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69632 --- Comment #1 from Andrew Pinski --- GCC 9+ produce: :1:28: error: 'parameter' function with trailing return type not declared with 'auto' type specifier 1 | int foo (long (int) -> char); |^~~~
[Bug c++/56389] Return types differs in block scope function declarations and function implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56389 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > Fixed for GCC 11. I cannot figure out which patch fixed it though. > There has been a bunch of fixes dealing with return types dealing with C++20 > concepts. For an example PR 96443.
[Bug c++/56389] Return types differs in block scope function declarations and function implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56389 Andrew Pinski changed: What|Removed |Added Keywords||accepts-invalid --- Comment #4 from Andrew Pinski --- Fixed for GCC 11. I cannot figure out which patch fixed it though. There has been a bunch of fixes dealing with return types dealing with C++20 concepts.
[Bug tree-optimization/101403] [12 Regression] wrong code with __builtin_bswap16() at -O1 by r12-2137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101403 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Roger Sayle --- Fixed on mainline.
[Bug c++/68288] botched floating-point UDL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68288 --- Comment #5 from Andrew Pinski --- GCC, ICC, and clang all reject this. MSVC accepts this.
[Bug objc/101718] Objective-C frontend emits wrong code to call methods returning scalar types returned in memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101718
--- Comment #1 from Iain Sandoe ---
(In reply to Matt Jacobson from comment #0)
> When a method returns a type that the platform ABI says is returned in
> memory, the Objective-C frontend (for the NeXT runtime ABIs) emits a call to
> `objc_msgSend_stret`; the `_stret` variant of the message dispatcher knows
> to look at the *second* argument for `self`, and so on, since the first
> argument is the pointer to where the return value will go.
>
> On some platforms, `_Complex double` is too large to be returned through
> registers, so it's returned through memory.
can you give me some idea of the platform? it would help with testing at least
(assuming that there is a suitable machine on the cfarm).
Having said that, there could be some types for which this would fire even on
Darwin.
> But the Objective-C frontend still insists on using `objc_msgSend`, not
> `objc_msgSend_stret`.
>
> `objc_msgSend` is thoroughly confused when the first argument, which it
> expects to be `self`, is actually a pointer to garbage-filled stack.
>
> I believe this happens because this check:
>
> ```
> /* If we are returning a struct in memory, and the address
> of that memory location is passed as a hidden first
> argument, then change which messenger entry point this
> expr will call. NB: Note that sender_cast remains
> unchanged (it already has a struct return type). */
> if (!targetm.calls.struct_value_rtx (0, 0)
> && (TREE_CODE (ret_type) == RECORD_TYPE
> || TREE_CODE (ret_type) == UNION_TYPE)
> && targetm.calls.return_in_memory (ret_type, 0))
> {
> ```
>
> limits the use of `stret` to record/union types. Primitive types that are
> returned in memory should also be made to use `stret` (the name's meaning
> notwithstanding).
makes sense, but the fix might be interesting given the "NB: Note that
sender_cast remains unchanged (it already has a struct return type)." which
would no longer be true for a primitive type.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 70069, which changed state. Bug 70069 Summary: Uninitialized value default to zero, plus warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/87210] [RFE] introduce build time options to zero initialize automatic stack variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 Andrew Pinski changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #8 from Andrew Pinski --- *** Bug 70069 has been marked as a duplicate of this bug. ***
[Bug middle-end/70069] Uninitialized value default to zero, plus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 87210 *** This bug has been marked as a duplicate of bug 87210 ***
[Bug middle-end/87210] [RFE] introduce build time options to zero initialize automatic stack variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Severity|normal |enhancement Ever confirmed|0 |1 Last reconfirmed||2021-08-07 Status|UNCONFIRMED |NEW --- Comment #7 from Andrew Pinski --- Confirmed.
[Bug middle-end/96426] __builtin_convertvector ICE without lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96426 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug middle-end/96426] __builtin_convertvector ICE without lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96426 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.4
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81376 --- Comment #15 from Andrew Pinski --- (In reply to Andrew Pinski from comment #14) > So the original case we do handle since r9-3447. I should say the cases where integer type does not fit into float/double is not handled and I cannot find it this was discussed when the patch was submitted or not. See PR 81376 also.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #14 from Andrew Pinski --- So the original case we do handle since r9-3447.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 95697, which changed state. Bug 95697 Summary: Failure to optimize float comparison of converted integer to integer comparison https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95697 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Andrew Pinski changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #13 from Andrew Pinski --- *** Bug 95697 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/95697] Failure to optimize float comparison of converted integer to integer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95697 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 60540. *** This bug has been marked as a duplicate of bug 60540 ***
[Bug c++/79751] Concept placeholder on another concept does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79751 Andrew Pinski changed: What|Removed |Added Keywords|wrong-code |accepts-invalid Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- :6:10: error: a concept cannot be constrained 6 | concept AnotherConcept = true; | ^~ Fixed in GCC 10+
[Bug c++/83167] decltype((x)) inside lambda is considered odr-use if x is not a reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83167 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79620, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94376 --- Comment #1 from Andrew Pinski --- No compiler fully accepts this code. clang fails on the 2nd and 4th asserts ICC fails on the 2nd assert only MSVC fails on all 4 asserts. GCC fails on the first 2 asserts. GCC is the only one that fails on the 1st assert via not being captured.
[Bug fortran/101814] Initialization of local variables broken in presence of SAVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101814 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-08-07 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=59537 Priority|P3 |P4 Keywords||rejects-valid Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- See also the related PR59537.
[Bug fortran/97896] [11/12 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #11 from Mikael Morin --- Patches posted: v1: https://gcc.gnu.org/pipermail/fortran/2021-August/056303.html v2: https://gcc.gnu.org/pipermail/fortran/2021-August/056317.html 11 backport: https://gcc.gnu.org/pipermail/fortran/2021-August/056329.html
[Bug fortran/68568] ICE with automatic character object and save, in combination with some options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68568 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from anlauf at gcc dot gnu.org --- The ICE is fixed for gcc-12. The issue with rejecting valid code in the presence of SAVE is tracked separately in PR101814. Thanks for the report!
[Bug fortran/68568] ICE with automatic character object and save, in combination with some options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68568 --- Comment #10 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:cd754efa9a5349c693919046b8be074395ea114e commit r12-2796-gcd754efa9a5349c693919046b8be074395ea114e Author: Harald Anlauf Date: Sat Aug 7 20:30:32 2021 +0200 Fortran: ICE with automatic character object, save, and various options gcc/fortran/ChangeLog: PR fortran/68568 * primary.c (gfc_expr_attr): Variable attribute can only be inquired when symtree is non-NULL.
[Bug fortran/101814] New: Initialization of local variables broken in presence of SAVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101814 Bug ID: 101814 Summary: Initialization of local variables broken in presence of SAVE Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- While working on PR68568, I realized that using initialization of local variables using -finit-local-zero, -finit-integer=nnn etc. rejects valid code in the presence of a SAVE statement. % cat zz1.f90 subroutine s1(n) integer, intent(in) :: n character(len=n):: x save x = 'a' end % gfc-12 -c zz1.f90 -finit-local-zero zz1.f90:1:13: 1 | subroutine s1(n) | 1 Error: non-constant initialization expression at (1) % cat zz2.f90 subroutine s2(n) integer, intent(in) :: n integer :: y(n) save y = 1 end % gfc-12 -c zz2.f90 -finit-local-zero zz2.f90:3:29: 3 | integer :: y(n) | 1 Error: Automatic array 'y' at (1) cannot have an initializer % cat zz3.f90 subroutine s1(n) integer, intent(in) :: n character(len=n):: x(n) save x = 'a' end % gfc-12 -c zz3.f90 -finit-local-zero zz3.f90:3:29: 3 | character(len=n):: x(n) | 1 Error: Automatic array 'x' at (1) cannot have an initializer Commenting out the SAVE statements or removing -finit* allows the code to compile. Both error messages are bogus, and the code is valid: F2018: 8.6.14 SAVE statement (1) (...) A SAVE statement without a saved entity list is treated as though it contained the names of all allowed items in the same scoping unit. As automatic objects are not allowed items they should be ignored by the SAVE and its presence should not make any difference.
[Bug middle-end/51839] GCC not generating adc instruction for canonical multi-precision add sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51839 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |8.0 Resolution|--- |FIXED Keywords||missed-optimization --- Comment #2 from Andrew Pinski --- So this was implemented with the following revisions: r6-3012 r6-5232 r8-7547 And maybe a few others were needed.
[Bug ipa/101813] New: -O3 does worse at constant folding than -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101813
Bug ID: 101813
Summary: -O3 does worse at constant folding than -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
#include
#include
using opts = boost::optional;
struct foo
{
foo(opts x) : b(x), c(x) {}
opts a, b, c;
};
int main()
{
opts a;
foo bar(a);
}
at -O2 the example completely folds out, but not at -O3
https://godbolt.org/z/3n97aKKEh
[Bug middle-end/90773] Improve piecewise operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90773 --- Comment #18 from H.J. Lu --- *** Bug 74113 has been marked as a duplicate of this bug. ***
[Bug middle-end/74113] by_pieces_ninsns doesn't support TImode/OImode/XImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74113 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |12.0 --- Comment #2 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 90773 ***
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 88531, which changed state. Bug 88531 Summary: Index data types when targeting AVX-512 vectorization with gather/scatter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/88531] Index data types when targeting AVX-512 vectorization with gather/scatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531 H.J. Lu changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from H.J. Lu --- Fixed for GCC 12.
[Bug tree-optimization/88531] Index data types when targeting AVX-512 vectorization with gather/scatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531 --- Comment #14 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:6866f4819ad8e6e62fef2177520f9fb217dfa353 commit r12-2795-g6866f4819ad8e6e62fef2177520f9fb217dfa353 Author: H.J. Lu Date: Sat Aug 7 07:29:04 2021 -0700 Add tests for PR tree-optimization/88531 PR tree-optimization/88531 * gcc.target/i386/pr88531-1a.c: New test. * gcc.target/i386/pr88531-1b.c: Likewise. * gcc.target/i386/pr88531-1c.c: Likewise. * gcc.target/i386/pr88531-2a.c: Likewise. * gcc.target/i386/pr88531-2b.c: Likewise. * gcc.target/i386/pr88531-2c.c: Likewise.
[Bug middle-end/101809] emulated gather capability doesn't support 32-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101809
--- Comment #1 from H.J. Lu ---
It fails in get_load_store_type:
else if (!TYPE_VECTOR_SUBPARTS (vectype).is_constant ()
|| !known_eq (TYPE_VECTOR_SUBPARTS (vectype),
TYPE_VECTOR_SUBPARTS
(gs_info->offset_vectype)))
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
"unsupported vector types for emulated "
"gather.\n");
return false;
}
For V2DF gather, we need V2DI index. But for -m32, index is V4SI.
[Bug target/101812] New: [12 Regression] ICE: Segmentation fault (in ix86_expand_sse_movcc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101812 Bug ID: 101812 Summary: [12 Regression] ICE: Segmentation fault (in ix86_expand_sse_movcc) Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu gcc-12.0.0-alpha20210801 (g:6f0c43e97825ee54e3779afbedcd0def12443001) ICEs when compiling gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c w/ -O1 -ftree-loop-vectorize -fvect-cost-model=unlimited: % x86_64-unknown-linux-gnu-gcc-12.0.0 -O1 -ftree-loop-vectorize -fvect-cost-model=unlimited -c gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c during RTL pass: expand gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c: In function 'foo': gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c:7:6: internal compiler error: Segmentation fault 7 | void foo (int ilast,float* w, float* w2) | ^~~ 0xe4816f crash_signal /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/toplev.c:328 0x128d90a ix86_expand_sse_movcc(rtx_def*, rtx_def*, rtx_def*, rtx_def*) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/config/i386/i386-expand.c:3815 0x128f491 ix86_expand_fp_vcond(rtx_def**) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/config/i386/i386-expand.c:4685 0x167e4b9 gen_vcondv2sfv2sf(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/config/i386/mmx.md:908 0xd2af98 maybe_expand_insn(insn_code, unsigned int, expand_operand*) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/optabs.c:7835 0xd2af98 expand_insn(insn_code, unsigned int, expand_operand*) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/optabs.c:7866 0xbb61d0 expand_vec_cond_optab_fn /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/internal-fn.c:2812 0x97e637 expand_call_stmt /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/cfgexpand.c:2752 0x97e637 expand_gimple_stmt_1 /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/cfgexpand.c:3879 0x97e637 expand_gimple_stmt /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/cfgexpand.c:4043 0x984889 expand_gimple_basic_block /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/cfgexpand.c:6085 0x98663e execute /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210801/work/gcc-12-20210801/gcc/cfgexpand.c:6811
[Bug c++/101811] New: Error not helpful for misplaced 'template'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101811
Bug ID: 101811
Summary: Error not helpful for misplaced 'template'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobi at gcc dot gnu.org
Target Milestone: ---
This is a bad error message that caught my eye while refactoring some code
(https://godbolt.org/z/558vM4Wb3):
struct X {
void f();
};
template // this line should not be here
void X::f()
{}
gives:
:6:6: error: no declaration matches 'void X::f()'
6 | void X::f()
| ^
:2:10: note: candidate is: 'void X::f()'
2 | void f();
| ^
:1:8: note: 'struct X' defined here
1 | struct X {
|^
Note that the error message doesn't actually include what's wrong and so it is
fairly confusing until you actually look at the code.
[Bug tree-optimization/95404] Failure to optimize compare to power of 2 and bitwise and to more direct bitwise and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95404
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-08-07
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
What is interesting is clang does not even do it for:
int f2(int x)
{
int t = 0;
if ((unsigned)x > 15)
t= false;
else t = ~x;
return t&1;
}
But once you change int to bool, it does .
We might be able to do it for both.
[Bug tree-optimization/95738] Failure to optimize comparison of vector after sign xor to unsigned comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95738
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-07
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Confirmed.
We don't even do the scalar one:
int64_t f(int64_t a, int64_t b)
{
auto sign = (int64_t)0x8000u;
return (a ^ sign) > (b ^ sign);
}
[Bug target/80355] Improve __builtin_shuffle on AVX512F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80355 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/95923] Failure to optimize bool checks into and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-07 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Andrew Pinski --- Mine. _1 = ~a_6(D); _3 = _1 & b_7(D); if (_3 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 467721933]: _10 = _1 | b_7(D); [local count: 1073741824]: # _5 = PHI <0(3), _10(4), 0(2)> This is _3 ? 0 : _10 -> (_10 & ~3) And then this simplifies more.
[Bug rtl-optimization/64525] Duplicate instructions in both paths in conditional code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64525 --- Comment #5 from Andrew Pinski --- I can't figure out what fixed it in GCC 7. The gimple level is the same between 6 and 7 even.
[Bug target/64525] Duplicate instructions in both paths in conditional code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64525 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 Known to fail||6.3.0 Known to work||7.1.0
[Bug tree-optimization/82854] more missing simplifcations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82854 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-08-07 --- Comment #2 from Andrew Pinski --- Summary of some of these /* x + (x & 0x8000) -> x & 0x7fff */ No one does /* (x | 0x8000) + 0x8000 -> x & 0x7FFF */ LLVM does /* x & (0x7FFF - x) -> x & 0x8000 */ No one does, ICC does (-x + 0x7FFF) & x /* x | (x + 0x8000) -> x | 0x8000 */ LLVM does /* x | (0x7FFF - x) -> x | 0x7FFF */ No one does, ICC does (-x + 0x7FFF) | x /* x | (x ^ y) -> x | y */ GCC and LLVM /* -x | 0xFFFE -> x | 0xFFFE */ LLVM does /* 0 - (x & 0x8000) -> x & 0x8000 */ LLVM does /* ~(x + c) -> ~c - x */ GCC and LLVM /* (x | c) - c -> x & ∼c */ GCC and LLVM /* 0x7FFF - (x ^ c) -> x ^ (0x7FFF - c) */ LLVM does
[Bug tree-optimization/82854] more missing simplifcations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82854 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug middle-end/65855] SCEV / SCCP missing optimization: triangular numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855 Andrew Pinski changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #10 from Andrew Pinski --- *** Bug 82519 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/82519] Eliminating loop from summation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82519 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Yes I did, PR 65855. *** This bug has been marked as a duplicate of bug 65855 ***
[Bug middle-end/82519] Eliminating loop from summation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82519 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Severity|normal |enhancement Last reconfirmed||2021-08-07 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed, I thought I saw this one before.
[Bug sanitizer/61995] gcc 4.9.1 fails to compile with error in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61995 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- 2.6.32 (the last LTS for 2.6.x release) support was finished in 2016. So just closing as won't fix. 5 years after the newest kernel release of that release series is long enough.
[Bug sanitizer/61995] gcc 4.9.1 fails to compile with error in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61995 --- Comment #3 from Andrew Pinski --- https://lore.kernel.org/lkml/4d407589.2030...@teksavvy.com/
[Bug target/80355] Improve __builtin_shuffle on AVX512F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80355 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-07 Status|UNCONFIRMED |NEW Severity|normal |enhancement Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/79675] Pointless reg1 <- reg2; reg2 <- reg1 moves inside loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79675 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |9.0 --- Comment #3 from Andrew Pinski --- On the 9.3+ we get: .L4: ldrbw0, [x19], 1 cbz w0, .L6 .L3: sub x20, x19, #1 cmp w21, w0 bne .L4 mov x2, x23 mov x1, x22 mov x0, x19 bl strncmp cbnzw0, .L4 GCC 7 and 8 got us: .L9: beq .L8 .L4: mov x20, x19 mov x19, x20 ldrbw1, [x19], 1 cmp w21, w1 cbnzw1, .L9 ... .L8: .cfi_restore_state mov x2, x22 mov x1, x23 mov x0, x19 bl strncmp cbnzw0, .L4 Which had the moves. GCC 9+ ch does: Analyzing loop 1 Loop 1 is not do-while loop: latch has multiple predecessors. Will duplicate bb 7 Not duplicating bb 1: both sucessors are in loop. Duplicating header of the loop 1 up to edge 7->4, 4 insns. Loop 1 is do-while loop Loop 1 is now do-while loop. While 8- ch has: Analyzing loop 1 Loop 1 is do-while loop Which means this was fixed by r9-23.
