https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #7 from Andrew Pinski ---
So what I am suspecting is ranger/VRP information was improved which exposed
the latent bug in IVOPTs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
Andrew Pinski changed:
What|Removed |Added
Known to work||5.3.0, 5.5.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110200
Andrew Pinski changed:
What|Removed |Added
Known to work||11.4.1, 12.3.1, 13.1.1
Known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #5 from Andrew Pinski ---
(In reply to Aldy Hernandez from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > VRP2/DOM3 produces the wrong folding for some reason:
> > Folding statement: _27 = b.6_9 * 2;
> > Queued stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #9 from Andrew Pinski ---
That is these exports:
2->3 (T) c.5_7 : [irange] int [1334323000, +INF] NONZERO 0x7fff
2->3 (T) _8 : [irange] long unsigned int [1334323000, 2147483647] NONZERO
0x7fff
2->3 (T) b.6_9 :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
--- Comment #2 from Andrew Pinski ---
Looks like it is uninitialized variable related.
Here is one which shows that:
```
int a, b;
char c;
int d(int e) {
int t = 0;
if (e >= 'a')
return e;
return t;
}
int f(unsigned short e) {
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110247
--- Comment #2 from LIU Hao ---
(In reply to Andrew Pinski from comment #1)
> The way I read the documentation, it will NOT be used when dealing with
If it is known, then why shouldn't it?
One potential usecase where this would be helpful is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
Andrew Pinski changed:
What|Removed |Added
Keywords||compile-time-hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110119
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110262
Bug ID: 110262
Summary: `t < 0 ? 1 : min(t, 1)` is not simplified down to just
`t != 0`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252
--- Comment #4 from Andrew Pinski ---
here is another testcase which is reduced from sel-sched.cc which we currently
miscompile:
```
[[gnu::noipa]]
int g(int min_need_stall)
{
return min_need_stall < 0 ? 1 : ((min_need_stall) < (1) ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #7 from Kewen Lin ---
(In reply to Richard Biener from comment #6)
> (In reply to rsand...@gcc.gnu.org from comment #5)
> > ivopts does have code to treat ifn pointer arguments specially,
> > see get_mem_type_for_internal_fn But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252
--- Comment #3 from Andrew Pinski ---
smallest testcase:
```
signed char f() __attribute__((__noipa__));
signed char f() { return 0; }
int main()
{
int g = f() - 1;
int e = g < 0 ? 1 : ((g >> (8-2))!=0);
asm("":"+r"(e));
if (e != 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110253
--- Comment #1 from Andrew Pinski ---
ftrapv also does not always work either ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110119
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:0ec3fbb5903ac3ad735b3154e814b46724fe1a27
commit r14-1829-g0ec3fbb5903ac3ad735b3154e814b46724fe1a27
Author: Lehua Ding
Date: Wed Jun 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277
Andrew Pinski changed:
What|Removed |Added
CC||roland.illig at gmx dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110259
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110261
Bug ID: 110261
Summary: vec.h mentions C++03 requirement for PODs and with
respect to unions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
Bug ID: 110260
Summary: Multiple applications misbehave when compiled with
-march=znver4
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678
Andrew Pinski changed:
What|Removed |Added
CC||manuel.bergler at mvtec dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110257
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110257
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110257
--- Comment #4 from Manuel Bergler ---
I don't know if it helps find the offending commit and/or fix, but these are
the numbers I got from -ftime-report with the broken GCC 13.1:
Time variable usr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252
--- Comment #2 from Andrew Pinski ---
Created attachment 55323
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55323=edit
Patch which fixes this issue
This patch fixes the issue by temporary removing the flow sensitive information
on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110259
Bug ID: 110259
Summary: Wrong warning 'conversion to unsigned int' with enum
and comma
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15
Andrew Pinski changed:
What|Removed |Added
CC||magnus.hegdahl at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110258
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110258
Bug ID: 110258
Summary: Undefined reference to intrinsic when taking function
reference at namespace scope
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110257
Andrew Pinski changed:
What|Removed |Added
Known to work|12.1.0 |12.3.0
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110254
--- Comment #1 from Segher Boessenkool ---
Off topic / pet peeve: it's not an array of functions, so it should not be
called
something_p .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110257
Manuel Bergler changed:
What|Removed |Added
Attachment #55322|Source file that reproduces |Source file that reproduces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110257
--- Comment #1 from Manuel Bergler ---
Created attachment 55322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55322=edit
Source file that reproduces the problem; I couldn't attach the pre-processed
file because it exceeds the file size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110257
Bug ID: 110257
Summary: [13 Regression] Excessive compile time and memory
consumption
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110256
--- Comment #2 from Andrew Pinski ---
MSVC also accepts this code ...
It might be the case that clang is incorrectly rejecting it.
Basically the way I understand is that b will always be false due to incorrect
usage of std::integral/c here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110256
--- Comment #1 from Andrew Pinski ---
Reduced to:
```
template
concept c = true;
template
concept d = false;
template
concept b = requires (T t ) {
{ t } -> d;
};
static_assert(!b);
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110256
Bug ID: 110256
Summary: passing concept to concept compiles
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110255
Stam Markianos-Wright changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110255
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110255
--- Comment #1 from Andrew Pinski ---
My suggestion is yes it is ambigious because of -flax-vector-conversions . and
really don't use -flax-vector-conversions unless you can't fix the original
code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110255
Bug ID: 110255
Summary: arm: MVE intrinsics C++ polymorphism with
-flax-vector-conversions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110254
Bug ID: 110254
Summary: improve_allocation() routine does not update
allocated_hardreg_p[] array
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
--- Comment #9 from Costas Argyris ---
Fixed by
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df
Also this is windows-host-specific (Host field in the PR is empty).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110247
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660
--- Comment #16 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Andrew Pinski from comment #13)
> > Using the C front-end we still have a casting issue.
>
> There are a few issues of even for the C++ front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-06-14
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110253
Bug ID: 110253
Summary: The documentation for -ftrapv seems to have an
incomplete list of operations
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252
Bug ID: 110252
Summary: Wrong code at -O2/3/s on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
Bug ID: 110251
Summary: Hang at -O3 on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
--- Comment #18 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:4ec6b627cb008e31ea3d1ee93a209297f56c6a3e
commit r14-1810-g4ec6b627cb008e31ea3d1ee93a209297f56c6a3e
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110215
--- Comment #4 from Vladimir Makarov ---
(In reply to Richard Biener from comment #3)
>
>
> We don't have any pass after reload that would perform loop invatiant motion,
> I'm not sure how this situation is handled in general in RA - is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110250
--- Comment #2 from Jivan Hakobyan ---
Thank you.
Will fix and send the patch to gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110250
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #6 from Richard Biener ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> ivopts does have code to treat ifn pointer arguments specially,
> see get_mem_type_for_internal_fn But like Kewen says,
> it's still only based on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #5 from rsandifo at gcc dot gnu.org
---
ivopts does have code to treat ifn pointer arguments specially,
see get_mem_type_for_internal_fn But like Kewen says,
it's still only based on the mode.
Personally I'd prefer an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
--- Comment #4 from David Brown ---
Yes, __builtin_assume_aligned is the best way to write things in this
particular case (and optimises fine for -O1 and -O2). It is also clearer in
the source code (IMHO), as it shows the programmer's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96365
wierton <141242068 at smail dot nju.edu.cn> changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344
Rainer Orth changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #4 from Richard Biener ---
I think the main issue is that IVOPTs treats all of the memory access
internal functions as calls and thus the pointer "argument" as
address calculation only and thus costs it as such.
To fix this IVOPTs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110250
Bug ID: 110250
Summary: Broken url to README in st/cli-be project
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
--- Comment #3 from Richard Biener ---
We could pattern-match this to
p = __builtin_assume_aligned (p, 8);
which is btw the better way to write this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #2 from Richard Biener ---
(In reply to Alexander Monakov from comment #1)
> Sorry, was your recent patch g:1c3661e224e3ddfc6f773b095740c0f5a7ddf5fc
> tackling a different issue?
Yes, the issue in this bug persists after the above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #3 from JuzheZhong ---
You mean add a default argument = nullptr to targethook legitimate_address_p to
let powerPC do more middle-end address ivopts analysis?
If yes, I am ok with that. Let's see Richard and Richi more comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #2 from Kewen Lin ---
Can you extend the current hook legitimate_address_p with one default value
nullptr gimple* argument? When middle-end passes like ivopts want to query with
the constructed address reference, it can pass the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
Kewen Lin changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
--- Comment #2 from David Brown ---
My apologies - it does not optimise the code to a single aligned load at -O1
(at least, not with the combinations I have now tried). The code was
originally C++, with a reference, which /does/ exhibit this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
Bug ID: 110249
Summary: __builtin_unreachable helps optimisation at -O1 but
not at -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160
--- Comment #12 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:9c03391ba447ff86038d6a34c90ae737c3915b5f
commit r14-1805-g9c03391ba447ff86038d6a34c90ae737c3915b5f
Author: Thomas Schwinge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111
--- Comment #18 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:9c03391ba447ff86038d6a34c90ae737c3915b5f
commit r14-1805-g9c03391ba447ff86038d6a34c90ae737c3915b5f
Author: Thomas Schwinge
Hello,
Hope you are doing well.
Would you be interested in building your Mobile app or any types of Software
development?
We have expertise in:
. Tours and Travel App
. Business/ Finance applications
. Fitness App
. GPS navigation
. E-learning App
. E-commerce App & etc.
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Alexander Klepikov changed:
What|Removed |Added
Attachment #55284|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #73 from Alexander Klepikov
---
I had to check everything a few more times because I found a bug in my patch
that caused the long shifts to expand incorrectly. I added a test that checks
correct shifts expansion in this regard.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110104
--- Comment #2 from Mason ---
You meant PR79173 ;)
Latest update:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621554.html
I didn't see my testcase specifically in Jakub's patch,
but I'll test trunk on godbolt when/if the patch lands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
Bug ID: 110248
Summary: ivopts could under-cost for some addressing modes on
len_{load,store}
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #4 from Aldy Hernandez ---
FWIW, a less intrusive and probably more correct way of seeing what ranger
knows at this point would be to put a breakpoint where you're seeing:
Queued stmt for removal. Folds to: 2147483647
This is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #3 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #2)
> VRP2/DOM3 produces the wrong folding for some reason:
> Folding statement: _27 = b.6_9 * 2;
> Queued stmt for removal. Folds to: 2147483647
>
> I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094
--- Comment #5 from Jakub Jelinek ---
One argument against doing it during expansion is that if we need the large
constant for other purposes, loading it with movabsq and just doing comparison
is better, the overflow way also clobbers the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110235
--- Comment #3 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #2)
> FAIL: gcc.target/i386/avx2-vpackssdw-2.c execution test
>
> This one is about sign saturation which should match rtl SS_TRUNCATE.
I realize for 256-bit/512-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110227
--- Comment #7 from Hongtao.liu ---
Fixed for GCC14 and GCC13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110227
--- Comment #6 from CVS Commits ---
The releases/gcc-13 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:66f8f9b35f0499cf54b8a432fbe5f645ad1c523a
commit r13-7445-g66f8f9b35f0499cf54b8a432fbe5f645ad1c523a
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110227
--- Comment #5 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:b7e42b85212e03eb59193a712eb523f26911a581
commit r14-1802-gb7e42b85212e03eb59193a712eb523f26911a581
Author: liuhongt
Date: Tue Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110241
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110247
Bug ID: 110247
Summary: suboptimal code about `no_caller_saved_registers` on
caller side
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110178
Thomas Schwinge changed:
What|Removed |Added
Target|powerpc64le-linux-gnu |
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110235
--- Comment #2 from Hongtao.liu ---
FAIL: gcc.target/i386/avx2-vpackssdw-2.c execution test
This one is about sign saturation which should match rtl SS_TRUNCATE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #3
98 matches
Mail list logo
