> Writing sed scripts that change source code is likely to be very
> unpalletable to some users. If you're working in an ISO9000
> environment where every single source line change is tracked
> by a rather burdensome process, the last thing you want to do
> is invoke that process for some source ba
On Thursday 27 October 2005 21:22, Richard Kenner wrote:
> It says it is *recommended* that $HOME/.ssh/config have permission 600.
> However, I seem to get an error if it doesn't, so I think this should be
> "required", not "recommended".
There's also a reason why it's a wiki.
Paul
> I am still working on tarballs of a .svk/local dir for people.
Any reason you're doing a tarball instead of a bootstrap dump?
http://svk.elixus.org/?SVKBootStrap
Paul
On Monday 31 October 2005 07:32, Hanzac Chen wrote:
> On 10/31/05, Hanzac Chen wrote:
> > Hi,
> >
> > Is the comment symbol for arm "@"? But the intermediate code
> > (assembler code) generated by GCC 4.1.0 (gcc-4.1-20051022) can't be
> > assembled by the latest release of binutils (binutils-2.16.
> But I'd rather do:
> svn diff Makefile.in -rgcc_4_1_1_release
>
> I.e. no silly naming of the path from the trunk root to the file, and no
> repetition of the file name itself.
$ cat `which difftag`
#! /bin/sh
if echo "$1" | grep '-branch$' > /dev/null ; then
subdir=branches
else
subdir=tags
On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote:
> Per Bothner <[EMAIL PROTECTED]> writes:
> | A "function-never-returns-null" attribute doesn't seem like
> | the right mechanism. Instead, there should be a "never-null"
> | attribute on pointer types. A "function-never-returns-null" is
On Saturday 12 November 2005 20:57, Gabriel Dos Reis wrote:
> Paul Brook <[EMAIL PROTECTED]> writes:
> | On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote:
> | > Per Bothner <[EMAIL PROTECTED]> writes:
> | > | A "function-never-returns-null" attri
> | Well in fortran, all agruments are passed via a reference so that is just
> | wrong. Using pointers there would be just wrong, as that is not the
> | semantics for the variable.
>
> So, what is the semantics? What is the real difference?
Did you actually read the thread I referenced?
The sh
On Wednesday 16 November 2005 14:35, Dorit Naishlos wrote:
> We're going to commit to autovect-branch vectorization support for
> non-unit-stride accesses.
> We'd like to suggest a few new tree-codes/optabs in order to express the
> extraction and merging of elements from/to vectors.
> Background:
> ../../../gcc-head-test/libiberty/regex.c: In function
> 'byte_common_op_match_null_string_p':
>
> ../../../gcc-head-test/libiberty/regex.c:7724: error: insn does not
> satisfy its constraints:
> (insn 158 85 159 8
> ../../../gcc-head-test/libiberty/regex.c:7699 (set
On Thursday 17 November 2005 15:20, Hans-Peter Nilsson wrote:
> > From: Paul Brook <[EMAIL PROTECTED]>
> > Date: Thu, 17 Nov 2005 15:12:50 +
> >
> > > ../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
> > >
> > >(sign_e
On Sunday 20 November 2005 00:49, Chris Lattner wrote:
> On Sun, 20 Nov 2005, Steven Bosscher wrote:
> > On Saturday 19 November 2005 18:56, Chris Lattner wrote:
> >>> Only the Ada frontend seems to be in a state to maybe support direct
> >>> frontend IR to LLVM translation.
> >>
> >> Sure, also ma
>Merging back to mirror source svn://gcc.gnu.org/svn/gcc.
You need to use svn+ssh:// . svn:// is anonymous readonly access.
Paul
I'm having problems building a canadian cross to a target that uses fixproto
(m68k-elf). There seems to be some inconsistency in how fix-headers is
build/run.
In gcc/Makefile.in we have the following comments:
# gen-protos and fix-header are compiled with CC_FOR_BUILD, but they are only
# used
> I was hoping that having it there when people did test runs would change
> the psychology; instead of having already checked in a patch, which
> we're then looking to revert, we'd be making ourselves aware of
> performance impact before check-in, even for patches that we don't
> expect to have pe
> The "-1" sentinal used for CTOR_LIST is not a representable address,
> and the code gcc ends up using compares 0x (the -1) with
> 0x00ff (what ends up in $a0) and it doesn't match.
>
> Suggestions?
Use ELF .init_array/.fini_array
Paul
On Thursday 08 December 2005 00:52, DJ Delorie wrote:
> > > The "-1" sentinal used for CTOR_LIST is not a representable address,
> > > and the code gcc ends up using compares 0x (the -1) with
> > > 0x00ff (what ends up in $a0) and it doesn't match.
> > >
> > > Suggestions?
> >
> > Use E
We (CodeSourcery) currently working on developing ColdFire targeted GNU
toolchains (gcc, etc).
Currently gcc nominally uses a 12-byte "extended" precision type for the C
"long double" floating point type. This is inherited from the m68k gcc port,
but doesn't really make a whole lot of sense for
In m68k.md we have:
;; Speed up pushing a single byte but leaving four bytes of space.
(define_peephole
[(set (mem:QI (pre_dec:SI (reg:SI SP_REG)))
(match_operand:QI 1 "general_operand" "dami"))
(set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (const_int 2)))]
The (const_int 2) looks
On Friday 16 December 2005 02:35, Andreas Schwab wrote:
> Paul Brook <[EMAIL PROTECTED]> writes:
> > In m68k.md we have:
> >
> > ;; Speed up pushing a single byte but leaving four bytes of space.
> >
> > (define_peephole
> &g
On Monday 16 January 2006 16:46, Richard Kenner wrote:
> So a naiive ./configure && make will configure for host == target ==
> powerpc64 but still (wrongly so in your opinion?) build stage1 as
> 32bit binaries (but defaulting to -m64 code generation now), and the
> following stage
On Monday 16 January 2006 17:10, Richard Kenner wrote:
> I don't see how this is any different to boostrapping gcc with any
> other system compiler. It's fairly common for the system compiler to
> use a different ABI to the new gcc. Why is 32/64-bit any different?
>
> It isn't any diffe
On Monday 16 January 2006 20:35, Leif Ekblad wrote:
> Now that I've succeeded in building both a C and C++
> cross-compiler for RDOS, I would like to build a native
> version (although it probably won't run for a while yet).
> I've tried to do it like this:
>
> ./configure --prefix=/usr/local --tar
> If you're trying to build a native hosted rdos compiler you need to have an
> rdos targeted (native hosted) cross compiler already in your path. This
> compiler will be used to build the target libraries.
Ugh. I used "native hosted" twice in the same sentence with two different
meanings. I mean
> Hi,
>
> I was having a look to this long standing, and unconfirmed, PR:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36778
>
> and the rationale makes sense to me. What do you think, shall we have
> -Wfatal-warnings too, together with -Wfatal-errors?
>
> AFAICS, the patch would be rat
> >> So, suggestions welcome. Is there a nice way to detect a signal frame?
That just makes me ask why are you're trying to detect a signal frame in the
first place?
> > Libunwind also reads the IP to detect signal frames on ARM Linux:
> > http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=b
> On 10/27/2011 02:15 AM, Paul Brook wrote:
> >>>> So, suggestions welcome. Is there a nice way to detect a signal
> >>>> frame?
> >
> > That just makes me ask why are you're trying to detect a signal frame in
> > the first place?
>
>
> I'm trying to understand what you mean, but your comments are rather
> obscure. Which file do you think I should change? Just tell me where to
> look and I'll do it.
glibc/ports/sysdeps/unix/sysv/linux/arm/eabi/sigrestorer.S Currently has:
.fnstart
.save {r0-r15}
.pad #
> So, question time again : could this be in my port, or a more
> fundamental issue as Dave hints ?
Both. By my reading the ABI you're trying to implement does not provide the
guarantees required to use iwmmxt instructions. There are ways around this,
but none of them are simple or pretty. The s
> > Both. By my reading the ABI you're trying to implement does not provide
> > the guarantees required to use iwmmxt instructions. There are ways around
> > this, but none of them are simple or pretty. The simplest answer is
> > "don't do that".
>
> Hi Paul,
>
> Thanks for the answer, but I'm not
> Do we want to enable more multilibs in arm-elf?
Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
maintenance only mode. You should be using arm-eabi.
IMHO building lots of multilibs by default significantly increases toolchain
size and build time for little actual ben
> I am happy to construct all of this on a Unix system with the various
> tools (m4 etc) available.
>
> But from the Unix system, I need to be able to generate the
> above very simple compile script, which is a precursor to creating
> very simple JCL steps (trust me, you don't want to see what
> S
> Since this will be arm-rtems multilib's when submitted,
> which variants and matches need to be added so we have
> the right libraries for all CPU model arguments. ld is
> complaining at least about libc.a mismatches for these variations.
>
> does not use Maverick instructions, whereas a.out
> > Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
> > maintenance only mode. You should be using arm-eabi.
>
> I'm possibly (probably?) wrong, but as far as I know, it forces alignment
> of 64-bit datum (namely, doubles and long longs) to 8 byte boundaries,
> which does
> Nothing you've said changes the fact that there are a class of users
> for whom that information is vital and we ought to spend some time
> thinking about how to provide the information in a form they can
> digest. GCC dumps as they exist today are largely useless for a non-GCC
> developer to u
> Here is a problem that '#' is a symbol used in my chip assembler as
> prefix before immediate. Like: MOV R0 #0x123.
> ...
> Is there any solution to solve this?
Make your assembler accept # as as a comment stat only if it appears at the
start of a line. There are several other targets (e.g. A
On Monday 21 December 2009, Mohamed Shafi wrote:
> Hi all,
>
> I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of
> scheduling framework i have to write the move patterns with more
> clarity, so that i could control the scheduling with the help of
> attributes. Re-writting the patter
> > > I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of
> > > scheduling framework i have to write the move patterns with more
> > > clarity, so that i could control the scheduling with the help of
> > > attributes. Re-writting the pattern resulted in movsi pattern with 41
> > > alte
> > > Or use the more modern iterators approach.
> >
> > Aren't iterators for generating multiple insns (e.g. movsi and movdi)
> > from the same pattern, whereas in this case we have a single insn that
> > needs to accept many different operand combinartions?
>
> Yes, but that is often better, I
On Wednesday 06 January 2010, Carrot Wei wrote:
> So thumb2 can also use the instructions similar to thumb1, right? It
> potentially has better performance and smaller code size.
Technically yes, however in ARMv7 the relevant instruction (add.n , pc)
is deprecated.
Paul
On Thursday 07 January 2010, Richard Earnshaw wrote:
> On Wed, 2010-01-06 at 18:26 +0000, Paul Brook wrote:
> > On Wednesday 06 January 2010, Carrot Wei wrote:
> > > So thumb2 can also use the instructions similar to thumb1, right? It
> > > potentially has better perfor
> > > Is there a way to get GCC to only use the FPU when we explicitly want
> > > to use it (i.e. when we use doubles/floats)? Is -msoft-float my only
> > > option here? Is there any sort of #pragma that could do the same
> > > thing as -msoft-float (I didn't see one)?
> >
> > To absolutely
On Thursday 09 October 2008, Farlie A wrote:
> Hi,
>
> Would you be willing to consider supporting the PE object formats on the
> ARM based port of ReactOS?
I'd really rather not. You should be using an EABI based target and a
postlinker, like SymbianOS does.
See
http://infocenter.arm.com/help/
> >> Would you be willing to consider supporting the PE object formats on the
> >> ARM based port of ReactOS?
> >
> > I'd really rather not. You should be using an EABI based target and a
> > postlinker, like SymbianOS does.
> >
> > See
> > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.do
On Thursday 13 November 2008, Michael Meissner wrote:
> On Thu, Nov 13, 2008 at 09:14:06PM +0100, Paul Chavent wrote:
> > Hi.
> >
> > I wonder why there aren't any endianess attributes ?
> >
> > For example we could write this :
> > int x __attribute__ ((endianess (lil))) = 0;
> >
> > Is it a silly
> > the code you provided tries to allocate a huge chunk of memory on the
> > stack.
> Interesting. At least. There should be a warning from gcc.
The limit is nothing to do with GCC. It is an OS setting (ulimit -s).
Paul
> The real heart of the matter though is that most of the people that
> contribute to gcc aren't themselves users of these targets, and so it's
> only natural that they don't know about or care about the status of any
> target-specific issues. What has worried me lately however is how much
> ELF-s
> When the offsets stored in the instructions are used, they refer to
> offsets from the address of the instruction (IA) plus 8 bytes. Are the
> pool_ranges also calculated from IA+8, from the address of the
> instruction itself or even from the address of the following
> instruction (IA+4)?
>
> In
> What are the expectations here? Do we expect simulators to set up
> argv[0]? (the m32c BSP acts like you're on real hardware) Do we expect
> simulators to blithely ignore NULL pointer references?
I think a more relevant question is whether it's ok to pass 0, {NULL} for
argc, argv. If yes then
On Tuesday 18 November 2008, DJ Delorie wrote:
> > I think a more relevant question is whether it's ok to pass 0, {NULL} for
> > argc, argv.
>
> You can do that on desktop linux, you know:
>
> execl(some_prog_name, NULL);
>
> argv[0] is NOT guaranteed to be non-NULL:
>
> ISO/IEC 9899:1999(E)
On Monday 08 December 2008, Alexandre Pereira Nunes wrote:
> A patch follows. I didn't take care of the scheduling case the correct
> way, tought (aliased to clz class).
Please read http://gcc.gnu.org/contribute.html
In particular you need a copyright assignment, ChangeLog entry, and testing.
Yo
On Tuesday 30 December 2008, Balaji V. Iyer wrote:
> I forgot to mention one important part..I am using GCC 4.0.2
The first thing you should to is update to current gcc (preferably svn trunk).
4.0.2 is really old and hasn't been maintained for quite some time. There's
a good chance things have
> For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH
> to zero. Inlining at -Os should already only happen if it decreases
> (overall!) code-size. Thus, inlining a function that is called once and
> that does not need to be emitted will always be an overall code-size
> win.
>
> > A side
> > On Thumb-2 we found that the overhead of a function call was often
> > smaller than the cost of lengthening branches in the caller.
> > It turns out that, over a fair selection of applications, programmers
> > tend to write "nice" sized functions. After inlining we have big nasty
> > blocks of
On Friday 06 February 2009, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
> > All of these have an outer code of SET. Therefore, I'm not quite
> > positive of how I'm supposed to implement my rtx_cost function. Since
> > I don't seem to get a choice between a set 0xcb03 and a (plus 0xca
On Wednesday 25 February 2009, Andrew Haley wrote:
> Uwe Kleine-König wrote:
> > currently[1] __builtin_return_address for ARM only works with level == 0.
> >
> > For ftrace in the linux kernel it would be great to implement that for
> > level > 0 (provided that framepointers or unwind information
> >> As I understand it, the ARM kernel can now do something similar. So,
> >> the only use for a __builtin_return_address(N) that used the frame
> >> pointer chain would be if the code were compiled with nonstandard
> >> options.
> >
> > Correct.
>
> Well, but wouldn't it still be nice if __bui
On Friday 27 February 2009, Dave Korn wrote:
> Julian Brown wrote:
> > Unfortunately backtraces don't currently terminate cleanly if code
> > without unwind data is reached: CodeSourcery are currently working on
> > fixing the linker so that non-unwindable regions are marked properly,
> > which we
On Tuesday 10 March 2009, DJ Delorie wrote:
> One of our customers has a chip with memory-mapped peripheral
> registers that need to be accessed in a specific mode. The registers
> represent bitfields within the hardware, so a volatile struct is an
> obvious choice to represent them in C.
>
> Comm
On Wednesday 06 May 2009, DJ Delorie wrote:
> Is there an opaque vector type? Something that can be assigned
> to/from other vector types of the same size, without warning?
>
> I'm working on a coprocessor which has separate SIMD arithmetic
> operations for each data size, but only one SIMD logica
> So my next question is what support is there in the various formats,
> technologies and runtime libraries to provide a backwards compatible
> solution, such that a binary from one system when put on another can
> have any hardware incompatibilities detected at the soonest opportunity,
> for examp
> Both Linaro and Debian are considering supporting the ARM hard-float
> variant of the EABI, at least as an unofficial port. This ABI is not
> compatible with the gnueabi currently in use for most ARM Linux distros,
> but has a number of performance advantages.
>
> This means that we need to choo
> .../configure --prefix=...
>
> must build a native compiler that conforms to the native ABI of the
> machine.
By my reading at least ppc, mips and sparc allow the default ABI to be changed
via --with-float, but none of them have a separate target triplet for this
purpose.
> > It's wort
> > It really does seem like a hack to use triplets in this way; I think
> > Paul's point that anything that depends on the toolchain triplet to
> > determine ABI is inherently busted is pretty persuasive.
>
> Which means the whole GNU way of doing this has always been busted,
> since that's essen
> However, although no one currently sells FPA hardware, it is widely
> supported as the only floating point model emulated by the Linux
> kernel, and people have to use it when compiling stuff to run on OABI
> systems, which include boards currently on the market based on ARMv4
> (no t) such as th
> Ian Lance Taylor writes:
> > Unfortunately, as far as I know, no such solution was ever adopted for
> > the x86 family. So this does not help your immediate problem, and will
> > not help it until somebody implements such an approach for x86.
>
> The Sun assembler, linker, and runtime linker i
> I have run into variable alignment issues, which turned out to be
> caused by forward declaration w/o the aligned attribute repeated.
> Could someone explain this please? If it's a bug to not include the
> aligned attribute in the forward declaration, would it be hard to add
> a warning for that
> > PR45112. See also http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00283.html
>
> Thanks a lot for info.
> If I got the discussion right, it's ok for the definition to use more
> strict alignment than the declaration.
Not quite. Any mismatch is user error, and may cause nasal daemons.
Whether thi
> Hi,
> I wish to selectively enable specific optimizations to observe its effect
> on the source. My project requires me to do this analysis. It seemed, the
> -f* flags would enable me to do that. But it turns out that individual
> optimizations can't be enabled like that, and all the optimization
> > In fact we might want to move switch optimization up to the tree level
> > (just because it's way easier to deal with there). Thus, lower switch
> > to a mixture of binary tree & jump-tables (possibly using perfect
> > hashing).
>
> Doing the optimisation at the tree-level was exactly my init
> A while back I posted a question about adding edit-and-continue
> abilities. Since then I've begun work on a rapid development compiler
> (rdc) which has these abilities, but I've had some thoughts I'd like to
> share, and receive some feedback from the GCC experts:
>
> What if a subset of GCC
> I would like to reduce this to
>
> STACK_BOUNDARY
>
> -- minimum alignment enforced by hardware.
>...
> -- unchanged
This may be determined by factors other than hardware. For example the ARM
EABI requires that the stack be 8-byte aligned at public entry points. However
within a functio
> > Your proposal doesn't make this problem any worse, if anything it's
> > better because we don't have to device between S_B and
> > PREFERRED_STACK_BOUNDARY. I'm just noting that documenting this as a
> > hardware property is at best misleading.
>
> Well, I'm hoping to document that it *is* a h
> [quote]
> Target Hook: int TARGET_SCHED_ISSUE_RATE (void)
> [snip]
> Although the insn scheduler can define itself the possibility of issue
> an insn on the same cycle, the value can serve as an additional
> constraint to issue insns on the same simulated processor cycle
> [snip]
> [/quote]
>
>
> > Does the Go language define a specific ABI convention for returning
> > two values from a function thru registers? If yes, how does GCC
> > implement it? Or is it some future work?
>
> The Go language does not define an ABI for returning multiple values.
> The gccgo frontend implements it by s
> Hi All,
>
> Is it possible to define UNITS_PER_SIMD_WORD as a global variable and
> to set this varibale using a pragma (even once for a compilation) and
> that way to be able to compile one file with UNITS_PER_SIMD_WORD = 8
> and another file with UNITS_PER_SIMD_WORD = 16?
No. This is an inter
> What about liveness? No hard reg, pseudo, mem will live avross the
> unspec volatile. Right?
Wrong. A volatile unspec may use/change machine state not directly accessible
by gcc. Any use of or changes to the machine state modelled by gcc should be
explicit in the pattern.
i.e. if your patter
> 2) Is there any reason we shouldn't prevent GCSE from propagating
> constants that we know will be split?
IIUC this will increase register pressure. i.e. it will probably be a win for
simple loops, but risks catastrophic spills in the inner loop of more
complicated code.
Paul
On Wednesday 25 January 2006 10:20, Igor Bukanov wrote:
> Is there any option to ask GCC to print various size and alignment
> info on the target platform? This would be very nice during cross
> compilation when one can not run the executables to autoconfigure for
> such parameters.
>
> Currently
On Wednesday 15 February 2006 20:06, DJ Delorie wrote:
> > > Note that there are some operations that gcc assumes you have 32-bit
> > > opcodes for, though. Or at least insns that emulate it.
> >
> > Like what ?
>
> Well, cmpsi2 for example. and divsi2.
You mean divsi3? Many targets don't have d
On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote:
> Hi all,
>
> I'm sending this mail because I'm a bit confused about the
> -mlong-double-128 option on (for example) ppc64-linux, and its impact
> on gfortran/libgfortran.
>
> When I simply bootstrap a compiler with "configure
> --w
On Thursday 16 February 2006 15:14, François-Xavier Coudert wrote:
> > Having gfortran magically know about certain ABI breaking options, and
> > doing funny things on certain targets seems a very bad precedent to me.
>
> Then, I think we should have the front-end refuse the option. It's
> annoying
On Thursday 16 February 2006 15:18, Richard Guenther wrote:
> On 2/16/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> > On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote:
> > > Hi all,
> > >
> > > I'm sending this mail because I'm a b
On Wednesday 01 March 2006 05:05, Daniel Jacobowitz wrote:
> On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote:
> > Thanks for the quick response!
> > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm
> > porting Gentoo Linux to iWMMXt with pure EABI kernel and u
> > It's a new feature and not a fix for a regression. -> totally
> > inappropriate.
>
> It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. I
> can't recommond gcc 4.1 to most people using IA32/x86-64. This ch
On Thursday 09 March 2006 18:04, Alan Lehotsky wrote:
> I've built a generic 4.1.0 for RH7.3 x86 linux (I did a make bootstrap)
>
> Compiling a rather large file, I get
>
> tmp.f_00.cxx:26432: error: unrecognizable insn:
> (insn 173 172 174 9 (set (reg:QI 122)
> (const_int 128 [0x80]))
> > Is this really worth it? Could this whole problem be solved by you
> > switching to rxvt? Maybe the only problem is that your xterm is broken.
>
> Nothing is "broken". The problem is that Cygwin applications run in a
> slightly special environment, where there may not be a console attached
On Tuesday 14 March 2006 19:46, Ross Ridge wrote:
> Dave Korn writes:
> >I don't understand why you think Mark's code needs to search the PATH or
> >append '.exe', when it invokes CreateProcess that does all that for you?
>
> I've already answered that question: "subtle differences in the other
> b
On Wednesday 15 March 2006 05:20, [EMAIL PROTECTED] wrote:
> Hi all,
> what is the difference beetween this abi?
> The standard arm procedure call is the first one. What is introduced in the
> apcs-gnu? Is there some documentation about the last one?
"apcs-gnu" is the pre-EABI calling convention.
> Ok,
> but the default is to use the apcs-gnu instend of aapcs. Is it right? For
> compatibility problem is usefull to forse the abi to the standard.
Depends how you configure your toolchain. If you use the eabi targets the
default will be aapcs/EABI.
Paul
On Saturday 18 March 2006 17:56, Vladimir N. Makarov wrote:
> I've created a branch for my allocator project which is called Yet
> Another Register Allocator (or YARA - yet another recursive acronim).
>
> I am think I reached the point when my work on a public branch can
> be made. I am focuse
On Tuesday 21 March 2006 14:57, Richard Henderson wrote:
> On Mon, Mar 20, 2006 at 04:03:08PM -, Dave Korn wrote:
> > Do you happen to know off the top of your head when get_frame_size()
> > becomes valid?
>
> You don't get a good first-pass estimate until after all rtl
> generation has been d
> >>scratchslot = argument
> >>argument = stack frame size - small
> >>sp += argument
> >>argument = scratchslot
> >>sp += small
> >
> > This assumes you have a frame pointer or sp+large_offset addressing mode
> > for accessing scratchslot. In which case you could either use fp
On Tuesday 28 March 2006 21:32, Jack Howarth wrote:
>I am trying to compile some fairly old legacy c code with gcc 4.1
> in FC5 and have been able to eliminate all the compiler warnings save
> one...
>
> warning: incompatible implicit declaration of built-in function 'exit'
>
> ...which is repe
On Wednesday 19 April 2006 14:41, Ian Lance Taylor wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
> > Converting a vector of floats (via a cast) to a vector of ints of the
> > same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> > converted. This is different from a cast fro
> I realize the gcc4.0.2 source code does not include any fortran frontend.
Yes it does.
Paul
> mrs $ svn cp -r113703 svn+ssh://src.apple.com/svn/fsf-gcc/gcc/
> branches/apple-local-200502-branch/gcc/testsuite/g++.dg/
> bitreverse-10.C bitreverse-10.C
> svn: Entry for 'bitreverse-10.C' exists (though the working file is
> missing)
>
> How do I `fix' this. I know how to fix it with multiple
On Wednesday 10 May 2006 21:38, Shaun Jackman wrote:
> What optimisation option is needed to prod arm-elf-gcc -mthumb to
> generate a tail call? ARM works as expected.
Thumb only has very limited (256 byte) direct branch offsets, so tail calls
aren't possible/useful.
Paul
> Has work been done to evaluate a calling convention that takes error
> checks like this into account? Are there size/performance wins? Or am
> I just reinventing a variation on exception handling?
This introduces an extra stack push and will confuse a call-stack branch
predictor. If both the ca
> Now, we'd like to modify the gnu sources that we downloaded and test the
> changes in our programm.
> In other words, we don't want to recompile the standard library that is
> installed on our computer, but we'd like to make some changes in the
> downloaded repository and check if our programms i
101 - 200 of 274 matches
Mail list logo
