Le 22/06/2023 à 22:23, Harald Anlauf via Fortran a écrit :
Dear all,
gfortran's ABI specifies that actual arguments to CHARACTER(LEN=1),VALUE
dummy arguments are passed by value in the scalar case. That did work
for constant strings being passed, but not in several other cases, where
pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #8 from Mikael Morin ---
(In reply to anlauf from comment #6)
> (In reply to Mikael Morin from comment #4)
>
> > Looks good.
> > I would suggest to create an overload that avoids duplicating the
> > build_int_cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #7 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-June/059503.html
Dear all,
gfortran's ABI specifies that actual arguments to CHARACTER(LEN=1),VALUE
dummy arguments are passed by value in the scalar case. That did work
for constant strings being passed, but not in several other cases, where
pointers were passed, resulting in subsequent random junk
character(kind=1)[1:1], integer(kind=8));
> > static integer(kind=4) a = 65;
> >
> > val ("A", 1);
> > {
> > character(kind=1) char.1;
> >
> > char.1 = (character(kind=1)) a;
> > val (, 1);
> > }
> >
> &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #5 from Mikael Morin ---
This is out of the scope of this PR, but in the [character, value, bind(c)]
case, only constant values and variables are supported?
er(kind=1) char.1;
>
> char.1 = (character(kind=1)) a;
> val (, 1);
> }
>
> Clearly, the second case is inconsistent with the ABI, see the prototype, and
>
Yes, but it's not worse than the first one: "A" is a pointer, not a value.
I would say that it is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Attachment #55380|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #2 from anlauf at gcc dot gnu.org ---
For reference: testcase, cross-checked with NAG 7.1:
! { dg-do run }
! PR fortran/110360
program p
implicit none
character, allocatable :: ca
character, pointer :: cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 55380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55380=edit
Patch
The attached patch fixes up the case of non-constant string expressions passed
to CHARACTER,VALUE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
Bug ID: 110360
Summary: ABI issue with character,value dummy argument
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
LGTM. Thanks.
juzhe.zh...@rivai.ai
From: shiyulong
Date: 2023-06-21 15:39
To: gcc-patches
CC: palmer; kito.cheng; jeffreyalaw; juzhe.zhong; pan2.li; wuwei2016; jiawei;
shihua; dje.gcc; pinskia; yulong
Subject: [PATCH V1] RISC-V:Add float16 tuple type abi
From: yulong
gcc/ChangeLog
From: yulong
gcc/ChangeLog:
* config/riscv/vector.md: Add float16 attr at sew、vlmul and ratio.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/abi-10.c: Add float16 tuple type case.
* gcc.target/riscv/rvv/base/abi-11.c: Ditto.
* gcc.target/riscv/rvv/base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110320
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jeevitha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110320
Bug ID: 110320
Summary: ELFv2 pc-rel ABI extension allows using r2 as a
volatile register
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110236
Bug ID: 110236
Summary: RFE: LoongArch: Supporting assembly output with
register aliases in ELF ABI
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
Rainer Orth changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
|`a` registers on RISC-V.|prevent using `reg` for
||ABI-mandated roles
||(argument register etc) and
||the behavior should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-06-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
it to also be defined non-inline in
the library, leading to an abi-check failure for (at least) sparc and
aarch64.
Suppress the definition in the library if long double and _Float128 have
are both IEEE binary128.
libstdc++-v3/ChangeLog:
PR libstdc++/110077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #2 from Jonathan Wakely ---
I'm testing this fix:
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -1325,7 +1325,8 @@ _ZSt10from_charsPKcS0_RDF128_St12chars_format(const
"CXXABI_1.3.12");
>> > known_versions.push_back("CXXABI_1.3.13");
>> > - known_versions.push_back("CXXABI_1.3.14");
>> > + known_versions.push_back("CXXABI_1.3.15");
>>
>> Did you really want to
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
In r14-1583-g192665feef7129 I meant to add CXXABI_1.3.15 but instead I
replaced CXXABI_1.3.14 with it. This restores the CXXABI_1.3.14 version.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_abi.cc
On Wed, 7 Jun 2023 at 05:43, François Dumont wrote:
>
> On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote:
> > Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > Add the recently added CXXABI_1.3.15 version. Also remove two "frozen"
> > versions from the
On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote:
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
Add the recently added CXXABI_1.3.15 version. Also remove two "frozen"
versions from the latestp list, as no more symbols should be added to
those now.
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
Add the recently added CXXABI_1.3.15 version. Also remove two "frozen"
versions from the latestp list, as no more symbols should be added to
those now.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_abi.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
Jonathan Wakely changed:
What|Removed |Added
Target|*-*-solaris2.11 |*-*-solaris2.11
|
Last reconfirmed||2023-06-01
Known to fail||14.0
Keywords||ABI
Status|UNCONFIRMED |ASSIGNED
Priority|P3 |P1
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
Bug ID: 110077
Summary: [14 regression] libstdc++-abi/abi_check FAILs on
Solaris
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
On Thu, 1 Jun 2023 10:53:02 +0530
Ajit Agarwal via Gcc-patches wrote:
> Hello All:
>
> This new version of patch 4 use improve ree pass for rs6000 target using
> defined ABI interfaces.
> Bootstrapped and regtested on power64-linux-gnu.
>
> Review comments incorp
Hello All:
This new version of patch 4 use improve ree pass for rs6000 target using
defined ABI interfaces.
Bootstrapped and regtested on power64-linux-gnu.
Review comments incorporated.
Thanks & Regards
Ajit
Improve ree pass for rs6000 target using defined abi interfaces
For rs6000 ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|11.4|11.5
--- Comment #11 from Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110013
--- Comment #2 from Devin Hussey ---
Scratch that. There is a somewhat easy way to fix this following psABI AND
using MMX with SSE.
Upon calling a function, we can have the following sequence
func:
movdq2q mm0, xmm0
movq mm1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110013
--- Comment #1 from Devin Hussey ---
As a side note, the official psABI does say that function call parameters use
MM0-MM2, if Clang follows its own rules then it means that the supposed
stability of the ABI is meaningless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110013
Bug ID: 110013
Summary: [i386] vector_size(8) on 32-bit ABI
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
|1
Last reconfirmed||2023-05-25
--- Comment #1 from Jonathan Wakely ---
Repeating the quoted comment, without bugzilla's unhelpful horizontal
scrollbar:
If compilers aren't going to give lambdas internal linkage in these situations,
the ABI needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109963
Bug ID: 109963
Summary: ABI: unexpected layout ordering of `this` pointer in
lambda capture
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
On 5/16/23 06:35, Ajit Agarwal wrote:
On 29/04/23 5:03 am, Jeff Law wrote:
On 4/28/23 16:42, Hans-Peter Nilsson wrote:
On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
Hello All:
This new version of patch 4 use improve ree pass for rs6000 target using
defined ABI interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23867
Andrew Pinski changed:
What|Removed |Added
Assignee|mark at codesourcery dot com |unassigned at gcc dot
gnu.org
On 29/04/23 5:03 am, Jeff Law wrote:
>
>
> On 4/28/23 16:42, Hans-Peter Nilsson wrote:
>> On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
>>
>>> Hello All:
>>>
>>> This new version of patch 4 use improve ree pass for rs6000 target usi
The following forces the g++.dg/torture/pr106922.C testcase to use
the C++11 libstdc++ ABI and checks if that was successful.
Does this look OK?
Thanks,
Richard.
* g++.dg/uninit-pr106722-2.C: Force _GLIBCXX_USE_CXX11_ABI to 1.
---
gcc/testsuite/g++.dg/torture/pr106922.C | 9
handled the testcases correctly, so this patch aligns
the GCC behaviour with the Clang behaviour.
I'm planning to remove the asserts on the branches, since we don't
want to change the ABI there.
Tested on aarch64-linux-gnu & pushed.
Richard
gcc/
PR target/109661
* config/aar
On 4/28/23 6:49 PM, Hans-Peter Nilsson wrote:
> On Fri, 28 Apr 2023, Jeff Law wrote:
>> So while what Ajit has done is a step forward, at some point the actual
>> details of the ABI need to be described in a way that can be checked and
>> consumed by REE.
>
> IIRC I a
Hi!
On Sat, Apr 22, 2023 at 02:36:20PM +0530, Ajit Agarwal wrote:
> * ree.cc (combline_reaching_defs): Add zero_extend
> using defined abi interfaces.
Typo. Also, please don't wrap lines early. Also, you are missing some
changes in this file in the cha
On Fri, 28 Apr 2023, Jeff Law wrote:
> On 4/28/23 16:42, Hans-Peter Nilsson wrote:
> > On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
> > I don't see anything in those functions that checks if
> > ZERO_EXTEND is actually a feature of the ABI, e.g. as oppose
On 4/28/23 16:42, Hans-Peter Nilsson wrote:
On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
Hello All:
This new version of patch 4 use improve ree pass for rs6000 target using
defined ABI interfaces.
Bootstrapped and regtested on power64-linux-gnu.
Thanks & Regards
On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
> Hello All:
>
> This new version of patch 4 use improve ree pass for rs6000 target using
> defined ABI interfaces.
> Bootstrapped and regtested on power64-linux-gnu.
>
> Thanks & Regards
> Ajit
>
&
Hello Jeff:
On 20/04/23 3:29 am, Jeff Law wrote:
>
>
> On 4/19/23 12:03, Ajit Agarwal wrote:
>> Hello All:
>>
>> This is patch-4 to improve ree pass for rs6000 target.
>> Use ABI interfaces support.
>>
>> Bootstrapped and regtested on powerp
Hello All:
This new version of patch 4 use improve ree pass for rs6000 target using
defined ABI interfaces.
Bootstrapped and regtested on power64-linux-gnu.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target using defined abi interfaces
For rs6000 target we
On 4/19/23 12:03, Ajit Agarwal wrote:
Hello All:
This is patch-4 to improve ree pass for rs6000 target.
Use ABI interfaces support.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target.
For rs6000 target we
Hello All:
This is patch-4 to improve ree pass for rs6000 target.
Use ABI interfaces support.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target.
For rs6000 target we see redundant zero and sign
exten
On Thu, 13 Apr 2023 08:59:58 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Ok, thanks :)
Committed.
Palmer Dabbelt 於 2023年4月13日 週四，23:12寫道：
The RVV test harness currently sets the ISA according to the target
tuple, but doesn't also set the ABI. This just sets the ABI to match
the ISA
The RVV test harness currently sets the ISA according to the target
tuple, but doesn't also set the ABI. This just sets the ABI to match
the ISA, though we should really also be respecting the user's specific
ISA to test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp (gcc_mabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
--- Comment #10 from Ben Woodard ---
Currently Libabigail is not able to detect this kind of ABI break. We would be
able to detect this if https://dwarfstd.org/issues/221105.1.html were
implemented. As mentioned in the DWARF issue, this would
Ok, thanks :)
Palmer Dabbelt 於 2023年4月13日 週四，23:12寫道：
> The RVV test harness currently sets the ISA according to the target
> tuple, but doesn't also set the ABI. This just sets the ABI to match
> the ISA, though we should really also be respecting the user's specific
> ISA to t
The RVV test harness currently sets the ISA according to the target
tuple, but doesn't also set the ABI. This just sets the ABI to match
the ISA, though we should really also be respecting the user's specific
ISA to test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp (gcc_mabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #11 from David Crocker ---
As the master branch was updated a year ago according to comment 10, does this
mean that there is now a stable release of gcc that incudes the patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109114
Bug ID: 109114
Summary: lambdas should be non-pod for ABI
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
and 7
further bits in the second byte, so per the Itanium ABI it should be 2:
"In either case, update dsize(C) to include the last byte
containing (part of) the bit-field, and update sizeof(C) to
max(sizeof(C),dsize(C))."
The following patch fixes it by computing bitsize of the end
, so per the Itanium ABI it should be 2:
"In either case, update dsize(C) to include the last byte
containing (part of) the bit-field, and update sizeof(C) to
max(sizeof(C),dsize(C))."
The following patch fixes it by computing bitsize of the end and using
CEIL_DIV_EXPR division to round
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #18 from Alexander Monakov ---
It seems you are saying that as long as GCC emits code according to the Holy
Scripture that is the ABI spec, everything is fine. I imagine on other
architectures maintainers are able to consider how
Hi,
As PR108727 shows, when cleanup code called by the stack
unwinder calls function _Unwind_Resume, it goes via plt
stub like:
function .plt_call._Unwind_Resume:
=> 0x10003580 <+0>: std r2,40(r1)
0x10003584 <+4>: ld r12,-31760(r2)
ters. This option should not change the FP calling convention
> > unless it's necessary."
> >
> > Though not explicitly stated, the rationale of this rule is to allow
> > combinations like "-mabi=lp64s -mfpu=64". This will be useful for
> > runnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
: Thu Mar 2 18:05:23 2023 +0800
LoongArch: Stop -mfpu from silently breaking ABI [PR109000]
In the toolchain convention, we describe -mfpu= as:
"Selects the allowed set of basic floating-point instructions and
registers. This option should not change the FP calling conve
2 18:05:23 2023 +0800
LoongArch: Stop -mfpu from silently breaking ABI [PR109000]
In the toolchain convention, we describe -mfpu= as:
"Selects the allowed set of basic floating-point instructions and
registers. This option should not change the FP calling convention
u
rationale of this rule is to allow
combinations like "-mabi=lp64s -mfpu=64". This will be useful for
running applications with LP64S/F ABI on a double-float-capable
LoongArch hardware and using a math library with LP64S/F ABI but native
double float HW instructions, for a better performa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #17 from Segher Boessenkool ---
What makes you think we need to tell the user to do something? There is
nothing that needs to be done as far as I can see? /confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Alexander Monakov changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
GCC!) in the first place.
If this is not correct, please add some info clarifying that, and reopen the
PR?
> considering that
> all linkers, including the BFD linker, initially misinterpreted the ABI the
> same way?
It wasn't implemented correctly there either, yes. That does not necessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #14 from Alexander Monakov ---
Are you guys really sure you want to blame the user here, considering that all
linkers, including the BFD linker, initially misinterpreted the ABI the same
way?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #13 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #10)
> (In reply to Rui Ueyama from comment #9)
> > I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
> > becaus
tions like "-mabi=lp64s -mfpu=64". This will be useful for
running applications with LP64S/F ABI on a double-float-capable
LoongArch hardware and using a math library with LP64S/F ABI but native
double float HW instructions, for a better performance.
And now a case in Linux ker
On Fri, 2023-03-03 at 10:12 +0800, Yujie Yang wrote:
> However, "loongarch64" is defined to include the "fpu64" ISA module[1]
> (i.e. enable "-mfpu=64" when -mfpu is not explicitly used). So I believe
> the above behavior you observed is expected.
Ah this make things much simpler and aligns with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000
Xi Ruoyao changed:
What|Removed |Added
Known to fail||12.2.0, 13.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000
Bug ID: 109000
Summary: LoongArch: "unmatched" -mabi and -mfpu setting can
break ABI silently
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severi
ongarch64" is never strictly defined. So we
> consider "loongarch64" a "64-bit LoongArch CPU with the simplest FPU
> needed by the ABI", and if -march=loongarch64 but -mfpu is not
> explicitly used, we set -mfpu such a simplest one.
Thanks for the fix on TARGET_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #12 from David Edelsohn ---
We're working to add a Power10 system to the Compile Farm. The systems are at
OSUOSL, but Power10 doesn't have official KVM support so the interface to the
OpenStack management system is complicated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #11 from Rui Ueyama ---
I'll try to add a POWER10 support to mold using Qemu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108883
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
::float16_t or std::bfloat16_t
and need RTTI for it, it should work out of the box. Furthermore,
libstdc++ ABI on ia32 shouldn't depend on whether the library
is compiled with -mno-sse or -msse2.
Unfortunately, just hacking up libsupc++ Makefile/configure so that
a single source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #10 from Alexander Monakov ---
(In reply to Rui Ueyama from comment #9)
> I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
> because I didn't have an access to a POWER10 machine and therefore co
tions like "-mabi=lp64s -mfpu=64". This will be useful for
running applications with LP64S/F ABI on a double-float-capable
LoongArch hardware and using a math library with LP64S/F ABI but native
double float HW instructions, for a better performance.
And now a case in Linux ker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #9 from Rui Ueyama ---
I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
because I didn't have an access to a POWER10 machine and therefore couldn't
verify the correctness of my implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #8 from Segher Boessenkool ---
To expand a bit: st_other with value 1 was reserved before, and now it
isn't anymore. Any tool that silently ignores the "special case" of
reserved values will not work correctly (it might sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Martin Liška changed:
What|Removed |Added
CC||rui314 at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #4 from Alexander Monakov ---
Let me address one point separately:
(In reply to Peter Bergner from comment #1)
> CCing Alan, since he probably knows best how this all works, but yes,
> -mcpu-power10 changes the ABI, namely i
/103936.html
and, I think, in this patchset for the Gold linker:
https://sourceware.org/pipermail/binutils/2019-July/107486.html
Corresponding support in the LLVM linker (LLD) also seems to appear around
2018.
It looks like de-facto ABI change even if on paper nothing changed, because all
Linux
localentry, so the nop in the caller stays a nop after linking).
My local 64bit-elfv2-abi spec v1.5 has the following description:
3.4.1. Symbol Values
"The values of these three most significant bits of the st_other field have the
following meanings:
...
1 The local and global entry po
#1 from Peter Bergner ---
CCing Alan, since he probably knows best how this all works, but yes,
-mcpu-power10 changes the ABI, namely it adds pcrel support which is an ABI
extension, where the function compiled with -mcpu=power10 doesn't use r2 to
access its GOT, but uses pcrel code instead. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108919
jcmvbkbc at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
to xtensa_expand_call.
(xtensa_expand_call): Emit the call and add a clobber expression
for the static chain to it in case of windowed ABI.
* config/xtensa/xtensa.md (call, call_value, sibcall)
(sibcall_value): Call xtensa_expand_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108919
Bug ID: 108919
Summary: pure nested function may clobber its static chain
pointer in windowed ABI on xtensa
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108883
--- Comment #3 from Jakub Jelinek ---
Created attachment 54506
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54506=edit
gcc13-pr108883.patch
Untested fix on the compiler side of emit_support_tinfos.
That said, these fundamental types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108883
--- Comment #2 from Richard Biener ---
(In reply to Richard Biener from comment #1)
> Can we split them out to a separate CU that we can build with -msse2?
>
> That is, does it work to simply add tinfo-x86-sse2.o by compiling
>
401 - 500 of 5007 matches
Mail list logo
