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!
Hans-Peter Nilsson via Gcc-patches writes:
>> Date: Tue, 29 Aug 2023 15:42:27 -0400
>> From: Marek Polacek via Gcc-patches
>
>> Surely, there must be no ABI impact, the option cannot cause
>> severe performance issues,
>
>> Currently, -fhardened enables:
> ...
>>
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
> Date: Tue, 29 Aug 2023 15:42:27 -0400
> From: Marek Polacek via Gcc-patches
> Surely, there must be no ABI impact, the option cannot cause
> severe performance issues,
> Currently, -fhardened enables:
...
> -ftrivial-auto-var-init=zero
> Thoughts?
Regarding -ftrivial-auto-var-init=zero, I
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:
This patch supports VLS reduction vectorization.
It can optimize the current reduction vectorization codegen with current COST
model.
#define DEF_REDUC_PLUS(TYPE)\
TYPE __attribute__ ((noinline, noclone))\
reduc_plus_##TYPE (TYPE * __restrict a, int n) \
{
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|
So when VN finds a name which has a nop conversion, it says
both names are equivalent to each other and the valuaization
function for one will return the other. This normally does not
cause any issues as there is no recusive matches. But after
r14-4038-gb975c0dc3be285, there was one added. So we
在 2023/9/16 下午10:52, WANG Xuerui 写道:
Hi,
On 9/16/23 17:16, mengqinggang wrote:
The cost of lo_sum rtx for addi.d instruction my be a very big number if
computed by common function. It may cause some symbols saving to
stack and
loading from stack if there no enough registers during loop
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
Snapshot gcc-13-20230916 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20230916/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
On Sat, 16 Sep 2023, Jason Merrill wrote:
> On 9/15/23 13:55, Patrick Palka wrote:
> > This corrects decltype of a (class) NTTP object as per
> > [dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case.
> > In the non-dependent case (nontype-class8.C) we resolve the decltype
> >
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
On Sat, 16 Sep 2023, Jason Merrill wrote:
> On 9/15/23 12:03, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > Here convert_to_void always completes the type of an INDIRECT_REF or
> > VAR_DECL expression, but
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
On 9/12/23 20:33, Patrick Palka wrote:
Bootstrpaped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
This simple patch extends the r12-3271-gf1e73199569287 optimization
to apply to deduction without explicit template arguments as well.
The motivation for this
On 9/13/23 13:53, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here more_specialized_partial_spec considers the two partial
specializations to be unordered ultimately because unify for identical
parm=arg=A::C returns failure due
On 9/13/23 13:53, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
Since the LHS of a qualified-id is a non-deduced context, it effectively
means we can't deduce from outer template arguments of a class template
On 9/15/23 12:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here convert_to_void always completes the type of an INDIRECT_REF or
VAR_DECL expression, but according to [expr.context] an lvalue-to-rvalue
conversion is applied to
On 9/15/23 12:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
When constraining the visibility of an instantiation, we weren't
properly considering the visibility of PTRMEM_CST and TEMPLATE_DECL
template arguments.
On 9/15/23 13:55, Patrick Palka wrote:
This corrects decltype of a (class) NTTP object as per
[dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case.
In the non-dependent case (nontype-class8.C) we resolve the decltype
ahead of time, and finish_decltype_type already made sure to
On 9/15/23 16:32, Marek Polacek wrote:
On Fri, Sep 15, 2023 at 02:08:46PM -0400, Jason Merrill wrote:
On 9/13/23 20:02, Marek Polacek wrote:
On Wed, Sep 13, 2023 at 05:57:47PM -0400, Jason Merrill wrote:
On 9/13/23 16:56, Marek Polacek wrote:
On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason
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
Hi Richard,
> On 14 Sep 2023, at 11:18, Richard Biener wrote:
>
> On Wed, Sep 6, 2023 at 5:44 PM FX Coudert wrote:
>>
>> ping**2 on the revised patch, for Richard or another global reviewer. So far
>> all review feedback is that it’s a step forward, and it’s been widely used
>> for both
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
`(a == CST) & a` can be either simplified to simplying `a == CST`
or 0 depending on the first bit of the CST.
This is an extension of the already pattern of `X & !X` and allows
us to remove the 2 xfails on gcc.dg/binop-notand1a.c and
gcc.dg/binop-notand4a.c.
OK? Bootstrapped and tested on
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
Hi,
On 9/16/23 17:16, mengqinggang wrote:
The cost of lo_sum rtx for addi.d instruction my be a very big number if
computed by common function. It may cause some symbols saving to stack and
loading from stack if there no enough registers during loop optimization.
Thanks for the patch! It
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
Committed, thanks Robin.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Robin Dapp via Gcc-patches
Sent: Friday, September 15, 2023 11:44 PM
To: 钟居哲 ; Jeff Law ; kito.cheng
Cc: rdapp@gmail.com; gcc-patches ; kito.cheng
Subject: Re: [PATCH V4] RISC-V: Expand VLS mode to
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
The cost of lo_sum rtx for addi.d instruction my be a very big number if
computed by common function. It may cause some symbols saving to stack and
loading from stack if there no enough registers during loop optimization.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
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
(moved to gcc@)
> On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote:
> > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote:
> > >
> > >
> > >
> > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote:
> > > >
> > > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote:
> > > CLANG
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
Am Freitag, dem 15.09.2023 um 11:11 -0400 schrieb Marek Polacek:
> On Wed, Aug 30, 2023 at 10:46:14AM +0200, Martin Uecker wrote:
> > > Improving the security of software has been a major trend in the recent
> > > years. Fortunately, GCC offers a wide variety of flags that enable extra
> > >
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%]
67 matches
Mail list logo
