https://gcc.gnu.org/g:788ccd269e0c32c33ce0c1359137fe1b35dc7a2d
commit r14-10205-g788ccd269e0c32c33ce0c1359137fe1b35dc7a2d
Author: Jonathan Wakely
Date: Thu Apr 11 15:35:11 2024 +0100
libstdc++: Update ABI test to disallow adding to released symbol versions
If we update the list
Hello.
This is a draft FDPIC ABI specification for the Xtensa architecture.
Please send comments. I will be implementing the final ABI version in
gcc and binutils.
The Xtensa FDPIC ABI
April 8, 2024
Version 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #5 from Trevor Gross ---
Looks like bugz cut off part of the sysv quote, here for reference:
> Arguments of types __float128, _Decimal128 and __m128 are split
> into two halves. The least significant ones belong to class SSE, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #4 from Trevor Gross ---
To my knowledge, MSVC does not support or specify an ABI for 16- or 128-bit
IEEE floating point types, so I do suppose that either GCC or Clang could be
considered correct here.
SysV doesn't say anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #3 from Andrew Pinski ---
https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#parameter-passing
So it uses floating point as the type. But then it is vague on those kind of
type. Gcc treats _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #2 from Andrew Pinski ---
Does Microsoft's abi documents this case?
If not then gcc is as correct here as clang is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #1 from Andrew Pinski ---
What does msvc do?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
Bug ID: 115054
Summary: __float128 and _Float16 use incorrect ABI on x86-64
MinGW
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/g:7c0daba10e43586df2ede9cd4037c50b85648e6a
commit 7c0daba10e43586df2ede9cd4037c50b85648e6a
Author: Nobel Singh
Date: Fri Jan 19 20:51:34 2024 +0545
Set the default ABI to C for extern blocks and extern functions
Previously, the default ABI was set to Rust
https://gcc.gnu.org/g:b9415046fa27d6b3faea89871dbb84b673afadaf
commit r15-288-gb9415046fa27d6b3faea89871dbb84b673afadaf
Author: Zac Walker
Date: Thu Apr 11 13:30:27 2024 +0200
aarch64: Mark x18 register as a fixed register for MS ABI
Define the MS ABI for aarch64-w64-mingw32
https://gcc.gnu.org/g:327a285500ac640f1d8257d11ea56bf4ab65ee47
commit 327a285500ac640f1d8257d11ea56bf4ab65ee47
Author: Pierre-Emmanuel Patry
Date: Mon Sep 4 14:23:10 2023 +0200
Change ABI setup and add gccrs_proc_macro attr
Change the way the ABI is setup on a function to avoid
Tested x86_64-linux. Pushed to trunk.
-- >8 --
If we update the list of "active" symbols versions now, rather than when
adding a new symbol version, we will notice if new symbols get added to
the wrong version (as in PR 114692).
libstdc++-v3/ChangeLog:
*
https://gcc.gnu.org/g:6e25ca387fbbb412a2e498e28ea5db28e033a318
commit r15-277-g6e25ca387fbbb412a2e498e28ea5db28e033a318
Author: Jonathan Wakely
Date: Thu Apr 11 15:35:11 2024 +0100
libstdc++: Update ABI test to disallow adding to released symbol versions
If we update the list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
Richard Biener changed:
What|Removed |Added
Target Milestone|14.0|14.2
--- Comment #3 from Richard
https://gcc.gnu.org/g:ad30265ccfb211fca35789df2d1404cc12302219
commit r15-98-gad30265ccfb211fca35789df2d1404cc12302219
Author: Nathaniel Shead
Date: Tue Apr 16 22:50:26 2024 +1000
c++: Implement modules ABI for vtable emissions
This patch implements the changes described
On 5/1/24 04:37, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This patch implements the changes described in
https://github.com/itanium-cxx-abi/cxx-abi/pull/171.
One restriction that is lifted in the ABI that hasn't been updated h
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This patch implements the changes described in
https://github.com/itanium-cxx-abi/cxx-abi/pull/171.
One restriction that is lifted in the ABI that hasn't been updated here
is that the ABI no longer requires unique vtab
https://gcc.gnu.org/g:7ef60541a89b2e7b3585df434d14010396769ca2
commit 7ef60541a89b2e7b3585df434d14010396769ca2
Author: Alexandre Oliva
Date: Sun Apr 21 17:24:30 2024 -0300
add explicit ABI and align options to pr88233.c
We've observed failures of this test on powerpc
https://gcc.gnu.org/g:895bb1b2eb82e76d3bfc48bf35a0bbafae82d873
commit r11-11341-g895bb1b2eb82e76d3bfc48bf35a0bbafae82d873
Author: Matt Jacobson
Date: Thu Jul 29 09:57:23 2021 +0100
Objective-C: Default flag_objc_sjlj_exceptions off for NeXT ABI >= 2.
Signed-off-by: Matt Jacob
https://gcc.gnu.org/g:30e8256702cc4dfb56d329ee279e957a10fc962b
commit 30e8256702cc4dfb56d329ee279e957a10fc962b
Author: Alexandre Oliva
Date: Sun Apr 21 17:24:30 2024 -0300
add explicit ABI and align options to pr88233.c
We've observed failures of this test on powerpc
https://gcc.gnu.org/g:68e3d62f56eea3a5fa798ec514bd89ddc6668c4a
commit 68e3d62f56eea3a5fa798ec514bd89ddc6668c4a
Author: Alexandre Oliva
Date: Sun Apr 21 17:24:30 2024 -0300
add explicit ABI and align options to pr88233.c
We've observed failures of this test on powerpc
The branch 'aoliva/heads/testme' was updated to point to:
68e3d62f56e... add explicit ABI and align options to pr88233.c
It previously pointed to:
edf330eeb9d... [testsuite] [powerpc] adjust -m32 counts for fold-vec-extra
Diff:
!!! WARNING: THE FOLLOWING COMMITS ARE NO LONGER ACCESSIBLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114417
--- Comment #11 from Imple Lee ---
> What you want to use instead is std::experimental::simd_abi::deduce_t.
> That'll give you a not-fixed_size ABI if one exists. And those will likely be
> passed via registers (as long as the psA
|UNCONFIRMED |RESOLVED
--- Comment #10 from Matthias Kretz (Vir) ---
Here's your example with the simd_abi::compatible ABI tag:
https://godbolt.org/z/WbWr75EGW
This is all working as intended. Note that no such ABI-stable ABI tag is
currently planned for the TS merge to C++26. So I
or registers. That's beyond the abstract
machine. It still asks for that behavior non-normatively, though.
What you want to use instead is std::experimental::simd_abi::deduce_t.
That'll give you a not-fixed_size ABI if one exists. And those will likely be
passed via registers (as long as the psABI allows).
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566530.html
(modified version follows)
We've observed failures of this test on powerpc configurations that
default to different calling conventions and alignment requirements.
Both settings are needed for the original expectations to be
https://gcc.gnu.org/g:c5fbacee0313fb1b760a870964877f343bf4b90e
commit c5fbacee0313fb1b760a870964877f343bf4b90e
Author: Alexandre Oliva
Date: Sun Apr 21 17:24:30 2024 -0300
add explicit ABI and align options to pr88233.c
We've observed failures of this test on powerpc
https://gcc.gnu.org/g:387ce53fd3fdaeefc7dc9d603df0d66495580fbf
commit 387ce53fd3fdaeefc7dc9d603df0d66495580fbf
Author: Alexandre Oliva
Date: Sun Apr 21 17:24:30 2024 -0300
add explicit ABI and align options to pr88233.c
We've observed failures of this test on powerpc
https://gcc.gnu.org/g:c3999e0292deb3c5f3c8ccc8ddccc21da4ef3644
commit c3999e0292deb3c5f3c8ccc8ddccc21da4ef3644
Author: Alexandre Oliva
Date: Sun Apr 21 17:24:30 2024 -0300
add explicit ABI and align options to pr88233.c
We've observed failures of this test on powerpc
The branch 'aoliva/heads/testme' was updated to point to:
c3999e0292d... add explicit ABI and align options to pr88233.c
It previously pointed to:
b6144ccafe3... [testsuite] [powerpc] adjust -m32 counts for fold-vec-extra
Diff:
!!! WARNING: THE FOLLOWING COMMITS ARE NO LONGER ACCESSIBLE
https://gcc.gnu.org/g:89e5150772d91d129fd4a8ca6ebda361e546
commit 89e5150772d91d129fd4a8ca6ebda361e546
Author: Alexandre Oliva
Date: Sun Apr 21 17:24:30 2024 -0300
add explicit ABI and align options to pr88233.c
We've observed failures of this test on powerpc
https://gcc.gnu.org/g:4c6efa350d11a66674d85046cc7b7cbc69f6dbe1
commit 4c6efa350d11a66674d85046cc7b7cbc69f6dbe1
Author: Alexandre Oliva
Date: Tue Apr 16 01:26:20 2024 -0300
[libstdc++] introduce --disable-compat-libstdcxx-abi
A number of libstdc++ tests that implicitly instantiate
On Apr 16, 2024, Jonathan Wakely wrote:
>> +dnl
>> +dnl Enable -Wabi=2 if not overridden by --disable-compat-libstdcxx-abi.
>> +dnl
>> +AC_DEFUN([GLIBCXX_ENABLE_WABI], [
>> + # Default.
>> + WARN_FLAGS_WABI=\ -Wabi=2
>> + AC_MSG_CH
ls to load modules containing
> them), and because creating such modules doesn't involve final
> linking, only -r linking. The vague-linkage weak defs with abi-v2
> mangling that get discarded from floating_to_chars.o because the same
> comdat section is present in the main executab
involve final
linking, only -r linking. The vague-linkage weak defs with abi-v2
mangling that get discarded from floating_to_chars.o because the same
comdat section is present in the main executable. But since the
alternate mangling is not defined in the main executable, the weak
definition decays
From: Zac Walker
Date: Thu, 11 Apr 2024 13:30:27 +0200
Subject: [PATCH v3 02/12] aarch64: Mark x18 register as a fixed register for
MS ABI
Define the MS ABI for aarch64-w64-mingw32.
Adjust FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and
STATIC_CHAIN_REGNUM for AArch64 MS ABI.
The X18 register
Evgeny Karpov writes:
> From: Zac Walker
> Date: Fri, 1 Mar 2024 09:56:59 +0100
> Subject: [PATCH v2 03/13] aarch64: Mark x18 register as a fixed register for
> MS ABI
>
> Define the MS ABI for aarch64-w64-mingw32.
> Adjust FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and
https://gcc.gnu.org/g:3a787e038fe3549d6ec9ec9aa6416dcbba664fd9
commit r14-9890-g3a787e038fe3549d6ec9ec9aa6416dcbba664fd9
Author: Andre Vieira
Date: Wed Apr 10 16:29:21 2024 +0100
aarch64: Do not give ABI change diagnostics for _BitInt(N)
This patch makes sure we do not give ABI
"Andre Vieira (lists)" writes:
> @@ -6907,6 +6938,11 @@ aarch64_layout_arg (cumulative_args_t pcum_v, const
> function_arg_info )
> && (!alignment || abi_break_gcc_9 < alignment)
> && (!abi_break_gcc_13 || alignment < abi_break_gcc_13));
>
> + /* _BitInt(N) was only
regards,
Andre
On 28/03/2024 12:54, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
This patch makes sure we do not give ABI change diagnostics for the ABI
breaks of GCC 9, 13 and 14 for any type involving _BitInt(N), since that
type did not exist before this GCC version.
/abi doesn't test |x86_64/abi should add tests
|__float128, __int128 nor|__float128, __int128 and
|DFP |DFP
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from
"Andre Vieira (lists)" writes:
> This patch makes sure we do not give ABI change diagnostics for the ABI
> breaks of GCC 9, 13 and 14 for any type involving _BitInt(N), since that
> type did not exist before this GCC version.
>
> ChangeLog:
>
>
This patch makes sure we do not give ABI change diagnostics for the ABI
breaks of GCC 9, 13 and 14 for any type involving _BitInt(N), since that
type did not exist before this GCC version.
ChangeLog:
* config/aarch64/aarch64.cc (bitint_or_aggr_of_bitint_p): New function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94485
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94485
--- Comment #11 from Andrew Pinski ---
SRA in 10.2.0:
```
Created a replacement for D.14474 offset: 0, size: 64: SR.70D.14479
Created a replacement for D.14475 offset: 0, size: 64: SR.71D.14480
Removing load: D.13665 = D.14475;
```
in 10.3.0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94485
--- Comment #10 from Sam James ---
ok, on godbolt, 8.5 fails. I think we're fine here then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94485
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109813
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
in in extract_insn, at |ICE with BF16 on ARM with
|recog.cc:2791 on ARM with |-mfloat-abi=soft
|-mflip-thumb|-march=armv6
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #4 from Eric Botcazou ---
My reading is that the ABI has overlooked this case though, so it is up to the
implementation to make its opinion. That of the vendor's compiler is probably
more in line with the spirit of the calling
Jiang An ---
There're comments saying:
> // The following ensures, function arguments are passed via the stack.
> // This is important for ABI compatibility across TU boundaries
I have no idea about why this was considered outweighting trivial copyability.
b=HEAD#l27):
...
* The fixed_size ABI gives the following guarantees:
* - simd objects are passed via the stack
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114417
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
is
|parameters are passed by|not a POD (by ABI
|memory on x64 , not using |definitions) and is always
|the available sse registers |passed by reference instead
||of by value
Component|target
pretty clear that the %o[0-5] registers are only
for non-fp parameter slots, while the first could be interpreted either
way (fp *fields only* or fp fields in general).
While compatibility with the vendor compiler is a strong argument, in
the end the ABI remains the reference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #1 from Rainer Orth ---
Created attachment 57757
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57757=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
Bug ID: 114416
Summary: SPARC V9 struct return with floating-point members
violates ABI
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/g:e35b26c2442b61e7f45deb5ef3062d0ab6ec584b
commit r12-10257-ge35b26c2442b61e7f45deb5ef3062d0ab6ec584b
Author: Jonathan Wakely
Date: Tue Jan 31 22:32:15 2023 +
libstdc++: Define std::basic_stringbuf::view() for old std::string ABI
Unlike the new str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759
--- Comment #17 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #15)
Iain, any chance of addressing this one?
If would have really helped with quite a number of usable software for PowerPC
(majority of which are 32-bit, and even
On Sat, 9 Mar 2024 at 12:18, Jonathan Wakely wrote:
>
>
>
> +template
>> + __wait_result_type
>> + __wait_for(const __platform_wait_t* __addr, __wait_args __args,
>> +const chrono::duration<_Rep, _Period>& __rtime) noexcept
>> +{
>> + if (!__rtime.count())
On Thu, 16 Nov 2023 at 13:49, Jonathan Wakely wrote:
> From: Thomas Rodgers
>
> These two patches were written by Tom earlier this year, before he left
> Red Hat. We should finish reviewing them for GCC 14 (and probably squash
> them into one?)
>
> Tom, you mentioned further work that changes
From: Zac Walker
Date: Fri, 1 Mar 2024 09:56:59 +0100
Subject: [PATCH v2 03/13] aarch64: Mark x18 register as a fixed register for
MS ABI
Define the MS ABI for aarch64-w64-mingw32.
Adjust FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and
STATIC_CHAIN_REGNUM for AArch64 MS ABI.
The X18 register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110320
Jeevitha changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
In user mode on Windows, it points to TEB (Thread Environment Block).
more information here
https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers
https://learn.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-teb
Regards,
Evgeny
pports the ABI, Wine should just work
with it, in theory. I didn't try it, but I don't see things like vararg support
in this patchset nor in the repo, so I assume it won't work yet.
Thanks for the work!
Jacek
This change has been refactored based on the review and will be included in v2.
Original aarch64.h will remain unchanged, and the required definition for MS
ABI will be implemented in aarch64-abi-ms.h. The reference to this file will be
added to config.gcc.
This change has been verified
define CALL_USED_X18 1
> +#endif
>
> I'm not overly keen on ifdefs like this (and the one below), it can get quite
> confusing if we have to support more than a couple of ABIs. Perhaps we could
> create a couple of new headers, one for the EABI (which all existing targets
> would the
to include) and one for the MS ABI. Then the mingw port would
use that instead of the EABI header.
An alternative is to make all this dynamic, based on the setting of the
aarch64_calling_abi enum and to make the adjustments in
aarch64_conditional_register_usage.
Dynamically might be needed also if we
ve to support more than a couple of ABIs. Perhaps
>> we could create a couple of new headers, one for the EABI (which all
>> existing targets would then need to include) and one for the MS ABI. Then
>> the mingw port would use that instead of the EABI header.
>>
>>
g targets
> would then need to include) and one for the MS ABI. Then the mingw port
> would use that instead of the EABI header.
>
> An alternative is to make all this dynamic, based on the setting of the
> aarch64_calling_abi enum and to make the adjustments in
> aarch64_condit
Hi Richard,
Thanks for the review!
TARGET_ARM64_MS_ABI refers to the official Microsoft ARM64 ABI naming used for
the target.
If AARCH64 is a more preferred name, it will be changed in PATCH v2.
https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170
Regards
On 21/02/2024 18:30, Evgeny Karpov wrote:
>
+ tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"
I missed this on first reading...
The GCC port name uses AARCH64, please use that internally rather than other
names. The only time when we should be using ARM64 is when it's needed for
can get quite
confusing if we have to support more than a couple of ABIs. Perhaps we could
create a couple of new headers, one for the EABI (which all existing targets
would then need to include) and one for the MS ABI. Then the mingw port would
use that instead of the EABI header.
An alternat
From 72ca3f49e3eef9b18946b8d4e77019c1441e1a97 Mon Sep 17 00:00:00 2001
From: Zac Walker
Date: Tue, 20 Feb 2024 15:30:33 +0100
Subject: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for
MS ABI
Define the MS ABI for aarch64-w64-mingw32.
Adjust FIXED_REGISTERS
From: Nobel Singh
Previously, the default ABI was set to Rust, which is not correct for
extern blocks and extern functions. This patch changes the default
ABI to C for these cases.
gcc/rust/ChangeLog:
* hir/rust-ast-lower-base.cc (ASTLoweringBase::lower_qualifiers):
Change
From: Nobel Singh
Previously, the default ABI was set to Rust, which is not correct for
extern blocks and extern functions. This patch changes the default
ABI to C for these cases.
gcc/rust/ChangeLog:
* hir/rust-ast-lower-base.cc (ASTLoweringBase::lower_qualifiers):
Change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113608
--- Comment #2 from JuzheZhong ---
vuint16m2_t vadd(vuint16m2_t a, vuint8m1_t b) {
int vl = __riscv_vsetvlmax_e8m1();
vuint16m2_t c = __riscv_vzext_vf2_u16m2(b, vl);
return __riscv_vadd_vv_u16m2(a, c, vl);
}
ed 32-bit time_t.
> +// This internal glibc macro will be defined iff new 64-bit time_t is in
> use.
This is correct for current glibc releases, but in glibc master
__USE_TIME_BITS64 is defined unconditionally to 0 or 1 and tells you the size
of time_t, not whether it switched to 64-bit counter to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #1 from Jonathan Wakely ---
Maybe something like this:
diff --git a/libstdc++-v3/config/os/gnu-linux/os_defines.h
b/libstdc++-v3/config/os/gnu-linux/os_defines.h
index 0af29325388..f7c73560831 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112846
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: Tue Jan 30 12:07:21 2024 -0500
testsuite: fix anon6 mangling [PR112846]
As with r14-6796-g2fa122cae50cd8, avoid mangling compatibility aliases in
mangling tests, and test the new mangling.
PR c++/112846
gcc/testsuite/ChangeLog:
* g++.dg/abi/anon6.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112846
Jason Merrill changed:
What|Removed |Added
Last reconfirmed||2024-01-30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113451
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
: Tue Jan 30 11:36:53 2024 -0500
testsuite: mangle-reparm1a options [PR113451]
When I added -fabi-compat-version=8 to avoid mangling aliases it also
suppressed the -Wabi warning.
PR c++/113451
gcc/testsuite/ChangeLog:
* g++.dg/abi/mangle-regparm1a.C: Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113451
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
= a[i] + b5[i]
>+ a[i] * a2[i] * a3[i] * a4[i] * a5[i] * c[i] * c2[i] * c3[i]
>* c4[i] * c5[i] * d[i] * d2[i] * d3[i] * d4[i] * d5[i];
> }
> return vector;
> }
>
> This case will have vector spills after enabling default vector ABI.
Thes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113608
Bug ID: 113608
Summary: RISC-V: Vector spills after enabling vector abi
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113538
Yanzhang, Wang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Committed, thanks Juzhe.
Pan
From: juzhe.zhong
Sent: Thursday, January 25, 2024 9:08 PM
To: Wang, Yanzhang
Cc: gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; Li, Pan2
; Wang, Yanzhang
Subject: Re: [PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]
lgtm
Replied Message
25 21:06:09 2024 +0800
RISC-V: remove param riscv-vector-abi. [PR113538]
Also adjust some of the tests for scan-assembly. The behavior is the
same as --param=riscv-vector-abi before.
gcc/ChangeLog:
PR target/113538
* config/riscv/riscv.cc
lgtm Replied Message Fromyanzhang.w...@intel.comDate01/25/2024 21:06 Togcc-patches@gcc.gnu.org Ccjuzhe.zh...@rivai.ai,kito.ch...@sifive.com,pan2...@intel.com,yanzhang.w...@intel.comSubject[PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]
From: Yanzhang Wang
Also adjust some of the tests for scan-assembly. The behavior is the
same as --param=riscv-vector-abi before.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag.
(riscv_fntype_abi): Ditto.
* config/riscv/riscv.opt: Ditto
From: Yanzhang Wang
Also adjust some of the tests for scan-assembly. The behavior is the
same as --param=riscv-vector-abi before.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag.
(riscv_fntype_abi): Ditto.
* config/riscv/riscv.opt: Ditto
.li; yanzhang.wang
Subject: [PATCH] RISC-V: remove param riscv-vector-abi. [PR113538]
From: Yanzhang Wang
Ran a full test to adjust some of the tests for scan-assembly. The
behavior is the same as --param=riscv-vector-abi before.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info
From: Yanzhang Wang
Ran a full test to adjust some of the tests for scan-assembly. The
behavior is the same as --param=riscv-vector-abi before.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag.
(riscv_fntype_abi): Ditto.
* config/riscv
> I suppose the frontend could simply not allow changing the M2 language
> "long double" (however it is called) with -mabi=... (which really only
> change the C language ABI!). Of course calls to libm are subject to the
> C language ABI.
ok yes. So m2's longreal data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113538
Bug ID: 113538
Summary: [RISC-V] --param=riscv-vector-abi will fail some cases
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
||ABI
--- Comment #1 from Richard Biener ---
There's also the question on compatibility to libgm2 from GCC 13.
I suppose the frontend could simply not allow changing the M2 language
"long double" (however it is called) with -mabi=... (which really only
change the C la
1 - 100 of 4998 matches
Mail list logo
