v1 -> v2:
- Add a new test for LoongArch. Check if extensions are omitted
when loading large/huge parameters from the stack.
On Tue, Sep 09, 2025 at 02:18:54PM +0800, Yang Yujie wrote:
> v1 -> v2:
>
> - Add a new test for LoongArch. Check if extensions are omitted
> when loading large/huge parameters from the stack.
Bootstrapped and tested on x86_64-linux-gnu and loongarch64-linux-gnu.
Ok for trunk?
Lower the partial limbs of extended _BitInts like the full limbs for most
operations, so that explicit extensions can be inserted only where they
are really needed.
gcc/ChangeLog:
* gimple-lower-bitint.cc (struct bitint_large_huge): Remove
the abi_load_p parameter of limb_access.
On Tue, Sep 02, 2025 at 04:51:37PM GMT, Jakub Jelinek wrote:
> On Tue, Aug 19, 2025 at 07:37:29PM +0800, Yang Yujie wrote:
> > This patch fixes regressions of the gcc.dg/torture/bitint-* tests
> > caused by r16-3036-ga76a032354ee48 with --enable-checking=all.
> >
> > Th
Lower the partial limbs of extended _BitInts like the full limbs for most
operations, so that explicit extensions can be inserted only where they
are really needed.
gcc/ChangeLog:
* gimple-lower-bitint.cc (struct bitint_large_huge): Remove
the abi_load_p parameter of limb_access.
This patch fixes regressions of the gcc.dg/torture/bitint-* tests
caused by r16-3036-ga76a032354ee48 with --enable-checking=all.
The errors are similar to the following:
../../gcc/testsuite/gcc.dg/torture/bitint-14.c:54:1: error: type mismatch in
'array_ref'
unsigned long
_42 = VIEW_CONVERT_E
-linux-gnu.
Yang Yujie (4):
bitint: Avoid extending ABI-extended large/huge _BitInts on load
bitint: Make sure BEXTC checks extension when optimized
bitint: Zero-extend the result of a signed->unsigned widening cast
bitint: Do not optimize away conversion to _BitInt before a VCE
gcc
On Wed, Aug 06, 2025 at 11:58:09AM GMT, Jakub Jelinek wrote:
> On Wed, Aug 06, 2025 at 05:57:49PM +0800, Yang Yujie wrote:
> > This patch also make casts of ABI-extended large/huge _BitInts
> > behave the same as the small/middle case, i.e. no-op for casts
> > to a higher p
A _BitInt value may rely on a conversion to become properly extended.
So a conversion to _BitInt is not trivially removable even if the
types of the result and the operand have the same precision and size.
This patch fixes gcc.dg/torture/bitint-64.c at -O2 on LoongArch,
which fails because extensi
This patch also make casts of ABI-extended large/huge _BitInts
behave the same as the small/middle case, i.e. no-op for casts
to a higher precision _BitInt with the same number of limbs /
extension for casts that turns a full top limb into a partial limb.
This conveniently helps keep some code with
A widening cast from a signed _BitInt operand to an unsigned _BitInt
type involves filling the extra limb(s) with sign extension.
On a target that wants _BitInts extended in memory, if this unsigned
type has a partial limb, the unused part of it should be zeroed.
e.g. Assuming limb_mode == E_DImod
In BEXTC, whether a _BitInt object is properly extended is examined
by a value comparison against a copied object in a wider _BitInt
type that utilizes all of the partial limb.
Since the (implicit) conversion to the wider type may be optimized
away now and cause the result of the comparison to alw
On Tue, Aug 05, 2025 at 11:58:45AM GMT, Jakub Jelinek wrote:
> On Sat, Aug 02, 2025 at 05:14:21PM +0800, Yang Yujie wrote:
> > In BEXTC, whether a _BitInt object is properly extended is examined
> > by a value comparison against a copied object in a wider _BitInt
> > type tha
On Tue, Aug 05, 2025 at 12:22:17PM GMT, Jakub Jelinek wrote:
> On Sat, Aug 02, 2025 at 05:14:23PM +0800, Yang Yujie wrote:
> > A widening cast from a signed _BitInt operand to an unsigned _BitInt
> > type involves filling the extra limb(s) with sign extension.
> > On a targe
On Tue, Aug 05, 2025 at 12:26:08PM GMT, Jakub Jelinek wrote:
> On Tue, Aug 05, 2025 at 06:21:40PM +0800, Yang Yujie wrote:
> > On Tue, Aug 05, 2025 at 11:49:42AM GMT, Jakub Jelinek wrote:
> > > On Sat, Aug 02, 2025 at 05:14:20PM +0800, Yang Yujie wrote:
> > > > In Lo
On Tue, Aug 05, 2025 at 12:04:56PM GMT, Jakub Jelinek wrote:
> On Sat, Aug 02, 2025 at 05:14:22PM +0800, Yang Yujie wrote:
> > tree
> > -bitint_large_huge::limb_access (tree type, tree var, tree idx, bool
> > write_p)
> > +bitint_large_huge::limb_access (tree typ
On Tue, Aug 05, 2025 at 11:49:42AM GMT, Jakub Jelinek wrote:
> On Sat, Aug 02, 2025 at 05:14:20PM +0800, Yang Yujie wrote:
> > In LoongArch psABI, large _BitInt(N) (N > 64) objects are only
> > extended to fill the highest 8-byte chunk that contains any used bit,
> > but
A widening cast from a signed _BitInt operand to an unsigned _BitInt
type involves filling the extra limb(s) with sign extension.
On a target that wants _BitInts extended in memory, if this unsigned
type has a partial limb, the unused part of it should be zeroed.
e.g. Assuming limb_mode == E_DImod
In BEXTC, whether a _BitInt object is properly extended is examined
by a value comparison against a copied object in a wider _BitInt
type that utilizes all of the partial limb.
Since the (implicit) conversion to the wider type may be optimized
away and cause the result of the comparison to always
This patch adds support for C23's _BitInt for LoongArch.
>From the LoongArch psABI[1]:
> _BitInt(N) objects are stored in little-endian order in memory
> and are signed by default.
>
> For N ≤ 64, a _BitInt(N) object have the same size and alignment
> of the smallest fundamental integral type tha
In LoongArch psABI, large _BitInt(N) (N > 64) objects are only
extended to fill the highest 8-byte chunk that contains any used bit,
but the size of such a large _BitInt type is a multiple of their
16-byte alignment. So there may be an entire unused 8-byte
chunk that is not filled by extension, an
This patch also make casts of ABI-extended large/huge _BitInts
behave the same as the small/middle case, i.e. no-op for casts
to a higher precision _BitInt with the same number of limbs /
extension for casts that turns a full top limb into a partial limb.
This conveniently helps keep some code with
libgcc/ChangeLog:
* config.host: Remove unused code. Include LoongArch-specific
tmake_files after the OS-specific ones.
---
libgcc/config.host | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/libgcc/config.host b/libgcc/config.h
A _BitInt value may rely on a conversion to become properly extended.
So a conversion to _BitInt is not trivially removable even if the
types of the result and the operand have the same precision and size.
This patches fixes gcc.dg/torture/bitint-64.c at -O2 on LoongArch,
which fails because exten
For targets that set the "extended" flag in TARGET_C_BITINT_TYPE_INFO,
we assume small _BitInts to be internally extended after arithmetic
operations. In this case, an extra extension during RTL expansion
can be avoided.
gcc/ChangeLog:
* expr.cc (expand_expr_real_1): Do not call
r
For targets that treat small _BitInts like the fundamental
integral types, we should allow their machine modes to be promoted
in the same way.
gcc/ChangeLog:
* explow.cc (promote_function_mode): Add a case for
small/medium _BitInts.
(promote_mode): Same.
---
gcc/explow.cc
parision of the partial limbs.
This series was bootstrapped and tested on x86_64-linux-gnu and
loongarch64-linux-gnu.
Yang Yujie (9):
bitint: Allow mode promotion of _BitInt types
expand: Reduce unneeded _BitInt extensions
bitint: Allow unused bits when testing extended _BitInt ABIs
bitint:
On Wed, Jul 30, 2025 at 01:07:32PM +0200, Jakub Jelinek wrote:
> On Wed, Jul 30, 2025 at 06:52:40PM +0800, Yang Yujie wrote:
> > I'm OK with your implementation. Just curious, do you mean that
> > memcmp shouldn't be used on "(x)" at all?
>
> If there a
On Wed, Jul 30, 2025 at 12:37:33PM GMT, Jakub Jelinek wrote:
> On Wed, Jul 30, 2025 at 06:24:42PM +0800, Yang Yujie wrote:
> > On Wed, Jul 30, 2025 at 12:19:24PM GMT, Jakub Jelinek wrote:
> > > On Wed, Jul 30, 2025 at 06:15:56PM +0800, Yang Yujie wrote:
> > > > So wo
On Wed, Jul 30, 2025 at 12:19:24PM GMT, Jakub Jelinek wrote:
> On Wed, Jul 30, 2025 at 06:15:56PM +0800, Yang Yujie wrote:
> > So wouldn't it be simpler if I just change the comparison in my patch into
> > a memcmp? This works regardless of how comparison is implemented.
>
On Wed, Jul 30, 2025 at 11:28:11AM GMT, Jakub Jelinek wrote:
> On Wed, Jul 30, 2025 at 04:56:06PM +0800, Yang Yujie wrote:
> > I'm not sure if this is correct, but isn't accessing __x in its own type
> > after do_copy already an undefined behavior?
> >
> > N
On Wed, Jul 30, 2025 at 10:17:42AM GMT, Jakub Jelinek wrote:
> On Wed, Jul 30, 2025 at 10:16:06AM +0200, Jakub Jelinek wrote:
> > Or maybe better
> > _BitInt(PROMOTED_SIZE (x) * __CHAR_BIT__) __x;
> > int __y = S (x);
> > do_copy (&__x, &(x), sizeof (__x));
> > if (__y < PROMOTED_SIZE (x) *
On Wed, Jul 30, 2025 at 09:37:10AM GMT, Jakub Jelinek wrote:
> On Fri, Jul 25, 2025 at 10:53:39AM +0800, Yang Yujie wrote:
> > In BEXTC, whether a _BitInt object is properly extended is examined
> > by a value comparison against a copied object in a wider _BitInt
> > type tha
On Wed, Jul 30, 2025 at 09:29:49AM GMT, Jakub Jelinek wrote:
> On Fri, Jul 25, 2025 at 10:53:37AM +0800, Yang Yujie wrote:
> > +
> >addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (var));
> >if (as != TYPE_ADDR_SPACE (ltype))
> > ltype = build_qualified_typ
libgcc/ChangeLog:
* config.host: Remove unused code. Include LoongArch-specific
tmake_files after the OS-specific ones.
---
libgcc/config.host | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/libgcc/config.host b/libgcc/config.h
This patch adds support for C23's _BitInt for LoongArch.
>From the LoongArch psABI[1]:
> _BitInt(N) objects are stored in little-endian order in memory
> and are signed by default.
>
> For N ≤ 64, a _BitInt(N) object have the same size and alignment
> of the smallest fundamental integral type tha
A _BitInt value may rely on a conversion to become properly extended.
So a conversion to _BitInt is not trivially removable even if the
types of the result and the operand have the same precision and size.
This patches fixes gcc.dg/torture/bitint-64.c at -O2 on LoongArch,
which fails because exten
A widening cast from a signed _BitInt operand to an unsigned _BitInt
type involves filling the extra limb(s) with sign extension.
On a target that wants _BitInts extended in memory, if this unsigned
type has a partial limb, the unused part of it should be zeroed.
e.g. Assuming limb_mode == E_DImod
In LoongArch psABI, large _BitInt(N) (N > 64) objects are only
extended to fill the highest 8-byte chunk that contains any used bit,
but the size of such a large _BitInt type is a multiple of their
16-byte alignment. So there may be an entire unused 8-byte
chunk that is not filled by extension, an
al
limb.
4. Other fixes from Jakub's review on v3.
This series has been bootstrapped and tested on x86_64-linux-gnu,
and tested on loongarch64-linux-gnu (right now bootstrap on LoongArch
do not pass due to some strict checks failing in final.cc).
Yang Yujie (9):
bitint: Allow mode promo
In BEXTC, whether a _BitInt object is properly extended is examined
by a value comparison against a copied object in a wider _BitInt
type that utilizes all of the partial limb.
Since the (implicit) conversion to the wider type may be optimized
away and cause the result of the comparison to always
This patch also make casts of ABI-extended large/huge _BitInts
behave the same as the small/middle case, i.e. no-op for casts
to a higher precision _BitInt with the same number of limbs /
extension for casts that turns a full top limb into a partial limb.
This conveniently helps keep some code with
For targets that set the "extended" flag in TARGET_C_BITINT_TYPE_INFO,
we assume small _BitInts to be internally extended after arithmetic
operations. In this case, an extra extension during RTL expansion
can be avoided.
gcc/ChangeLog:
* expr.cc (expand_expr_real_1): Do not call
r
For targets that treat small _BitInts like the fundamental
integral types, we should allow their machine modes to be promoted
in the same way.
gcc/ChangeLog:
* explow.cc (promote_function_mode): Add a case for
small/medium _BitInts.
(promote_mode): Same.
---
gcc/explow.cc
On Fri, Jun 27, 2025 at 10:00:00AM GMT, Jakub Jelinek wrote:
> On Fri, Jun 27, 2025 at 03:33:35PM +0800, Yang Yujie wrote:
> > @@ -11291,6 +11296,13 @@ expand_expr_real_1 (tree exp, rtx target,
> > machine_mode tmode,
> >type = TREE_TYPE (exp);
> >mode = TYPE_MO
For targets that set the "extended" flag in TARGET_C_BITINT_TYPE_INFO,
we assume small _BitInts to be internally extended after arithmetic
operations. In this case, an extra extension during RTL expansion
can be avoided.
gcc/ChangeLog:
* expr.cc (expand_expr_real_1): Do not call
r
.
(Note: It seems that atomic fetch/op doesn't work for _BitInts even
they have the right size, CAS loop is always used when handling
modification. Fixing this later.)
This series has been bootstrapped and regtested on
loongarch64-linux-gnu and x86_64-linux-gnu.
Yang Yujie (6):
bitint: Allow
This patch adds support for C23's _BitInt for LoongArch.
>From the LoongArch psABI[1]:
> _BitInt(N) objects are stored in little-endian order in memory
> and are signed by default.
>
> For N ≤ 64, a _BitInt(N) object have the same size and alignment
> of the smallest fundamental integral type tha
A _BitInt value may rely on a conversion to become properly extended.
So a conversion to _BitInt is not trivially removable even if the
types of the result and the operand have the same precision and size.
This patches fixes gcc.dg/torture/bitint-64.c at -O2 on LoongArch,
which fails because exten
libgcc/ChangeLog:
* config.host: Remove unused code. Include LoongArch-specific
tmake_files after the OS-specific ones.
---
libgcc/config.host | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/libgcc/config.host b/libgcc/config.h
In LoongArch psABI, large _BitInt(N) (N > 64) objects are only
extended to fill the highest 8-byte chunk that contains any used bit,
but the size of such a large _BitInt type is a multiple of their
16-byte alignment. So there may be an entire unused 8-byte
chunk that is not filled by extension, an
For targets that treat small _BitInts like the fundamental
integral types, we should allow their machine modes to be promoted
in the same way.
gcc/ChangeLog:
* explow.cc (promote_function_mode): Add a case for
small/medium _BitInts.
(promote_mode): Same.
---
gcc/explow.cc
On Thu, Jun 19, 2025 at 12:32:57PM GMT, Jakub Jelinek wrote:
> As mentioned in another mail, please follow what aarch64 is doing here (at
> least unless you explain how it violates your psABI):
> if (n <= 8)
> info->limb_mode = QImode;
> else if (n <= 16)
> info->limb_mode = HImode;
>
On Thu, Jun 19, 2025 at 01:18:10PM GMT, Jakub Jelinek wrote:
> On Thu, Jun 19, 2025 at 07:13:07PM +0800, Yang Yujie wrote:
> > On Thu, Jun 19, 2025 at 12:32:57PM GMT, Jakub Jelinek wrote:
> > > As mentioned in another mail, please follow what aarch64 is doing here (at
>
In LoongArch psABI, large _BitInt(N) (N > 64) objects are only
extended to fill the highest 8-byte chunk that contains any used bit,
but the size of such a large _BitInt type is a multiple of their
16-byte alignment. So there may be an entire unused 8-byte
chunk that is not filled by extension, an
For targets that have extended bitints, we need to ensure these
are extended before writing to the memory, including via atomic
exchange.
gcc/c-family/ChangeLog:
* c-common.cc (resolve_overloaded_atomic_exchange): Extend
_BitInts before atomic exchange if needed.
(resolve_
For targets that set the "extended" flag in TARGET_C_BITINT_TYPE_INFO,
we assume small _BitInts to be internally extended after arithmetic
operations. In this case, an extra extension during RTL expansion
can be avoided.
gcc/ChangeLog:
* expr.cc (expand_expr_real_1): Do not call
r
-bitint.cc,
maybe later.
3. Add symbol versions (GCC_16.0.0) for bitint helper
functions in libgcc.
This series has been bootstrapped and regtested on
loongarch64-linux-gnu and x86_64-linux-gnu.
Yang Yujie (7):
bitint: Allow mode promotion of _BitInt types
bitint: Allow different limb_mode
abi_limb_mode and limb_mode were asserted to be the same when
the target has different endianness for limbs in _BitInts
and words in objects. Otherwise, this assertion also held when the
TYPE_PRECISION of _BitInt type being laid out is less than or equal
to the precision of abi_limb_mode.
But in
libgcc/ChangeLog:
* config.host: Remove unused code. Include LoongArch-specific
tmake_files after the OS-specific ones.
---
libgcc/config.host | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/libgcc/config.host b/libgcc/config.h
This patch adds support for C23's _BitInt for LoongArch.
>From the LoongArch psABI[1]:
> _BitInt(N) objects are stored in little-endian order in memory
> and are signed by default.
>
> For N ≤ 64, a _BitInt(N) object have the same size and alignment
> of the smallest fundamental integral type tha
For targets that treat small _BitInts like the fundamental
integral types, we should allow their machine modes to be promoted
in the same way.
gcc/ChangeLog:
* explow.cc (promote_function_mode): Add a case for
small/medium _BitInts.
(promote_mode): Same.
---
gcc/explow.cc
On Wed, May 21, 2025 at 11:48:08AM GMT, Jakub Jelinek wrote:
> In gimple-lower-bitint.cc I'd strongly prefer to differentiate between
> changes required to get info->extended working correctly (that is what
> should be committed first, and right now should include the LSHIFT_EXPR in
> lower_shift_s
On Wed, May 21, 2025 at 09:21:40AM GMT, Jakub Jelinek wrote:
>
> The existing testsuite never tests whether the padding bits are sign or zero
> extended or contain unknown values.
> In the s390x patch, info->extended is set to true, yet all bitint tests but
> bitint-64.c at -O3 pass.
>
> So, I'm
On Tue, May 20, 2025 at 03:44:09PM GMT, Jakub Jelinek wrote:
> I'd suggest working on it incrementally rather than with a full patch set.
> In one or multiple patches handle the promote_mode stuff, the atomic
> extension and expr.cc changes with the feedback incorporated.
Ok.
> For gimple-lower-b
On Tue, May 20, 2025 at 09:55:04PM GMT, Xi Ruoyao wrote:
> On Tue, 2025-05-20 at 15:44 +0200, Jakub Jelinek wrote:
> > > Specifically, the tests told me to extend (thought "truncate"
> > > was kind of an equivalent word) the output of left shift, plus/minus,
> >
> > Truncation is the exact opposit
Hi Jakub,
Thanks for the quick review.
Aside from code formatting issues, can I conclude that you suggest
we should rebase this onto your new big-endian support patch? Or
do you think it's necessary to add big-endian && extended support
together?
> Are you sure all those changes were really nec
o be made to gimple lowering
and expand.
This series has been bootstrapped and regtested with x86_64-linux-gnu and
loongarch64-linux-gnu (against a version that leaves the partial limbs
undefined).
Please help us find if there's something we've missed.
Thanks,
Yujie
Yang Yujie (3):
The padding bits of _BitInt(N) are undefined in the x86-64 and
the aarch64 ABI. In general, the current lowering and expand process
perform truncations when taking a _BitInt value as input,
while leaving them as-is in the output.
By adding truncation on the output side, we can define psABIs
(e.g.
gcc/ChangeLog:
* stor-layout.cc (layout_type): Allow limb_mode to be DImode
while abi_limb_mode is TImode for _BitInt(N), N > 64.
---
gcc/stor-layout.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
index 18b5af56124.
This patch adds support for C23's _BitInt for LoongArch.
Though there's not an official psABI definition, our plan
is to have 16-byte alignment for N > 64 and the padding bits
sign/zero-extended when passed between procedures.
One exception would be "unsigned _BitInt(32)". To match the
behavior o
Tested with nawk, mawk, and gawk.
gcc/ChangeLog:
* config/loongarch/genopts/gen-evolution.awk: remove
usage of "asort".
* config/loongarch/genopts/genstr.sh: replace sed with awk.
---
.../loongarch/genopts/gen-evolution.awk | 12 +++-
gcc/config/loongarch/genopts/ge
gcc/ChangeLog:
* config/loongarch/genopts/gen-evolution.awk: Do not use
"length()" to compute the size of an array.
---
gcc/config/loongarch/genopts/gen-evolution.awk | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/config/loongarch/genopts/gen-evolut
Builds for the LoongArch target fail if the system "awk" is not "gawk".
This patch removes this unnecessary requirement.
Thanks to Jan-Benedict Glaw for finding and reporting
this issue.
Yang Yujie (1):
LoongArch: Remove gawk extension from a generator script.
gcc/conf
v1 -> v2:
- Fixed build issues of runtime libraries caused by the new header.
- Restored the default ARCH of lp64f/lp64s ABI to "abi-default".
v2 -> v3:
- Fixed libobjc build.
- Modify "LoongArch v1.1 features" to "LoongArch v1.1 instructions"
in invoke.texi.
v3 -> v4:
- Do not define __loongarc
These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
* config.gcc: Add loongarch-evolution.o.
* config/loongarch/genopts/genstr.sh: Enable generation of
v1 -> v2:
- Fixed build issues of runtime libraries caused by the new header.
- Restored the default ARCH of lp64f/lp64s ABI to "abi-default".
v2 -> v3:
- Fixed libobjc build.
- Modify "LoongArch v1.1 features" to "LoongArch v1.1 instructions"
in invoke.texi.
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
* config.gcc: Add loongarch-evolution.o.
* config/loongarch/genopts/genstr.sh: Enable generation of
These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
v1 -> v2:
- Fixed build issues of runtime libraries caused by the new header.
- Restored the default ARCH of lp64f/lp64s ABI to "abi-default".
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
* config.gcc: Add loongarch-evolution.o.
* config/loongarch/genopts/genstr.sh: Enable generation of
These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
On Fri, Apr 19, 2024 at 07:34:33PM +0800, Xi Ruoyao wrote:
> On Fri, 2024-04-19 at 19:04 +0800, Yang Yujie wrote:
> > These ISA versions are defined as -march= parameters and
> > are recommended for building binaries for distribution.
> >
> > Detailed description of the
These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.
gcc/ChangeLog:
* config.gcc: Add loongarch-evolution.o.
* config/loongarch/genopts/genstr.sh: Enable generation of
On Mon, Apr 08, 2024 at 04:49:58PM +0800, Xi Ruoyao wrote:
> On Mon, 2024-04-08 at 16:46 +0800, Yang Yujie wrote:
> > v1 -> v2:
> > Remove spaces from changelog.
>
> I've rebuilt the base system with a GCC including this patch. LTO+PGO
> bootstrap fine, regtes
v1 -> v2:
Remove spaces from changelog.
This patch fixes the back-end context switching in cases where functions
should be built with their own target contexts instead of the
global one, such as LTO linking and functions with target attributes (TBD).
PR target/113233
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loon
On Sun, Apr 07, 2024 at 08:56:53PM +0800, Xi Ruoyao wrote:
> On Sun, 2024-04-07 at 15:47 +0800, Yang Yujie wrote:
> > * config/loongarch/loongarch-builtins.cc
> > (loongarch_init_builtins):
> > Initialize all builtin functions at startup.
>
> git gcc-verif
On Sun, Apr 07, 2024 at 04:23:53PM +0800, Xi Ruoyao wrote:
> On Sun, 2024-04-07 at 15:47 +0800, Yang Yujie wrote:
> > This patch fixes the back-end context switching in cases where functions
> > should be built with their own target contexts instead of the
> > global one, su
This patch fixes the back-end context switching in cases where functions
should be built with their own target contexts instead of the
global one, such as LTO linking and functions with target attributes (TBD).
PR target/113233
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loon
gcc/ChangeLog:
* config/loongarch/t-loongarch: Add loongarch-def-arrays.h
to OPTION_H_EXTRA.
---
gcc/config/loongarch/t-loongarch | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/config/loongarch/t-loongarch b/gcc/config/loongarch/t-loongarch
index 3dd7
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Mark -m[no-]recip as
aliases to -mrecip={all,none}, respectively.
* config/loongarch/loongarch.opt: Regenerate.
* config/loongarch/loongarch-def.h (ABI_FPU_64): Rename to...
(ABI_FPU64_P): ...this.
v1 -> v2:
- Rebased to master.
- Specifies "(void)" for the empty parameter list of loongarch_global_init.
v2 -> v3:
- Keep the original option-processing behavior (-march=la664 enables
-mrecip=all)
and fix the ICE when -mfrecipe is not passed with -mrecip.
v3 -> v4:
- Rewrite changelog.
gcc/ChangeLog:
* config.gcc: Add a case for loongarch*-*-linux-musl*.
* config/loongarch/linux.h: Disable the multilib-compatible
treatment for *musl* targets.
* config/loongarch/musl.h: New file.
---
gcc/config.gcc | 3 +++
gcc/config/loongarch/linu
v1 -> v2:
- Rebased to master.
- Specifies "(void)" for the empty parameter list of loongarch_global_init.
v2 -> v3:
- Keep the original option-processing behavior (-march=la664 enables
-mrecip=all)
and fix the ICE when -mfrecipe is not passed with -mrecip.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Mark -m[no-]recip as
aliases to -mrecip={all,none}.
* config/loongarch/loongarch.opt: Same.
* config/loongarch/loongarch-def.h: Modify ABI condition macros for
convenience.
* config/loongarc
v1 -> v2:
- Rebased to master.
- Specifies "(void)" for the empty parameter list of loongarch_global_init.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Mark -m[no-]recip as
aliases to -mrecip={all,none}.
* config/loongarch/loongarch.opt: Same.
* config/loongarch/loongarch-def.h: Modify ABI condition macros for
convenience.
* config/loongarc
1 - 100 of 191 matches
Mail list logo
