Hi!
I've searched for some uses of (HOST_WIDE_INT) constant or (unsigned
HOST_WIDE_INT) constant and turned them into uses of the appropriate
macros.
THere are quite a few cases in non-i386 backends but I've left that out
for now.
The only behavior change is in build_replicated_int_cst where the
Hi!
The following patch implements support for VIEW_CONVERT_EXPRs from/to
large/huge _BitInt to/from vector or complex types or anything else but
integral/pointer types which doesn't need to live in memory.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-24 Jakub
From: Fangrui Song
Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c
-mfdpic does not pass --fdpic to gas. This is an unnecessary
restriction. Just define the ASM_SPEC in bpabi.h.
Additionally, use armelf[b]_linux_fdpiceabi emulations for -mfdpic in
linux-eabi.h. This
This enables construction of V4SF CST like `{1.0f, 1.0f, 0.0f, 0.0f}`
(and other fp enabled CSTs) by using `fmov v0.2s, 1.0` as the instruction
is designed to zero out the other bits.
This is a small extension on top of the code that creates fmov for the case
where the all but the first element is
Aarch64 has a way to form some floating point CSTs via the fmov instructions,
these instructions also zero out the upper parts of the registers so they can
be used for vector CSTs that have have one non-zero constant that would be able
to formed via the fmov in the first element.
This implements
Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Bound testcase
+Martin who may have an opinion
(https://github.com/mstorsjo/llvm-mingw supports aarch64)
On Fri, Feb 23, 2024 at 6:15 AM Evgeny Karpov
wrote:
>
> Hi Andrew and Richard,
>
> Thank you for pointing out there's no need for a 64-bit ISA and the
> big-endian target.
> These changes will be
Hi Martin,
Thank you for the clarification regarding the vararg implementation.
It is correct. The work is still in progress and will be included in
a later patch series.
ARM64EC is a separate work, which is outside the scope of the current
contribution plan.
Regards,
Evgeny
-Original
On Fri, Feb 23, 2024 at 10:15:17PM +0100, Harald Anlauf wrote:
> Hi Steve, all,
>
> here's an updated patch with an enhanced testcase that also
> checks MOLD= besides SOURCE=.
>
> Regtested on x86_64-pc-linux-gnu. Is it OK for mainline?
>
>From my viewpoint, yes.
Thanks for finding a better
Hi Richard,
Thank you for your review!
The MS_ABI definition is for the x86/x64 MS ABI, and it's clear that it
shouldn't be used on aarch64.
The AARCH64_CALLING_ABI_MS definition resolves the issue.
It just needs to be properly handled in mingw32.h.
The change below is sufficient to resolve
On 23 February 2024 22:15:17 CET, Harald Anlauf wrote:
>Hi Steve, all,
>
>here's an updated patch with an enhanced testcase that also
>checks MOLD= besides SOURCE=.
>
>Regtested on x86_64-pc-linux-gnu. Is it OK for mainline?
LGTM
cheers
>
>Cheers,
>Harald
Hi Steve, all,
here's an updated patch with an enhanced testcase that also
checks MOLD= besides SOURCE=.
Regtested on x86_64-pc-linux-gnu. Is it OK for mainline?
Cheers,
Harald
On 2/22/24 22:32, Harald Anlauf wrote:
On 2/22/24 22:01, Steve Kargl wrote:
BTW, my patch and I suspect your
On Thu, 22 Feb 2024 15:56:46 +
Evgeny Karpov wrote:
> A ChangeLog template using "Moved... ...here" has been generated by
> contrib/mklog.py.
> It seems that it needs modification.
>
> Regards,
> Evgeny
>
> -Original Message-
> Thursday, February 22, 2024 12:11 PM
> Richard
> +/* { dg-final { scan-assembler-times "vmv\.v\.i\tv\[0-9\],0" 0 } } */
>
> I think you should use "scan-assembler-not"
Thanks, going to commit with that change.
Regards
Robin
On Fri, 23 Feb 2024, Richard Sandiford wrote:
Are there two distinct ABIs for aarch64-*-mingw*? Or are these
distinctions ignored on aarch64 and just retained for compatibility?
On Windows on AArch64, the calling convention normally matches regular
AAPCS64 - so the ms_abi attribute normally
+CC Greg who might also have some bits in flight here.
On 2/23/24 01:23, Li, Pan2 wrote:
>
> > I would prefer to only keep zvl and scalable or zvl only, since I
>
> > don't see too much value in specifying a value which different from
>
> > zvl*b, that's a legacy option used before zvl*b option
On 2/22/24 2:08 PM, Jakub Jelinek wrote:
On Thu, Feb 22, 2024 at 12:59:18PM -0800, Greg McGary wrote:
The sign bit of a sign-extending load cannot be known until runtime,
so don't attempt to simplify it in the combiner.
2024-02-22 Greg McGary
PR rtl-optimization/113010
On 2/23/24 06:23, Alexandre Oliva wrote:
I'm not so worried about bootstrap itself as I am about post-bootstrap
host tools. Those are unusual in that, after native bootstraps, they're
built using the just-built (last-stage) compiler and target libraries,
rather than the host compiler and
On Fri, Feb 23, 2024 at 02:43:45PM +0100, Juergen Christ wrote:
> The emulation via word mode tries to perform integer arithmetic on floating
> point values instead of floating point arithmetic. This leads to
> mis-compilations.
>
> Failure occured on s390x on these existing test cases:
>
"Richard Earnshaw (lists)" writes:
> On 21/02/2024 17:47, Evgeny Karpov wrote:
>> Hello,
>>
>> We would like to take your attention to the review of changes for the
>> new GCC target, aarch64-w64-mingw32. The new target will be
>> supported, tested, added to CI, and maintained by Linaro. This
On Tue, Feb 20, 2024 at 06:35:34PM +0800, Kewen.Lin wrote:
> on 2024/2/8 03:58, Michael Meissner wrote:
> $ grep -r "define PROCESSOR_DEFAULT" gcc/config/rs6000/
> gcc/config/rs6000/aix71.h:#define PROCESSOR_DEFAULT PROCESSOR_POWER7
> gcc/config/rs6000/aix71.h:#define PROCESSOR_DEFAULT64
On Fri, Feb 23, 2024 at 9:51 AM Richard Sandiford
wrote:
>
> Evgeny Karpov writes:
> > The calling ABI enum definition has been done following a similar
> > convention in
> >
Hi All,
In certain cases we can have a situation where the merge block has a vUSE
virtual PHI and the exits do not. In this case for instance the exits lead
to an abort so they have no virtual PHIs. If we have a store before the first
exit and we move it to a later block during vectorization we
On 2/23/24 08:53, Christophe Lyon wrote:
On Fri, 23 Feb 2024 at 10:13, Christophe Lyon
wrote:
On Fri, 23 Feb 2024 at 09:42, Jakub Jelinek wrote:
Hi!
When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
constructor is supposed to return this pointer, but when we cp_fold
Evgeny Karpov writes:
> The calling ABI enum definition has been done following a similar convention
> in
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-opts.h;h=ef2825803b32001b9632769bdff196d1e43d27ba;hb=refs/heads/master#l41
>
> MS_ABI is used in gcc/config/i386/mingw32.h
On Thu, 22 Feb 2024 20:29:37 PST (-0800), Kito Cheng wrote:
I guess Palmer is too busy, so committed to trunk :P
Thanks, I got distracted with some work stuff ;)
On Tue, Feb 13, 2024 at 11:55 PM Jeff Law wrote:
On 2/9/24 09:53, Palmer Dabbelt wrote:
> This builds for me, and I
Evgeny Karpov writes:
> From 1ea6efa6f88d131884ecef21c4b5d2ecbab14ea7 Mon Sep 17 00:00:00 2001
> From: Zac Walker
> Date: Tue, 20 Feb 2024 18:06:36 +0100
> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for
> AArch64
>
> Define Cygwin and MinGW environment such as types,
Evgeny Karpov writes:
> From 55fd2a63afa9abb3543d714b6f5925efd2682e08 Mon Sep 17 00:00:00 2001
> From: Zac Walker
> Date: Wed, 21 Feb 2024 12:20:46 +0100
> Subject: [PATCH v1 04/13] aarch64: Add aarch64-w64-mingw32 COFF
>
> Define ASM specific for COFF format on AArch64.
>
> gcc/ChangeLog:
>
>
"Richard Earnshaw (lists)" writes:
> On 21/02/2024 18:30, Evgeny Karpov wrote:
>>
> +/* X18 reserved for the TEB on Windows. */
> +#ifdef TARGET_ARM64_MS_ABI
> +# define FIXED_X18 1
> +# define CALL_USED_X18 0
> +#else
> +# define FIXED_X18 0
> +# define CALL_USED_X18 1
> +#endif
>
> I'm not
Fix libatomic build to support --disable-gnu-indirect-function on AArch64.
Always build atomic_16.S and add aliases to the __atomic_* functions if
!HAVE_IFUNC.
Passes regress and bootstrap, OK for commit?
libatomic:
PR target/113986
* Makefile.in: Regenerated.
*
This fixes the cost model for BFI instructions which don't
use directly zero_extract on the LHS.
aarch64_bfi_rtx_p does the heavy lifting by matching of
the patterns.
Note this alone does not fix PR 107270, it is a step in the right
direction. There we get z zero_extend for the non-shifted part
On 22.02.2024 18:45, Andrew Pinski wrote:
On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists)
wrote:
On 21/02/2024 18:30, Evgeny Karpov wrote:
+/* X18 reserved for the TEB on Windows. */
+#ifdef TARGET_ARM64_MS_ABI
+# define FIXED_X18 1
+# define CALL_USED_X18 0
+#else
+# define
Hi Richard,
> This bit isn't. The correct fix here is to fix the pattern(s) concerned to
> add the missing predicate.
>
> Note that builtin-bswap.x explicitly mentions predicated mnemonics in the
> comments.
I fixed the patterns in v2. There are likely some more, plus we could likely
merge
On Fri, 23 Feb 2024, Jakub Jelinek wrote:
> On Fri, Feb 23, 2024 at 02:22:19PM +, Andrew Stubbs wrote:
> > On 23/02/2024 13:02, Jakub Jelinek wrote:
> > > On Fri, Feb 23, 2024 at 12:58:53PM +, Andrew Stubbs wrote:
> > > > This is a follow-up to the previous patch to ensure that integer
I had forgotten to add the doc since there is now a new API.
Here it is.
On Wed, 2024-02-21 at 19:45 -0500, Antoni Boucher wrote:
> Thanks for the review.
>
> Here's the updated patch.
>
> On Thu, 2023-12-07 at 20:04 -0500, David Malcolm wrote:
> > On Thu, 2023-12-07 at 17:29 -0500, Antoni
On Fri, Feb 23, 2024 at 02:22:19PM +, Andrew Stubbs wrote:
> On 23/02/2024 13:02, Jakub Jelinek wrote:
> > On Fri, Feb 23, 2024 at 12:58:53PM +, Andrew Stubbs wrote:
> > > This is a follow-up to the previous patch to ensure that integer vector
> > > bit-masks do not have excess bits set.
On 23/02/2024 13:02, Jakub Jelinek wrote:
On Fri, Feb 23, 2024 at 12:58:53PM +, Andrew Stubbs wrote:
This is a follow-up to the previous patch to ensure that integer vector
bit-masks do not have excess bits set. It fixes a bug, observed on
amdgcn, in which the mask could be incorrectly set
The calling ABI enum definition has been done following a similar convention in
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-opts.h;h=ef2825803b32001b9632769bdff196d1e43d27ba;hb=refs/heads/master#l41
MS_ABI is used in gcc/config/i386/mingw32.h and gcc/config/i386/winnt-d.cc
Most code in early-ra used is_chain_candidate to check whether we
should chain two allocnos. This included both tests that matter
for correctness and tests for certain heuristics.
Once that test passes for one pair of allocnos, we test whether
it's safe to chain the containing groups (which
early-ra already had code to do regrename-style "broadening"
of the allocation, to promote scheduling freedom. However,
the pass divides the function into allocation regions
and this broadening only worked within a single region.
This meant that if a basic block contained one subblock
of FPR use,
> Am 23.02.2024 um 14:03 schrieb Jakub Jelinek :
>
> On Fri, Feb 23, 2024 at 12:58:53PM +, Andrew Stubbs wrote:
>> This is a follow-up to the previous patch to ensure that integer vector
>> bit-masks do not have excess bits set. It fixes a bug, observed on
>> amdgcn, in which the mask
Hi Andrew and Richard,
Thank you for pointing out there's no need for a 64-bit ISA and the big-endian
target.
These changes will be addressed in v2.
Regards,
Evgeny
-Original Message-
Thursday, February 22, 2024 12:33 PM
Richard Earnshaw (lists) wrote:
>
+aarch64*-*-mingw*)
Other
Am Fri, Feb 23, 2024 at 01:57:12PM + schrieb Sam James:
>
> Juergen Christ writes:
>
> > The emulation via word mode tries to perform integer arithmetic on floating
> > point values instead of floating point arithmetic. This leads to
> > mis-compilations.
>
> Is the bug ref + test
Juergen Christ writes:
> The emulation via word mode tries to perform integer arithmetic on floating
> point values instead of floating point arithmetic. This leads to
> mis-compilations.
Is the bug ref + test missing?
>
> Failure occured on s390x on these existing test cases:
>
On Fri, 23 Feb 2024 at 10:13, Christophe Lyon
wrote:
>
> On Fri, 23 Feb 2024 at 09:42, Jakub Jelinek wrote:
> >
> > Hi!
> >
> > When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
> > constructor is supposed to return this pointer, but when we cp_fold such
> > a call, we
The emulation via word mode tries to perform integer arithmetic on floating
point values instead of floating point arithmetic. This leads to
mis-compilations.
Failure occured on s390x on these existing test cases:
gcc.dg/vect/tsvc/vect-tsvc-s112.c
gcc.dg/vect/tsvc/vect-tsvc-s113.c
On Fri, Feb 23, 2024 at 11:12:41AM +0100, Uros Bizjak wrote:
> On Fri, Feb 23, 2024 at 3:45 AM H.J. Lu wrote:
> >
> > On Thu, Feb 22, 2024 at 6:39 PM Hongtao Liu wrote:
> > >
> > > On Thu, Feb 22, 2024 at 10:33 PM H.J. Lu wrote:
> > > >
> > > > On Sun, Feb 18, 2024 at 8:02 AM H.J. Lu wrote:
>
On Fri, Feb 23, 2024 at 12:58:53PM +, Andrew Stubbs wrote:
> This is a follow-up to the previous patch to ensure that integer vector
> bit-masks do not have excess bits set. It fixes a bug, observed on
> amdgcn, in which the mask could be incorrectly set to zero, resulting in
> wrong-code.
>
This is a follow-up to the previous patch to ensure that integer vector
bit-masks do not have excess bits set. It fixes a bug, observed on
amdgcn, in which the mask could be incorrectly set to zero, resulting in
wrong-code.
The mask was broken when nunits==32. The patched version will probably
be
Hi Edwin,
Looks like 6ec84c45a19403d3435b2affe4ec60e518fc1f97 result in sorts of rvv.exp
asm check failure (I list some but not all of them in below) in upstream.
Could you please help to double check about it? Ping me if any more information
is needed. Thanks.
= Summary
On Fri, Feb 23, 2024 at 12:25:54PM +0100, Tobias Burnus wrote:
> When checking something else, I noticed that there was one warning in
> openmp.cc that did not use OPT_Wopenmp.
>
> I intent to commit the attached patch later today as obvious.
>
> Tobias
> Fortran/Openmp: Use OPT_Wopenmp for
Excerpts from Jørgen Kvalsvik's message of Februar 23, 2024 12:18 pm:
> This is a mostly straight port from the gcov-19.c tests from the C test
> suite. The only notable differences from C to D are that D flips the
> true/false outcomes for loop headers, and the D front end ties loop and
> ternary
The expand pattern for reciprocal division was enabled for all math
optimization modes, but the patterns it was generating were not
enabled unless -funsafe-math-optimizations were enabled, this leads to
an ICE when the pattern we generate cannot be recognized.
Fixed by only enabling vector
When checking something else, I noticed that there was one warning in
openmp.cc that did not use OPT_Wopenmp.
I intent to commit the attached patch later today as obvious.
Tobias
Fortran/Openmp: Use OPT_Wopenmp for gfc_match_omp_depobj warning
gcc/fortran/ChangeLog:
* openmp.cc
Hello Richard:
On 23/02/24 1:19 am, Richard Sandiford wrote:
> Ajit Agarwal writes:
>> Hello Alex/Richard:
>>
>> I have placed target indpendent and target dependent code in
>> aarch64-ldp-fusion for load store fusion.
>>
>> Common infrastructure of load store pair fusion is divided into
>>
On Feb 21, 2024, Jason Merrill wrote:
> So indeed I guess we still
> want both prev and current libgcc directories in RPATH to handle the
> case where we've removed the previous stage, as below.
*nod*, thanks
> I can't think of why we would need to depend on the current stage
> target
Hello Richard/Alex/Segher:
This patch adds the changed code for target independent and
dependent code for load store fusion.
Common infrastructure of load store pair fusion is
divided into target independent and target dependent
changed code.
Target independent code is the Generic code with
This is a mostly straight port from the gcov-19.c tests from the C test
suite. The only notable differences from C to D are that D flips the
true/false outcomes for loop headers, and the D front end ties loop and
ternary conditions to slightly different locus.
The test for >64 conditions warning
On Thu, 2024-02-22 at 19:09 +0800, chenglulu wrote:
>
> 在 2024/2/22 下午6:20, Xi Ruoyao 写道:
> > To improve Binutils compatibility we've had to backported relaxation
> > support. But if a user just updates to GCC 13.3 and sticks with
> > Binutils 2.41, there is no reason to use -mno-explicit-relocs
On Fri, 2024-02-23 at 11:37 +0800, chenglulu wrote:
>
> 在 2024/2/23 上午11:27, Xi Ruoyao 写道:
> > On Fri, 2024-02-23 at 11:16 +0800, chenglulu wrote:
> > > 在 2024/2/22 下午5:17, Xi Ruoyao 写道:
> > > > The gold linker has never been ported to LoongArch (and it seems
> > > > unlikely to be ported in the
On Fri, Feb 23, 2024 at 3:45 AM H.J. Lu wrote:
>
> On Thu, Feb 22, 2024 at 6:39 PM Hongtao Liu wrote:
> >
> > On Thu, Feb 22, 2024 at 10:33 PM H.J. Lu wrote:
> > >
> > > On Sun, Feb 18, 2024 at 8:02 AM H.J. Lu wrote:
> > > >
> > > > If assembler and linker supports
> > > >
> > > > add %reg1,
On Fri, 23 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because the REDUCE_BIT_FIELD macro uses
> the target variable implicitly:
> #define REDUCE_BIT_FIELD(expr) (reduce_bit_field \
> ?
On Fri, 23 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcases show 2 bugs in the .{ADD,SUB}_OVERFLOW lowering,
> both related to storing of the REALPART_EXPR part of the result.
> On the first testcase prec is 255, prec_limbs is 4 and for the second limb
> in the loop the store of
The following documents obsoleting of ia64*-*-*.
Pushed.
* gcc-14/changes.html: Document ia64*-*-* obsoleting.
---
htdocs/gcc-14/changes.html | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index
Hi All,
The following patch has been bootstrapped and regtested on powerpc64le-linux.
PTImode attribute assists in generating even/odd register pairs on 128 bits.
When the user specifies PTImode as an attribute, it breaks because there is no
internal type to handle this mode . We have created a
> I would prefer to only keep zvl and scalable or zvl only, since I
> don't see too much value in specifying a value which different from
> zvl*b, that's a legacy option used before zvl*b option was introduced,
> and the reason to add that is that could used for compatible with
> clang/LLVM
gcc.dg/vect/vect-bic-bitmask-12.c and gcc.dg/vect/vect-bic-bitmask-23.c
currently FAIL on 32 and 64-bit Solaris/SPARC
FAIL: gcc.dg/vect/vect-bic-bitmask-12.c -flto -ffat-lto-objects scan-tree-dump
dce7 "<=s*.+{ 255,.+}"
FAIL: gcc.dg/vect/vect-bic-bitmask-12.c scan-tree-dump dce7
On Fri, 23 Feb 2024 at 09:42, Jakub Jelinek wrote:
>
> Hi!
>
> When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
> constructor is supposed to return this pointer, but when we cp_fold such
> a call, we don't take that into account and just INIT_EXPR the object,
> so we can
> On 21 Feb 2024, at 23:36, Iain Sandoe wrote:
>
>> On 21 Feb 2024, at 23:06, Jason Merrill wrote:
>>
>> On 2/20/24 00:45, Alexandre Oliva wrote:
>>> On Feb 16, 2024, Jason Merrill wrote:
So, for stage2+, let's add just prev- libgcc.
>>> I'm pretty sure this will break bootstrap-lean
gcc.dg/plugin/crash-test-write-though-null-sarif.c FAILs on Solaris:
FAIL: gcc.dg/plugin/crash-test-write-though-null-sarif.c
-fplugin=./crash_test_plugin.so scan-sarif-file "text": "Segmentation fault
Comparing the sarif files between Linux and Solaris reveals
-
Hi!
When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
constructor is supposed to return this pointer, but when we cp_fold such
a call, we don't take that into account and just INIT_EXPR the object,
so we can later ICE during gimplification, because the expression doesn't
I personally think it's better to has VLS compile option and attribute in
GCC-14.
Since there are many people porting different libraury
(eigen/highway/xnnpack/openBLAS,...) with VLS feature,
they test them with Clang.
If we don't support it, we will end up with Clang can compile those lib but
On 2/23/24 01:22, Kito Cheng wrote:
I would prefer to only keep zvl and scalable or zvl only, since I
don't see too much value in specifying a value which different from
zvl*b, that's a legacy option used before zvl*b option was introduced,
and the reason to add that is that could used for
On 2/23/24 01:05, Richard Biener wrote:
The following deprecates ia64*-*-* for GCC 14. Since we plan to
force LRA for GCC 15 and the target only has slim chances of getting
updated this notifies people in advance. Given both Linux and
glibc have axed the target further development is also
Hi!
The following testcase ICEs, because the REDUCE_BIT_FIELD macro uses
the target variable implicitly:
#define REDUCE_BIT_FIELD(expr) (reduce_bit_field \
? reduce_to_bit_field_precision ((expr), \
I would prefer to only keep zvl and scalable or zvl only, since I
don't see too much value in specifying a value which different from
zvl*b, that's a legacy option used before zvl*b option was introduced,
and the reason to add that is that could used for compatible with
clang/LLVM for
Hi!
The PR complains that for the __builtin_stdc_bit_* "builtins" the
diagnostics doesn't mention the name of the builtin the user used, but
instead __builtin_{clz,ctz,popcount}g instead (which is what the FE
immediately lowers it to).
The following patch repeats the checks from
Richard Biener writes:
> The following deprecates ia64*-*-* for GCC 14. Since we plan to
> force LRA for GCC 15 and the target only has slim chances of getting
> updated this notifies people in advance. Given both Linux and
> glibc have axed the target further development is also made
Hi!
The following testcases show 2 bugs in the .{ADD,SUB}_OVERFLOW lowering,
both related to storing of the REALPART_EXPR part of the result.
On the first testcase prec is 255, prec_limbs is 4 and for the second limb
in the loop the store of the REALPART_EXPR of .USUBC (_30) is stored through:
From: Pan Li
This patch would like to introduce one new gcc option for RVV. To
appoint the bits size of one RVV vector register. Valid arguments to
'-mrvv-vector-bits=' are:
* 64
* 128
* 256
* 512
* 1024
* 2048
* 4096
* 8192
* 16384
* 32768
* 65536
* scalable
* zvl
1. The scalable will be the
The following deprecates ia64*-*-* for GCC 14. Since we plan to
force LRA for GCC 15 and the target only has slim chances of getting
updated this notifies people in advance. Given both Linux and
glibc have axed the target further development is also made difficult.
"Tested" for ia64-elf and
81 matches
Mail list logo
