On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek wrote:
> etc. Could we just pretend in the compiler to libgfortran ABI that
> powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
> would actually think it is 17 bytes it uses 16 instead (though, kind=10
>
ly).
Any architecture that supports a software floating-point ABI (i.e. one
that does argument passing and return for floating-point in integer
registers) should specify it in its ABI documents. For example,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc
describes
On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> > There's still some code in the compiler for a very old soft-float ABI for
> > binary128 long double (passing by reference, using _q_* libcall names). I
> > don't really think it makes much sense to use that for futur
On Wed, Oct 06, 2021 at 07:42:31PM +, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> > Soft float is not described in any formal ABI btw (well, except the
> > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.
>
> It's fully
On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> Soft float is not described in any formal ABI btw (well, except the
> Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.
It's fully documented in the unified 32-bit ABI document (under
ATR-SOFT-FLOAT conditionals
.
This would cover POWER6 and later server CPUs, as well as some other
cpus like in the Power Macs.
Anything without Altivec hardware would need to either not support
IEEE QP at all, or go through the work themselves of coming up with
a -msoft-altivec like ABI.
Peter
y?
> > But are those available everywhere where ppc64 is supported? For ppc32
> > certainly not, I don't remember for ppc64.
>
> As noted in previous discussions, while the current GCC implementation
> requires VSX for _Float128 support, the registers used in the ABI a
certainly not, I don't remember for ppc64.
> >
> > You can use VSX registers on 32 bit just fine.
>
> With -mvsx (or perhaps even -maltivec) sure, but if neither VSX nor Altivec
> ISA is there...
This was for -mcpu=power8 only. And yes, you can use -mno-vsx if you
have p8 o
;
> > This needs to be described with more granularity. IEEE QP
> > instructions work with either endianness.
> >
> > IEEE QP is enabled and supported for PPC64 LE Linux on Power. The
> > transition is under discussion.
>
> IEEE QP insns are enabled for BE as well:
don't remember for ppc64.
As noted in previous discussions, while the current GCC implementation
requires VSX for _Float128 support, the registers used in the ABI are the
same as AltiVec registers; it would be possible to implement support for
_Float128 on all powerpc64 with AltiVec (most but
ren't they?
>
> On BE just as well. And on 32 bit.
>
> > But are those available everywhere where ppc64 is supported? For ppc32
> > certainly not, I don't remember for ppc64.
>
> You can use VSX registers on 32 bit just fine.
With -mvsx (or perhaps even -ma
s supported? For ppc32
> certainly not, I don't remember for ppc64.
You can use VSX registers on 32 bit just fine.
> Sure, the ABI could say pass it in e.g. in a pair of integer registers...
Or more, on 32-bit. It isn't very useful to try to optimise this, so
it is easiest
double arguments and return values passed. On power8 le I think
they are passed in VSX registers, aren't they?
But are those available everywhere where ppc64 is supported? For ppc32
certainly not, I don't remember for ppc64.
Sure, the ABI could say pass it in e.g. in a pair of i
The
> transition is under discussion.
IEEE QP insns are enabled for BE as well:
powerpc64-linux-gcc -Wall -W -O2 -S qp.c -mcpu=power9
=== qp.c ===
#define QP _Float128
QP f(QP x) { return x*x; }
===
results in
.L.f:
xsmulqp 2,2,2
blr
> PPC64 BE Linux on Power does not define IEEE QP.
On Wed, Oct 06, 2021 at 05:41:07PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > >That means flipping the default on all PowerPC to no longer be double-
> > > >double. This
tions work with either endianness.
IEEE QP is enabled and supported for PPC64 LE Linux on Power. The
transition is under discussion.
PPC64 BE Linux on Power does not define IEEE QP. The ABI could be
updated and IEEE QP could be enabled, but PPC64 BE is not planning
future releases from Linux d
On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > On 05.10.21 23:54, Segher Boessenkool wrote:
> > >>There is also the issue of binary data. If some user has written
> > >>out data in double double and wants to
> instructions, or would that be trap and emulate? What is the
> plan there?
The registers used by the QP insns are the VRs. Trying to use the QP
insns on a p8 will trap. There is no kernel emulation for them afaik.
But, for p8 there is software emulation, that GCC can generate. This
foll
On 05.10.21 23:54, Segher Boessenkool wrote:
Hi!
On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote:
On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
Based on some IRC discussion, yet another option would be bump libgfortran
SONAME (on all arches), make real(kind=16) on powerpc64
Hi!
On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote:
> On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
> >Based on some IRC discussion, yet another option would be bump libgfortran
> >SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
> >always IEEE quad (starti
On Mon, 4 Oct 2021, 15:14 Jakub Jelinek via Gcc, wrote:
> On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote:
> > Or the last option would be to try to make libgfortran.so.5 ABI
> compatible
> > with both choices on powerpc64le-linux. From quick skimmin
On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
Based on some IRC discussion, yet another option would be bump libgfortran
SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
always IEEE quad (starting with GCC 12) and if wanted add support for
real(kind=15) meaning double
down. This is
> > more than just Fortran.
>
> Is the 64-bit BE (ELFv1) ABI maintained somewhere? (The 32-bit ABI,
> covering both hard float and soft float, is
> <https://github.com/ryanarn/powerabi> - no activity lately, but I think
> Ryan said he'd given writ
hat needs to be put into the ABIs, to define how parameter
> passing works for those types. Just treating it like a struct or an
> array of ints will work fine, but it needs to be written down. This is
> more than just Fortran.
Is the 64-bit BE (ELFv1) ABI maintained somewhere? (The 32
Hi!
On Mon, Oct 04, 2021 at 04:14:10PM +0200, Jakub Jelinek wrote:
> Based on some IRC discussion, yet another option would be bump libgfortran
> SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
> always IEEE quad (starting with GCC 12) and if wanted add support for
> real(kind
On Mon, 4 Oct 2021, Jakub Jelinek via Gcc wrote:
> One problem with that is that I think IEEE quad long double support relies
> on glibc 2.32 or later, so not sure what exactly would be done if gcc is
> built against older glibc when it needs to call libm routines. Perhaps
> convert to __ibm128,
On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote:
> Or the last option would be to try to make libgfortran.so.5 ABI compatible
> with both choices on powerpc64le-linux. From quick skimming of libgfortran,
> we have lots of generated functions, which use HAVE_GFC_RE
On Mon, Oct 04, 2021 at 01:36:56PM +0200, Jakub Jelinek via Gcc wrote:
> On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote:
> > > Your thoughts on this?
> >
> > How does glibc deal with this? There's a load of long double ABI in there.
>
> I don&#
On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote:
> > Your thoughts on this?
>
> How does glibc deal with this? There's a load of long double ABI in there.
I don't know, CCing Florian; all I can see is that starting with glibc 2.26
in addition to sin{f,,l}
hat eventually all
> distros switch to that (like they've switched from the --with-long-double-64
> default to --with-long-double-128 on powerpc64-linux, s390*-linux etc. years
> ago).
>
> libstdc++ has been changed already last year, so that the same
> libstdc++.so.6 is AB
ong-double-128 on powerpc64-linux, s390*-linux etc. years
ago).
libstdc++ has been changed already last year, so that the same
libstdc++.so.6 is ABI compatible with both configurations, in C++ the
IEEE quad long double mangles differently from IBM double double long
double and so it is possible (
On Wed, Sep 22, 2021 at 12:46 PM Christoph Müllner
wrote:
> Would it make sense to extend this proposal to include __strcmpeq()
> and __strncmpeq()?
>
> Both are already available internally in GCC in form of
> BUILT_IN_STRCMP_EQ and BUILT_IN_STRNCMP_EQ
> (tree-ssa-strlen.c detects them in handle
Would it make sense to extend this proposal to include __strcmpeq()
and __strncmpeq()?
Both are already available internally in GCC in form of
BUILT_IN_STRCMP_EQ and BUILT_IN_STRNCMP_EQ
(tree-ssa-strlen.c detects them in handle_builtin_string_cmp() and
builtins.c tries to inline them in expand_bui
On Fri, Sep 17, 2021 at 9:27 AM Florian Weimer via Libc-alpha <
libc-al...@sourceware.org> wrote:
> * Joseph Myers:
>
> > I was supposing a build-time decision (using
> GCC_GLIBC_VERSION_GTE_IFELSE
> > to know if the glibc version on the target definitely has this
> function).
> > But if we add a
On Fri, Sep 17, 2021, at 9:36 PM, James Y Knight via Libc-alpha wrote:
> Glibc currently implements bcmp as an alias to memcmp -- which is valid,
> but provides more than just the boolean equality semantics. There was
> concern raised that modifying that might break existing binaries. However,
> th
On Thu, Sep 16, 2021 at 5:50 PM enh wrote:
> plus testing for _equality_ can (as mentioned earlier) have slightly
> different properties from the three-way comparator behavior of
> bcmp()/memcmp().
>
Per spec, bcmp is not a three-way comparison, it is an equality comparison
with exactly the same
mentation), does that open up the possibility of depending on
> the
> > >> > bcmp-like behavior that we were trying to escape?
> > >>
> > >> The proposal is as an ABI only (compilers would generate calls to
> > >> __memcmpeq from boolean uses of me
provide __memcmpeq? Or would
glibc through magically communicate the availability of the new ABI
without actually declaring the function?
I do not think ELF provides that capability.
We can add a declaration to to communicate the availability.
I think this is how glibc (and other libcs
* Joseph Myers:
> I was supposing a build-time decision (using GCC_GLIBC_VERSION_GTE_IFELSE
> to know if the glibc version on the target definitely has this function).
> But if we add a header declaration, you could check for __memcmpeq being
> declared (and so cover arbitrary C libraries, not
On Fri, 17 Sep 2021, Richard Biener via Gcc wrote:
> when the libc version targeted does not provide __memcmpeq? Or would
> glibc through magically communicate the availability of the new ABI
> without actually declaring the function?
> (I'm not sure whether a GCC build-
mple alias for memcmp (since the notes mention that it's a valid
> >> >> > implementation), does that open up the possibility of depending on the
> >> >> > bcmp-like behavior that we were trying to escape?
> >> >>
> >> >> The proposal
Or would
> > glibc through magically communicate the availability of the new
> > ABI
> > without actually declaring the function?
>
> I do not think ELF provides that capability.
>
> We can add a declaration to to communicate the availability.
> I think
gt;> >>
>> >> > In terms of relying on the feature: If __memcmpeq is ever exposed as
>> >> > an a
>> >> > simple alias for memcmp (since the notes mention that it's a valid
>> >> > implementation), does that open up the pos
the feature: If __memcmpeq is ever exposed as an
> >> > a
> >> > simple alias for memcmp (since the notes mention that it's a valid
> >> > implementation), does that open up the possibility of depending on the
> >> > bcmp-like be
nce the notes mention that it's a valid
>> > implementation), does that open up the possibility of depending on the
>> > bcmp-like behavior that we were trying to escape?
>>
>> The proposal is as an ABI only (compilers would generate calls to
>> __memcmpeq from boolean
entation), does that open up the possibility of depending on the
> > bcmp-like behavior that we were trying to escape?
>
> The proposal is as an ABI only (compilers would generate calls to
> __memcmpeq from boolean uses of memcmp, users wouldn't write calls to
> __memcmpeq dire
On Thu, Sep 16, 2021 at 5:25 PM Chris Kennelly via Libc-alpha <
libc-al...@sourceware.org> wrote:
> On Thu, Sep 16, 2021 at 5:50 PM enh wrote:
>
> > plus testing for _equality_ can (as mentioned earlier) have slightly
> > different properties from the three-way comparator behavior of
> > bcmp()/m
On Thu, 16 Sep 2021, Chris Kennelly wrote:
> The mem* functions are extremely sensitive to instruction cache effects, so
> having 3 unique implementations (__memcmpeq, bcmp, memcmp) that do similar,
I don't think anyone is suggesting 3 unique implementations. The
obsolescent name bcmp would be
On Thu, Sep 16, 2021 at 5:50 PM enh wrote:
> plus testing for _equality_ can (as mentioned earlier) have slightly
> different properties from the three-way comparator behavior of
> bcmp()/memcmp().
>
llvm-libc's implementation only returns the boolean, though.
The mem* functions are extremely s
On Thu, Sep 16, 2021, 4:50 PM enh via Libc-alpha
wrote:
> plus testing for _equality_ can (as mentioned earlier) have slightly
> different properties from the three-way comparator behavior of
> bcmp()/memcmp().
>
How does bcmp() have a three-way comparator?
Or do you mean how it is currently im
plus testing for _equality_ can (as mentioned earlier) have slightly
different properties from the three-way comparator behavior of
bcmp()/memcmp().
On Thu, Sep 16, 2021 at 2:43 PM Joseph Myers
wrote:
> On Thu, 16 Sep 2021, James Y Knight wrote:
>
> > Wouldn't it be far simpler to just un-deprec
On Thu, 16 Sep 2021, James Y Knight wrote:
> Wouldn't it be far simpler to just un-deprecate bcmp?
The aim is to have something to which calls can be generated in all
standards modes. bcmp has never been part of ISO C; there's nothing to
undeprecate there.
--
Joseph S. Myers
jos...@codesourc
ro the two sequences are zero.
> 2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at
>offset 'i' of 's1' equals the byte at offset 'i' in 's2'.
>
> For a simple C implementation of '__memcmpeq()'
mple alias for memcmp (since the notes mention that it's a valid
> > implementation), does that open up the possibility of depending on the
> > bcmp-like behavior that we were trying to escape?
>
> The proposal is as an ABI only (compilers would generate calls to
> __memcmpeq fr
vior that we were trying to escape?
The proposal is as an ABI only (compilers would generate calls to
__memcmpeq from boolean uses of memcmp, users wouldn't write calls to
__memcmpeq directly, __memcmpeq wouldn't be declared in installed libc
headers). If such dependence arises, that w
the argument specifications are violated there are no
>> > guarantees about the behavior of the interface.
>> >
>> >
>> > Return Value Specification
>> >
>> > If the byte sequences starting at 's1' and 's2' are equals the
x27; are equals the
> > function will return zero. Otherwise the function will return a
> > non-zero value.
> >
> > Equality between the byte sequences starting at 's1' and 's2' is
> > defined as follows:
> >
> > 1. If 'n' is zero the two sequence
are zero.
> 2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at
>offset 'i' of 's1' equals the byte at offset 'i' in 's2'.
>
> For a simple C implementation of '__memcmpeq()' could be as follows:
&g
at offset 'i' in 's2'.
For a simple C implementation of '__memcmpeq()' could be as follows:
int __memcmpeq(const void* s1, const void* s2, size_t n)
{
int ret;
size_t i;
const char *s1c, *s2c;
s1c = (const char*)s1;
s2c = (const char*)s2;
for (i =
Hi!
The same testcase as has been used for powerpc64le-linux can be
used for aarch64-linux too:
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { float a, b, c, d; };
struct B : public X { float a, b, c, d; };
struct C : public Y { float a,
On Fri, 21 Feb 2020 at 05:57, Jason Mancini wrote:
>
> Any notable ABI changes from 9 to 10?
Any such changes will be documented at https://gcc.gnu.org/gcc-10/changes.html
Any notable ABI changes from 9 to 10?
Thanks!
-Jason
(Sorry for asking here, there was no response from gcc-help in January.)
On 22/05/2019 15:42, Szabolcs Nagy wrote:
> [AAELF64]: ELF for the Arm 64-bit Architecture (AArch64)
>https://developer.arm.com/docs/ihi0056/latest
> [VABI64]: Vector Function ABI Specification for AArch64
>
> https://developer.arm.com/tools-and-software/ser
t; The st_other member of a symbol table entry specifies the symbol's
>>>> visibility in the lowest 2 bits. The top 6 bits are unused in the
>>>> generic ELF ABI [SCO-ELF], and while there are no values reserved for
>>>> processor-speci
gt;>> visibility in the lowest 2 bits. The top 6 bits are unused in the
>>> generic ELF ABI [SCO-ELF], and while there are no values reserved for
>>> processor-specific semantics, many other architectures have used these
>>> bits.
>>>
ts. The top 6 bits are unused in the
>> generic ELF ABI [SCO-ELF], and while there are no values reserved for
>> processor-specific semantics, many other architectures have used these
>> bits.
>>
>> The defined processor-specific st_other flag
* Szabolcs Nagy:
> AAELF64: in the Symbol Table section add
>
> st_other Values
> The st_other member of a symbol table entry specifies the symbol's
> visibility in the lowest 2 bits. The top 6 bits are unused in the
> generic ELF ABI [SCO-ELF],
were discussed at
https://groups.google.com/forum/#!topic/generic-abi/Bfb2CwX-u4M
The ABI change draft is below the notes, it requires marking symbols
in the ELF symbol table that follow the vector PCS (or other variant
PCS conventions). This is most relevant to dynamic linkers with lazy
binding
Arm released an update (2019Q1.1) of the Vector Function ABI specifications for
AArch64 that uses the `declare variant` directive from OpenMP 5.0 to support
user
defined vector functions. The mechanism is introduced in chapter 4, and it is in
beta release status to allow feedback from the open
Am 2018-12-04 um 08:14 schrieb Lokesh Janghel:
Thank you Sirl,
-msvr4-struct-return=standard and -msvr4-struct-return=gnu (which would
be the default (-msvr4-struct-return=standard)
by default, you mean using registers to return?
Hi Lokesh,
both return small structs in registers. The quest
Thank you Sirl,
>>-msvr4-struct-return=standard and -msvr4-struct-return=gnu (which would
be the default (-msvr4-struct-return=standard)
by default, you mean using registers to return?
Lokesh
On Fri, Nov 30, 2018 at 4:18 PM Franz Sirl
wrote:
>
> Am 2018-11-26 um 06:13 schrieb Lokesh Janghel:
> >
Am 2018-11-26 um 06:13 schrieb Lokesh Janghel:
Hi Sirl,
As you mentioned in Bugzilla (comment 13),
aix_return ( return in memory)
svr4_return (return in register)
what is the semantics of svr4gnu w.r.t. return.
Hi Lokesh,
I don't quite understand what you are asking me here? In comment 13
I'v
mr 1,11
> > .LCFI4:
> > blr
> >
> >
> > Assembly code (with optimization -O2) is:
> > $ cc1 -msvr4-struct-return -O2 test.c
> > .LFB0:
> > stwu 1,-32(1)
> > .LCFI0:
> > lis 3,0x11
> >
Hi Sirl,
As you mentioned in Bugzilla (comment 13),
aix_return ( return in memory)
svr4_return (return in register)
what is the semantics of svr4gnu w.r.t. return.
Thanks
Lokesh
lwz 31,-4(11)
> > .LCFI3:
> > mr 1,11
> > .LCFI4:
> > blr
> >
> >
> > Assembly code (with optimization -O2) is:
> > $ cc1 -msvr4-struct-return -O2 test.c
> > .LFB0:
> > stwu 1,-32(1)
> > .LCFI0:
> >
lwz 31,-4(11)
> > .LCFI3:
> > mr 1,11
> > .LCFI4:
> > blr
> >
> >
> > Assembly code (with optimization -O2) is:
> > $ cc1 -msvr4-struct-return -O2 test.c
> > .LFB0:
> > stwu 1,-32(1)
> > .LCFI0:
> >
reproduce this issue.
Hi,
you already reproduced the issue, according to the ABI, the code should
look like:
.LFB0:
stwu 1,-32(1)
.LCFI0:
lis 3,0x1122
ori 3,3,0x3300
addi 1,1,32
.LCFI1:
blr
So the value being passed around should be left-aligned in the register
Hi Segher,
I am building the GCC with the following configuration ( using gcc trunk ).
../gcc/configure --target=powerpc-linux
--prefix=/opt/buckeye/powerpc-linux --disable-shared --disable-threads
--enable-languages=c --with-newlib
And my assembly code (without optimization) is:
$ cc1 -msvr4-
addr has
> historically used malloc to grow the DTV and to allocate dynamic TLS
> blocks, and if overriders to malloc end up using/clobbering unexpected
> registers, even if just because of lazy PLT resolution for calls in its
> implementation, things might go wrong. Sure enough, __tls_get_ad
dynamic TLS
blocks, and if overriders to malloc end up using/clobbering unexpected
registers, even if just because of lazy PLT resolution for calls in its
implementation, things might go wrong. Sure enough, __tls_get_addr
doesn't use a specialized ABI, so this is usually not an issue.
> Th
S (possibly considerably) faster. I'm just
concerned about whether it can be done without making thread
creation/exit significantly slower.
> except they're a lot more common. The only difference is that failures
> to preserve registers are less visible, because most of the time you&#
s visible, because most of the time you're
resolving them to functions that abide by the normal ABI, but once
specialized calling conventions kick in, the very same issues arise.
TLS descriptors are just one case of such specialized calling
conventions. Indeed, one of the reasons that mad
; > call-clobbered, but which are non-clobbered in the tlsdesc ABI. This
> > does not risk breakage when an existing valid build of libc/ldso is
> > used on new hardware and new appliations that provide new registers,
> > but it does risk breakage if an existing source vers
ddenly not compatible with existing
tlsdesc entry points in the libc.
i think extensions should not cause such abi break.
we could mark binaries so they fail to load on an old
system instead of failing randomly at runtime, but
requiring new libc for a new system is suboptimal
(you cannot deploy stable
ure ISA level and compiler supporting that
> ISA level to produce code, in the C functions called in the dynamic
> fallback case, instructions which clobber registers which are normally
> call-clobbered, but which are non-clobbered in the tlsdesc ABI. This
> does not risk breakage when an
oduce code, in the C functions called in the dynamic
fallback case, instructions which clobber registers which are normally
call-clobbered, but which are non-clobbered in the tlsdesc ABI. This
does not risk breakage when an existing valid build of libc/ldso is
used on new hardware and new appliations
On Sun, Nov 19, 2017 at 5:35 PM, Richard Bradfield wrote:
> On Sun, Nov 19, 2017 at 04:19:45PM +, bradf...@fstab.me wrote:
>>
>> For reference, I am compiling everything using gcc trunk, at commit
>> 254929 from Sun Nov 19, and I am benchmarking on a Skylake i7-6700K
>> at 4.0GHz.
>
>
> And so
On Sun, Nov 19, 2017 at 04:19:45PM +, bradf...@fstab.me wrote:
For reference, I am compiling everything using gcc trunk, at commit
254929 from Sun Nov 19, and I am benchmarking on a Skylake i7-6700K
at 4.0GHz.
And something else I should definitely have included in the first place,
I cannot
Hello,
I was playing around with 64bit arithmetic with -m32 enabled and
encountered some strange optimization in what I thought was a very
simple case.
My test function, which I appreciate is totally artifical, is as
follows:
uint64_t sum(uint64_t a, uint64_t b) {
return a + b;
}
This is ob
Hi Maciej,
Slow thread, sorry for dragging it out further...
Maciej Rozycki writes:
> On Fri, 11 Nov 2016, Matthew Fortune wrote:
>
> > This means that a user consciously creating an object that 'needs'
> ieee
> > compliance via use of -fieee=strict or -mieee=strict is thwarted by
> the
> > nex
Hi Matthew,
On Fri, 11 Nov 2016, Matthew Fortune wrote:
> This means that a user consciously creating an object that 'needs' ieee
> compliance via use of -fieee=strict or -mieee=strict is thwarted by the
> next user who builds the executable. This kind of scenario can occur with
> a static librar
Hi,
On Fri, 20 Jan 2017, Richard Henderson wrote:
> > You can't have a 4-aligned type of size 3. Sizes must be multiples of
> > alignment (otherwise arrays don't work). The type of a 3-sized field
> > in a packed struct that syntactically might be a 4-aligned type (e.g.
> > by using attribut
On 01/20/2017 05:41 AM, Michael Matz wrote:
Hi,
On Wed, 18 Jan 2017, Richard Henderson wrote:
Section 3 Rationale, alternative 1: I'm wondering if the example is
correct. For a 4-byte-aligned type of size 3, the implementation
cannot simply use 4-byte hardware-backed atomics because this will
Hi,
On Wed, 18 Jan 2017, Richard Henderson wrote:
> > Section 3 Rationale, alternative 1: I'm wondering if the example is
> > correct. For a 4-byte-aligned type of size 3, the implementation
> > cannot simply use 4-byte hardware-backed atomics because this will
> > inevitably touch the 4th by
> only work on 16-byte aligned data. This is a problem in particular
> > since the default alignment of 16-byte data types is still 8 bytes
> > on our platform (since the ABI only guarantees 8-byte stack alignment).
> >
> > That's why the libatomic configure check thi
On Wed, 2017-01-18 at 14:23 -0800, Richard Henderson wrote:
> On 01/17/2017 09:00 AM, Torvald Riegel wrote:
> > I think the ABI should set a baseline for each architecture, and the
> > baseline decides whether something is inlinable or not. Thus, the
> > x86_64 ABI would mak
On 01/17/2017 09:00 AM, Torvald Riegel wrote:
I think the ABI should set a baseline for each architecture, and the
baseline decides whether something is inlinable or not. Thus, the
x86_64 ABI would make __int128 operations not imlinable (because of the
issues with cmpxchg16b, see above).
If
On Thu, 2016-11-17 at 12:12 -0800, Bin Fan wrote:
> On 11/14/2016 4:34 PM, Bin Fan wrote:
> > Hi All,
> >
> > I have an updated version of libatomic ABI specification draft. Please
> > take a look to see if it matches GCC implementation. The purpose of
> >
On 22/12/16 17:37, Segher Boessenkool wrote:
> We do not always have all atomic instructions. Not all processors have
> all, and it depends on the compiler flags used which are used. How would
> libatomic know what compiler flags are used to compile the program it is
> linked to?
>
> Sounds like
the default alignment of 16-byte data types is still 8 bytes
> on our platform (since the ABI only guarantees 8-byte stack alignment).
>
> That's why the libatomic configure check thinks it cannot use the
> atomic instructions when building on z, and generates code that uses
>
101 - 200 of 809 matches
Mail list logo
