On Sat, Jun 8, 2024, 09:53 Richard Sandiford
wrote:
> Thanks a lot for doing this! It's a really nice series.
>
Thank you for your positive feedback and for your review and suggestions on
the patch series.
Just had a comment on the long division helper:
>
> Mariam Arutunian writes:
> > +/* R
The entire server/site appears gone for a while.
gcc:
* doc/install.texi (avr): Remove link to www.amelek.gda.pl/avr/.
---
gcc/doc/install.texi | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 906c78aaca5..2addafd2465 100644
--- a/gcc/
The following testcase:
unsigned
sub_sat (unsigned x, unsigned y)
{
unsigned res;
res = x - y;
res &= -(x >= y);
return res;
}
currently compiles (-O2) to:
sub_sat:
movl%edi, %edx
xorl%eax, %eax
subl%esi, %edx
cmpl%esi, %edi
setnb
> >
> > gcc/ChangeLog:
> >
> > * ifcvt.cc (cond_move_process_if_block):
> > Consider the result of targetm.noce_conversion_profitable_p()
> > when replacing the original sequence with the converted one.
> THanks. I pushed this to the trunk.
>
Sorry for the delay report. With thi
YunQiang Su 于2024年6月9日周日 18:25写道：
>
> > >
> > > gcc/ChangeLog:
> > >
> > > * ifcvt.cc (cond_move_process_if_block):
> > > Consider the result of targetm.noce_conversion_profitable_p()
> > > when replacing the original sequence with the converted one.
> > THanks. I pushed this to
Hi,
On Sat, Jun 08, 2024 at 03:34:02PM -0600, Jeff Law wrote:
> On 5/14/24 8:12 AM, Gabi Falk wrote:
> > Hi,
> >
> > This one still needs review:
> >
> > https://inbox.sourceware.org/gcc-patches/20240415233833.104460-1-gabif...@gmx.com/
> I think I just ACK'd an equivalent patch from someone else
A move/bstrins pair is as fast as a (addi.w|lu12i.w|lu32i.d|lu52i.d)/and
pair, and twice fast as a srli/slli pair. When the src reg and the dst
reg happens to be the same, the move instruction can be optimized away.
gcc/ChangeLog:
* config/loongarch/predicates.md (high_bitmask_operand):
On 6/7/24 4:31 PM, Jeff Law wrote:
I've actually added it to my tester just to see if there's any fallout.
It'll take a week to churn through the long running targets that
bootstrap in QEMU, but the crosses should have data Monday.
The first round naturally didn't trigger anything because t
On 6/9/24 5:45 AM, Gabi Falk wrote:
Hi,
On Sat, Jun 08, 2024 at 03:34:02PM -0600, Jeff Law wrote:
On 5/14/24 8:12 AM, Gabi Falk wrote:
Hi,
This one still needs review:
https://inbox.sourceware.org/gcc-patches/20240415233833.104460-1-gabif...@gmx.com/
I think I just ACK'd an equivalent pa
On 6/9/24 5:28 AM, YunQiang Su wrote:
YunQiang Su 于2024年6月9日周日 18:25写道：
gcc/ChangeLog:
* ifcvt.cc (cond_move_process_if_block):
Consider the result of targetm.noce_conversion_profitable_p()
when replacing the original sequence with the converted one.
THanks. I push
On 6/7/24 11:49 AM, Andreas Schwab wrote:
In file included from ../../gcc/rtl.h:3973,
from ../../gcc/config/riscv/riscv.cc:31:
In function 'rtx_def* init_rtx_fmt_ee(rtx, machine_mode, rtx, rtx)',
inlined from 'rtx_def* gen_rtx_fmt_ee_stat(rtx_code, machine_mode, rtx,
rt
Andreas noted we were getting an uninit warning after the recent
constant synthesis changes. Essentially there's no way for the uninit
analysis code to know the first entry in the CODES array is a UNKNOWN
which will set X before its first use.
So trivial initialization with NULL_RTX is the ob
Ping https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
again, adding more reviewers into CC...
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> the build is configured --enable-default-pie. Let's fix them.
>
Hi All,
I have extended the testcase - see below and have
s/dependent_decls_2/dependent_decls_2.f90/ in the ChnageLog.
Cheers
Paul
! { dg-do run }
!
! Fix for PR59104 in which the dependence on the old style function result
! was not taken into account in the ordering of auto array allocation a
bext is defined as (src >> n) & 1. With that formulation, particularly
the "&1" means the result is implicitly zero extended. So we can safely
use it on SI objects for rv64 without the need to do any explicit extension.
This patch adds the obvious pattern and a few testcases. I think one
o
> Date: Sat, 8 Jun 2024 11:10:21 -0600
> From: Jeff Law
> >>>resource.cc: Replace calls to find_basic_block with cfgrtl
> >>> BLOCK_FOR_INSN
> >>>resource.cc (mark_target_live_regs): Remove check for bb not found
> >>>resource.cc: Remove redundant conditionals
> >>
> >> I had to
Hi Paul,
your approach sounds entirely reasonable.
But as the following addition to the testcase shows, there seem to
be loopholes left.
When I add the following to function f:
integer :: l1(size(y))
integer :: l2(size(z))
print *, size (l1), size (l2), size (z)
I g
On Fri, 13 Aug 2021, Andreas Tobler via Gcc-patches wrote:
> I would like to commit the attached patch to trunk and after a settling
> period also to all open branches.
> Is this ok?
Our MAINTAINERS file has the following entry:
freebsd Andreas Tobler
So ... yes. :-)
Seeing this did no
On Sun, Jun 9, 2024 at 2:22 PM Gerald Pfeifer wrote:
>
> On Fri, 13 Aug 2021, Andreas Tobler via Gcc-patches wrote:
> > I would like to commit the attached patch to trunk and after a settling
> > period also to all open branches.
> > Is this ok?
>
> Our MAINTAINERS file has the following entry:
>
:-D Looks good to me. EXCEPT I think the test sample file would need a
change, too. I didn't see that.
On 6/7/24 02:37, FX Coudert wrote:
The fixincludes fix “math_exception” is being applied overly broadly, including
many targets which don’t need it, like darwin (and probably all non-glibc
t
> :-D Looks good to me. EXCEPT I think the test sample file would need a
> change, too. I didn't see that.
Running “make check” produces the additional diff, which I’ll add to the patch
before I push. Does it look okay?
FX
diff --git a/fixincludes/tests/base/math.h b/fixincludes/tests/base/
> > The rtx_cost may consider the compare operation in `seq` as quite expensive.
> Overall it sounds like a target issue to me -- ie, now that we're
> testing for profitability instead of just assuming it's profitable some
> targets need adjustment. Either in their costing model or in the
> testsu
Need reviewers for the tree and middle-end parts, as well as the C frontend.
Thanks!
-Andi
For popcount for bytes, we don't need the reduction addition
after the vector cnt instruction as we are only counting one
byte's popcount.
This implements a new define_expand to handle that.
Bootstrapped and tested on aarch64-linux-gnu with no regressions.
PR target/113042
gcc/ChangeLog:
Hi
libstdc++: [_Hashtable] Optimize destructor
Hashtable destructor do not need to call clear() method that in addition to
destroying all nodes also reset all buckets to nullptr.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (~_Hashtable()): Replace clear call with
a _M_deallocate
Ping.
On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote:
> This implements hard register constraints for inline asm. A hard register
> constraint is of the form {regname} where regname is any valid register. This
> basically renders register asm superfluous. For exampl
Hi Harald,
Thanks for the loophole detection! It is obvious now I see it, as is the
fix. I'll get on to it as soon as I find some time.
Cheers
Paul
On Sun, 9 Jun 2024 at 21:35, Harald Anlauf wrote:
> Hi Paul,
>
> your approach sounds entirely reasonable.
>
> But as the following addition to
On Fri, 7 Jun 2024, Jeff Law wrote:
>
>
> On 6/6/24 4:10 AM, Manolis Tsamis wrote:
> > This pass detects cases of expensive store forwarding and tries to avoid
> > them
> > by reordering the stores and using suitable bit insertion sequences.
> > For example it can transform this:
> >
> >
A shift of 31 on a signed int is undefined behavior. Since unsigned
int is 32-bits wide this change fixes it and silences the warning.
gcc/ChangeLog:
PR target/115409
* config/i386/avx512fp16intrin.h (_mm512_conj_pch): Make the
constant unsigned before shifting.
*
29 matches
Mail list logo
