Found it, finally. powerpc ld --relax had a bug affecting -fPIC
code. See http://sourceware.org/ml/binutils/2008-08/msg00040.html
--
Alan Modra
Australia Development Lab, IBM
---Andrew Pinski <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
> > The PPC has a very fast dcbz (data cache block zero) to clear memory,
> > and also dcbi (data cache block invalidate) which permit to have a
> > cached line caching an address without reading first the memory (when
> > yo
With a little more cross building experience...I'm still convinced there is a
problem here.
Canadian cross doesn't do the right thing in fixincludes.
There are remnants of a fix in the 4.3.1 configure.ac here:
# When building gcc with a cross-compiler, we need to adjust things so
# that the ge
> Date: Wed, 6 Aug 2008 11:27:36 -0400
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>
>
> On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote:
> > (gdb) bt
> > #0 0x4004ec0c in raise () from /lib/libc.so.6
> > #1 0x40050234 in abort () from /lib/libc.so.6
> > Backtrace stopped: frame
On Wed, Aug 06, 2008 at 05:42:48PM +0200, Mark Kettenis wrote:
> GCC should really not do this. People are almost guaranteed to want
> to be able to see a backtrace from abort(3).
Yes, it's come up for discussion several times... I don't like the
current behavior either. The current behavior was
> "Mark" == Mark Kettenis <[EMAIL PROTECTED]> writes:
>> Date: Wed, 6 Aug 2008 11:27:36 -0400 From: Daniel Jacobowitz
>> <[EMAIL PROTECTED]>
>>
>> On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote:
>> > (gdb) bt > #0 0x4004ec0c in raise () from /lib/libc.so.6 > #1
>> 0x40
Jack Howarth wrote:
> Peter,
> Thanks. If gcc's libtool is missing this dsymutil workaround, it would
> be nice if this could be fixed for both gcc trunk and 4.3.2.
> Jack
I went and looked for the patches that added dsymutil to libtool, looks
like I took the opport
Peter,
You are going to fix this on gcc trunk in any case, right?
Jack
On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote:
> Jack Howarth wrote:
> > Peter,
> > Thanks. If gcc's libtool is missing this dsymutil workaround, it would
> > be nice if this could be f
Jack Howarth wrote:
> Peter,
> You are going to fix this on gcc trunk in any case, right?
If there is a consensus that now is not the time to update libtool in
trunk, then I will have to :)
> Jack
>
> On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote:
>> Jack Ho
Hi,
I have just posted the first gcc test results
for arm-rtems to gcc-testresults.
C/C++: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00608.html
Ada: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00601.html
There were a lot (2116) of "unexpected failures"
for C, but most (1997 by gre
On Wed, 6 Aug 2008, Joel Sherrill wrote:
> Hi,
>
> I have just posted the first gcc test results
> for arm-rtems to gcc-testresults.
> C/C++: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00608.html
> Ada: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00601.html
>
> There were a lot (2116
Apologies to those who follow GCC-help; I posted something very
similar there yesterday without really thinking. I believe this better
belongs here however.
I'm looking to get loop information in an IPA pass; However, as near
as I can tell by the time the ipa-passes are called, the loop
informatio
Hi All,
The new test gcc.c-torture/compile/20080806-1.c, added by Andreas Krebbel on
2008-08-06, causes 8 new test failures for the AVR target. This test is invalid
for the AVR because the local array is too large for the AVR (64+ K). IIRC, for
testing purposes the AVR target only allows a 2K
Joseph S. Myers wrote:
On Wed, 6 Aug 2008, Joel Sherrill wrote:
Hi,
I have just posted the first gcc test results
for arm-rtems to gcc-testresults.
C/C++: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00608.html
Ada: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00601.html
There were
Weddington, Eric wrote on 06 August 2008 17:49:
> Hi All,
>
> The new test gcc.c-torture/compile/20080806-1.c, added by Andreas Krebbel
> on 2008-08-06, causes 8 new test failures for the AVR target. This test
> is invalid for the AVR because the local array is too large for t
On Wed, Aug 06, 2008 at 11:54:42AM -0400, Paul Koning wrote:
> I think the space savings in "noreturn" come from not having to save
> caller-saved registers in the calling function. That savings can add
> up if the noreturn function is called from many places.
>
> Clearly the return address needs
On Wed, 6 Aug 2008, Joel Sherrill wrote:
> I see the code for arm_neon_ok. If I can make that test fail,
> we are in business. I tried the cpp part of the following code
> and it doesn't trip for:
>
> arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c test_neon.c
>
> But when I a
> -Original Message-
> From: Dave Korn [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 06, 2008 11:04 AM
> To: Weddington, Eric; gcc@gcc.gnu.org
> Cc: 'Andy Hutchinson'; 'Anatoly Sokolov'; 'Andreas Krebbel';
> [EMAIL PROTECTED]
> Subject: RE: New test is invalid for AVR
>
> Weddin
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> On Wed, Aug 06, 2008 at 11:54:42AM -0400, Paul Koning wrote:
>> I think the space savings in "noreturn" come from not having to
>> save caller-saved registers in the calling function. That savings
>> can add up if the noreturn function
I wrote:
> Joe> There are several effects from "noreturn". We would want some
> Joe> of these effects for "abort", but not others, to get debuggable
> Joe> code without degrading compile-time warnings.
On Wed, Aug 06, 2008 at 01:37:51PM -0400, Paul Koning wrote:
> So the issue is that two unr
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> I wrote: There are several effects from "noreturn". We would
Joe> want some of these effects for "abort", but not others, to get
Joe> debuggable code without degrading compile-time warnings.
Joe> On Wed, Aug 06, 2008 at 01:37:51PM -040
[ Oh, hi Andreas, I just saw you're Cc'd into this thread! I guess that
post I sent to the -patches list was a bit superfluous then, sorry about
that! ]
Weddington, Eric wrote on 06 August 2008 18:14:
> I do have that line that you have in my atmega128-sim.exp:
> set_board_info gcc,stack_size
* Peter O'Gorman wrote on Wed, Aug 06, 2008 at 06:26:15PM CEST:
> Jack Howarth wrote:
> > On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote:
> >>
> >> I wonder what the chances are of moving mainline gcc to a newer libtool
> >> version? Introducing the darwin bits piecemeal would not b
Hi Ralf,
Ralf Wildenhues wrote:
> * Peter O'Gorman wrote on Wed, Aug 06, 2008 at 06:26:15PM CEST:
>> Jack Howarth wrote:
>>> On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote:
I wonder what the chances are of moving mainline gcc to a newer libtool
version? Introducing the da
Joseph S. Myers wrote:
On Wed, 6 Aug 2008, Joel Sherrill wrote:
I see the code for arm_neon_ok. If I can make that test fail,
we are in business. I tried the cpp part of the following code
and it doesn't trip for:
arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c test_neon.
On Wed, 6 Aug 2008, Joel Sherrill wrote:
> $ arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
> test_neon.c /tmp/ccBzigjD.s: Assembler messages:
> /tmp/ccBzigjD.s:13: Error: selected processor does not support `vldr
> d18,[fp,#-32]'
>
>
> So with that combination of options gcc
Hi,
Attached is the latest revision of the Ada
Hardware Interrupt patch. It has been tracked
as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
Interrupt support tested on sparc-rtems.
ACATS reported on sparc, mips, i386, powerpc, and arm.
2008-08-06 Joel Sherrill <[EMAIL PROTECTED]>
*
Paul Koning <[EMAIL PROTECTED]> writes:
> That's sufficient for live debugging but not for corefiles. In that
> case you do want caller-saved registers, because they may contain
> local variable values that don't live in memory at the time of the
> abort call.
In an optimized build you can't exp
Paul Koning <[EMAIL PROTECTED]> writes:
> > That's sufficient for live debugging but not for corefiles. In that
> > case you do want caller-saved registers, because they may contain
> > local variable values that don't live in memory at the time of the
> > abort call.
On Wed, Aug 06, 2008 at 11:
Snapshot gcc-4.2-20080806 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080806/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> From: mark@
> To: drow@; gcc@
> CC: sposelenov@; gdb@
> I suppose it optimizes away the instructions to save the return
> address, because abort() is marked with __attribute__(noreturn). But
Ouch. Other compilers put a breakpoint after a call to any noreturn function.
Really, the com
That said, updating in trunk is a different matter. There, the question
IMHO is mostly which libtool version to update to. The git version may
still have a regression or two, but 2.2.4 doesn't have the -fPIC on
HP/IA patch from Steve (which would be trivial to backport of course).
Alternativel
32 matches
Mail list logo
