ey
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 thinks it cannot use the
atomic inst
On 20/12/16 13:26, Ulrich Weigand wrote:
> Torvald Riegel wrote:
>> On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote:
>>> On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote:
>>>> Thanks for the comment. Yes, the ABI requires libatomic must que
Torvald Riegel wrote:
> On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote:
> > On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote:
> > > Thanks for the comment. Yes, the ABI requires libatomic must query the
> > > hardware. This is
> > >
On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote:
> On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote:
> > Hi Szabolcs,
> >
> > > On Nov 29, 2016, at 3:11 AM, Szabolcs Nagy wrote:
> > >
> > > On 17/11/16 20:12, Bin Fan wrote:
>
On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote:
> Hi Szabolcs,
>
> > On Nov 29, 2016, at 3:11 AM, Szabolcs Nagy wrote:
> >
> > On 17/11/16 20:12, Bin Fan wrote:
> >>
> >> Although this ABI specification specifies that 16-byte proper
Hi Szabolcs,
> On Nov 29, 2016, at 3:11 AM, Szabolcs Nagy wrote:
>
> On 17/11/16 20:12, Bin Fan wrote:
>>
>> Although this ABI specification specifies that 16-byte properly aligned
>> atomics are inlineable on platforms
>> supporting cmpxchg16b, we docu
On 17/11/16 20:12, Bin Fan wrote:
>
> Although this ABI specification specifies that 16-byte properly aligned
> atomics are inlineable on platforms
> supporting cmpxchg16b, we document the caveats here for further discussion.
> If we decide to change the
> inlineable attribute
Got an error from gcc@gcc.gnu.org alias. Remove the pdf attachment and
re-send it to the alias ...
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
this
Maciej Rozycki writes:
> I'm back to this effort now, thanks for patience.
Likewise, this thread got buried in email. At the risk of further delaying
this work I do still have issues with the design.
> > > 3.4 Relocatable Object Generation
> > >
> > > Tools that produce relocatable objects suc
On Sun, 4 Sep 2016, Uros Bizjak wrote:
> It looks that different handling of _Complex char, _Complex short and
> _Complex float is there on purpose. Is (was?) there a limitation in a
> c language standard that prevents passing of these arguments as
> varargs?
Well, ISO C doesn't define complex in
; one in the GCC testsuite rather than relying on a libffi test to test
>> GCC.)
>
> And if it is in g*.dg/compat/, it can even test ABI compatibility between
> different compilers or their versions.
What bothers me is the comment in
testsuite/gcc.dg/compat/scalar-by-value-4_main.c
es
not use FP instructions. (Formally, of course code knowing the ABI can
creating encodings directly, implement issignaling itself, etc., but that
should be rare.)
--
Joseph S. Myers
jos...@codesourcery.com
Hi Matthew,
I'm back to this effort now, thanks for patience.
> Thanks for the update. I've read through the whole proposal again and
> it looks good. I'd like to discuss legacy objects a bit more though...
Thanks for your review.
> > 3.4 Relocatable Object Generation
> >
> > Tools that p
this is an area where GNU strays from the N64 ABI definition but
> is defacto standard. TestA is a struct of two floating point fields which
> is passed and returned in FP registers. TestB is a struct of a struct of
> two floating point fields (or at least I think that is the interpretatio
Heiher writes:
> Looks the return value of TestNewA is passed on $f0/$f2 from disassembly
> code. I don't known why the return value of TestNewB is passed on
> $v0/$v1? a bug?
I believe this is an area where GNU strays from the N64 ABI definition but
is defacto standard. TestA
Hi,
Looks the return value of TestNewA is passed on $f0/$f2 from
disassembly code. I don't known why the return value of TestNewB is
passed on $v0/$v1? a bug?
229 00012c40 <_Z8TestNewAv>:
23012c40: 3c030002lui v1,0x2
23112c44: 0079182ddaddu v1,v1
Hi Maciej,
Thanks for the update. I've read through the whole proposal again and
it looks good. I'd like to discuss legacy objects a bit more though...
Maciej Rozycki writes:
> 3.4 Relocatable Object Generation
>
> Tools that produce relocatable objects such as the assembler shall
> always p
Dear fellow developers,
Here is the second revision of the ABI extension specification previously
posted, incorporating feedback received for the first revision. Changes
have been made to Section 4 "Implementation Notes", the remaining parts
have stayed the same. The master co
On Tue, Apr 5, 2016 at 2:45 AM, Umesh Kalappa wrote:
> I need to ,make the changes only to the function args(varargs),hence
> making the changes in TARGET_PROMOTE_FUNCTION_MODE will do ?.
If TARGET_PROMOTE_FUNCTION_MODE disagrees with PROMOTE_MODE, it is
possible that the middle end may generat
04/2016 08:55 AM, Umesh Kalappa wrote:
>>
>> We are in process of changing the gcc compiler for aarch64 abi ,w.r.t
>> varargs function arguments handling.
>>
>> default(LP64) ,where 1,2,4 bytes args are promoted to word size i.e 4
>> bytes ,we need to change th
On 04/04/2016 08:55 AM, Umesh Kalappa wrote:
We are in process of changing the gcc compiler for aarch64 abi ,w.r.t
varargs function arguments handling.
default(LP64) ,where 1,2,4 bytes args are promoted to word size i.e 4
bytes ,we need to change these behaviour to 8 bytes (double word).
we
Hi All,
We are in process of changing the gcc compiler for aarch64 abi ,w.r.t
varargs function arguments handling.
default(LP64) ,where 1,2,4 bytes args are promoted to word size i.e 4
bytes ,we need to change these behaviour to 8 bytes (double word).
we are looking both hooks like
On Sun, 14 Feb 2016, Suprateeka R Hegde wrote:
> On 11-Feb-2016 10:08 PM, Joseph Myers wrote:
> > I think that none of the ABI extensions in question are anything to do
> > with Linux, the kernel. Rather, they are ABI extensions for userspace in
> > the GNU system, which
0/LSB-Core-generic/LSB-Core-generic/progheader.html
lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
But it gives no details. Linux ABI group is the place where we propose
extensions before they get implemented.
How to implement, according to me, is design details of a particular
product. It
On Thu, Feb 11, 2016 at 10:50:29AM -0500, Ed Maste via llvm-commits wrote:
> On 8 February 2016 at 18:08, Joseph Myers wrote:
> > On Mon, 8 Feb 2016, H.J. Lu wrote:
> >
> >> >> I was referring to program properties:
> >> >>
> >> >> htt
neric/progheader.html
lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
But it gives no details. Linux ABI group is the place where we propose
extensions before they get implemented.
How to implement, according to me, is design details of a particular
product. It also depends on the language
for all
> discussions.
>
> What do you think?
I think that none of the ABI extensions in question are anything to do
with Linux, the kernel. Rather, they are ABI extensions for userspace in
the GNU system, which apply the same under multiple kernels (but some of
them may well not appl
t;> discussions.
>>>
>>> What do you think?
>>>
>>
>> LSB lists extensions which have been implemented. But it isn't a spec
>> you can use to implement them. For example:
>>
>>
>> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core
ut it gives no details. Linux ABI group is the place where we propose
extensions before they get implemented.
How to implement, according to me, is design details of a particular
product. It also depends on the language used to develop the product.
Standards, in most cases, are not tied to a lan
On 8 February 2016 at 18:08, Joseph Myers wrote:
> On Mon, 8 Feb 2016, H.J. Lu wrote:
>
>> >> I was referring to program properties:
>> >>
>> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>> >
>> > This looks mo
, PT_GNU_STACK and PT_GNU_RELRO.
But it gives no details. Linux ABI group is the place where we propose
extensions before they get implemented.
--
H.J.
:
On Mon, Feb 8, 2016 at 3:08 PM, Joseph Myers wrote:
On Mon, 8 Feb 2016, H.J. Lu wrote:
I was referring to program properties:
https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
This looks more like an ELF topic to me, not really ABI.
Please discuss this on a GNU project list
On Mon, Feb 8, 2016 at 3:08 PM, Joseph Myers wrote:
> On Mon, 8 Feb 2016, H.J. Lu wrote:
>
>> >> I was referring to program properties:
>> >>
>> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>> >
>> > This looks mo
On Mon, 8 Feb 2016, H.J. Lu wrote:
> >> I was referring to program properties:
> >>
> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
> >
> > This looks more like an ELF topic to me, not really ABI.
> >
> > Please discus
fication and extension of generic System V Application Binary
>>>> Interface:
>>>>
>>>> https://groups.google.com/d/forum/linux-abi
>>>>
>>>> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
>>>>
gt;>> https://groups.google.com/d/forum/linux-abi
>>>
>>> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
>>> I will propose some new extensions soon.
>>
>> Why can't you use the existing C++ ABI list? Is there no overlap at
>
//groups.google.com/d/forum/linux-abi
>>
>> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
>> I will propose some new extensions soon.
>>
>
> seems to require a registered email address at google.
> (and the archive does not work from any cons
On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>> I created a mailing list to discuss Linux specific,.processor independent
>> modification and extension of generic System V Application Binary Interface:
>>
>> https://groups.google.com/d/foru
* H.J. Lu [2016-02-08 11:24:53 -0800]:
> I created a mailing list to discuss Linux specific,.processor independent
> modification and extension of generic System V Application Binary Interface:
>
> https://groups.google.com/d/forum/linux-abi
>
> I will start to docum
* H. J. Lu:
> I created a mailing list to discuss Linux specific,.processor independent
> modification and extension of generic System V Application Binary Interface:
>
> https://groups.google.com/d/forum/linux-abi
>
> I will start to document existing Linux extensions, like
Hi,
I created a mailing list to discuss Linux specific,.processor independent
modification and extension of generic System V Application Binary Interface:
https://groups.google.com/d/forum/linux-abi
I will start to document existing Linux extensions, like STT_GNU_IFUNC.
I will propose some new
On Fri, 27 Nov 2015, Joseph Myers wrote:
> > I find it highly unlikely though that the writers will (be able to) chase
> > individual targets and any obscure hardware-dependent options the targets
> > may provide. And we cannot expect people compiling software to be
>
> What that says to me i
On Fri, 27 Nov 2015, Maciej W. Rozycki wrote:
> I find it highly unlikely though that the writers will (be able to) chase
> individual targets and any obscure hardware-dependent options the targets
> may provide. And we cannot expect people compiling software to be
What that says to me is tha
gets
may provide. And we cannot expect people compiling software to be
educated enough to understand all the complexities behind all the
standards and particular implementations involved.
What I think we therefore need is an option that, on top of the generic
compiler options like ones you've
On Fri, 20 Nov 2015, Maciej W. Rozycki wrote:
> The target audience for the `-mieee=strict' option is in my idea a
> non-technical user, say a physicist, who does not necessarily know or is
> fluent with the guts of computer hardware and who has the need to build
> and reliably run their softw
On Tue, 17 Nov 2015, Joseph Myers wrote:
> > Any or all of these options may have effects beyond propagating the IEEE
> > Std 754 compliance mode down to the assembler and the linker. In
> > particular `-mieee=strict' is expected to guarantee code generated to
> > fully comply to IEEE Std 754 ra
On Sat, 14 Nov 2015, Maciej W. Rozycki wrote:
> Any or all of these options may have effects beyond propagating the IEEE
> Std 754 compliance mode down to the assembler and the linker. In
> particular `-mieee=strict' is expected to guarantee code generated to
> fully comply to IEEE Std 754 rathe
cording to the usual way assumed for the environment used, which may be
> > a command-line option, a property setting, etc.
> >
> > In the `strict' linking mode both `strict' and `legacy' objects can be
> > linked together. All shall follow the same legacy-NaN or 20
gt; a command-line option, a property setting, etc.
>
> In the `strict' linking mode both `strict' and `legacy' objects can be
> linked together. All shall follow the same legacy-NaN or 2008-NaN ABI, as
> denoted by the EF_MIPS_NAN2008 flag described in Section 3.1. T
Dear fellow developers,
On behalf of Imagination Technologies I would like to introduce the
following ABI extension to create a compatibility solution for opposing
NaN encodings. I will appreciate your feedback and will happily answer
any questions and address any concerns you may have.
A
On 10/07/2015 11:34 AM, Ramana Radhakrishnan wrote:
On Wed, Oct 7, 2015 at 6:22 PM, Joseph Myers wrote:
On Wed, 7 Oct 2015, Jeff Law wrote:
I'm not sure why this attribute isn't documented, but clearly that should be
fixed.
I assume the reasoning was: we document support for Cilk+ (and what
nted). When it becomes a generic
GNU C attribute, that reasoning no longer applies.
Seems reasonable. I had a suspicion it was something of this nature.
I thought the ABI for this stuff was consistent across the implementations
(that was certainly the goal). So aside from an example of how to us
On Wed, Oct 7, 2015 at 6:22 PM, Joseph Myers wrote:
> On Wed, 7 Oct 2015, Jeff Law wrote:
>
>> I'm not sure why this attribute isn't documented, but clearly that should be
>> fixed.
>
> I assume the reasoning was: we document support for Cilk+ (and what's
> included in Cilk+ is externally document
GNU C attribute, that reasoning no longer applies.
> I thought the ABI for this stuff was consistent across the implementations
> (that was certainly the goal). So aside from an example of how to use the
> attribute to get calls into the vector math library, I'm not sure what's
>
exi, and you'll need to include documentation in
your GCC patch that makes this a generic extension rather than just part
of Cilkplus, and (b) you'll need to agree with the x86_64 ABI mailing list
an extension of the ABI document (as attached to
<https://sourceware.org/glibc/wiki/libmv
o include documentation in
your GCC patch that makes this a generic extension rather than just part
of Cilkplus, and (b) you'll need to agree with the x86_64 ABI mailing list
an extension of the ABI document (as attached to
<https://sourceware.org/glibc/wiki/libmvec>) to cover thi
Hello,
Recently vector ABI was introduced into GCC
Vector versions of math functions were incorporated in to GlibC
starting from v2.22.
Unfortunately, to get this functions work `-fopenmp'
switch must be added to compiler invocation. This is due to the fact that
vector variant of math func
At Cauldron this year, several people complained to me that our latest
ABI document was behind a registration wall. I'm happy to say that
we've finally gotten past the issues that were holding it there, and it
is now openly available at:
https://members.openpowerfoundation.org/docum
Oops. Hit the wrong button. I will check it in.
Thanks.
-- Forwarded message --
From: Uros Bizjak
Date: Sat, Dec 27, 2014 at 7:41 AM
Subject: Re: PATC: PR target/64409: ICE building Mesa 10.4.0 for x32 ABI
To: "H.J. Lu"
On Sat, Dec 27, 2014 at 3:54 PM, H.J. Lu w
exact vector function name.
Here is description of exact meaning of “#pragma omp declare simd” for x86_64.
This is proposed as agreement between compilers supporting OpenMP.
*** OpenMP vector function ABI for x86_64 ***
Name of vector math function is based on Intel Vector
On Tue, 4 Nov 2014, Tedeschi, Walfred wrote:
> Hello All,
>
> We would like to ping this patch:
> https://sourceware.org/ml/libc-alpha/2013-08/msg00482.html
This isn't a glibc / GCC / binutils patch. Try the
x86-64-...@googlegroups.com list instead.
--
Joseph S. Myers
jos...@codesourcery.com
Hello All,
We would like to ping this patch:
https://sourceware.org/ml/libc-alpha/2013-08/msg00482.html
We have some modifications on GDB side that depends on those changes.
Thanks and regards,
Walfred Tedeschi
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gese
and less cache misses happen.
Is this the same case for AArch64 ILP32 ABI?
2nd idea is that if integers are of 32 bit size, than 2 times more
integers can be saved in CPU registers than if they were of 64 bit size,
and thus less loads/stores to the memory are needed.
2. What's the cu
Hello All,
We would like to ping this patch:
https://sourceware.org/ml/libc-alpha/2013-08/msg00482.html
We have some modifications on GDB side that depends on those changes.
Thanks and regards,
Walfred Tedeschi
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gese
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Richard Sandiford writes:
>> >> Matthew Fortune writes:
>> >> > As it stands I wasn't planning on supporting .module arch= I was
>> >> > just going to add .module fp= and leave it at that. The only thing
>> >>
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> > As it stands I wasn't planning on supporting .module arch= I was
> >> > just going to add .module fp= and leave it at that. The only thing
> >> > I need to give assembly code wr
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > As it stands I wasn't planning on supporting .module arch= I was just
>> > going to add .module fp= and leave it at that. The only thing I need
>> > to give assembly code writers absolute control over is the over
Richard Sandiford writes:
> Matthew Fortune writes:
> > As it stands I wasn't planning on supporting .module arch= I was just
> > going to add .module fp= and leave it at that. The only thing I need
> > to give assembly code writers absolute control over is the overall FP
> > mode of the module.
Matthew Fortune writes:
> As it stands I wasn't planning on supporting .module arch= I was just
> going to add .module fp= and leave it at that. The only thing I need to
> give assembly code writers absolute control over is the overall FP mode
> of the module. I don't currently see any real need t
Richard Sandiford writes:
> Matthew Fortune writes:
> >> > With these defaults, the closest supported ABI is used for each
> >> > architecture based on the --with-o32-fp build option. The only one
> >> > I really care about is the middle one as it ma
Matthew Fortune writes:
>> > With these defaults, the closest supported ABI is used for each
>> > architecture based on the --with-o32-fp build option. The only one I
>> > really care about is the middle one as it makes full use of the O32
>> > FPXX ABI withou
use of fpxx by default to a configure time setting is OK
> >> > with me. When enabled it would still have to follow the rules as
> >> > defined in the design in that it can only apply to architectures
> >> > that can support the variant.
> >>
> >&
Richard Sandiford writes:
> Matthew Fortune writes:
> > The spec on:
> > https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinki
> > ng has been updated and attempts to account for all the feedback. Not
> > everything has been possible to simplify/rework as requested but I
> > beli
Matthew Fortune writes:
> The spec on:
> https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
> has been updated and attempts to account for all the feedback. Not
> everything has been possible to simplify/rework as requested but I
> believe I have managed to address many point
to architectures that
>> > can support the variant.
>>
>> Right. It's really equivalent to putting the -mfp on every command line
>> that doesn't have one.
>>
>> > Currently that means everything but mips1.
>>
>> Yeah, using -mips1 on a
oesn't have one.
>
> > Currently that means everything but mips1.
>
> Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
>
> > I'm not sure this is the same as tying an ABI to an architecture as
> > both fp32 and fpxx are O32 and lin
using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
> I'm not sure this is the same as tying an ABI to an architecture as
> both fp32 and fpxx are O32 and link compatible. Perhaps the configure
> switch would be --with-o32-fp={32|64|xx}. This shows it is just an O
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> > Are you're OK with automatically selecting fpxx if no -mfp option,
> >> > no .module and no .gnu_attribute exists? Such code woul
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Are you're OK with automatically selecting fpxx if no -mfp option, no
>> > .module and no .gnu_attribute exists? Such code would currently end up
>> > as FP ABI Any eve
Richard Sandiford writes:
> Matthew Fortune writes:
> > Are you're OK with automatically selecting fpxx if no -mfp option, no
> > .module and no .gnu_attribute exists? Such code would currently end up
> > as FP ABI Any even if FP code was present, I don't suppose
Matthew Fortune writes:
> Are you're OK with automatically selecting fpxx if no -mfp option, no
> .module and no .gnu_attribute exists? Such code would currently end up
> as FP ABI Any even if FP code was present, I don't suppose anything
> would get worse if this exi
verride it. Will there be any problems with a new ways
> >> > to
> >> generate a gnu attribute?
> >>
> >> I think we should just give an error if any .gnu_attributes are
> >> inconsistent with the module-level setting (whether that comes from
> >> .m
ttributes are
>> inconsistent with the module-level setting (whether that comes from
>> .module or command-line flags).
>
> I would need to account for the -msoft-float and -msingle-float command
> line options to calculate module-level setting in order to do this,
> which is fine
gt; > would override it. Will there be any problems with a new ways to
> generate a gnu attribute?
>
> I think we should just give an error if any .gnu_attributes are
> inconsistent with the module-level setting (whether that comes from
> .module or command-line flags).
I would
Matthew Fortune writes:
>> > Sorry, forgot about that. In that case maybe program headers would be
>> > best, like you say. I.e. we could use a combination of GNU attributes
>> > and a new program header, with the program header hopefully being more
>> > general than for just this case. I suppo
> > Sorry, forgot about that. In that case maybe program headers would be
> > best, like you say. I.e. we could use a combination of GNU attributes
> > and a new program header, with the program header hopefully being more
> > general than for just this case. I suppose this comes back to the
> >
> Matthew Fortune writes:
> >> >> If we do end up using ELF flags then maybe adding two new
> >> >> EF_MIPS_ABI enums would be better. It's more likely to be trapped
> >> >> by old loaders and avoids eating up those precious remaining bits.
> >> >
> >> > Sound's reasonable but I'm still trying to
Matthew Fortune writes:
> That sounds OK to me.
>
> I'm aiming to have an experimental implementation of the calling
> convention changes as soon as possible although I am having difficulties
> getting the frx calling convention working correctly.
>
> The problem is that frx needs to treat registe
Matthew Fortune writes:
>> >> If we do end up using ELF flags then maybe adding two new EF_MIPS_ABI
>> >> enums would be better. It's more likely to be trapped by old loaders
>> >> and avoids eating up those precious remaining bits.
>> >
>> > Sound's reasonable but I'm still trying to determine h
Richard Sandiford writes
> Doug Gilmore writes:
> > On 02/24/2014 10:42 AM, Richard Sandiford wrote:
> >>...
> >>> AIUI the old form never really worked reliably due to things like
> >>> newlib's setjmp not preserving the odd-numbered registers, so it
> >>> doesn't
> seem worth keeping aroun
Doug Gilmore writes:
> On 02/24/2014 10:42 AM, Richard Sandiford wrote:
>>...
>>> AIUI the old form never really worked reliably due to things like
>>> newlib's setjmp not preserving the odd-numbered registers, so it doesn't
seem worth keeping around. Also, the old form is identified by the
Richard Sandiford writes
> >> AIUI the old form never really worked reliably due to things like
> >> newlib's setjmp not preserving the odd-numbered registers, so it
> >> doesn't seem worth keeping around. Also, the old form is identified
> >> by the GNU attribute (4, 4) so it'd be easy for the l
On 02/24/2014 10:42 AM, Richard Sandiford wrote:
>...
>> AIUI the old form never really worked reliably due to things like
>> newlib's setjmp not preserving the odd-numbered registers, so it doesn't
>>> seem worth keeping around. Also, the old form is identified by the GNU
>>> attribute (4, 4) so
Matthew Fortune writes:
> Richard Sandiford writes
>> I understand the need to deprecate the current -mgp32 -mfp64 behaviour.
>> I don't think we should deprecate -mfp64 itself though. Instead, why
>> not keep -mfp32 as meaning FR0, -mfp64 meaning FR1 and add -mfpxx for
>> modeless? So rather t
Richard Sandiford writes
> Matthew Fortune writes:
> > All,
> >
> > Imagination Technologies would like to introduce the design of an O32
> > ABI extension for MIPS to allow it to be used in conjunction with MIPS
> > FPUs having 64-bit floating-point registers. T
Matthew Fortune writes:
> All,
>
> Imagination Technologies would like to introduce the design of an O32
> ABI extension for MIPS to allow it to be used in conjunction with MIPS
> FPUs having 64-bit floating-point registers. This is a wide-reaching
> design that involves changes
All,
Imagination Technologies would like to introduce the design of an O32 ABI
extension for MIPS to allow it to be used in conjunction with MIPS FPUs having
64-bit floating-point registers. This is a wide-reaching design that involves
changes to all components of the MIPS toolchain it is
0-i386/i386-unknown-freebsd10.0/include -isystem
/home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.0/sys-include -shared
-nostdlib /usr/lib/crti.o
/scratch2/tmp/gerald/OBJ-1031-1937/./gcc/crtbeginS.o .libs/cilk-abi-vla.o
.libs/os-unix-sysdep.o .libs/bug.o .libs/cilk-abi.o
.libs/cilk-abi-cilk-
@gcc.gnu.org
Subject: Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c
failure
Jakub Jelinek writes:
> On Thu, Oct 31, 2013 at 01:32:19PM +, Iyer, Balaji V wrote:
>> > It is not just about not including 3, but also the []s in
>> > configure.ac were eaten by m4. I
Jakub Jelinek writes:
> On Thu, Oct 31, 2013 at 01:32:19PM +, Iyer, Balaji V wrote:
>> > It is not just about not including 3, but also the []s in configure.ac
>> > were eaten by
>> > m4. In any case, shouldn't you fix also config/generic?
>> >
>>
>> I am in the process of fixing config/ge
201 - 300 of 809 matches
Mail list logo
