"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> > If you can't afford to lose a register, then I think your only option
> > is to pick some callee-saved register and have each branch instruction
> > explicitly clobber it. Then it will be available for use in a long
> > branch, and it will be avail
On 06 Dec 2006 23:13:35 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
David Daney <[EMAIL PROTECTED]> writes:
> > I am working on a private target where jump instruction patterns are
> > similiar to this
> >
> > jmp <24 bit offset>
> > jmp for 32 bit offsets
> >
> > if my offset is greater
Andrew Pinski wrote:
> But other non user-visible changes are mentioned on changes.html already.
> Forward prop in 4.3.
> Incompatible changes to the build system in 4.2 which seems very related to
> stuff like
> this.
If you want to make a patch, and Gerald approves it, it's fine by me.
But, fw
>
> Andrew Pinski wrote:
> >> What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
> >
> > t.c:
> >
> > #include
> > int main(void)
> > {
> > printf("Hello World\n");
> > return 0;
> > }
> >
> > --
> > No I did not set GCC_EXEC_PREFIX as I did not know I have to set that now.
Andrew Pinski wrote:
>> What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
>
> t.c:
>
> #include
> int main(void)
> {
> printf("Hello World\n");
> return 0;
> }
>
> --
> No I did not set GCC_EXEC_PREFIX as I did not know I have to set that now.
> Seems like a change like this
What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
t.c:
#include
int main(void)
{
printf("Hello World\n");
return 0;
}
--
No I did not set GCC_EXEC_PREFIX as I did not know I have to set that now.
Seems like a change like this should be mentioned on
http://gcc.gnu.org/gcc-4
On Dec 12, 2006, at 12:07 PM, David Edelsohn wrote:
Dale Johannesen writes:
Dale> It may have been intended to allow the callee to be a K&R-
style or
Dale> varargs function, where all float args get promoted to double.
Dale> In particular, printf was often called without being declared
in
> Dale Johannesen writes:
Dale> It may have been intended to allow the callee to be a K&R-style or
Dale> varargs function, where all float args get promoted to double.
Dale> In particular, printf was often called without being declared in K&R-
Dale> era code. This is one way to make that c
On Dec 12, 2006, at 11:42 AM, David Edelsohn wrote:
Joslwah writes:
Joslwah> Looking at the Linux 32bit PowerPC ABI spec, it appears to
me that
Joslwah> floats in excess of those that are passed in registers are
supposed to
Joslwah> be promoted to doubles and passed on the stack. Examin
> Joslwah writes:
Joslwah> Looking at the Linux 32bit PowerPC ABI spec, it appears to me that
Joslwah> floats in excess of those that are passed in registers are supposed to
Joslwah> be promoted to doubles and passed on the stack. Examing the resulting
Joslwah> stack from a gcc generated C c
I've come across an issue with using the -pg switch for profiling on the
DJGPP DOS platform, using GCC 4.1.0. After some digging through
disassembly, I found that the part of the function prologue for main()
before the call to mcount() is using the ECX register, and the call to
the mcount() funct
Andrew Pinski wrote:
> On Fri, 2006-10-13 at 12:51 -0400, Carlos O'Donell wrote:
>> A relocated compiler should not look in $prefix.
>> Comments?
>> OK for Stage1?
>
> I do have another issue with these set of patches which I did not notice
> until today.
> I can no longer do inside a just built G
Snapshot gcc-4.2-20061212 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061212/
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
> Ian Lance Taylor writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > In practice, %ebp either points to a call frame -- not necessarily
> the
> > > most recent one -- or is null. I don't think that having an optional
> > > frame pointer mees you can use %ebp for anything r
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > In practice, %ebp either points to a call frame -- not necessarily the
> > most recent one -- or is null. I don't think that having an optional
> > frame pointer mees you can use %ebp for anything random at all, but we
Andrew Haley <[EMAIL PROTECTED]> writes:
> In practice, %ebp either points to a call frame -- not necessarily the
> most recent one -- or is null. I don't think that having an optional
> frame pointer mees you can use %ebp for anything random at all, but we
> need to make a clarification request
On Tue, Dec 12, 2006 at 03:26:34PM +, Andrew Haley wrote:
> Ulrich Drepper writes:
> > Andrew Haley wrote:
> > > Null-terminating the call stack is too well-established practice to be
> > > changed now.
> >
> > Which does not mean that the mistake should hold people back.
>
> Sure it doe
On Mon, Dec 11, 2006 at 02:40:22PM -0800, Roland McGrath wrote:
> My reading is that the "ABI authoring body" for GNU systems or the
> "compilation system authoring body" for GNU compilers already specifies
> that the default rule is same_value for callee-saves registers (as chosen
> by each partic
On Tue, 12 Dec 2006 16:26:34 +0100, Andrew Haley wrote:
...
> It's certainly an inconsistency in the specification, which says that
> null-termination is supported, and this implies that you can't put a zero in
> there.
I tested now that you can put the zero there for both the libgcc unwinder and
Andrew Haley wrote:
Sure it does. Not breaking things is an excellent reason, probably
one of the the best reasons you can have.
Nothing breaks if the responsible tools are updated in unison.
Really? Well, that's one interpretation. I don't believe that,
though. It's certainly an inconsi
Ulrich Drepper writes:
> Andrew Haley wrote:
> > Null-terminating the call stack is too well-established practice to be
> > changed now.
>
> Which does not mean that the mistake should hold people back.
Sure it does. Not breaking things is an excellent reason, probably
one of the the best r
Andrew Haley wrote:
Null-terminating the call stack is too well-established practice to be
changed now.
Which does not mean that the mistake should hold people back. This is
just one of the mistakes in the x86-64 ABI. It was copied from x86 and
it was wrong there already.
In practice, %
Mark Kettenis writes:
> > Jan Kratochvil writes:
> >
> > > currently (on x86_64) the gdb backtrace does not properly stop at
> > > the outermost frame:
> > >
> > > #3 0x0036ddb0610a in start_thread () from
> > /lib64/tls/libpthread.so.0
> > > #4 0x0036dd0c68c3 in clone
> Jan Kratochvil writes:
>
> > currently (on x86_64) the gdb backtrace does not properly stop at
> > the outermost frame:
> >
> > #3 0x0036ddb0610a in start_thread () from
> /lib64/tls/libpthread.so.0
> > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
> > #5 0x
Jan Kratochvil writes:
> currently (on x86_64) the gdb backtrace does not properly stop at
> the outermost frame:
>
> #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0
> #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
> #5 0x in ?? ()
>
25 matches
Mail list logo
