Committed.
* config/mep/mep.c (mep_legitimize_arg): Leave control registers
alone too.
Index: config/mep/mep.c
===
--- config/mep/mep.c(revision 149868)
+++ config/mep/mep.c(working copy)
@@ -6201,13 +6201,15
Snapshot gcc-4.4-20090721 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090721/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
This is the beta release of binutils 2.19.51.0.13 for Linux, which is
based on binutils 2009 0721 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
Gregory Casamento wrote:
> As far as I'm aware apple has an assignment for changes to gcc, so it
> should be possible to pull them in.
You're not forced to assign changes that you do not want to assign.
Paolo
As far as I'm aware apple has an assignment for changes to gcc, so it
should be possible to pull them in.
On Tuesday, July 21, 2009, wrote:
> Op 21 jul. 2009 21:50 schreef Paolo Bonzini :
>> Gregory Casamento wrote:
>>
>> > Hey guys I'm wondering if there's a timeline for incorporating the
>
Gregory Casamento wrote:
> All,
>
> Hey guys I'm wondering if there's a timeline for incorporating the
> Objective-C 2.0 changes from Apple into the trunk of GCC.
>
> If not, I would like to know what the GNUstep project can do to help
> make this happen.
No. But you just have to take patch
All,
Hey guys I'm wondering if there's a timeline for incorporating the
Objective-C 2.0 changes from Apple into the trunk of GCC.
If not, I would like to know what the GNUstep project can do to help
make this happen.
Thanks very much. :)
Sincerely, GC
--
Gregory Casamento
Open Logic Corpora
Douglas B Rupp writes:
> 1) submit the target independent bits and pieces first then the
> configure bits.
This seems like the right approach to me.
Ian
AdaCore has been maintaining the IVMS and AVMS ports for many years and
would like to submit our patches.
The patches consolidate the common parts of AVMS and IVMS into a new
config/vms directory. Since IVMS is a new port I believe the rules allow
it to be submitted all at once, but it does re
Actually, thinking further, the fix is for a consequence of the
incorrect placement of the breakpoint right after the branch.
I remember hitting the problem described too, but i didn't pursue a fix
for that (yet).
Luis
On Tue, 2009-07-21 at 10:50 -0300, Luis Machado wrote:
> Hi,
>
> Yes, this is
Hi,
Yes, this is exactly what i was chasing some time ago. The GCC fix i had
in mind (it just changes the ordering of statements) didn't get through
since it dealt with arch-independent code and there was fear that this
would break architectures other than PPC (or have the potential to do
so).
Th
Just ignore my previous mail. I find the error is because we failed to
import the new 4.5 directory libstdc++v3/python to our repository.
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Bingfeng Mei
> Sent: 21 July 2009 12:41
> To: gcc@gcc
On Thu, 2009-07-16 at 13:55 -0700, Michael Eager wrote:
> I've tracked down a failure in gdb to hit a breakpoint
> set at printf to the the breakpoint being placed incorrectly.
>
> Here is the code generated for printf with -mhard-float:
>
> .loc 1 29 0
> .cfi_startproc
> .LVL0:
>
Hello,
I am experiencing the following error when building TRUNK version of our port.
I am not familar with libtool. In 4.4, GCC produces its own libtools under
libstdc++v3 directory and other similar directories. But I cannot track
how the libtool is generated. Even I remove libtool under libstd
14 matches
Mail list logo
