Hello,
the file libgcc/gthr.h defines the interface for the thread support used
by libgcc2 and C11. A couple of types are required, e.g.
__gthread_key_t
Is it allowed to copy objects of this type? For example is the
following a valid use case
__gthread_key_t k1;
__gthread_key
Hi.
I'm building libgcc for a "iamcu" target (Pentium-like but with
soft-fp emulation, the only x86 with SoftFP I know) with
--enable-target-optspace.
It works properly but I noticed that code the size for many arithmetic
functions is much more larger than for soft-fp emulation provided by
LLVM
On Tue, Jun 30, 2015 at 4:33 AM, Zinovy Nis wrote:
> Hi.
>
>
> I'm building libgcc for a "iamcu" target (Pentium-like but with
> soft-fp emulation, the only x86 with SoftFP I know) with
> --enable-target-optspace.
Support for i?86*-*-elfiamcu target has been checked in as of
revision 225199.
>
On Tue, 30 Jun 2015, Zinovy Nis wrote:
> It works properly but I noticed that code the size for many arithmetic
> functions is much more larger than for soft-fp emulation provided by
> LLVM's compiler_rt library.
Code size is discussed in the paper about soft-fp in the 2006 Summit
proceedings.
On Tue, Jun 30, 2015 at 10:44 AM, Joseph Myers wrote:
> On Tue, 30 Jun 2015, Zinovy Nis wrote:
>
>> It works properly but I noticed that code the size for many arithmetic
>> functions is much more larger than for soft-fp emulation provided by
>> LLVM's compiler_rt library.
>
> Code size is discuss
On 6/30/2015 1:42 PM, H.J. Lu wrote:
On Tue, Jun 30, 2015 at 10:44 AM, Joseph Myers wrote:
On Tue, 30 Jun 2015, Zinovy Nis wrote:
It works properly but I noticed that code the size for many arithmetic
functions is much more larger than for soft-fp emulation provided by
LLVM's compiler_rt li
On Tue, 30 Jun 2015, H.J. Lu wrote:
> > soft-fp is expected to be used on 32-bit and 64-bit systems for which a
> > few kB code size is insignificant.
>
> Size is very important for IA MCU. Would it be acceptable to update
> soft-fp to optimize for size with
>
> #ifdef __OPTIMIZE_SIZE__
> #else
I have a series of patches to convert all non-optab instructions to
the target-insns.def interface. config-list.mk showed up one problem
though. The pa indirect_jump pattern is:
;;; Hope this is only within a function...
(define_insn "indirect_jump"
[(set (pc) (match_operand 0 "register_operan
I'm interested in your thoughts on fixing c++/65945 in 5.2.
It's trivial to fix the alignment of nullptr_t, but I was concerned
about ABI impact. On further research it seems that it won't cause any
trouble with argument alignment, since that doesn't seem to rely on
TYPE_ALIGN at all; I think
Hi all-
I'm working on a massive set of cleanups to Linux's syscall handling.
We currently have a nasty optimization in which we don't save rbx,
rbp, r12, r13, r14, and r15 on x86_64 before calling C functions.
This works, but it makes the code a huge mess. I'd rather save all
regs in asm and the
I would think pmode_register_operand is correct. Then, condition can be
removed.
Dave
On 2015-06-30 4:53 PM, Richard Sandiford wrote:
I have a series of patches to convert all non-optab instructions to
the target-insns.def interface. config-list.mk showed up one problem
though. The pa indir
On 06/30/2015 02:22 PM, Andy Lutomirski wrote:
> Hi all-
>
> I'm working on a massive set of cleanups to Linux's syscall handling.
> We currently have a nasty optimization in which we don't save rbx,
> rbp, r12, r13, r14, and r15 on x86_64 before calling C functions.
> This works, but it makes the
On Tue, Jun 30, 2015 at 02:22:33PM -0700, Andy Lutomirski wrote:
> I'm working on a massive set of cleanups to Linux's syscall handling.
> We currently have a nasty optimization in which we don't save rbx,
> rbp, r12, r13, r14, and r15 on x86_64 before calling C functions.
> This works, but it make
On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
> I'd say the most natural API for this would be to allow
> f{fixed,call-{used,saved}}-REG in target attribute.
Either that or
__attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r11)))
... just to be shorter. Either way, I would consider this
On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin wrote:
> On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
>> I'd say the most natural API for this would be to allow
>> f{fixed,call-{used,saved}}-REG in target attribute.
>
> Either that or
>
> __attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r
On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
> On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin wrote:
>> On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
>>> I'd say the most natural API for this would be to allow
>>> f{fixed,call-{used,saved}}-REG in target attribute.
>>
>> Either that or
>>
>>
On Tue, Jun 30, 2015 at 2:52 PM, H. Peter Anvin wrote:
> On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
>> On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin wrote:
>>> On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
I'd say the most natural API for this would be to allow
f{fixed,call-{used,s
On 06/30/2015 02:55 PM, Andy Lutomirski wrote:
> On Tue, Jun 30, 2015 at 2:52 PM, H. Peter Anvin wrote:
>> On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
>>> On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin wrote:
On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
> I'd say the most natural API
Snapshot gcc-5-20150630 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150630/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
On 06/30/2015 04:02 PM, H. Peter Anvin wrote:
On 06/30/2015 02:55 PM, Andy Lutomirski wrote:
On Tue, Jun 30, 2015 at 2:52 PM, H. Peter Anvin wrote:
On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin wrote:
On 06/30/2015 02:37 PM, Jakub Jelinek wro
20 matches
Mail list logo
