https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116523
--- Comment #3 from Andrew Pinski ---
Whoops wrong one. PR 116510
*** This bug has been marked as a duplicate of bug 116510 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116510
Andrew Pinski changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116516
Andrew Pinski changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116523
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116521
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116521
--- Comment #1 from Andrew Pinski ---
The default ABI for xtensa is to use windowed registers which does not
currently support sibcalling.
include/xtensa-config.h :
#define XSHAL_ABI XTHAL_ABI_WINDOWED
#define XTHAL_ABI_WI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116516
--- Comment #4 from Andrew Pinski ---
Just for reference here is the code:
```
extern void my_func (int);
typedef struct {
int var;
} info_t;
extern void *_data_offs;
void test()
{
info_t *info = (info_t *) ((void *)((void *)1) + ((unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116515
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116518
--- Comment #2 from Andrew Pinski ---
I tried to reduce it to:
```
struct s1 {
struct {
char t[1];
} t;
unsigned long tt;
};
struct s2
{
char t[3];
};
int f()
{
s2 *t;
{
struct s1 a = {};
a.t.t[0] = 120;
a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116518
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116518
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 116519, which changed state.
Bug 116519 Summary: Arm64(?): undue array bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116512
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-08-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116512
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116512
Andrew Pinski changed:
What|Removed |Added
Known to work||7.1.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116511
--- Comment #3 from Andrew Pinski ---
Reduced and cleaned up some more:
```
template
struct s1 {
enum { e1 = 1 };
};
template
struct s2 {
enum { e1 = s1::e1 };
s2() requires(0 != e1);
};
s2<8> a;
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116511
Andrew Pinski changed:
What|Removed |Added
Summary|ICE segmentation fault |[14/15 Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116511
--- Comment #1 from Andrew Pinski ---
Back trace:
#0 tree_class_check (__g=0x25daeef "to_wide", __l=6460, __f=0x25d20d9
"../../gcc/tree.h", __class=tcc_type, __t=0x0) at ../../gcc/tree.h:3786
#1 wi::to_wide (t=t@entry=0x772eee38) at ../../
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116510
--- Comment #6 from Andrew Pinski ---
#6 0x0187822c in gimple_simplify_226 (res_op=0x7fffcd00,
seq=0x7fffced0, valueize=0xd13880 ,
type=0x7741cb28, captures=0x7fffa160, cmp=EQ_EXPR) at
gimple-match-9.cc:1994
1994 if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116510
--- Comment #2 from Andrew Pinski ---
There is a type mismatch going on ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116510
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-08-28
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116510
Andrew Pinski changed:
What|Removed |Added
Component|c |tree-optimization
Summary|ic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107533
--- Comment #3 from Andrew Pinski ---
(In reply to Ramana Radhakrishnan from comment #2)
> yes the by-value parameters are a separate issue that I hope recent patches
> on the list (I remember something flying past) should help correct.
The pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116508
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116509
--- Comment #1 from Andrew Pinski ---
Created attachment 59018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59018&action=edit
What LLVM produces
This is what LLVM produces. GCC should be able to do similarly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116509
Bug ID: 116509
Summary: 128bit integer compares can be improved
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116508
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > part of the problem here is the use of OPTAB_DIRECT when it should use
> > OPTAB_WIDEN instead.
>
> That fixes s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116508
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> part of the problem here is the use of OPTAB_DIRECT when it should use
> OPTAB_WIDEN instead.
That fixes short but for char looks like there is still some cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116508
--- Comment #2 from Andrew Pinski ---
part of the problem here is the use of OPTAB_DIRECT when it should use
OPTAB_WIDEN instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116507
--- Comment #1 from Andrew Pinski ---
Hmm, the whole `*mov_aarch64` set of patterns are a mess and looks like
they need some cleanup too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114224
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282
Andrew Pinski changed:
What|Removed |Added
See Also||https://bugzilla.mozilla.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116484
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > (In reply to J Lee from comment #4)
> > > Is this error also related to the same 'const' issue?
> >
> > No that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116484
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> (In reply to J Lee from comment #4)
> > Is this error also related to the same 'const' issue?
>
> No that is unrelated to this attribute issue.
Well the origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116484
--- Comment #5 from Andrew Pinski ---
(In reply to J Lee from comment #4)
> Is this error also related to the same 'const' issue?
No that is unrelated to this attribute issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114224
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116508
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-08-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116508
Bug ID: 116508
Summary: [15 Regression] `popcount(short) == 1` or char no
longer expands to using `(arg ^ (arg - 1)) > arg - 1`
trick after r15-2946-gfcc3af99498804
Product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116507
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116507
Bug ID: 116507
Summary: [15 Regression] movhi_aarch64 should use fmov if FP16
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
--- Comment #8 from Andrew Pinski ---
(In reply to andi from comment #7)
> Thanks. Updated patch. This one seems obvious so I'll commit soon.
>
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c
> b/gcc/testsuite/gcc.dg/vect/vect-sw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114224
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Note after r15-2946-gfcc3af99498804, for:
> ```
> int fc(unsigned char a)
> {
> return __builtin_popcountg(a) == 1;
> }
> ```
>
> Without CSSC, GCC produces:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114224
--- Comment #4 from Andrew Pinski ---
Note after r15-2946-gfcc3af99498804, for:
```
int fc(unsigned char a)
{
return __builtin_popcountg(a) == 1;
}
```
Without CSSC, GCC produces:
```
and w0, w0, 255
fmovd31, x0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |testsuite
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
--- Comment #5 from Andrew Pinski ---
(In reply to Andi Kleen from comment #4)
> It seems sparc doesn't support comparisons in vectorization?
I think you want to check vect_condition for this. (like bb-slp-69.c )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112456
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115612
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116505
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115612
Andrew Pinski changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116502
Andrew Pinski changed:
What|Removed |Added
Summary|[15 Regression] |[15 Regression]
|-Wun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116499
--- Comment #1 from Andrew Pinski ---
Note BMI is used as a x86_64 target instruction set; Bit manipulation
instruction set .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116501
Andrew Pinski changed:
What|Removed |Added
Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #14 from Andrew Pinski ---
(In reply to andi from comment #13)
> Or a test case for the intended register allocation benefits?
> That's more complicated and won't be small.
So what if it won't be small but it will be understanding t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #5 from Andrew Pinski ---
Musttail can never be used for correctness.
Also lto deals deals just fine with localizing a function.
But again you are making hacks what for? Code which is specific to one
application rather than making
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #3 from Andrew Pinski ---
>When writing threaded code interpreters by chaining functions with musttail
>the normal ABI behavior of some caller saved registers can cause unnecessary
>spills and fills compared to using indirect goto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #2 from Andrew Pinski ---
Sounds more like the attribute is not needed but gcc should figure out how to
improve the abi for static functions instead, like what is done already for
32bit x86.
I think even musttail is also a bogus way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97986
Andrew Pinski changed:
What|Removed |Added
CC||hnarkaytis at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116495
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973
Andrew Pinski changed:
What|Removed |Added
CC||leonid.satanovsky at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116441
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116493
--- Comment #1 from Andrew Pinski ---
Forgot to mention this is at -O2 (or -O3).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116493
Bug ID: 116493
Summary: widening reduction add could be better
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Slightly reduced:
In this example if you comment out:
```
requires true_c
```
GCC does the correct thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492
--- Comment #2 from Andrew Pinski ---
>The same does not happen in clang, and in gcc with similar examples from other
>classes I have tried.
So it comes down to the concept on the constructor which is why you didn't run
into similar examples f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-08-26
Summary|inherited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116491
--- Comment #7 from Andrew Pinski ---
Or rather see
https://cmake.org/cmake/help/latest/prop_tgt/CXX_EXTENSIONS.html#prop_tgt:CXX_EXTENSIONS
.
That is -std=c++17 vs -std=gnu++17. GCC defaults to gnu++17 in newer versions
of GCC.
So the bug is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116491
--- Comment #6 from Andrew Pinski ---
(In reply to Sergey Markelov from comment #3)
> This is not a duplicate. The macro is defined conditionally, this is not a
> correct behavior.
Yes and that is by design. -std=gnu++17 enables some non-standa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116491
--- Comment #5 from Andrew Pinski ---
Specifically https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84400#c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116491
--- Comment #4 from Andrew Pinski ---
(In reply to Sergey Markelov from comment #3)
> This is not a duplicate. The macro is defined conditionally, this is not a
> correct behavior.
Yes it is. Please read that one and pr84400 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65128
Andrew Pinski changed:
What|Removed |Added
CC||mihaipop11 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84400
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #5 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65128
Andrew Pinski changed:
What|Removed |Added
CC||sergio_nsk at yahoo dot de
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116491
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116489
--- Comment #2 from Andrew Pinski ---
>In any case, the behavior seems to be undocumented:
Well considering the documentation says:
place sections with the .noinit prefix
you can assume they conflict :).
Also "prefix" is almost always added w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116489
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114224
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Interesting:
> ```
> int h1(unsigned a)
> {
> return __builtin_popcountg(a) == 1;
> }
> ```
> works.
>
>
> Anyways I will be adding POPCOUNT's rtl cos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116488
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-08-26
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116488
Andrew Pinski changed:
What|Removed |Added
Version|unknown |15.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116487
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116486
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116486
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116483
--- Comment #7 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #6)
> with the caveats that you'd only get that for future gcc releases
I think this caveat is fine as if adding the other feature to asm goto you
would also have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116485
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-08-26
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #22 from Andrew Pinski ---
(In reply to Richard Biener from comment #20)
> Unfortunately the following doesn't reproduce the issue.
>
> #include
> #include
>
> void g();
>
> void f(int nBands, double maxZErr) {
> for (int i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116480
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116484
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-08-26
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116484
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/riscv-no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #16 from Andrew Pinski ---
(In reply to Richard Biener from comment #14)
> (In reply to Andrew Pinski from comment #13)
> > (In reply to Andrew Pinski from comment #8)
> > > ./a.ltrans6.ltrans.212t.forwprop4
> > >
> > > Removing dea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116483
--- Comment #3 from Andrew Pinski ---
> But for satisfying some tools analyzing the generated machine code
Also this sounds like a limitation in the tool analyzing the generated code and
outside of gcc; I know helping the tool along is useful b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116483
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-08-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116484
--- Comment #1 from Andrew Pinski ---
This attribute is not documented so ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
--- Comment #5 from Andrew Pinski ---
(In reply to Bruno Haible from comment #4)
> Why? This code is accessing read-only memory near the address of the 'tramp'
> function. Why would it need 'volatile' when doing so? (I don't claim that
> this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #13 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> ./a.ltrans6.ltrans.212t.forwprop4
>
> Removing dead stmt noDataCandVec$_M_start_888 = PHI <_1783(176), _577(186)>
> ...
> Removing dead stmt:_598 = _888 + 16;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
Andrew Pinski changed:
What|Removed |Added
Known to fail||12.1.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
Andrew Pinski changed:
What|Removed |Added
Blocks||56456
Target|hppa-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116480
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
501 - 600 of 4393 matches
Mail list logo
