Several months ago changes were made to the vectorizer which mucked up
several of the scan tests. All but one of the cases in pr115375 have
since been fixed.
The remaining failure seems to be primarily a debugging dump issue --
we're still selecting the same lmul values. This patch adjusts t
On 12/30/24 8:16 AM, Richard Sandiford wrote:
Andrew Pinski writes:
On Fri, Dec 27, 2024 at 3:19 AM Robin Dapp wrote:
Thanks for the helpful suggestion. The attached v2 patch tries to implement
it.
It was bootstrapped and regtested on x86, aarch64 and Power 10.
Also regtested on rv64gcv_
On 27/12/2024 19:52, Paul-Antoine Arras wrote:
On 23/12/2024 21:04, Tobias Burnus wrote:
For adjust-args-10.f90, I wonder whether it is sufficient as compile-
time only or whether it makes more sense to have a "dg-do run" to
check that type(C_ptr) value vs. not-value works. I think either is
f
Address Richard's comment.
Thanks
Jim
Richard Sandiford 於 2024年12月30日 週一 下午7:50寫道：
>
> Tsung Chun Lin writes:
> > From ddb7852c92dc0222af9eeec1deafce753b3a7067 Mon Sep 17 00:00:00 2001
> > From: Jim Tsung-Chun Lin
> > Date: Mon, 30 Dec 2024 15:32:12 +0800
> > Subject: [PATCH] Prefer scalar_int
Richard Sandiford writes:
> Wilco Dijkstra writes:
>> Hi Richard,
>>
A common case is a constant string which is compared against some
argument. Most string functions work on 8 or 16-byte quantities. If we
ensure the whole array fits in one aligned load, we save time in the
st
Sorry to react so late on this patch.
I'm only surprised by the expected result of the added __builtin_expect
which is 0.
It means that we consider that hasher is not perfect, we have several
entries in the same bucket. Shouldn't we reward those that are spending
time on their hasher to make it a
On 12/30/24 12:34 AM, Paul Richard Thomas wrote:
Hi Jerry,
With such an illustrious group of contributors, I can hardly say 'no',
can I? :-)
It looks fine to me - OK for trunk.
Regards
Paul
Thanks Paul. Special thanks to Steve for taking this on.
commit efc0981077a70c4de4596f682c4aeade0
Akram Ahmad writes:
> GIMPLE code which performs a narrowing truncation on the result of a
> vector concatenation currently results in an unnecessary XTN being
> emitted following a UZP1 to concate the operands. In cases such as this,
> UZP1 should instead use a smaller arrangement specifier to re
Jeff Law writes:
> On 12/30/24 8:16 AM, Richard Sandiford wrote:
>
>>
>> The divisor is by definition 1. I think dropping it would make the
>> loop more obviously correct, since the same assumption is implicit in
>> the loop body.
> I'll likely pick this up as Robin is on PTO for the next ~10 da
On Sun, 29 Dec 2024 00:47:05 + (GMT)
"Maciej W. Rozycki" wrote:
> > ChangeLog
> > * Makefile.def: Add libgcobol module and cobol language.
>
> Since this implies the regeneration of top-level Makefile.in please
> add a ChangeLog entry to that effect and include the changes to
> Makefile
This is a fix for a bug Andrew P filed a while back where essentially a
poorly crafted asm statement could trigger a ICE during assembly output.
Various cases will use INTVAL (op) without verifying the operand is a
CONST_INT node first.
The usual way to handle this is via output_operand_lossa
Jeff Law writes:
> The BZ in question is a failure to recognize a pair of shifts as a sign
> extension.
>
> I originally thought simplify-rtx would be the right framework to
> address this problem, but fwprop is actually better. We can write the
> recognizer much simpler in that framework.
>
>
On Sun, Dec 29, 2024 at 10:54:03AM -0700, Jeff Law wrote:
>
>
> On 12/5/24 8:45 AM, Andrew Carlotti wrote:
>
> > > So at a 30k foot level, one thing to be very leery of is extending the
> > > lifetime of any hard register. It's probably not a big deal on aarch, but
> > > it can cause all kinds
Hi Jerry,
With such an illustrious group of contributors, I can hardly say 'no', can
I? :-)
It looks fine to me - OK for trunk.
Regards
Paul
On Sun, 29 Dec 2024 at 23:10, Jerry D wrote:
> Attached is the revised patch incorporating handling of optional
> arguments of a calling procedure and
Tsung Chun Lin writes:
> From ddb7852c92dc0222af9eeec1deafce753b3a7067 Mon Sep 17 00:00:00 2001
> From: Jim Tsung-Chun Lin
> Date: Mon, 30 Dec 2024 15:32:12 +0800
> Subject: [PATCH] Prefer scalar_int_mode if the size - 1 is equal to
> UNITS_PER_WORD.
>
> Don't use the QI vector if its size is eq
Applied to master (with fixed-up commit message). Thanks!
--Philipp.
On Sun, 29 Dec 2024 at 17:58, Jeff Law wrote:
>
>
>
> On 12/17/24 4:51 AM, Konstantinos Eleftheriou wrote:
> > From: kelefth
> >
> > During the initialization of the base register for the zero-offset store, in
> > the case th
Hi PA,
Paul-Antoine Arras wrote:
On 27/12/2024 19:52, Paul-Antoine Arras wrote:
Running adjust-args-10.f90 manually exhibited a bug that no other
testcase triggered. So I fixed the bug; then moved adjust-args-10.f90
to the libgomp testsuite, renamed it to dispatch-3.f90 and made it
dg-run.
I
On Sun, 29 Dec 2024, Maciej W. Rozycki wrote:
> Contrary to user documentation the `-mbwx', `-mcix', `-mfix', `-mmax'
> feature options and their inverse forms are ignored whenever `-mcpu='
> option is in effect, either by having been given explicitly or where
> configured as the default such a
Hi PA,
Paul-Antoine Arras wrote:
Folded everything in one patch. […]
Updated ChangeLog. […]
Thanks.
Rebased and amended accordingly. I believe I did the right thing but
please have a quick look to be sure.
...
Otherwise, LGTM. Thanks!
LGTM :-)
For libgomp.fortran/dispatch-3.f90, see just
Keith Packard writes:
>> insn_propagation would previously only replace (reg:M H) with X
>> for some hard register H if the uses of H were also in mode M.
>> This patch extends it to handle simple mode punning too.
>
> (this is from GCC commit 9d20529d94b23275885f380d155fe8671ab5353a)
>
> Looks li
Andrew Pinski writes:
> On Fri, Dec 27, 2024 at 3:19 AM Robin Dapp wrote:
>>
>> Thanks for the helpful suggestion. The attached v2 patch tries to implement
>> it.
>>
>> It was bootstrapped and regtested on x86, aarch64 and Power 10.
>> Also regtested on rv64gcv_zvl512b.
>>
>> Those are all littl
On 12/30/24 8:16 AM, Richard Sandiford wrote:
The divisor is by definition 1. I think dropping it would make the
loop more obviously correct, since the same assumption is implicit in
the loop body.
I'll likely pick this up as Robin is on PTO for the next ~10 days. So
just to be 100% clear
The BZ in question is a failure to recognize a pair of shifts as a sign
extension.
I originally thought simplify-rtx would be the right framework to
address this problem, but fwprop is actually better. We can write the
recognizer much simpler in that framework.
fwprop already simplifies nes
On 12/30/24 3:02 PM, Richard Sandiford wrote:
Jeff Law writes:
The BZ in question is a failure to recognize a pair of shifts as a sign
extension.
I originally thought simplify-rtx would be the right framework to
address this problem, but fwprop is actually better. We can write the
recogniz
This is a minor testsuite adjustment
attr-complex-method-2.c selects between two scan-tree-dump clauses based
on avr, !avr. But what they really should be checking is "large_double"
that way it works for avr, h8, rl78 and any other target which makes
doubles the same size as floats.
attr-co
25 matches
Mail list logo
