On 13/11/12 14:56, Ian Lance Taylor wrote:
Currently -fPIC -fPIE seems to be the same as -fPIE. Unfortunately,
-fPIE -fPIC also seems to be the same as -fPIE. It seems to me that,
as is usual with conflicting options, we should use the one that
appears last on the command line.
Do we have an
On 21/11/12 22:47, Ian Lance Taylor wrote:
On Wed, Nov 21, 2012 at 1:20 PM, Paolo Bonzini bonz...@gnu.org wrote:
On Wed, Nov 21, 2012 at 8:02 PM, Ian Lance Taylor i...@google.com wrote:
The main advantage is that you can compile a program with CFLAGS=-O2 -g
-fPIE, and libtool's adding of -fPIC
On 07/12/12 15:13, Christophe Lyon wrote:
Hi,
As ARM supports unaligned vector accesses for almost no penalty, I'd
like to disable loop peeling on ARM targets.
I have ran benchmarks on cortex-A9 (hard-float) and noticed these
significant improvements:
* 1.5% improvement on a popular embedded
On 11/12/12 09:45, Richard Biener wrote:
On Mon, Dec 10, 2012 at 10:07 PM, Andi Kleen a...@firstfloor.org wrote:
Jan Hubicka hubi...@ucw.cz writes:
Note that I think Core has similar characteristics - at least for string
operations
it fares well with unalignes accesses.
Nehalem and later
On 11/12/12 09:56, Richard Biener wrote:
On Tue, Dec 11, 2012 at 10:48 AM, Richard Earnshaw rearn...@arm.com wrote:
On 11/12/12 09:45, Richard Biener wrote:
On Mon, Dec 10, 2012 at 10:07 PM, Andi Kleen a...@firstfloor.org wrote:
Jan Hubicka hubi...@ucw.cz writes:
Note that I think Core
On 13/12/12 11:24, Steven Bosscher wrote:
On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote:
I don't speak for FreeBSD, but dropping them from Tier 1 support because
they don't use a GPLv3 *BASE* compiler is a bit vindictive.
FreeBSD has dropped GCC for future releases so there's no reason
On 06/02/13 08:38, Ye Joey wrote:
Following case attempts to set floating point control register and
execute floating point operation afterward. However, it doesn't works
as expected with -Os, as GCC hoists multiply operation beyond FP
control register setting.
As there is no register
On 21/05/13 10:32, Ard Biesheuvel wrote:
Hello all,
I am currently exploring various ways of using NEON instructions in
kernel mode. One of the ways of doing so is using NEON intrinsics,
which we would like to support in the kernel, but unfortunately, at
the moment we can't because the support
On 22/05/13 21:19, Richard Henderson wrote:
On 05/22/2013 12:43 AM, Jakub Jelinek wrote:
Changing frame grows upward into frame grows downward shouldn't be that
hard, see e.g. rs6000 port, where
#define FRAME_GROWS_DOWNWARD (flag_stack_protect != 0 || flag_asan != 0)
and grep the port where it
On 23/05/13 17:36, Jakub Jelinek wrote:
On Thu, May 23, 2013 at 05:28:29PM +0100, Richard Earnshaw wrote:
FWIW, I would actually recommend against conditionalizing FRAME_GROWS_DOWNWARD
for a new port. Just make it _always_ grow down and save yourself the
additional code bloat in the backend
On 30/07/13 12:59, hemant wrote:
I have written a std code for ARM 32-bit platform using math.h library and
float=powf(float,float) function. When I give input to my system as 100 ^
4.4 it gives me answer as 630957632. (as float) whereas calculator in
WindowsXP gives answer as
On 08/08/13 08:20, zhaobin xv wrote:
Hi
In linux/arch/arm/boot/
compressed/head.S:
#ifndef __ARM_ARCH_2__
/*
* Booting from Angel - need to enter SVC mode and disable
* FIQs/IRQs (numeric definitions from angel arm.h source).
* We only do this if we
On 02/10/13 14:59, Richard Biener wrote:
The main reason for technical review of a port is to avoid that it uses
deprecated mechanisms and thus blocks removal of them. Like
accepting a port that uses target macros when a corresponding
target hook exists, or accepting a port that uses reload
On 17/10/13 08:56, Joey Ye wrote:
There is no macro to indicate VFP variances. Probably you can check
CPU variance instead. As I know Cortex-R only support D16.
Checking __ARM_ARCH_PROFILE == 'R' would tell you that it's R profile
and therefore only 16 regs.
R.
Joey
On Thu, Oct 17, 2013
On 17/10/13 13:46, Sebastian Huber wrote:
On 2013-10-17 14:24, Richard Earnshaw wrote:
On 17/10/13 08:56, Joey Ye wrote:
There is no macro to indicate VFP variances. Probably you can check
CPU variance instead. As I know Cortex-R only support D16.
Checking __ARM_ARCH_PROFILE == 'R' would
On 09/01/14 08:26, Bernd Edlinger wrote:
Hi,
On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:
Sandra, Bernd,
Can you take a look at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734
It seems a siimple case still doesn't work as expected. Did I miss anything?
Thanks,
Joey
Yes,
this
On 10/01/14 08:49, Bernd Edlinger wrote:
On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
On 09/01/14 08:26, Bernd Edlinger wrote:
Hi,
On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:
Sandra, Bernd,
Can you take a look at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734
It seems
On 10/01/14 13:45, Richard Biener wrote:
On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:
On 10/01/14 08:49, Bernd Edlinger wrote:
On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
On 09/01/14 08:26
On 19/02/14 23:19, Andrew Pinski wrote:
On Wed, Feb 19, 2014 at 3:17 PM, Renato Golin renato.go...@linaro.org wrote:
On 19 February 2014 11:58, Richard Sandiford
rsand...@linux.vnet.ibm.com wrote:
I agree that having an unrecognised asm shouldn't be a hard error until
assembly time though.
On 22/07/14 16:23, Ramana Radhakrishnan wrote:
On 22/07/14 14:14, Kyrill Tkachov wrote:
Hi all,
In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 with a comment that says:
/* We could use unified syntax for arm mode, but for now we just use
On 12/08/14 07:49, Andrew Pinski wrote:
On Mon, Aug 11, 2014 at 11:44 PM, Marat Zakirov m.zaki...@samsung.com wrote:
Hi Vladimir!
I think you are as the main IRA contributor would be appropriate person to
answer question bellow. Please confirm or refute my statement about
unsplittable
On 12/08/14 18:03, Kyrill Tkachov wrote:
On 12/08/14 16:16, Kyrill Tkachov wrote:
On 12/08/14 16:11, Kyrill Tkachov wrote:
On 12/08/14 15:22, Jeff Law wrote:
On 08/12/14 04:31, Kyrill Tkachov wrote:
On 12/08/14 10:39, Richard Biener wrote:
On Mon, Aug 11, 2014 at 9:56 PM, Jeff Law
On 14/08/14 09:45, Kyrill Tkachov wrote:
On 13/08/14 18:32, Segher Boessenkool wrote:
On Wed, Aug 13, 2014 at 03:57:31PM +0100, Richard Earnshaw wrote:
The problem with the frankenmonster patterns is that they tend to
proliferate into the machine description, and before you know where you
On 21/08/14 00:24, Richard Henderson wrote:
On 08/20/2014 08:22 AM, Wilco Dijkstra wrote:
2. Change the mid-end to call arch_frame_pointer_required even when
!flag_omit_frame_pointer.
Um, it does that already. At least as far as I can see from
ira_setup_eliminable_regset and
On 05/11/14 17:14, Evandro Menezes wrote:
It doesn't seem that the option -mno-lra does what it implies. If so, what
does it do, for the it does result in differences.
It causes the compiler to use 'reload' rather than LRA for handling part
of the register allocation process.
R.
On 10/11/14 15:26, Joel Sherrill wrote:
Hi
With gcc, newlib, and binutils head, arm-rtems and arm-eabi both
die building libgcc2.c for the Thumb. I don't know if this is a recent
gcc change or binutils having added some new error checking. Anyone
got any ideas?
On Tue, 2007-06-19 at 01:50 +, Joseph S. Myers wrote:
The ARM EABI says that only standard entries under aeabi should affect
link-compatibility of object files, not vendor entries such as gnu, but
in the absence of corresponding standards for other processors I don't
think we can avoid
On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
I suspect that the realview compiler accepts
this as an oversight or a bug, not as an intentional feature.
Let's ask.
Richard E., is the fact that RealView 3.0SP1 accepts:
class __declspec(notshared) S {
; compared to 32 in the front
end.
So it is quite heavily used by MD code.
R.
--
Richard Earnshaw Email: [EMAIL PROTECTED]
ARM Ltd Phone: +44 1223 400569 (Direct + VoiceMail)
110 Fulbourn RoadSwitchboard: +44 1223 400400
Cherry Hinton
On Mon, 2007-07-09 at 09:30 -0700, Ian Lance Taylor wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
I am going to argue that it was a bug that we did not allow new
pseudos after flow had ran. And that we should have always allowed
pseudos before the register allocator. Since flow was
On 01/08/11 10:11, Jakub Jelinek wrote:
On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote:
It's quite necessary to solve the general problem in middle-end rather than
in back-end.
That's what we disagree on. All back-ends but ARM are able to handle it
right, why can't ARM too?
On 02/08/11 13:22, Richard Guenther wrote:
On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson mi...@it.uu.se wrote:
Michael Walle writes:
Hi,
To confirm that try -fno-tree-ter.
lm32-gcc -O1 -fno-tree-ter -S -c test.c generates the following working
assembly code:
f2:
On 08/08/11 21:35, Jan Hubicka wrote:
On Fri, Aug 5, 2011 at 3:24 PM, Jan Hubicka hubi...@ucw.cz wrote:
In a way I like the current scheme since it is simple and extending it
should IMO have some good reason. We could refine -Os behaviour without
changing current predicates to optimize for
On 08/09/11 12:33, Diego Novillo wrote:
On Thu, Sep 8, 2011 at 07:16, Richard Guenther
richard.guent...@gmail.com wrote:
Well, you'd need to maintain a list of known XPASS/FAILs anyway.
Yes, of course. That's the manifest of things you expect to be broken.
And that's only going to work
On 08/09/11 14:54, Diego Novillo wrote:
On Thu, Sep 8, 2011 at 09:23, Richard Earnshaw rearn...@arm.com wrote:
And that's only going to work if all the test names are unique. I
currently see quite a few tests that appear in my log as both PASS and
FAIL in a single run. For example
On 14/10/11 17:40, Ben Gamari wrote:
According to the ELF for ARM specification, this case requires the
generation of veneer code to handle the instruction set switch. My
question is where can one reliably place this veneer such that it is
within the 2^11 window permitted by the relevant
On 14/10/11 17:40, Ben Gamari wrote:
I was recently trying to test GCC's behavior in producing various types
of ARM relocations. In particular, I was trying to produce an
R_ARM_JUMP24 relocation, which requires veneer. It was suggested that
the code most likely to produce this relocation would
On 14/10/11 19:31, Ben Gamari wrote:
On Fri, 14 Oct 2011 18:38:26 +0100, Richard Earnshaw rearn...@arm.com wrote:
On 14/10/11 17:40, Ben Gamari wrote:
I was recently trying to test GCC's behavior in producing various types
of ARM relocations. In particular, I was trying to produce
On 01/04/12 20:57, Maxim Kuvyrkov wrote:
On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote:
I volunteer as the reviewer for Android sub-port.
Android/Bionic support is an extension over Linux port and is being
gradually added for more and more architectures. I wrote the original
Android
On 27/04/12 21:24, David Sehr wrote:
Hello All,
We are using gcc trunk as of 4/27/12, and are attempting to add
support to the ARM gcc compiler for Native Client.
We are trying to get gcc -march=armv7-a to use movw/movt consistently
instead of minipools. The motivation is for
a new target
On 02/05/12 14:13, nick clifton wrote:
Hi Richard,
Well, given the replies from you, Ian and Vlad (when reviewing the patch),
I feel once again in a minority of one here :-) but... I just don't
think we should be advertising this sort of stuff to users.
OK, what about Ian's suggestion of
On 20/06/12 15:27, Sebastian Huber wrote:
Hi,
maybe it makes sense to look at some test suite comments since now all non
EABI
configurations have been removed (is this correct?).
No, not quite. All configurations using the FPA have been removed.
That's not quite the same thing.
NetBSD
On Mon, 2008-12-15 at 10:00 +0100, Markus Barenhoff wrote:
Hi,
I've a problem with a array of void*, with different versions of arm-elf-gcc.
Tried it with 4.3.1 and with current HEAD 4.4.0 from CVS.. Problem seems to
exists von both versions. I've created a small example of it:
snip
This message is really off topic for this list, please direct any
follow-ups to gcc-h...@gcc.gnu.org.
On Wed, 2009-01-21 at 19:53 +1100, Zoltán Kócsi wrote:
I have a question with regards to ARM interworking. The target is
ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc,
On Sun, 2006-05-07 at 10:06, Steven Newbury wrote:
I have built an EABI/iWMMXt Gentoo based system. The toolchain I used is
modified to add a Linux/EABI/iWMMXt target. It has been fine until I changed
my binutils from an earlier snapshot to a current version Gentoo 2.16.92,
csl-2_17-branch
On Tue, 2006-05-09 at 22:16, Richard Kenner wrote:
Can there be two consecutive insns that use cc0 after cc0 is set?
No.
Yes. But only very very late in the compilation, once all normal
re-ordering and optimization has been completed. I think it's probably
final that folds out
On Sun, 2006-05-14 at 17:09, Joern RENNECKE wrote:
The constant pool placement that sh_reorg does has somewhat hapazard
results. It does not take execution frequencies into account, so if
you are unlucky, you can end up with a constant table wedged into some
hoit spot of the code, which not
they will live entirely in registers).
Please direct any follow-ups to [EMAIL PROTECTED] This is off-topic
for this list.
R.
--
Richard Earnshaw Email: [EMAIL PROTECTED]
ARM Ltd Phone: +44 1223 400569 (Direct + VoiceMail)
110 Fulbourn RoadSwitchboard
On Thu, 2006-06-01 at 03:43, Mike Stump wrote:
Mine was designed to do two things, figure out if the results are
interesting and not send email, if they are not, and to show
engineers the `interesting' detailed results in priority order. It's
meant to be run daily, and on good days, it
On Thu, 2006-06-01 at 16:05, Mark Shinwell wrote:
Mark Mitchell wrote:
Mark Shinwell wrote:
As for the remaining problem, I suggest that we could:
(i) always return the hard frame pointer, and disable FP elimination in
the current function; or
(iii) ...the same as option (i), but
On Fri, 2006-06-02 at 14:57, Mark Shinwell wrote:
Richard Earnshaw wrote:
I'm not keen on this. On some machines a frame pointer is *very*
expensive, both in terms of the code required to set it up, and the
resulting loss of a register which affects code quality (in addition, on
Thumb
On Fri, 2006-06-02 at 15:30, Mark Shinwell wrote:
However when dealing with __builtin_frame_address, we must return the
correct value from this function no matter what the value of count. This
patch therefore forces use of a hard FP in such situations.
Eh? The manual explicitly says that
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a backtrace
on Arm. However if you assume only Arm code code and -fno-omit-frame-pointer
then you can walk the frames. Given this assumption I think it make sense to
have
On Fri, 2006-06-02 at 16:35, Daniel Jacobowitz wrote:
On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a
backtrace
on Arm. However if you assume only Arm
On Fri, 2006-06-02 at 16:46, Mark Mitchell wrote:
Richard, I can't tell from your comments how you think _b_f_a(0) should
be implemented on ARM. We could use Mark's logic (forcing a hard frame
pointer), but stuff it into INITIAL_FRAME_ADDRESS_RTX. We could also
try to reimplement the thing
On Sun, 2006-06-04 at 22:01, Rask Ingemann Lambertsen wrote:
On Sun, Jun 04, 2006 at 12:24:53PM +0100, Paul Brook wrote:
For the record these hacks are unlikely to ever be acceptable in mainline
gcc.
They're relatively invasive changes who's only purpose is to support
fundamentally
On Mon, 2006-06-05 at 12:47, Wolfgang Mües wrote:
/* Output the address of an operand. */
#define ARM_PRINT_OPERAND_ADDRESS(STREAM, X)\
{ \
int is_minus = GET_CODE (X) == MINUS;
On Tue, 2006-06-06 at 15:05, Dirk Behme wrote:
Fengwei Yin wrote:
Hi Daniel,
I have already reported this bug. The bug number is #27363.
I also tried the gcc snapshot 4.1.1-20060421. The bug is not
fixed in this version too.
On 5/1/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On
On Wed, 2006-06-07 at 01:36, Geoffrey Keating wrote:
On 06/06/2006, at 5:25 PM, Andrew Pinski wrote:
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
Right above, you said We control the debug output machinery
generating this, and can simply tell it to only deal in one
language. Here,
On Wed, 2006-06-07 at 06:22, Wolfgang Mües wrote:
Rask,
On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
+ swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0
You should get a price for cleverness here!
Thanks! Indeed it looks good until you think of volatile variables.
Nick
Clifton or Richard Earnshaw? If I could find the person and the file
that added this feature, I could probably track down the patch in svn
and modify it for XIP.
It was probably me. But why can't you do this yourself? Look at the
assembly. See what the output string is. Search
On Wed, 2006-06-28 at 16:51, Shaun Jackman wrote:
On 6/27/06, David McCullough [EMAIL PROTECTED] wrote:
AFAIK, you need to drop the -FPIC in favour of -fpic everywhere.
From the GCC manual, -fpic vs. -fPIC `makes a difference on the m68k,
PowerPC and SPARC.' For my purposes, it makes no
On Mon, 2006-07-03 at 02:10, Bridge Wu wrote:
Hello,
When I built blob with arm-iwmmxt-linux-gnueabi toolchain, I found the
SP value before invoking number() in printf() may be 0 or 4 modulo 8.
If SP is 0 modulo 8, printf worked well, but while SP is 4 modulo 8,
printf failed. It cannot
On Thu, 2006-07-20 at 12:04, Dave Korn wrote:
On 20 July 2006 07:03, Wolfgang Mües wrote:
Hello Rask,
On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote:
I've spotted a function named emit_set_insn() in arm.c. It might be
the problem, because it uses gen_rtx_SET()
On Tue, 2006-10-10 at 04:22, Mark Mitchell wrote:
Kaveh R. GHAZI wrote:
Has there been any thought to including GMP/MPFR in the GCC repository
like we do for zlib and intl?
I do not think we should be including more such packages in the GCC
repository. It's complicated from an FSF
On Fri, 2009-11-20 at 10:18 -0500, David Edelsohn wrote:
On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton bol...@icerasemi.com wrote:
From some simple experiments (see below), it appears as though GCC aims
to
create a lop-sided tree when there are constants involved (func1 below),
but a
On Thu, 2009-11-26 at 00:08 +0100, Richard Guenther wrote:
On Thu, Nov 26, 2009 at 12:04 AM, Tom Tromey tro...@redhat.com wrote:
Basile == Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Basile Of course, not every one has it (notably those working on non-linux
Basile systems), but
On Wed, 2009-11-25 at 18:02 +0100, Michael Matz wrote:
Hi,
On Wed, 25 Nov 2009, Richard Guenther wrote:
Remove trailing white spaces.
WTF?
Thankyouverymuch.
This 1) wasn't posted or approved 2) is bad as it breaks svn blame
3) chokes all branches.
What's
On Fri, 2009-11-27 at 09:40 -0500, Joern Rennecke wrote:
Quoting Richard Earnshaw rearn...@arm.com:
An SVN pre-commit filter (default on, disabled by SVN attribute if
needed) should instead just reject files that have trailing white space.
I think a better mechanism to deal
On Mon, 2009-12-14 at 19:18 +0100, Thomas Schwinge wrote:
Hello!
I noticed the following on ARM, GCC trunk -- didn't check yet whether it
is ARM-specific; may be a general issue.
Hacking out the forcing-off of emitting CFI statements in arm.c, I see
the following function prologue
On Thu, 2009-12-17 at 21:00 +0100, Laurent GUERBY wrote:
On Thu, 2009-12-17 at 21:02 +0100, Eric Botcazou wrote:
The 43 slides presentation in english is available here
in PDF and openoffice format:
http://guerby.org/ftp/gcc-toulibre-20091216.pdf
On Mon, 2009-12-21 at 16:06 +, Paul Brook wrote:
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
On Mon, 2009-12-21 at 18:44 +, Paul Brook wrote:
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
On Tue, 2009-12-22 at 09:10 -0500, Daniel Jacobowitz wrote:
On Tue, Dec 22, 2009 at 12:09:55PM +, Paul Brook wrote:
i.e. the following will work as expected:
(define_insn *my_movsi
(set (match_operand:SI ... =a,b)
(match_operand:SI ... ab,ab)))
However the following
On Wed, 2009-12-23 at 10:11 +0530, Mohamed Shafi wrote:
2009/12/22 Richard Earnshaw rearn...@arm.com:
On Mon, 2009-12-21 at 18:44 +, Paul Brook wrote:
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
On Tue, 2010-01-05 at 15:42 +0800, Carrot Wei wrote:
Hi
In function arm_load_pic_register in file arm.c there are following code:
if (TARGET_ARM)
{
...
}
else if (TARGET_THUMB2)
{
/* Thumb-2 only allows very limited access to the
On Wed, 2010-01-06 at 18:26 +, 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 performance and smaller code size.
Technically yes, however in ARMv7 the relevant instruction
In PR target/42894 rguenth said:
Only RMs may set priority.
I beg your pardon? Where in the docs does it say that?
R.
On Fri, 2010-01-29 at 12:24 +0100, Richard Guenther wrote:
On Fri, Jan 29, 2010 at 12:26 PM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
On 29/01/2010 11:03, Richard Guenther wrote:
This should ideally be documented in
http://gcc.gnu.org/bugs/management.html
Both the way that
On Fri, 2010-01-29 at 11:26 +, Dave Korn wrote:
On 29/01/2010 11:03, Richard Guenther wrote:
This should ideally be documented in
http://gcc.gnu.org/bugs/management.html
Both the way that page is named, and the way the link to it is indented
under the link to the BZ frontpage in
On Fri, 2010-01-29 at 12:25 +, Dave Korn wrote:
On 29/01/2010 12:02, Richard Earnshaw wrote:
We have three categories of users of BZ: RMs, Developers, and the rest.
Developers are *not* the same as the rest and that extends beyond the
ability to modify bug reports.
Ah, I may
On Fri, 2010-04-30 at 15:26 +, Joseph S. Myers wrote:
On Fri, 30 Apr 2010, Joel Sherrill wrote:
For EABI, this is done
with .cpu, .arch and .fpu directives; for non-EABI you may need to write
specs to pass command-line options to the assembler. Creating an
arm-rtemseabi or
On Tue, 2010-05-11 at 17:40 -0400, DJ Delorie wrote:
I discovered that if you build a plain arm-elf toolchain, the default
float-abis for gcc and gas don't match. I added this patch locally to
make it just work but it seems to me it would be better to have the
defaults match, although I'm
On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote:
On 5/11/10, Mark Mitchell m...@codesourcery.com wrote:
Richard Earnshaw wrote:
Speaking of which, we should probably formally deprecate the old arm-elf
derived targets in 4.6 so that we can remove them in 4.7.
Similarly, we
On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell m...@codesourcery.com wrote:
Martin Guy wrote:
Dropping FPA support from GCC effectively makes the OABI unusable, and
often we are forced to use that by the environment supplied to
On Mon, 2010-05-24 at 12:42 +0200, Steven Bosscher wrote:
On 5/24/10, Richard Earnshaw rearn...@arm.com wrote:
On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell m...@codesourcery.com
wrote:
Martin Guy wrote:
Dropping FPA
for the relevant maintainers, which in this case means target
maintainers together with OS maintainers (or target maintainers alone if
noone is maintaining the OS ports to ARM).
On Mon, 24 May 2010, Richard Earnshaw wrote:
OABI should be on the deprecated list too, as should all ports
On Mon, 2010-05-24 at 06:40 -0500, Joel Sherrill wrote:
The question we would like answered is what impact this
has on our code base. What changes will we have to
make to accomodate this? Register usage changes, stack
frame changes, etc.
By far the biggest change is to the layout of 64-bit
On Mon, 2010-05-31 at 08:40 -0700, Mark Mitchell wrote:
Eric Botcazou wrote:
We do require long long for 32-64 cross compilers.
Right, only in this case, and I don't see why this should be changed with
the
transition to C++, that's orthogonal.
I agree.
We need it for any
On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
initial subset of C++ used in
On Mon, 2010-05-31 at 08:22 -0400, Robert Dewar wrote:
Gcc is very widespread at this point. Yes, there is the issue
of completely new targets, but these can be easily handled by
building cross-compilers.
Provided that the object format for binaries is published and that we
can therefore
On Wed, 2010-06-02 at 19:50 +0200, Jakub Jelinek wrote:
On Wed, Jun 02, 2010 at 06:17:25PM +0100, Richard Earnshaw wrote:
On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer
On Mon, 2010-06-28 at 01:37 +0100, Martin Guy wrote:
On 6/27/10, Gerald Pfeifer ger...@pfeifer.com wrote:
On Mon, 24 May 2010, Richard Kenner wrote:
I think that's a critical distinction. I can't see removing a port just
because it's not used much (or at all) because it might be
On Wed, 2010-06-16 at 08:09 -0700, Andrew Pinski wrote:
Sent from my iPhone
On Jun 16, 2010, at 6:04 AM, Richard Guenther richard.guent...@gmail.com
wrote:
On Wed, Jun 16, 2010 at 5:52 PM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
Hello,
Currently gcc (at least
On Mon, 2010-07-12 at 10:23 -0400, Joern Rennecke wrote:
Quoting Andrew Stubbs a...@codesourcery.com:
Hi All,
Hi, long time no see...
So here are my suggestions:
arm-linux-gnueabihf
or maybe
arm-linux-gnueabi-hf
I don't like the inflation of dashes - it breaks
On Mon, 2010-07-12 at 16:03 +0100, Paul Brook wrote:
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
On Mon, 2010-07-12 at 09:19 -0700, Mark Mitchell wrote:
Richard Earnshaw wrote:
The reason why a new triplet is required is that config.guess needs to
generate it when running native. Config.guess is the only way to
communicate the information needed for a native compiler when no other
?
(2) Richard Earnshaw objected to applying the patch to 4.1 because it
requires a newer GAS. Paul's counter that the newer GAS is only needed
if your compiler would otherwise crash seems persuasive to me, if true,
but I'd certainly want Richard to be comfortable with the change.
I agree
On Fri, 2007-03-30 at 17:57 +0530, vivek tyagi wrote:
Hi ,
This is the wrong list for these sorts of questions, you should really
be asking on gcc-help.
I am working on Shared flat file support for uClinux (No MMU ARM ).The
gcc version
I am using is 2.95 and 3.4.0.Theory of operation is
On Thu, 2007-04-12 at 08:59 +, Mick CORNUT wrote:
Hi Andrew,
Ps: I've just tried with gcc 4.1.1, but the problem doesn't occur
since gcc removes the temporary buffer allocation on the stack,
furthermore, we want to keep gcc 3.4.x!
Changing the testcase to
void trace(int p1, int p2, int
1 - 100 of 3057 matches
Mail list logo
