On Fri, Oct 15, 2021 at 04:20:49PM +0200, Jakub Jelinek wrote:
> If we do implement double-double support, I think KIND=15 would be better
> than KIND=17, it is true that double-double has for certain numbers much
> higher precision than IEEE quad, but the precision depends on the numbers
> and
On 15.10.21 20:11, Jakub Jelinek wrote:
On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither
precision of C long double if it is
On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
> > with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
> > 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither
> > precision of C long double if it is double-double nor range matches
> >
On 15.10.21 16:20, Jakub Jelinek wrote:
[...]
when one compiles
integer function foo ()
foo = precision (0.0_16)
end function foo
integer function bar ()
bar = range (0.0_16)
end function bar
with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
33 and 4931. The
e was agreement. I'd also like to separate out short-term
> considerations
> for powerpc64le and GCC 12 from other topics like supporting more targets.
>
> ===
>
> First, for the short-term. For powerpc64le only (little-endian, ELFv2 ABI)
> Thomas suggested
&g
for powerpc64le and GCC 12 from other topics like supporting more targets.
===
First, for the short-term. For powerpc64le only (little-endian, ELFv2 ABI)
Thomas suggested
that Fortran's best course of action is:
- Change KIND=16 in GCC 12 from double-double to IEEE QP just for affected
targets
- Bump
gt; language from it. That may have been an excess of caution, or it may not...
I am not suggesting you should share this text with some other ABI.
Just that you can put it in the same repository :-)
> That said, with enough diligence I would hope we would be able to create
> modifications
s a choice
> that should be made explicitly, and documented (in the relevant ABI if one
> is maintained), and coordinated between implementations when there's more
> than one implementation for the architecture trying to be compatible.
I don't disagree at all. But: GCC makes that ch
e 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-bit ABI,
>> covering both hard float and soft float, is
>> <https:
Am Donnerstag, dem 14.10.2021 um 13:17 + schrieb Michael Matz:
> Hello,
>
> On Wed, 13 Oct 2021, Martin Uecker wrote:
>
> > > [... static chain ...]
> > > If you mean that, then it's indeed psABI specific, and possibly
> > > not
> > > al ABIs specify it (in which case GCC will probably have
Hello,
On Wed, 13 Oct 2021, Martin Uecker wrote:
> > [... static chain ...]
> > If you mean that, then it's indeed psABI specific, and possibly not
> > al ABIs specify it (in which case GCC will probably have set a de-
> > facto standard at least for unixy systems). The x86-64 psABI for
> >
(and C++ liaison list) of whether it would
be useful to have a public list of C-relevant ABIs and their maintainer
contacts and ABI-relevant new features in C language versions. I was
thinking of such a list as being to help people do due diligence after
making ABI-relevant C standard changes (co
Am Mittwoch, dem 13.10.2021 um 15:21 + schrieb Michael Matz:
> Hello,
>
> On Wed, 13 Oct 2021, Martin Uecker wrote:
>
> > does anybody know if all architectures support passing
> > an environment pointer in their function call ABI?
>
...
>
> Or you could m
Hello,
On Wed, 13 Oct 2021, Martin Uecker wrote:
> does anybody know if all architectures support passing
> an environment pointer in their function call ABI?
Define "environment pointer". I can imagine two things you could mean:
the custom to pass envp as third argument to
Hi all,
does anybody know if all architectures support passing
an environment pointer in their function call ABI?
Are the some where this does not exist?
Is there are table somewhere which lists the
register (or stack slot) used for this for
all architectures?
Somehow I could not find
es with other choices - in
particular, whether to say some or all the higher bits in the register or
stack slot are sign-extended, zero-extended or undefined). It's a choice
that should be made explicitly, and documented (in the relevant ABI if one
is maintained), and coordinated between
* Andreas Schwab:
> On Okt 09 2021, Thomas Koenig via Fortran wrote:
>
>> There is no choice - we need to make object code compiled by the user
>> incompatible between the old and the new format on the systems where
>> we make the switch.
>
> If you link, but not recompile, object files compiled
On Sat, Oct 09, 2021 at 11:11:51AM +0200, Thomas Koenig wrote:
> The question is still if we can avoid a new SONAME for >99% of our users
> for no gain at all for them. Is there a possibility of aliasing the
> SONAME somehow (grasping at straws here)?
I'd hope Debian can just
ln -sf
> On 9 Oct 2021, at 10:11, Thomas Koenig wrote:
>
>
> On 09.10.21 01:18, Iain Sandoe wrote:
>>> I meant the case where the user writes, with an old, KIND=16 is double
>>> double compiler,
>>>
>>> subroutine foo(a)
>>>real(kind=16) :: a
>>>a = a + 1._16
>>> end subroutine foo
>>>
On 09.10.21 01:18, Iain Sandoe wrote:
I meant the case where the user writes, with an old, KIND=16 is double
double compiler,
subroutine foo(a)
real(kind=16) :: a
a = a + 1._16
end subroutine foo
and puts it in a library or an old object file, and in new code with an
IEEE QP
On Okt 09 2021, Thomas Koenig via Fortran wrote:
> There is no choice - we need to make object code compiled by the user
> incompatible between the old and the new format on the systems where
> we make the switch.
If you link, but not recompile, object files compiled against different
versions
> On 8 Oct 2021, at 23:55, Thomas Koenig via Gcc wrote:
>
>
> Hi Iain,
>
>>> Things get interesting for user code, calling a routine compiled
>>> for double double with newer IEEE QP will result in breakage.
>> That would not happen with the proposal above, since the library would
>> have
Hi Thomas,
recognising that this is complex - the intent here is to see if there are ways
to partition the problem (where the pain falls does depend on the choices
made).
perhaps:
*A library (interface, name)
*B compiler internals
*C user-facing changes
> On 8 Oct 2021, at 17:26, Thomas
Hi Iain,
Things get interesting for user code, calling a routine compiled
for double double with newer IEEE QP will result in breakage.
That would not happen with the proposal above, since the library would
have different entry points for the two formats.
I meant the case where the user
On Wed, Oct 06, 2021 at 11:42:11PM -0400, Michael Meissner 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:
> > > On 05.10.21 23:54, Segher Boessenkool wrote:
> > > >>There is also the issue of binary
scription get a working sofware floating point (for binary32 and
> > binary64 currently).
>
> 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 documen
Hi Iain,
If one wanted to prioritize library SO name stability - then, perhaps, the
approach Jonathan mentioned has been used for libstdc++ (add new
symbols for ieee128 with a different mangling to the existing r/c_16 ..)
would be preferable (the FE then has to choose the relevant symbol/
> On 8 Oct 2021, at 07:35, Thomas Koenig via Fortran
> wrote:
>
>
> On 07.10.21 17:33, Jakub Jelinek wrote:
>>> It will also be a compatibility issue if users have code compiled on a LE
>>> system with GCC 11 and earlier with KIND=16, it will not link with G
On 07.10.21 17:33, Jakub Jelinek wrote:
It will also be a compatibility issue if users have code compiled on a LE
system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
libgfortran ABI changed multiple times in the past already, e.g. the
so.1 -> so.2 transition in 4.2
s
n powerpc64le-linux doesn't imply we also have to change it
for powerpc64-linux, or perhaps can change it later than in GCC 12.
> It will also be a compatibility issue if users have code compiled on a LE
> system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
libgfortran ABI
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > I tried this at one point. There are a lot of hidden assumptions that the
> > kind
> > number is the number of bytes. I'm sure it can be tracked down, but the
> > problem
ev to point to 6, drops libgfortran5 from
the Debian archive (but doesn't delete the package libgfortran5 from the
users' computer) and we rebuild and transition simultaneously all
packages that depend on libgfortran5.
So if we introduce libgfortran6 for ppc64le (with potential ABI changes
On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
> On Okt 07 2021, Alastair McKinstry wrote:
>
> > I strongly advise against this -- identical SONAMEs for the libraries on
> > all architectures is a key assumption on all Debian-based distributions
> > and designs
>
> Even glibc
On Okt 07 2021, Alastair McKinstry wrote:
> I strongly advise against this -- identical SONAMEs for the libraries on
> all architectures is a key assumption on all Debian-based distributions
> and designs
Even glibc has differing sonames on some architectures. And libgcc_s,
too.
Andreas.
--
On 06/10/2021 07:59, Thomas Koenig via Fortran wrote:
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
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > I tried this at one point. There are a lot of hidden assumptions that the
> > kind
> > number is the number of bytes. I'm sure it can be tracked down, but the
> > problem
variable, I'd say
we should use a new one and reuse the existing parsing routines.
Sounds like a reasonable minimum of user pain to me.
The rest I'll leave to the experts in all things ABI and POWER :-)
> 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,
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
&g
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 future _Flo
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 docu
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).
T
s 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
> > 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 are the
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 or later
;
> > 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
n'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 not all 6
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 -maltivec) su
ported? 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 to just handle
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 integer reg
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
ructions 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
gt; 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
follows t
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
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
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 write acc
but that 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
>
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_GF
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't know
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} there is
t 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 ABI compatib
-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 (with quite
, then return -1, otherwise return the count in the
- sub-tree. */
+ sub-tree.
+
+ There have been some ABI snafus along the way with C++. Modify
+ EMPTY_BASE_SEEN to a nonzero value iff a C++ empty base class makes
+ an appearance; separate flag bits indicate whether or not such a
+ field
Hi!
On Tue, Sep 21, 2021 at 05:35:56PM -0500, Bill Schmidt wrote:
> Previously zero-width bit fields were removed from structs, so that
> otherwise
> homogeneous aggregates were treated as such and passed in FPRs and VSRs.
> This was incorrect behavior per the ELFv2 ABI. Now that
;
+ }
So, from what you wrote, :0 in the ppc* psABIs the intent is that :0 is not
ignored, right?
In that case I don't really understand the above (the continue in
particular). Because the continue means it is ignored for C++ and not
ignored for C, so basically you return to the 4.5-11 ABI
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
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
;
> > > > + }
>
> So, from what you wrote, :0 in the ppc* psABIs the intent is that :0 is not
> ignored, right?
> In that case I don't really understand the above (the continue in
> particular). Because the continue means it is ignored for C++ and not
> igno
.
So, for most backends, C and C++ was ABI compatible in presence of :0
initially, then for several got incompatible in 4.5 and now is time to
decide for each backend what to do according to their psABI, if :0 should be
ignored or not during the function arg/return value passing decisions.
> > &
ABI. Now that these fields are no
longer being removed, we generate the correct parameter passing code. Alert
the unwary user in the rare cases where this behavior changes.
As noted in the PR, once the GCC 12 Changes page has text describing this issue,
we can update the diagnostic message
On Tue, 2021-09-21 at 17:35 -0500, Bill Schmidt wrote:
> Hi!
>
> Previously zero-width bit fields were removed from structs, so that otherwise
> homogeneous aggregates were treated as such and passed in FPRs and VSRs.
> This was incorrect behavior per the ELFv2 ABI. Now th
Hi!
Previously zero-width bit fields were removed from structs, so that otherwise
homogeneous aggregates were treated as such and passed in FPRs and VSRs.
This was incorrect behavior per the ELFv2 ABI. Now that these fields are no
longer being removed, we generate the correct parameter passing
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,
>
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
tion), 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 memcm
not 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,
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-time
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 pro
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 th
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 possibil
ms 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 possibility of depending on the
> >> > bcmp-like beha
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 uses
ntation), 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 directly, __me
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
> >
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
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
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
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
int ret;
> size_t i;
> const char *s1c, *s2c;
> s1c = (const char*)s1;
> s2c = (const char*)s2;
> for (i = 0, ret = 0; ret == 0 && i < n; ++i) {
> ret = s1c[i] - s2c[i]
> }
> return ret;
> }
>
>
> Notes ###
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 from bo
801 - 900 of 5007 matches
Mail list logo
