https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98304
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #18 from John Soo ---
And actually the proposed patch is not conservative enough, because the size of
the strings in argv/env also matter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106379
Andrew Pinski changed:
What|Removed |Added
Blocks||106380, 106505, 106381
Depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106505
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-09-17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110529
--- Comment #6 from mengli ming ---
(In reply to David Malcolm from comment #5)
> Should be fixed on trunk for gcc 14 by the above commit.
Thanks a lot for your hard work!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438
--- Comment #4 from Andrew Pinski ---
Also see
https://github.com/containerd/containerd/discussions/5525#discussioncomment-2685649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438
--- Comment #3 from Andrew Pinski ---
(In reply to Gamal Akabani from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > >GCC: 13.2.0, GCC, gfortran was installed using homebrew
> > > but the code sometimes crashes in my new Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438
--- Comment #2 from Gamal Akabani ---
(In reply to Andrew Pinski from comment #1)
> >GCC: 13.2.0, GCC, gfortran was installed using homebrew
> > but the code sometimes crashes in my new Mac Studio M2 Pro.
>
> GCC upstream does not have support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438
Bug ID: 111438
Summary: Missing libSystem.B.dylib during execution - Mac OS
13.5.2 (22G91), XCODE: Version 14.3.1 (14E300c)
Product: gcc
Version: 13.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
--- Comment #9 from Andrew Pinski ---
Created attachment 55915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55915=edit
match pattern for the non-ifcombine case
sometimes we need to handle this outside of ifcombine due to phiopt or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370
--- Comment #7 from Andrew Pinski ---
Created attachment 55914
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55914=edit
Patch
Combined with the patch for PR 109960. We are able to optimize this correctly:
_5 = bio_4(D)->bi_flags;
_8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> _10 = _9 >> 1;
> _11 = (bool) _10;
> if (_11 != 0)
>
>
> Should just be optimized to:
> _t = _9 & 1
> if (_t != 0)
>
> Let me add that to match.
We do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243
--- Comment #15 from Alex Mohr ---
Thank you Richard B, Richard G, Xi, Jonathan, Jakub, and Eric for all the great
info. Much appreciated.
With more experience using '-Og -fno-inline' I've found that sometimes
inspecting local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370
--- Comment #5 from Andrew Pinski ---
_10 = _9 >> 1;
_11 = (bool) _10;
if (_11 != 0)
Should just be optimized to:
_t = _9 & 1
if (_t != 0)
Let me add that to match.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
--- Comment #8 from Andrew Pinski ---
Created attachment 55913
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55913=edit
part of the ifcombine fixes
It does not catch:
_10 = _5 >> 1;
_11 = (_Bool) _10;
if (_11 != 0)
Though. I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370
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=109960
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
--- Comment #7 from Andrew Pinski ---
Created attachment 55912
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55912=edit
Patch which I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111436
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111437
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-09-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
--- Comment #6 from Andrew Pinski ---
Note my testcase needs exceptions turned on ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111437
Bug ID: 111437
Summary: Some always inline functions are incorrectly warn of
as "might not be inlinable"
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
--- Comment #5 from Andrew Pinski ---
Here is a better testcase:
```
void find_slot_with_hash(const int &,int, int);
void put(const int , const int ) {
find_slot_with_hash(k, 0, 1);
__builtin_unreachable();
}
unsigned len();
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
--- Comment #4 from Sergei Trofimovich ---
Meanwhile cvise extracted this test:
// $ cat tree-ssa-loop-niter.cc.cc
int discover_iteration_bound_by_body_walk_queue_index, m_vec;
int *address();
unsigned length();
int deref(unsigned ix) {
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111436
Bug ID: 111436
Summary: Wrong code when bit-casting struct through pointer
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
--- Comment #3 from Andrew Pinski ---
Changing the match pattern for conversions to non-recusive fixes the issue.
That is:
/* A conversion from an zero_one_valued_p is still a [0,1].
This is useful when the range of a variable is not known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52345
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> // (a | zero_one) != 0 -> a!=0 | zero_one
>
> (simplify
> (ne (bit_ior:c @1 zero_one_value_p@2) integer_zerop@3)
> (bit_ior (convert @1) (ne @2 @3)))
>
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
--- Comment #2 from Andrew Pinski ---
So Basically you can't have a recusive match because of the way VN works ...
I should have figured that out when I was adding bitwise_inverted_equal_p .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
.cc -dumpbase-ext .cc -m32 -mtune=generic
-march=x86-64 -O2 -version -o /run/user/1000/ccgZ63HD.s
GNU C++17 (GCC) version 14.0.0 20230916 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 14.0.0 20230916 (experimental), GMP version
6.3.0, MPFR version 4.2.1, MPC version 1.3.1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52345
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111431
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #17 from John Soo ---
Created attachment 55910
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55910=edit
libiberty, Unix: pass argv over ARG_MAX through an @file
This does not handle environ being too large, but it is an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111434
Bug ID: 111434
Summary: Infinite loop with limited withs?
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111433
Bug ID: 111433
Summary: Erroneous message "error: null exclusion for "O" does
not match"
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111391
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:86451305d8b2a25e7c6ea6c2f1ee69c419cba3ef
commit r14-4077-g86451305d8b2a25e7c6ea6c2f1ee69c419cba3ef
Author: Juzhe-Zhong
Date: Thu Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425
--- Comment #4 from Frank Scheiner ---
(In reply to Richard Biener from comment #3)
Hi Richard,
in case you wanted me to test this reduced test case, I ran it through as if it
was the file in question. I needed to remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110941
--- Comment #2 from Andrew Pinski ---
GCC 13:
Global Exported: _6 = [irange] unsigned int [0, 24] NONZERO 0x1e
trunk:
Global Exported: _6 = [irange] unsigned int [0, 24][+INF, +INF] MASK 0x1c VALUE
0x0
And then:
Folding predicate _6 > 24 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95408
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110502
--- Comment #3 from Andrew Pinski ---
Note LIM2 has way different IR selection which is kinda interesting since there
are no stores that happened in the bbs that were removed:
if (_2 != 0)
goto ; [75.00%]
else
goto ; [25.00%]
45 matches
Mail list logo
