> You set a breakpoint at the return address assuming that you
> will reach it when you finish the function.
OK, in this case you'll need to adjust like in the EH unwinder.
--
Eric Botcazou
It was suggested that I post an RFC here. With advance apologies for its
length, I am looking for comments, remarks, and/or advice.
I'm currently trying to code a C language structure for a complex block
of 0x200 bytes in size from a paper document. This particular
declaration is rife with bit
Hi,
In addition to Kenneth's reply, here are a few references you may want to look
at:
Edwin Bonilla, "Predicting Good Compiler Transformations Using Machine
Learning",
MS Thesis, School of Informatics, University of Edinburgh, UK, October 2004.
http://www.inf.ed.ac.uk/publications/thesis/onl
Andrew Pinski wrote:
> On 6/7/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> * PTR_PLUS branch.
>>
>> I believe that this branch should be included in GCC 4.3. Andrew,
>> would you please update me as to its status?
>> In particular, are there
>> any regressions on primary or secondary targets
Besides my duties as RM, I plan to focus my GCC development time on LTO.
This project has been dormant for a while, due to a variety of
constraints, but we (my fellow Sourcerers and I) will be able to put
more effort into LTO in the near future. Kenny plans to work on LTO
once dataflow is merged.
I hear dataflow-branch is near merge to trunk, so I thought it'd
be about time to verify that it works for the targets I
maintain...
Comparing dataflow-branch with trunk, both r125590, I see these
regressions (alas no improvements) on the branch for cris-elf
cross from x86_64-unknown-linux-gnu (De
Hi,
Can I get any help on this???
Thanks in advance
Regards,
Stephen K. Gadde
-Original Message-
From: Jeanne Rasata via RT [mailto:[EMAIL PROTECTED]
Sent: Friday, June 08, 2007 7:43 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [gnu.org #336636] Needed Java Compilers for SUS
Thanks for the detailed instruction on how to reproduce it
- I have successfully reproduced the problem, and narrowed it down
to combine that's deleting the insn in question.
Hopefully I'll be able to figure out what's wrong soon.
Seongbae
On 6/10/07, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote
This little patch:
diff -r 9e2b1e62931a gcc/combine.c
--- a/gcc/combine.c Wed Jun 06 23:08:38 2007 +
+++ b/gcc/combine.c Mon Jun 11 05:39:25 2007 +
@@ -4237,7 +4237,7 @@ subst (rtx x, rtx from, rtx to, int in_d
So force this insn not to match in this (rare) case. */
if (!
