On Fri, Apr 23, 2021 at 1:35 AM H.J. Lu via Gcc-patches
wrote:
>
> For op_by_pieces operations between two areas of memory on non-strict
> alignment target, add -foverlap-op-by-pieces=[off|on|max-memset] to
> generate overlapping operations to minimize number of operations if it
> is not a stack p
On Fri, Apr 23, 2021 at 2:50 PM Uros Bizjak wrote:
>
> On Fri, Apr 23, 2021 at 8:36 AM Hongtao Liu wrote:
> >
> > Hi:
> > The patch is a follow-up to
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564320.html.
> > Bootstrapped and regtested on x86-64_iinux-gnu{-m32,}.
> > Ok for
On Fri, Apr 23, 2021 at 9:15 AM Hongtao Liu wrote:
>
> On Fri, Apr 23, 2021 at 2:50 PM Uros Bizjak wrote:
> >
> > On Fri, Apr 23, 2021 at 8:36 AM Hongtao Liu wrote:
> > >
> > > Hi:
> > > The patch is a follow-up to
> > > https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564320.html.
> > >
On Tue, Apr 20, 2021 at 8:49 PM Martin Liška wrote:
>
> On 4/20/21 2:46 PM, Richard Biener wrote:
> > OK. Can you somehow arrange for trunk to pick up LTO_major from GCC
> > major automagically then?
>
> I have a pretty nice solution for it where I extended (and simplified)
> the existing gcov-io
On Fri, Apr 9, 2021 at 10:28 AM Richard Biener wrote:
>
> We can use TBAA even when we have a DR, do so. For the testcase
> that means fully vectorizing it instead of only vectorizing
> the first store group resulting in suboptimal code.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, qu
On 4/23/21 9:28 AM, Richard Biener wrote:
> On Tue, Apr 20, 2021 at 8:49 PM Martin Liška wrote:
>>
>> On 4/20/21 2:46 PM, Richard Biener wrote:
>>> OK. Can you somehow arrange for trunk to pick up LTO_major from GCC
>>> major automagically then?
>>
>> I have a pretty nice solution for it where I
On Wed, Apr 14, 2021 at 2:41 PM Richard Biener wrote:
>
> This avoids use of valid_gimple_rhs_p and instead gimplifies to
> such a RHS, avoiding more SSA copies being generated by IVOPTs.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1
g:b26485f1af45423980b7bc1206411cf4
On Fri, Apr 23, 2021 at 3:18 PM Uros Bizjak wrote:
>
> On Fri, Apr 23, 2021 at 9:15 AM Hongtao Liu wrote:
> >
> > On Fri, Apr 23, 2021 at 2:50 PM Uros Bizjak wrote:
> > >
> > > On Fri, Apr 23, 2021 at 8:36 AM Hongtao Liu wrote:
> > > >
> > > > Hi:
> > > > The patch is a follow-up to
> > > > h
Richard Biener writes:
> This fixes VECTOR_CST element access with POLY_INT elements and
> allows to produce dump files of the PR98726 testcase without
> ICEing.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> 2021-01-26 Richard Biener
>
> PR middle
On Fri, 23 Apr 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > This fixes VECTOR_CST element access with POLY_INT elements and
> > allows to produce dump files of the PR98726 testcase without
> > ICEing.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > Thanks,
On Fri, Apr 23, 2021 at 12:53:58PM +0800, Hongtao Liu via Gcc-patches wrote:
> + if (!CONST_INT_P (er))
> + return 0;
> + ei = INTVAL (er);
> + if (i < nelt2 && ei != i)
> + return 0;
> + if (i >= nelt2
> + && (ei < nelt || ei >= nelt<<1))
Formatting:
1) yo
loop_optimizer_init (LOOPS_NORMAL) already performs this (quite
expensive) marking.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
2021-04-23 Richard Biener
PR tree-optimization/100222
* predict.c (pass_profile::execute): Remove redundant call to
mark_irreduc
On 4/23/21 8:49 AM, Richard Biener wrote:
> On Thu, Apr 22, 2021 at 9:47 PM Andi Kleen via Gcc-patches
> wrote:
>>
>> Martin Liška writes:
>>
>>> Hey.
>>>
>>> I/O buffering in gcov seems duplicite to what modern C library can provide.
>>> The patch is a simplification and can provide easier inter
On Fri, Apr 23, 2021 at 11:04 AM Hongtao Liu wrote:
>
> On Fri, Apr 23, 2021 at 3:18 PM Uros Bizjak wrote:
> >
> > On Fri, Apr 23, 2021 at 9:15 AM Hongtao Liu wrote:
> > >
> > > On Fri, Apr 23, 2021 at 2:50 PM Uros Bizjak wrote:
> > > >
> > > > On Fri, Apr 23, 2021 at 8:36 AM Hongtao Liu wrote
On Fri, Apr 23, 2021 at 9:59 AM Martin Liška wrote:
>
> On 4/23/21 9:28 AM, Richard Biener wrote:
> > On Tue, Apr 20, 2021 at 8:49 PM Martin Liška wrote:
> >>
> >> On 4/20/21 2:46 PM, Richard Biener wrote:
> >>> OK. Can you somehow arrange for trunk to pick up LTO_major from GCC
> >>> major auto
On Fri, Apr 23, 2021 at 11:24 AM Martin Liška wrote:
>
> On 4/23/21 8:49 AM, Richard Biener wrote:
> > On Thu, Apr 22, 2021 at 9:47 PM Andi Kleen via Gcc-patches
> > wrote:
> >>
> >> Martin Liška writes:
> >>
> >>> Hey.
> >>>
> >>> I/O buffering in gcov seems duplicite to what modern C library c
> > That needs to be combined with the generated auto-host.h header file.
> > From which locations do you want to build the hash? Any other $objdir
> > files except auto-host.h?
>
> In fact for PCH just summing the gengtype generated files would be
> good enough I guess ...
I think one can, for e
Hi,
This simple patch fixes a mismatched operator new/delete in
early-remat.c which triggers ASan errors on (at least) AArch64 when
compiling SVE code.
Bootstrap and regtest on aarch64-linux-gnu in progress.
OK for trunk and backports (as appropriate) if testing looks good?
Thanks,
Alex
gcc/Ch
On Fri, Apr 23, 2021 at 11:51 AM Jan Hubicka wrote:
>
> > > That needs to be combined with the generated auto-host.h header file.
> > > From which locations do you want to build the hash? Any other $objdir
> > > files except auto-host.h?
> >
> > In fact for PCH just summing the gengtype generated
On Thu, Feb 25, 2021 at 2:29 PM Richard Biener wrote:
>
> Most callers of connect_infinite_loops_to_exit already do this but
> the few that do not end up with extra exit edges. The following
> makes that consistent, also matching the post-dominance DFS walk code.
>
> Boostrapped and tested on x86
On 4/23/21 12:59 PM, Richard Biener wrote:
> True, the question is on how much detail we have to pay attention to.
Agree with that.
> For us of course the build-id solution works fine. And hopefully the
> days of PCH are counted...
Yes.
I have a tentative patch that emits the attached checksum
On 01/04/2021 18:35, Richard Earnshaw wrote:
>
>
> On 01/04/2021 17:11, Alex Coplan via Gcc-patches wrote:
> > Hi all,
> >
> > This patch fixes PR99748 which shows us trying to pass the argument to
> > __aeabi_f2iz in the VFP register s0 when the library function is
> > expecting to use the GPR
On 4/23/21 11:44 AM, Richard Biener wrote:
On Fri, Apr 23, 2021 at 11:24 AM Martin Liška wrote:
On 4/23/21 8:49 AM, Richard Biener wrote:
On Thu, Apr 22, 2021 at 9:47 PM Andi Kleen via Gcc-patches
wrote:
Martin Liška writes:
Hey.
I/O buffering in gcov seems duplicite to what modern C l
This removes now unnecessary special-casings of VEC_COND_EXPRs after
making its first operand a gimple value.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-04-14 Richard Biener
* genmatch.c (lower_cond): Remove VEC_COND_EXPR special-casing.
(capture_info::c
On Fri, Apr 23, 2021 at 2:13 PM Alex Coplan via Gcc-patches
wrote:
>
> Hi,
>
> This simple patch fixes a mismatched operator new/delete in
> early-remat.c which triggers ASan errors on (at least) AArch64 when
> compiling SVE code.
>
> Bootstrap and regtest on aarch64-linux-gnu in progress.
>
> OK
libstdc++-v3/ChangeLog:
* include/experimental/socket (socket_base::shutdown_type):
(socket_base::wait_type, socket_base::message_flags):
Remove enumerators. Initialize constants directly with desired
values.
(socket_base::message_flags): Make all operators
Add a comment documenting the __w parameter of the private
ios_context::async_wait function. Add casts to callers, making the
conversions explicit.
Tested powerpc64le-linux and sparc-solaris. Committed to trunk.
commit 3517dfe05c05a48885149334143230fcf0ebe6be
Author: Jonathan Wakely
Date: Fr
This adds dummy placeholders to net::io_context so that it can still be
compiled on targets without .
Tested powerpc64le-linux and sparc-solaris. Committed to trunk.
This could be backported so that it fixes PR 100180 everywhere, but
after the gcc-11 release.
commit 0e1e7b77904f1fe2a6dbfe84bb4
On Tue, Feb 02, 2021 at 11:38:11AM -0700, Jeff Law via Gcc-patches wrote:
> On 1/16/21 11:13 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > The following patch tests both x / y * y and x - x % y expansion for the
> > former GIMPLE code and chooses the cheaper of those sequences.
> >
> > Bootstrapped/regt
On Tue, Feb 02, 2021 at 07:40:02PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Feb 02, 2021 at 11:39:30AM -0700, Jeff Law wrote:
> > > This patch adds some ctz simplifications (e.g. ctz (x) >= 3 can be done by
> > > testing if the low 3 bits are zero, etc.).
> > >
> > > In addition, I've
On Tue, Feb 09, 2021 at 12:12:24PM +0100, Jakub Jelinek via Gcc-patches wrote:
> As mentioned in the PR, we don't support arithmetic right V2DImode or
> V4DImode on x86 without -mavx512vl or -mxop. The ISAs indeed don't have
> {,v}psraq instructions until AVX512VL, but we actually can emulate it q
64bit loads to/stores from x87 and SSE registers are atomic also on 32-bit
targets, so there is no need for additional atomic moves to a temporary
register.
Introduced load peephole2 patterns assume that there won't be any additional
loads from the load location outside the peepholed sequence and
On Thu, 22 Apr 2021, Tom de Vries wrote:
> Ah, I see, agreed, that makes sense. I was afraid there was some
> fundamental problem that I overlooked.
>
> Here's an updated version. I've tried to make it clear that the
> futex_wait/wake are locally used versions, not generic functionality.
Could
This is a backport of the PR96796 fix to GCC 10 and GCC 9. The original
trunk patch was:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552878.html
reviewed here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553308.html
I'm not aware of any fallout since then. However
ChangeLog:
2021-04-23 David Faust
* MAINTAINERS (Write After Approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index db25583b37b..c589c0b30ac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -387,6 +387,7 @@ Doug Evans
64bit targets default to 128bit long double, so -m96bit-long-double should
not be used. Together with -m128bit-long-double, this option was intended
to be an optimization for 32bit targets only.
Error out when -m96bit-long-double is used with 64bit targets.
2021-04-23 Uroš Bizjak
gcc/
PR
On 4/23/21 5:45 PM, Alexander Monakov wrote:
> On Thu, 22 Apr 2021, Tom de Vries wrote:
>
>> Ah, I see, agreed, that makes sense. I was afraid there was some
>> fundamental problem that I overlooked.
>>
>> Here's an updated version. I've tried to make it clear that the
>> futex_wait/wake are loc
Hi YiFei,
I've just checked in both patches to master and GCC 10 on your behalf.
Thanks!
On 4/22/21 11:54 PM, Jose E. Marchesi via Gcc-patches wrote:
>
> Hi YiFei.
>
>> Prior to this, a BSS declaration such as:
>>
>> int foo;
>> static int bar;
>>
>> Generates:
>>
>> .global foo
>> .lo
On Fri, Apr 23, 2021 at 12:25 PM David Faust wrote:
> I've just checked in both patches to master and GCC 10 on your behalf.
On 4/22/21 11:54 PM, Jose E. Marchesi via Gcc-patches wrote:
> Thanks for the patch.
> This is OK for both master and GCC 10.
Thanks to both of you :)
YiFei Zhu
On 2021-04-23 12:13 p.m., Richard Sandiford wrote:
This is a backport of the PR96796 fix to GCC 10 and GCC 9. The original
trunk patch was:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552878.html
reviewed here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/55330
Finally getting to this now that the GCC 11 rush is over. Sorry for
the slow response.
I've tried to review most of the code below, but skipped the testsuite
parts in the interests of time. I'll probably have more comments in
future rounds, just wanted to get the ball rolling.
This is realy Ric
On 4/20/2021 8:06 AM, Andreas Krebbel via Gcc-patches wrote:
With the current handling of decl alignments it is impossible to
reduce the alignment requirement as part of a variable declaration.
This change has been proposed by Richard in the PR. It fixes the
align-1.c testcase on IBM Z.
Boots
On Fri, Apr 23, 2021 at 08:05:29PM +0100, Richard Sandiford wrote:
> Finally getting to this now that the GCC 11 rush is over. Sorry for
> the slow response.
>
> I've tried to review most of the code below, but skipped the testsuite
> parts in the interests of time. I'll probably have more comme
On 4/22/21 9:46 AM, Patrick Palka wrote:
On Wed, 21 Apr 2021, Patrick Palka wrote:
On Wed, 21 Apr 2021, Jason Merrill wrote:
On 4/12/21 1:20 PM, Patrick Palka wrote:
Here we're crashing during deduction for a template placeholder from a
dependent initializer because one of the initializer's
On Thu, Apr 22, 2021 at 05:56:32PM -0500, Segher Boessenkool wrote:
> On Fri, Apr 09, 2021 at 05:09:07PM -0400, Michael Meissner wrote:
> > Fix logic error in 32-bit trampolines, PR target/98952.
> >
> > The test in the PowerPC 32-bit trampoline support is backwards. It aborts
> > if the trampoli
Some manual pages are already using C99 syntax for integral
types 'uint32_t', but some aren't. There are some using kernel
syntax '__u32'. Fix those.
Some pages also document attributes, using GNU syntax
'__attribute__((xxx))'. Update those to use the shorter and more
portable C2x syntax, which
On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar
wrote:
>
> Some manual pages are already using C99 syntax for integral
> types 'uint32_t', but some aren't. There are some using kernel
> syntax '__u32'. Fix those.
>
> Some pages also document attributes, using GNU syntax
> '__attribute__((xxx))
On Fri, Apr 23, 2021 at 06:24:07PM -0400, Michael Meissner wrote:
> On Thu, Apr 22, 2021 at 05:56:32PM -0500, Segher Boessenkool wrote:
> > As Will says, it looks like the ELFv2 version has the same bug. Please
> > fix that the same way.
>
> Yes it has the same bug. However in practice it would
Some ports require libatomic for atomic operations, at least for some
data types and widths. The libstdc++ testsuite previously was updated
to link against libatomic, but the search path was hard-coded to
something that is not always correct, and the shared library search
path was not set.
The se
On 4/14/2021 12:41 AM, Richard Biener wrote:
On Wed, 14 Apr 2021, Xionghu Luo wrote:
Hi,
On 2021/3/26 15:35, Xionghu Luo via Gcc-patches wrote:
Also we already have a sinking pass on RTL which even computes
a proper PRE on the reverse graph - -fgcse-sm aka store-motion.c.
I'm not sure wheth
On 4/19/2021 1:28 PM, Richard Sandiford via Gcc-patches wrote:
This patch adds target selectors of the form:
{ any-opts "opt1" ... "optn" }
{ no-opts "opt1" ... "optn" }
for skipping or xfailing tests based on compiler options. It only
works for dg-final selectors.
The patch then uses
On 4/23/2021 6:54 PM, David Edelsohn via Gcc-patches wrote:
Some ports require libatomic for atomic operations, at least for some
data types and widths. The libstdc++ testsuite previously was updated
to link against libatomic, but the search path was hard-coded to
something that is not always
52 matches
Mail list logo
