Joseph S. Myers wrote:
> On Sun, 24 May 2009, Andrew Haley wrote:
>
>> Of course we have to fix the assembler output. For [any] two declarations
>> a and b, &a != &b, even when a is a zero-length array. So, you have to
>> allocate at least one byte.
>
> I don't think this is necessarily part of
Hi,
I'd like to support sibling calls for a target where function args can
be passed in call-saved registers, namely AVR.
The trouble is this: If a callee gets some arguments passed on the stack
or in call-saved regs, the callee is not ok for a sibling call. That's
because sibcall_epilogue e
Hi,
I am trying to build a MinGW toolchain for M16CM32C target using the following
sources:
GCC-4.4.0
Binutils-2.19
Newlib-1.17
The linux toolchain was built successfully, however MinGW toolchain build
failed.
During make, I get the following error.
2009/5/29 Mahesh Basavaraj Shavari :
> Hi,
> I am trying to build a MinGW toolchain for M16CM32C target using the
> following sources:
>
> GCC-4.4.0
> Binutils-2.19
> Newlib-1.17
>
> The linux toolchain was built successfully, however MinGW toolchain build
> failed.
> During make, I get the follo
2009/5/29 Kai Tietz :
> 2009/5/29 Mahesh Basavaraj Shavari :
>> Hi,
>> I am trying to build a MinGW toolchain for M16CM32C target using the
>> following sources:
>>
>> GCC-4.4.0
>> Binutils-2.19
>> Newlib-1.17
>>
>> The linux toolchain was built successfully, however MinGW toolchain build
>> fail
Kai Tietz wrote:
> Second remark. In you build line there is a typo. Not sure if this a
> paste issue, but
>
> ... "win/../compat/strtoull.c -o strtoull.o o tcl.res.o" ...
>
> is wrong. There is a '-' missing before 'o'. It should be something like
>
> ... "win/../compat/strtoull.c -o strtoull.
Georg-Johann Lay wrote:
> The trouble is this: If a callee gets some arguments passed on the stack
> or in call-saved regs, the callee is not ok for a sibling call. That's
> because sibcall_epilogue executes before sibcall insns.
>
> All this information is pretty easy available in FUNCTION_ARGS
Georg-Johann Lay writes:
> The trouble is this: If a callee gets some arguments passed on the
> stack or in call-saved regs, the callee is not ok for a sibling
> call. That's because sibcall_epilogue executes before sibcall insns.
I'm having trouble with your terminology "call-saved regs". Do t
While looking into PR 37565 I began to wonder if we need to modify how
we handle optimization flag handling. Currently we have
OVERRIDE_OPTIONS, C_COMMON_OVERRIDE_OPTIONS, and OPTIMIZATION_OPTIONS to
set or override the optimization flags a user gives. One proposal to
fix 37565 was to split OVERR
Ian Lance Taylor schrieb:
Georg-Johann Lay writes:
The trouble is this: If a callee gets some arguments passed on the
stack or in call-saved regs, the callee is not ok for a sibling
call. That's because sibcall_epilogue executes before sibcall insns.
I'm having trouble with your terminology
Dave Korn schrieb:
Georg-Johann Lay wrote:
The trouble is this: If a callee gets some arguments passed on the stack
or in call-saved regs, the callee is not ok for a sibling call. That's
because sibcall_epilogue executes before sibcall insns.
All this information is pretty easy available in FU
Georg-Johann Lay wrote:
> But this will only (or is intended to) track information for the caller,
> not information needed for the callee that was gathered in the mentioned
> hooks. It can be used, of course, to exchange data between hooks
> provided with CUMULATIVE_ARGS and hooks that aren't, bu
Georg-Johann Lay wrote:
> Yes that's right. It would work if I recreate the information which code
> a couple of lines away did already, I just wanted to avoid doubling
> (some parts of) the code/work in order to keep the backend clean.
Well, then don't! Factor out the common parts of your sta
Steve Ellcey writes:
> So instead of
> if (flag_var_tracking)
> we would have
> if (targetm.get_optimization_flag_value(OPT_fvar_tracking))
I don't particularly want to have to make an indirect function call
every time we check a flag. I don't see why we should check every time
whe
On Fri, 29 May 2009, Steve Ellcey wrote:
> While looking into PR 37565 I began to wonder if we need to modify how
> we handle optimization flag handling. Currently we have
> OVERRIDE_OPTIONS, C_COMMON_OVERRIDE_OPTIONS, and OPTIMIZATION_OPTIONS to
> set or override the optimization flags a user gi
Ian Lance Taylor wrote:
> Steve Ellcey writes:
>
>> So instead of
>> if (flag_var_tracking)
>> we would have
>> if (targetm.get_optimization_flag_value(OPT_fvar_tracking))
>
> I don't particularly want to have to make an indirect function call
> every time we check a flag. I don't se
On Fri, 2009-05-29 at 09:38 -0700, Ian Lance Taylor wrote:
> Steve Ellcey writes:
>
> > So instead of
> > if (flag_var_tracking)
> > we would have
> > if (targetm.get_optimization_flag_value(OPT_fvar_tracking))
>
> I don't particularly want to have to make an indirect function call
> ev
On Fri, 2009-05-29 at 16:56 +, Joseph S. Myers wrote:
> I don't really feel that either the original proposal or this one is any
> cleaner than what we have right now, and the original proposal is at least
> simpler. As neither really addresses the general issues with how options
> are han
I've put at
http://www.math.purdue.edu/~lucier/bugzilla/9/
some compile-time and run-time statistics related to PR 39157 and PR
33928 and compile times and run times for the programs in the Gambit
Scheme benchmark suite. The statistics are for 4.1.2 release, 4.2.4
release, 4.3.3 release, 4.4.1 2
Steve Ellcey writes:
> On Fri, 2009-05-29 at 09:38 -0700, Ian Lance Taylor wrote:
>> Steve Ellcey writes:
>>
>> > So instead of
>> >if (flag_var_tracking)
>> > we would have
>> >if (targetm.get_optimization_flag_value(OPT_fvar_tracking))
>>
>> I don't particularly want to have to make
Hi,
We are using ARM Cortex-A9 processor. The toolchain is gcc-4.0.0 with
uClibc-0.9.30 and the kernel is 2.6.28.
Using this toolchain when we build any application like "Hello World"
and link it against pthread lib, the application does a segmentation
fault when executed on target and gives "Ill
This is the beta release of binutils 2.19.51.0.6 for Linux, which is
based on binutils 2009 0529 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
Nitin Garg writes:
> We are using ARM Cortex-A9 processor. The toolchain is gcc-4.0.0 with
> uClibc-0.9.30 and the kernel is 2.6.28.
>
> Using this toolchain when we build any application like "Hello World"
> and link it against pthread lib, the application does a segmentation
> fault when execut
On Wed, 13 May 2009, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
>
> > 1. Consider MPC as an optional library now, install all the code and make
> > it hard-required only when all the complex math functions are made
> > available in a future released version of the library or sometime in
24 matches
Mail list logo
