This is the mail archive of the
mailing list for the GCC project.
Re: [gofrontend-dev] [PATCH 0/9] Gccgo port to s390[x] -- part I
- From: Ian Lance Taylor <iant at golang dot org>
- To: vogt at linux dot vnet dot ibm dot com, gcc-patches <gcc-patches at gcc dot gnu dot org>, "gofrontend-dev at googlegroups dot com" <gofrontend-dev at googlegroups dot com>
- Date: Thu, 16 Oct 2014 17:07:00 -0700
- Subject: Re: [gofrontend-dev] [PATCH 0/9] Gccgo port to s390[x] -- part I
- Authentication-results: sourceware.org; auth=none
- References: <20140909124446 dot GA25290 at linux dot vnet dot ibm dot com>
On Tue, Sep 9, 2014 at 5:44 AM, Dominik Vogt <email@example.com> wrote:
> The following series' of patches introduce s390[x] support for
> Gccgo. For practical reasons they will be submitted in separate
> parts. This is the first part of the submissions with
> architecture independent bug fixes and enhancements that affect
> the following directories:
> gcc (Gcc)
> gcc/testsuite/gcc.misc-tests (Gcc)
> gcc/go/gofrontend (gofrontend)
> gcc/testsuite/go.test (golang)
> libgo (Gcc?)
> libgo/go (gofrontend)
> libgo/runtime (gofrontend)
> It seemed infeasible to split this patch series and send the
> patches only to the "right" places. The following s390[x] patch
> series' depend on all of them.
> Summary of this series:
> 0001: Fix for bug #60406. (gofrontend)
> 0002: Test case for 0001. (golang)
> 0003: Bug fix for opening s390 libs. (gofrontend)
> 0004: Libgo compile fix. (gofrontend)
> 0005: Cleanup of x86 relocations in libgo. (gofrontend, optional)
> 0006: Fix in libgo/runtime/proc.c (Gcc?)
> 0007: Extend -fdump-go-spec (bitfields, unions and a bugfix) (Gcc)
> 0008: Extend -fdump-go-spec (complex types) (Gcc, optional)
> 0009: Fix handling of whitespace in configure script. (Gcc?)
I think I've now replied to all the patches in this series.
Thanks very much for sending them.
It looks like you sent these messages by replying to earlier messages.
Next time I encourage you not to do that, as it puts all the messages,
and the replies to them, into a single thread in a threaded e-mail
reader. That makes it hard to separate out the discussion about the
individual separate patches. Better to send each patch as a separate
new e-mail message, not a reply, to start a new thread for each one.