From: Pan Li
During investigate the combine from vec_dup and vop.vv into
vop.vx, we need to depend on the cost of the insn operate
from the gr to vr, for example, vadd.vx. Thus, for better
control and test, we introduce a new option, aka below:
--param=rvv-gr2vr-cost=
To specific the cost valu
From: Pan Li
Add asm dump check and for vec_duplicate + vadd.vv combine to vadd.vx.
The late-combine will not take action when GR2VR cost is 15.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec
From: Pan Li
Add asm dump check and for vec_duplicate + vadd.vv combine to vadd.vx.
The late-combine will not take action when GR2VR cost is 1.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/
From: Pan Li
This patch would like to introduce the combine of vec_dup + vadd.vv into
vadd.vx on the cost value of GR2VR. The late-combine will take place if
the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15
in test.
The below test suites are passed for this patch series.
From: Pan Li
This patch would like to combine the vec_duplicate + vadd.vv to the
vadd.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR, it will:
* The pattern matching will be active by default.
* The cost of GR2VR will be added to the tot
From: Pan Li
Add asm dump check and run test for vec_duplicate + vadd.vv combine
to vadd.vx. Introduce new folder to hold all related testcases.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.ex
> There's still some nagging issues (which I'll describe in a seperate email),
> but
> I think we can go ahead and merge this one too to close the loop.
Thanks Vineet, but I'd like to wait the ack from Jeff before commit.
Pan
-Original Message-
From: Vineet Gupta
Sent: Saturday, May 3
Hello world,
I just committed the following patch after noticing that an option name
was wrong in the gcc15/changes.html file.
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index d851a744..b442b8d9 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@
Hello world,
This patch fixes a case where too much was being checked with
-Wexternal-arguments-mismatch with a procedure pointer with an
unlimited polymorphic and an INTEGER argument which was inferred from
an actual argument.I also found some checks which can trigger false
positives, which this
On Sat, May 3, 2025 at 1:44 PM Jakub Jelinek wrote:
>
> On Sat, May 03, 2025 at 01:32:35PM +0200, Richard Biener wrote:
> > Any reason for unsigned long long vs. uint64_t for the following?
> >
> > -size_t attr;// See cbl_field_attr_t
> > +unsigned long long attr;// See
On Fri, May 2, 2025 at 4:53 PM Jakub Jelinek wrote:
>
> On Sun, Apr 06, 2025 at 03:39:27PM +0200, Jakub Jelinek wrote:
> > Right now it is not possible to even build cross-compilers from 32-bit
> > architectures to e.g. x86_64-linux or aarch64-linux, even from little-endian
> > ones.
> >
> > The f
On Sat, May 3, 2025 at 12:39 AM Andrew MacLeod wrote:
>
> On trunk I'll eventually do something different.. but it will be more
> invasive than I think is reasonable for a backport.
>
> The problem in the PR is that there is a variable with a range and has a
> bitmask attached to it. We often de
On Sat, May 03, 2025 at 01:32:35PM +0200, Richard Biener wrote:
> Any reason for unsigned long long vs. uint64_t for the following?
>
> -size_t attr;// See cbl_field_attr_t
> +unsigned long long attr;// See cbl_field_attr_t
Because it needs to be handled the same by th
在 2025-5-2 01:25, LIU Hao 写道:
Remove `STACK_REALIGN_DEFAULT` for this target, because now the default value of
`incoming_stack_boundary` equals `MIN_STACK_BOUNDARY` and it doesn't have an effect any more.
I suddenly realized the previous patch was for GCC 15 branch. Here's a new one,
rebase
On 4/30/25 7:13 AM, Tomasz Kaminski wrote:
Hi,
As we will be landing patches for extends, this will become a separate
patch series.
I would prefer, if you could commit per layout, and start with layout_right
(default)
I try to provide prompt responses, so if that works better for you, you can
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
c_common_post_options limits flag_abi_version and flag_abi_compat_version to
actual ABI version numbers, but let's not do that for warn_abi_version; we
might want to add a warning relative to a future ABI version that isn't
available in the
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This testcase was incidentally fixed by r16-325 for PR119162.
PR c++/85944
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-temp3.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/constexpr-temp3.C | 8
1 file changed
On 5/3/25 4:52 AM, Richard Biener wrote:
On Fri, 2 May 2025, Paul Koning wrote:
On May 2, 2025, at 12:27 PM, Maciej W. Rozycki wrote:
...
NB I understand your position and the need to cut the line sometime, and
I knew what the situation is with the VAX backend and that it would be
manag
Topic: follow up question about operator() for layout_stride.
On 4/30/25 7:13 AM, Tomasz Kaminski wrote:
Hi,
As we will be landing patches for extends, this will become a separate
patch series.
I would prefer, if you could commit per layout, and start with layout_right
(default)
I try to provid
On 3 May 2025 13:53:02 CEST, Richard Biener wrote:
>On Sat, May 3, 2025 at 1:44 PM Jakub Jelinek wrote:
>>
>> On Sat, May 03, 2025 at 01:32:35PM +0200, Richard Biener wrote:
>> > Any reason for unsigned long long vs. uint64_t for the following?
>> >
>> > -size_t attr;// See cb
On 1 May 2025 17:01:16 CEST, Andrew Pinski wrote:
>While looking into bitwise optimizations, I noticed that
>get_known_nonzero_bits_1 does `bm.value () & ~bm.mask ()` which
>is ok except it creates a temporary wide_int. Instead if we
>use wi::bit_and_not, we can avoid the temporary and on some
d
On Sat, May 3, 2025 at 1:03 PM Bernhard Reutner-Fischer
wrote:
>
> On 1 May 2025 17:01:16 CEST, Andrew Pinski wrote:
> >While looking into bitwise optimizations, I noticed that
> >get_known_nonzero_bits_1 does `bm.value () & ~bm.mask ()` which
> >is ok except it creates a temporary wide_int. Inst
>No, I have not looked.
In IPA, we should be able to see them, the mask as not requiring the tmp, but
the same otherwise
On 5/3/25 2:20 AM, Li, Pan2 wrote:
There's still some nagging issues (which I'll describe in a seperate email), but
I think we can go ahead and merge this one too to close the loop.
Thanks Vineet, but I'd like to wait the ack from Jeff before commit.
Go ahead. I just wanted to make the two
Hi Thomas,
I haven't tested your patch very thorougly, but when manually
compiling
% gfc-16 gcc/testsuite/gfortran.dg/proc_ptr_52.f90
-Wexternal-argument-mismatch && ./a.out
STOP 1
It appears that something is not right and generates wrong code with
the check enabled. Can you have another lo
The recent adjustment to more correctly cost register moves tripped a
few testsuite regressions.
I'm pretty torn on the thead test adjustments. But in reality they only
worked because the register move costing was broken. So I've reverted
the scan-asm part of those to a prior state for two o
As GCC15 is now strict on dynamic function as
int *func()
to mean exactly zero arguments via its default -std=gnu23, I'm looking
into a dynamic option that would work for C23 and recognized libffi
being built as part of GCC and being part of its source tree, which
possibly is a way to go (u
Hello.
The bug log contains a slightly improved v16.
Marc Poulhiès:
> issue we currently see is that some application code doesn't build. In
> particular gprbuild needs to be adjusted following your changes. We don't want
> to split the ecosystem between code that builds with latest compiler only
> On May 3, 2025, at 6:52 AM, Richard Biener wrote:
>
> On Fri, 2 May 2025, Paul Koning wrote:
>
>>
>>
>>> On May 2, 2025, at 12:27 PM, Maciej W. Rozycki wrote:
>>>
>>> ...
>>> NB I understand your position and the need to cut the line sometime, and
>>> I knew what the situation is with
Dear all,
the attached, semi-obvious patch fixes bugging issues with passing of
array subreferences when either an inquiry reference to a complex array
or a substring reference to a character array was involved, and the
array was a component of a derived type. The obvious cause was always
an ear
Topics of this chain:
- computing __fwd_prod and __rev_prod.
- checking representability preconditions.
On 4/30/25 7:13 AM, Tomasz Kaminski wrote:
Hi,
As we will be landing patches for extends, this will become a separate
patch series.
I would prefer, if you could commit per layout, and start
This chain discusses changes to `mapping::operator()`. For concrete
discussion, see below. I have a general question: is there a reason
other than style to prefer folds over recursion?
On 4/30/25 7:13 AM, Tomasz Kaminski wrote:
Hi,
As we will be landing patches for extends, this will become a
On 5/3/25 07:41, Richard Biener wrote:
On Sat, May 3, 2025 at 12:39 AM Andrew MacLeod wrote:
On trunk I'll eventually do something different.. but it will be more
invasive than I think is reasonable for a backport.
The problem in the PR is that there is a variable with a range and has a
bitm
Hi,
Inliner currently applies different heuristics to hot and cold calls (the
second are inlined only if the code size will shrink). It may happen that the
call itself is hot, but the significant time is spent in callee and inlining
makes it faster. For this reason we want to check if the anticip
Hello,
> This mini-series removes the TARGET_LRA_P hook, forcing all targets
> to use LRA. I have not touched the targets that define -mlra
> in terms of a 'Target Mask(XXX)' since IIRC there's no way to
> "default" that. I'd expect those to wrongly assume LRA isn't enabled
> when using that
John Paul Adrian Glaubitz writes:
> Hello,
>
>
>
>
>> This mini-series removes the TARGET_LRA_P hook, forcing all targets
>> to use LRA. I have not touched the targets that define -mlra
>> in terms of a 'Target Mask(XXX)' since IIRC there's no way to
>> "default" that. I'd expect those to wrong
Hi Maciej,
On Fri, 2025-05-02 at 11:57 +0100, Maciej W. Rozycki wrote:
> - I have only learnt last year that the Alpha backend also needs some work
> here and it appears that it relies on a hack or a bunch within reload to
> propagate alignment information required for non-BWX targets to pro
On Sat, May 3, 2025 at 10:29 PM John Paul Adrian Glaubitz
wrote:
>
> Hello,
>
>
>
>
> > This mini-series removes the TARGET_LRA_P hook, forcing all targets
> > to use LRA. I have not touched the targets that define -mlra
> > in terms of a 'Target Mask(XXX)' since IIRC there's no way to
> > "defau
Hello,
> This mini-series removes the TARGET_LRA_P hook, forcing all targets
> to use LRA. I have not touched the targets that define -mlra
> in terms of a 'Target Mask(XXX)' since IIRC there's no way to
> "default" that. I'd expect those to wrongly assume LRA isn't enabled
> when using that XXX
Hi Maciej,
On Fri, 2025-05-02 at 17:27 +0100, Maciej W. Rozycki wrote:
> I only have non-BWX hardware and I'm not interested in decommissioning it
> or upgrading. There appear to be a few users around, but I seem to be the
> last GCC developer remaining who is willing to do anything about the
Hi Andrew,
On Sat, 2025-05-03 at 22:32 -0700, Andrew Pinski wrote:
> > PPS: Sorry for posting out of thread, but unlike lore.kernel.org, I could
> > not find a way to obtain the message or mboxes on gcc-patches.
>
> https://inbox.sourceware.org/gcc-patches/ is the link to the official
> publ
Simon Sobisch writes:
> As GCC15 is now strict on dynamic function as
> int *func()
> to mean exactly zero arguments via its default -std=gnu23, I'm looking
> into a dynamic option that would work for C23 and recognized libffi
> being built as part of GCC and being part of its source tree, wh
On Sat, 3 May 2025, Paul Koning wrote:
> > As for MEM(MEM(xyz)) addressing modes I'm less sure - I suppose those
> > are usually formed at RTL expansion time (rather than, say, by
> > RTL combine)? If PDP-11 is the only target with those then it might
> > be easier to recover those post-LRA durin
On Fri, 2 May 2025, Paul Koning wrote:
>
>
> > On May 2, 2025, at 12:27 PM, Maciej W. Rozycki wrote:
> >
> > ...
> > NB I understand your position and the need to cut the line sometime, and
> > I knew what the situation is with the VAX backend and that it would be
> > manageable. In princip
44 matches
Mail list logo
