On 05/12/14 22:40, Jeff Law wrote:
On 12/05/14 15:34, Dominique Dhumieres wrote:
As I've tried to explain, that is IMHO wrong though.
If what you are after is the -B stuff too, then perhaps:
...
Sorry but it does not work:
BTW, thanks for working with Jakub on this. We're going to be
On 25/11/14 20:37, Mike Stump wrote:
On Nov 23, 2014, at 4:06 PM, FX fxcoud...@gmail.com wrote:
One question to build maintainers, and one patch submitted to top-level
configure.ac
So, not sure who wants to review this. From the darwin perspective, Ok.
I mean from my limited viewpoint it
On 06/11/14 11:33, Rainer Orth wrote:
Hi Phil,
The configure change is fine. Also the include. (From a libcc
authorship point of view). I am not aware of the history of AF_UNIX
over AF_LOCAL so I have no comment on that. Please await permission
the glibc manual states
AF_UNIX
On 03/11/14 16:54, Rainer Orth wrote:
I noticed that the new libcc1 wasn't built on Solaris. This happens
because socketpair doesn't live in libc, but in libsocket instead. To
deal with this, I've copied the libgo (and libjava) code to detect the
need for libsocket and libnsl. Once the
On 29/10/14 10:31, Jakub Jelinek wrote:
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim
gdb gprof etc expect
On 29/10/14 10:53, Paolo Bonzini wrote:
2) why is GMPLIB not handled in the same way?
The only problem is that system.h includes gmp.h, so we need a way
to find that header. I think libcc1 doesn't use any functions from gmp
itself, so if gmp.h can be included, GMPLIB isn't really needed.
On 29/10/14 10:53, Paolo Bonzini wrote:
On 10/29/2014 11:51 AM, Jakub Jelinek wrote:
On Wed, Oct 29, 2014 at 11:37:42AM +0100, Paolo Bonzini wrote:
On 10/29/2014 11:28 AM, Jakub Jelinek wrote:
If this passes bootstrap/regtest, is it ok for trunk (should fix
two bootstrap issues)? Is the
On 29/10/14 10:31, Jakub Jelinek wrote:
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim
gdb gprof etc expect
On 29/10/14 11:24, Phil Muldoon wrote:
On 29/10/14 10:31, Jakub Jelinek wrote:
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex bison binutils gas ld fixincludes gcc
On 29/10/14 14:26, Phil Muldoon wrote:
On 29/10/14 11:24, Phil Muldoon wrote:
On 29/10/14 10:31, Jakub Jelinek wrote:
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex
On 28/10/14 08:13, Jakub Jelinek wrote:
On Tue, Oct 28, 2014 at 01:05:00AM +0100, Dominique Dhumieres wrote:
This patch has now been committed.
It breaks bootstap on x86_64-apple-darwin14:
...
make[3]: Entering directory `/opt/gcc/p_build/libcc1'
make all-am
make[4]: Entering directory
On 28/10/14 08:36, Uros Bizjak wrote:
This patch has now been committed.
Also breaks bootstap on x86_64-linux-gnu, CentOS 5.11:
gmake[4]: Entering directory `/home/uros/gcc-build/libcc1'
/bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../../gcc-svn/trunk/libcc1 -I
On 28/10/14 09:57, Uros Bizjak wrote:
On Tue, Oct 28, 2014 at 10:35 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Oct 28, 2014 at 09:36:45AM +0100, Uros Bizjak wrote:
This patch has now been committed.
Also breaks bootstap on x86_64-linux-gnu, CentOS 5.11:
For -Werror, I'd think that
On 28/10/14 10:51, Uros Bizjak wrote:
On Tue, Oct 28, 2014 at 11:35 AM, Phil Muldoon pmuld...@redhat.com wrote:
This patch has now been committed.
Also breaks bootstap on x86_64-linux-gnu, CentOS 5.11:
For -Werror, I'd think that should fix that, WARN_FLAGS should
already contain -Werror
On 28/10/14 10:51, Uros Bizjak wrote:
On Tue, Oct 28, 2014 at 11:35 AM, Phil Muldoon pmuld...@redhat.com wrote:
This patch has now been committed.
Also breaks bootstap on x86_64-linux-gnu, CentOS 5.11:
For -Werror, I'd think that should fix that, WARN_FLAGS should
already contain -Werror
if to Makefile.am.
The conditional if I am not terribly sure of. But it is the only way
I can think of to conditionally test for one version of libiberty over
another. I pretty much just took the if code from the
lto_plugin/Makefile.am
What do you think?
Cheers
Phil
--
2014-10-28 Phil Muldoon
On 28/10/14 12:24, Phil Muldoon wrote:
Hi
A few issues came to light this morning on some systems with
bootstrapping and libiberty linking issues. We erroneously specified
-Werror in stage one builds. This patch removes that flag. We also
unconditionally linked with the PIC version
On 28/10/14 12:34, Jakub Jelinek wrote:
On Tue, Oct 28, 2014 at 12:24:39PM +, Phil Muldoon wrote:
2014-10-28 Phil Muldoon pmuld...@redhat.com
* configure.ac: Remove -Werror.
* configure: Regenerate.
* Makefile.am: Remove -Werror. Link correct libiberty.
* Makefile.in
On 28/10/14 13:19, Joseph S. Myers wrote:
I'm seeing a different bootstrap failure from those already discussed:
In file included from
/scratch/jmyers/fsf/gcc-mainline/libcc1/../gcc/gcc-plugin.h:28:0,
from
/scratch/jmyers/fsf/gcc-mainline/libcc1/plugin.cc:34:
On 10/10/14 22:58, Jeff Law wrote:
On 10/09/14 03:07, Phil Muldoon wrote:
Given the length of time since the original post and now, can you please do
sanity bootstrap to make sure nothing's bitrotted before you commit?
I've built both pristine and patched branches with bootstrap enabled
On 10/10/14 22:58, Jeff Law wrote:
On 10/09/14 03:07, Phil Muldoon wrote:
Sorry for taking so long to reply. We've talked, on irc and elsewhere
a little (some at the Cauldron too!). I think the consensus is as
nobody has explicitly mentioned anything, this is OK to go in?
Yes, please go
, and libcc1 uses
this to invoke the proper GCC. This is done by (ewww) searching $PATH.
Tom
2014-06-19 Phil Muldoon pmuld...@redhat.com
Tom Tromey tro...@redhat.com
So my biggest concern here is long term maintenance -- who's going to own
care and feeding of these bits over time
On 19/08/13 09:00, Jonathan Wakely wrote:
On 16 August 2013 16:28, Tom Tromey wrote:
Phil == Phil Muldoon pmuld...@redhat.com writes:
Phil Anyway, I have regenerated the patch with the fixes requested.
Thanks.
Phil 2013-08-16 Phil Muldoon pmuld...@redhat.com
Phil PR gcc/53477
I
On 23/07/13 15:23, Tom Tromey wrote:
Phil == Phil Muldoon pmuld...@redhat.com writes:
Phil On 03/07/13 08:33, Phil Muldoon wrote:
This new patch replaces and obsoletes the previous. On further
inspection of some other pretty printer related bugs, it seems that
all of the printers need
On 13/06/13 14:49, Tom Tromey wrote:
Phil == Phil Muldoon pmuld...@redhat.com writes:
Phil Attached is an updated patch correcting the issues that you pointed
Phil out.
The patch itself looks fine to me, but I don't think I can approve it.
Tom
This new patch replaces and obsoletes
On 21/03/13 14:20, Tom Tromey wrote:
Phil == Phil Muldoon pmuld...@redhat.com writes:
Phil 2013-03-21 Phil Muldoon pmuld...@redhat.com
Phil PR gdb/15195
I think this should use a full URL.
Phil def to_string (self):
Why doesn't the 'children' method also need a fix
This patch fixes a bug in the std::tuple printer where, if the value
was passed by reference, the printer was not correctly dereferencing the
value before printing.
Cheers,
Phil
2013-03-21 Phil Muldoon pmuld...@redhat.com
PR gdb/15195
* python/libstdcxx/v6/printers.py
27 matches
Mail list logo
