https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61110
Bug 61110 depends on bug 114894, which changed state.
Bug 114894 Summary: `a == 0 ? 0 : a * b` -> `a * b` likewise for `a & b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970
Andrew Pinski changed:
What|Removed |Added
Summary|32-bit ARM gcc-14.1 new |[14/15 Regression] 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979
--- Comment #3 from Andrew Pinski ---
(In reply to Jorge Acereda from comment #2)
> Thanks for the prompt reply. I understand the behaviour for external
> functions, but for static functions, isn't it a missed opportunity for
> optimization?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114952
--- Comment #3 from Andrew Pinski ---
Note I don't think this is a `False positive` exactly because GCC has no
knowledge that errno could be non-zero after a fail call to open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||2024-05-07
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Andrew Pinski ---
I think this is a dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97263
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew D'Addesio from comment #7)
>
> This actually has gotten me curious. Would you have an idea/explanation
> behind that 2 function call threshold @Andrew Pinski?
Most likely it is due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
--- Comment #6 from Andrew Pinski ---
Reduded testcase that fails at -O1 (but passes at -O2):
```
[[gnu::noipa]]
static void g(char pad1) {
if (pad1 != '0' && pad1 != '+' && pad1 != '_')
__builtin_unreachable();
if (pad1 == '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
--- Comment #5 from Andrew Pinski ---
Oh I see where the bug is coming from.
reassociation is turning:
_2 = pad_6 == 48;
_3 = pad_6 == 43;
_4 = _2 | _3;
Into:
_11 = (unsigned char) pad_6;
_12 = (int) _11;
_13 = 290271069732864 >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
Andrew Pinski changed:
What|Removed |Added
Summary|[14/15 Regression] wrong|[13/14/15 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
Andrew Pinski changed:
What|Removed |Added
Attachment #58112|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
--- Comment #1 from Andrew Pinski ---
Created attachment 58112
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58112=edit
Slightly reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97263
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114177
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962
--- Comment #4 from Andrew Pinski ---
(In reply to Marek Polacek from comment #3)
> // PR c++/114962
Reduced much further and even removing the for loop and the array:
```
struct A {
void third();
using Handler = void (A::*)();
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
--- Comment #10 from Andrew Pinski ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650833.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275
--- Comment #9 from Andrew Pinski ---
(In reply to Adhemerval Zanella from comment #8)
> This has triggered some regression on aarch64 [1]:
>
> Running g++:g++.dg/modules/modules.exp ...
> FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114960
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527
--- Comment #8 from Andrew Pinski ---
(In reply to Deepthi H from comment #7)
>
> Let us know your comments on this solution. Such a solution is acceptable to
> change the gcc driver?
Seems better to place the arguments in a file instead and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955
--- Comment #6 from Andrew Pinski ---
It is not about the alignment of the first field but rather the alignment of a
struct. BUT variable alignment is controlled separately from struct alignment.
That is the point I am trying to make. If you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
--- Comment #7 from Andrew Pinski ---
(In reply to YunQiang Su from comment #6)
> With some test on some CPUs, in fact, the lacking of `sll` won't make
> troubles to us.
> It seems that most of MIPS64 CPUs can process it well as expected.
When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955
--- Comment #2 from Andrew Pinski ---
Also DATA_ALIGNMENT (and LOCAL_ALIGNMENT) does not conflict with `pragma pack`.
The documentation says
https://gcc.gnu.org/onlinedocs/gcc/Structure-Layout-Pragmas.html :
```
that change the maximum
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
I noticed the `#pragma pack` is not in the concept index but there exists a
page for it:
https://gcc.gnu.org/onlinedocs/gcc/Structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955
Andrew Pinski changed:
What|Removed |Added
Component|c |target
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #20 from Andrew Pinski ---
New patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650757.html
It was simplier than I had expected too.
: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
The testcase has:
```
auto const dur = 250ms;
...
auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114952
--- Comment #1 from Andrew Pinski ---
Most likely GCC does not know errno is non-zero after the call to elf_open and
checking `fd < 0`.
Adding:
if (ret == 0) __builtin_unreachable();
After the assignment of `ret = -errono;` fixes the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114951
Andrew Pinski changed:
What|Removed |Added
Known to work||14.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114948
Andrew Pinski changed:
What|Removed |Added
Summary|ICE on valid code at -O3|[14/15 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114945
Andrew Pinski changed:
What|Removed |Added
Summary|[14 regression] Sporadic|[14/15 regression] Sporadic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-05-03
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
--- Comment #12 from Andrew Pinski ---
Note only the `;` issue has been resolved, the other 2 issues I have to rework.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860
--- Comment #5 from Andrew Pinski ---
(In reply to prathamesh3492 from comment #4)
> To check for any
> possible icache misses I used L1I_CACHE_REFILL counter, and turns out that
> there are 64% more L1 icache misses for above adrp instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114938
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |c
Summary|Basic blocks in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114938
--- Comment #1 from Andrew Pinski ---
Created attachment 58102
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58102=edit
reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114939
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941
--- Comment #1 from Andrew Pinski ---
So a patch like what was done in r0-56719-g34208acf14fa02 needs to be done to
libbacktrace . Basically this has always been broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
--- Comment #7 from Andrew Pinski ---
(In reply to LIU Hao from comment #6)
> This paragraph is new in N4658 and was not in N4917. Better to avoid it by
> moving the specialization into an extern "C++" block. Thanks for the report.
Right that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
--- Comment #5 from Andrew Pinski ---
The easy fix is to do:
extern "C++" { template struct __MCF_static_assert; }
extern "C++" { template<> struct __MCF_static_assert { }; }
Note from the commit message:
However there are also a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
--- Comment #3 from Andrew Pinski ---
(In reply to Sergei Trofimovich from comment #1)
> /cc LIU Hao in case it's a new c++20 restriction and mcfgthread would need
> to adapt.
Looks like it is one:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
--- Comment #2 from Andrew Pinski ---
r15-84-g79420dd3441458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #7 from Andrew Pinski ---
(In reply to Segher Boessenkool from comment #6)
> (In reply to Andrew Pinski from comment #2)
> > Looks like the issue is during combine.
> >
> > We go from CCGC with a sign_extend to a zero_extend with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #3 from Andrew Pinski ---
It will involve the struct TclStubs too. I suspect it does not have its
aliasing set correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114927
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #8 from Andrew Pinski ---
(In reply to nfxjfg from comment #7)
> > Note also the order of the writes to reg1 and reg2 might happen in a
> > different order in HW so you need to have a full (HW) write barrier between
> > them to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
--- Comment #34 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #22)
> Without load/store handling, here are the following optimizations that
> either can move to match.pd already or need some extra work to do it:
>
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61110
--- Comment #5 from Andrew Pinski ---
Created attachment 58089
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58089=edit
Start of rewriting value_replacement to use match-and-simplify
This is a start and does not remove the old code. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
--- Comment #10 from Andrew Pinski ---
Patches submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650586.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650587.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Andrew Pinski changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928
--- Comment #5 from Andrew Pinski ---
*** This bug has been marked as a duplicate of bug 103088 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103318
Andrew Pinski changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97263
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #10 from Andrew Pinski ---
If Aldy does not fix it by Saturday, I will give the union a try then. I will
also try out the solaris machine on the compile farm if possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #6 from Andrew Pinski ---
Some resources about memory barriers and why they are needed here (for both HW
and SW):
https://en.wikipedia.org/wiki/Memory_barrier
https://www.kernel.org/doc/Documentation/memory-barriers.txt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
--- Comment #1 from Andrew Pinski ---
I thought char8_t is still a character type so aliasing wise it falls under
that rule.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-05-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #7 from Andrew Pinski ---
Created attachment 58084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58084=edit
Something like this
This should cause the char array be on the correct alignment ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #6 from Andrew Pinski ---
I might see if I can figure out a patch for some to try later tonight.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #5 from Andrew Pinski ---
I see the issue then.
char m_buffer[sizeof (int_range_max)];
Needs _Align to get the alignment correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
--- Comment #5 from Andrew Pinski ---
(In reply to Jorg Brown from comment #4)
> Also odd is that the above code (including a()) works fine on gcc 10.1
> through 13.2. As seen https://godbolt.org/z/z3qnosG37
This is not really odd since it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114915
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #3 from Andrew Pinski ---
LVL labels comes from the debugging info when it comes to variable tracking.
This looks like it has always been broken ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #2 from Andrew Pinski ---
C6x Linux support was removed in 2021:
https://lore.kernel.org/linux-arm-kernel/20210120124812.2800027-1-a...@kernel.org/T/
So maybe it is time to remove it from GCC too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #2 from Andrew Pinski ---
What compiler version are you starting with?
It could be that compiler is miscompiling stage 1 here; especially when it
comes to C++ usage is becoming more and more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83912
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
--- Comment #3 from Andrew Pinski ---
here is a C++11 testcase:
```
struct strt {
char *_M_dataplus;
char _M_local_buf=0;
constexpr strt()
: _M_dataplus(&_M_local_buf) {}
constexpr strt(const strt &__str)
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
Andrew Pinski changed:
What|Removed |Added
Known to fail||13.2.0
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
--- Comment #1 from Andrew Pinski ---
Reducing, note this ICEs only with checking enable and not release checking ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114911
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.7.1
Keywords|ice-checking
-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
void g();
template
struct Capture;
template
struct Capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114904
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
Andrew Pinski changed:
What|Removed |Added
CC||oleg at smolsky dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114909
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #1 from Andrew Pinski ---
The only thing hardcfr.c uses special is __builtin_return_address and
__builtin_trap otherwise it is just normal C code ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> here is a reduced testcase:
> Note ` -O1 -fno-tree-fre -fno-tree-forwprop -fno-tree-ccp
> -fno-tree-dominator-opts`
This testcase is broken in GCC 13 for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #4 from Andrew Pinski ---
here is a reduced testcase:
```
[[gnu::noipa]]
int f(int b)
{
int tt1 = ~b;
int t = 1 & tt1;
int e = -t;
int tt = e >= -1;
if (tt) return 0;
__builtin_trap();
}
int main()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #3 from Andrew Pinski ---
Note this is almost definitely a latent bug exposed by some change. Might be
interesting to see what change exposed it but not so much really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|wrong code at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177
Andrew Pinski changed:
What|Removed |Added
CC||jankodedic2 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114900
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114900
--- Comment #1 from Andrew Pinski ---
This is by design for C++20 ...
The support for P2014 is not in GCC yet, and IIRC it won't be enable for C++20
only C++23+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894
--- Comment #4 from Andrew Pinski ---
And divides should happen if we know if the divisor is non-zero:
eg:
```
int fdiv(int a, int b)
{
if (b == 0) __builtin_unreachable();
int c = a / b;
int d = a != 0;
return c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894
--- Comment #3 from Andrew Pinski ---
Note we should catch this too:
```
int fmul2(unsigned a, int b)
{
int c = a * b;
int d = a != 0;
return c & -d;
}
```
Which is more complex ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
--- Comment #16 from Andrew Pinski ---
(In reply to Thomas Mercier from comment #15)
> No objection to the error message, but I would have expected a syntax error
> for standards earlier than 23 which don't claim to support manually
> specifying
801 - 900 of 35210 matches
Mail list logo
