https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Andrew Pinski changed:
What|Removed |Added
Keywords||alias, missed-optimization
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #4 from Andrew Pinski ---
(In reply to Xi Ruoyao from comment #2)
> Does not Richard's response still apply here?
>
> > Sorry, but the vector v is potentially clobbered by the call to f, so the
> > load
> > of the array pointer you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Xi Ruoyao changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445
Andrew Pinski changed:
What|Removed |Added
Component|libstdc++ |ipa
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445
Bug ID: 109445
Summary: r13-6372-g822a11a1e642e0 regression due to noline with
-Ofast -march=sapphirerapids -funroll-loops -flto,
541.leela_r performance decrease by 2-3%
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109444
--- Comment #1 from Andrew Pinski ---
There is padding bytes for Foo because the alignment of Foo needs to be the
same alignment as a pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109444
Bug ID: 109444
Summary: Possible array overflow without diagnosis in memcpy if
called within a virtual method scenario
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356
--- Comment #5 from Jonny Grant ---
I see it is more complicated than I imagined. Thank you for looking into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #2 from AK --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #1 from AK ---
Link to issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269 where I
derived the testcase from.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Bug ID: 109443
Summary: missed optimization of std::vector access (Related to
issue 35269)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433
--- Comment #2 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #1)
> With -std=c++11, started to ICE with r12-6326-ge948436eab818c527dd6.
> With -std=c++14, started to ICE with r9-1483-g307193b82cecb8ab79cf.
Yes that is exactly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
Bug ID: 109442
Summary: Dead local copy of std::vector not removed from
function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584
--- Comment #2 from Andrew Pinski ---
I think there is just a missing warning for the plain decl case and the
structure member case is not a spurious warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584
oliver at futaura dot co.uk changed:
What|Removed |Added
CC||oliver at futaura dot co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441
--- Comment #1 from AK ---
I guess a better test case is this:
#include
using namespace std;
using T = int;
T v(std::vector v) {
T s;
std::fill(v.begin(), v.end(), T());
for (auto i = 0; i < v.size(); ++i) {
s += v[i];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440
Andrew Pinski changed:
What|Removed |Added
Keywords||alias
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441
Bug ID: 109441
Summary: missed optimization when all elements of vector are
known
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440
Bug ID: 109440
Summary: Missed optimization of vector::at when a function is
called inside the loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177
--- Comment #5 from Stam Markianos-Wright ---
With the fix to MVE auto_inc having gone in as
ddc9b5ee13cd686c8674f92d46045563c06a23ea I have found that this fix keeps the
auto-inc on these predicated stores broken.
It seems to fail in auto_inc_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439
Bug ID: 109439
Summary: RFE: Spurious -Wanalyzer-use-of-uninitialized-value
tagging along -Wanalyzer-out-of-bounds
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
--- Comment #10 from Martin Jambor ---
The problem is actually slightly different, I have just attached a possible fix
to both to PR 107769.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769
--- Comment #7 from Martin Jambor ---
Created attachment 54817
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54817&action=edit
potential patch
I am testing the attached patch. I'd like to think about the whole situation a
bit more next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109438
Bug ID: 109438
Summary: Excessive Duplication of -Wanalyzer-out-of-bounds
warnings
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437
Bug ID: 109437
Summary: -Wanalyzer-out-of-bounds is emitted at most once per
frame.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061
--- Comment #6 from Barry Revzin ---
Any action on this one?
A workaround right now is to change code that would ideally look like (which is
pretty clean in my opinion):
template
void foo() {
[[gnu::section(".meow")]] static int value = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109436
Bug ID: 109436
Summary: AArch64: suboptimal codegen in 128 bit constant stores
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109402
--- Comment #2 from Mikael Pettersson ---
Please send patches to gcc-patches for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:ddc9b5ee13cd686c8674f92d46045563c06a23ea
commit r13-7114-gddc9b5ee13cd686c8674f92d46045563c06a23ea
Author: Richard Earnshaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028
--- Comment #7 from LIU Hao ---
clang generates 14 bytes:
```
mov rax, 0x7FFF # 48 B8 FF FF FF FF FF FF FF 7F
and rax, rcx # 48 23 C1
ret # C3
``
but in principle this function requires o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109416
--- Comment #3 from Sinan ---
Hi Andrew,
Thank you for taking the time to explain the issue. I appreciate it.
I think the issue between init/init2 and init3 might be different. Regarding
init3, any 32-bit backend attempting to split a complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435
--- Comment #1 from Jovan Dmitrović ---
This is compile command that I used:
mipsisa64r6-linux-gnuabi64-gcc -march=mips64r6 -mabi=64 -O0 -o foo foo.c
-static
I used the MIPS gcc package from Ubuntu's package repository.
Also, I used qemu-mips6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435
Bug ID: 109435
Summary: [MIPS64R6] Typedef struct alignment returns incorrect
results
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12 Regression] |[10/11 Regression] variadic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425
--- Comment #3 from Marek Polacek ---
(In reply to Hannes Hauswedell from comment #2)
> Thanks for the quick reply, and nice that it is already fixed for 13!
>
> I assume this will not be backported? It wouldn't be a huge problem, because
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431
Marek Polacek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:7f056d5f4a0b9e29561d0375d5b4ad42c9f3f61e
commit r13-7113-g7f056d5f4a0b9e29561d0375d5b4ad42c9f3f61e
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028
--- Comment #6 from LIU Hao ---
Looks like this has been fixed? https://gcc.godbolt.org/z/xP5E76aYz
Despite that however, GCC generates suboptimal code that uses an XMM register
to perform the bitwise AND operation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-04-06
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
Bug ID: 109434
Summary: std::optional weird -Wmaybe-unitialized and behaviour
with -O2
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426
--- Comment #6 from Jonathan Wakely ---
It's a pattern with this person:
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&email1=zhonghao%40pku.org.cn&emailreporter1=1&ema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698
Matthijs Kooijman changed:
What|Removed |Added
CC||matthijs at stdin dot nl
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426
--- Comment #5 from Xi Ruoyao ---
(In reply to Jonathan Wakely from comment #4)
> N.B. this code is just copied from PR 54402. It might have been helpful to
> say where you found the code.
>
> zhonghao, it's really not helpful to just copy&past
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433
Bug ID: 109433
Summary: [12/13 Regression] ICE with -std=c++11 and static
constexpr array inside a template constexpr
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431
--- Comment #1 from Andrew Pinski ---
Reduced:
```
struct RangeLimits
{
int low = 0;
int high = 1;
constexpr RangeLimits() { }
};
template
int parameterLimits(void)
{
static RangeLimits constexpr param_limits[ 2 ] = {};
aut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429
--- Comment #3 from Jovan Dmitrović ---
Another thing that has come to attention is the register pressure costs being
calculated improperly. More information and a patch are submitted at the link
below.
https://gcc.gnu.org/pipermail/gcc-patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429
--- Comment #2 from Jovan Dmitrović ---
*** Bug 109430 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109430
Jovan Dmitrović changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426
--- Comment #4 from Jonathan Wakely ---
N.B. this code is just copied from PR 54402. It might have been helpful to say
where you found the code.
zhonghao, it's really not helpful to just copy&paste code that you don't
understand into bug report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
--- Comment #14 from Jonathan Wakely ---
You need to change godbolt.org to compile C not C++. Please stop adding
completely useless comments to bugzilla or I will block your account.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480
--- Comment #5 from Jonathan Wakely ---
(In reply to zhonghao from comment #4)
> Is this bug fixed? I tried the latest gcc, but it still rejects the sample
> code.
No, the latest gcc accepts this C code without errors. Please stop commenting
on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508
--- Comment #3 from Jonathan Wakely ---
(In reply to Frank Heckenbach from comment #2)
> And all that because the library
> doesn't know what the space character is in UTF-8.
That's a completely wrong description of the problem.
The standard li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407
--- Comment #2 from johgjc ---
thank you very much.
At 2023-04-04 23:55:25, "pinskia at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407
>
>Andrew Pinski changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429
--- Comment #1 from Jovan Dmitrović ---
It seems that commit f9f69dd changed the way complexity is calculated, so now
the complexity equals zero across the board, for each candidate.
Here is one testcase:
void daxpy(float *vector1, float *vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
zhonghao at pku dot org.cn changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480
zhonghao at pku dot org.cn changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109432
Bug ID: 109432
Summary: tracker bug for issues with -Wanalyzer-out-of-bounds
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431
Bug ID: 109431
Summary: internal compiler error: in
output_constructor_regular_field (varasm.c:5207)
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109430
Bug ID: 109430
Summary: ivopts: Revert register pressure cost when there are
enough registers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429
Bug ID: 109429
Summary: ivopts: Compute complexity for unsupported addressing
modes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495
--- Comment #8 from Jakub Jelinek ---
No, works just fine. Perhaps you are compiling with C++ when this is C?
71 matches
Mail list logo
