Hi!
On Thu, 30 Oct 2014 11:10:51 +0100, I wrote:
> Build a shared host libiberty also for libcc1's benefit.
Backported to gomp-4_0-branch in r216918:
commit 595db85c7323b08d29bf344911a7bd709d68685b
Author: tschwinge
Date: Thu Oct 30 11:09:14 2014 +
Build a shared host libiberty a
Hi!
On Thu, 30 Oct 2014 09:51:59 +0100, Jakub Jelinek wrote:
> On Thu, Oct 30, 2014 at 09:33:08AM +0100, Thomas Schwinge wrote:
> > Here is a patch that I'm testing; OK? I didn't understand what the
> > conditions are that libcc1 might not be built as a shared library: is it
> > always built as
On Thu, Oct 30, 2014 at 09:33:08AM +0100, Thomas Schwinge wrote:
> Here is a patch that I'm testing; OK? I didn't understand what the
> conditions are that libcc1 might not be built as a shared library: is it
> always built as one -- but is that really supported on all systems? If
It is not unco
Hi!
On Tue, 28 Oct 2014 13:23:50 +0100, Jakub Jelinek wrote:
> On Tue, Oct 28, 2014 at 11:47:31AM +, Phil Muldoon wrote:
> > I think I have a solution. Though my automake fu is very weak. Does
> > this patch work for you? I'm really not sure how to deal with the
> > three possible versions
On 10/29/14 04:28, Jakub Jelinek wrote:
On Tue, Oct 28, 2014 at 05:36:50PM +, Phil Muldoon wrote:
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
On 10/28/14 06:23, Jakub Jelinek wrote:
On Tue, Oct 28, 2014 at 11:47:31AM +, Phil Muldoon wrote:
I think I have a solution. Though my automake fu is very weak. Does
this patch work for you? I'm really not sure how to deal with the
three possible versions of libiberty any other way.
Tha
On 10/29/2014 11:59 AM, Jakub Jelinek wrote:
>> > Ah, got it. Is it hard to move the inclusion to the actual users?
> I think it is hard. I think it has been moved to system.h very much
> intentionally, as including gmp.h only in selected headers was causing lots
> of troubles, e.g. because of #p
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 bootst
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 n
On Wed, Oct 29, 2014 at 11:53:28AM +0100, 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 in
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
>>> https://gcc.gnu.org/ml/gc
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
> > https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02936.html
> > patch ok too (
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
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02936.html
> patch ok too (that one already tested; another bootstrap issue)?
Both seem okay, though I'
On Tue, Oct 28, 2014 at 05:36:50PM +, Phil Muldoon wrote:
> 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,
> >
On Tue, 28 Oct 2014, Phil Muldoon wrote:
> Joseph,
>
> Hi, sorry for the troubles! I am having difficulty seeing this fail on
> my system. I built gmp from upstream, installed it, and pointed to
> the install location with --with-gmp. Which stage does your build fail
> at?
To get the failure yo
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:
> /scratch
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:
/scratch/jmyers/fsf/gcc-mainline/libcc1/../gcc/system.h:653:1
On Tue, Oct 28, 2014 at 11:47:31AM +, Phil Muldoon wrote:
> I think I have a solution. Though my automake fu is very weak. Does
> this patch work for you? I'm really not sure how to deal with the
> three possible versions of libiberty any other way.
That is insufficient,
a) you don't filter
On 28/10/14 10:51, Uros Bizjak wrote:
> On Tue, Oct 28, 2014 at 11:35 AM, Phil Muldoon 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
On 28/10/14 10:51, Uros Bizjak wrote:
> On Tue, Oct 28, 2014 at 11:35 AM, Phil Muldoon 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 du
On Tue, Oct 28, 2014 at 11:35 AM, Phil Muldoon 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 during stage2/stage3 unless --disable-
On 28/10/14 09:57, Uros Bizjak wrote:
> On Tue, Oct 28, 2014 at 10:35 AM, Jakub Jelinek 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 sh
On Tue, Oct 28, 2014 at 10:35 AM, Jakub Jelinek 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 should fix that, WARN_FLAGS should
> already co
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 should fix that, WARN_FLAGS should
already contain -Werror during stage2/stage3 unless --disable-werror.
Untes
On Tue, Oct 28, 2014 at 9:50 AM, Phil Muldoon wrote:
> 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=com
On Tue, Oct 28, 2014 at 08:43:35AM +, Phil Muldoon wrote:
> 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]: Ent
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
On 28 October 2014 09:43, Phil Muldoon wrote:
> 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
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]: Enteri
> 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 ../../gcc-svn/trunk/libcc1/../include
-I ../
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 `/opt/gcc/p_build/libcc1'
> mak
> 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 `/opt/gcc/p_build/libcc1'
make[4]: *** No rule to make target `../libiberty/pic/libiberty.a', needed by
`libcc1.la'
> 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 ena
On 10/24/14 01:15, Phil Muldoon wrote:
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, t
On Fri, Oct 24, 2014 at 08:15:36AM +0100, Phil Muldoon wrote:
> 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
> >>
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, ple
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 ahead and check it in. You'll be the fir
On Thu, Oct 09, 2014 at 10:07:23AM +0100, Phil Muldoon wrote:
> >> 2014-06-19 Phil Muldoon
> >> Tom Tromey
>
> > So my biggest concern here is long term maintenance -- who's going to own
> > care and feeding of these bits over time.
>
> Sorry for taking so long to reply. We've talk
On 31/07/14 05:47, Jeff Law wrote:
> On 06/19/14 14:52, Tom Tromey wrote:
>> Here's a new version of patch #5.
>> I've removed the generated code; let's see if it gets through without
>> compression.
>>
>> I think this addresses all the reviews:
>>
>> * It uses gcc-plugin.m4 to disable the plugin
>
On Sun, 14 Sep 2014 17:07:05 +0200, Manuel López-Ibáñez wrote:
> What happened with this? I don't see any libcc1 in the gcc repository
> and this patch was never committed.
It was discussed internally and the patches are going to be updated, rebased
and later checked in.
Thanks,
Jan
What happened with this? I don't see any libcc1 in the gcc repository
and this patch was never committed.
Cheers,
Manuel.
On 31 August 2014 17:12, Gerald Pfeifer wrote:
> Hi Jan,
>
> On Fri, 8 Aug 2014, Jan Kratochvil wrote:
"Jeff" == Jeff Law writes:
Does this deserve a mention
Hi Jan,
On Fri, 8 Aug 2014, Jan Kratochvil wrote:
>>> "Jeff" == Jeff Law writes:
>>> Does this deserve a mention in the news file?
> Attached (based on Tom's PATCH 0/5 mail).
Index: htdocs/gcc-5/changes.html
===
+C
+
+GDB
On Tue, 05 Aug 2014 21:34:00 +0200, Tom Tromey wrote:
> > "Jeff" == Jeff Law writes:
> Jeff> Does this deserve a mention in the news file?
>
> I suppose so, I will get someone here to write it.
Attached (based on Tom's PATCH 0/5 mail).
Jan
Index: htdocs/gcc-5/changes.html
=
> "Jeff" == Jeff Law writes:
Jeff> Obviously if there are no objections and you check in the change,
Jeff> please be on the lookout for any fallout. I'm particularly concerned
Jeff> about AIX, Solaris and other non-linux platforms.
I did a build on the AIX box (gcc111) in the compile farm a
> "Mike" == Mike Stump writes:
Mike> So the normal way to do this would be to make the plugin front-end
Mike> non-default and then never gate any release decisions upon the state
Mike> of the that front-end.
Not sure if this is overly pedantic, but the plugin is just a library,
not a front e
On Thu, Jul 31, 2014 at 01:51:45PM -0600, Tom Tromey wrote:
> > "Trevor" == Trevor Saunders writes:
>
> Trevor> the plugin part seems fine, but I do find my self wondering if
> there's a
> Trevor> better way of doing the hooks into C, if they can be more genrally
> Trevor> useful.
>
> There
On Jul 30, 2014, at 9:47 PM, Jeff Law wrote:
> So my biggest concern here is long term maintenance -- who's going to own
> care and feeding of these bits over time.
>
> My inclination is to go ahead and approve, but explicitly note that if the
> bits do start to rot that we'll be fairly aggress
> "Trevor" == Trevor Saunders writes:
Trevor> the plugin part seems fine, but I do find my self wondering if there's a
Trevor> better way of doing the hooks into C, if they can be more genrally
Trevor> useful.
There's just one now, the binding oracle.
(There used to be two but we reimplement
On Thu, Jul 31, 2014 at 01:12:54PM -0600, Tom Tromey wrote:
> Richard> Can you briefly elaborate on how this relates to the JIT work from
> Richard> David Malcom?
>
> I think Trevor answered this bit well but I had a bit more to add...
>
> Richard> Just throwing in my mental notes from the Summit
On Thu, Jul 31, 2014 at 01:12:54PM -0600, Tom Tromey wrote:
> Richard> [ideally both frontends and targets would be shared objects, but of
> Richard> course even frontends have target dependencies pulled in via
> Richard> target macros at the moment...]
>
> We actually started development with thi
Richard> Can you briefly elaborate on how this relates to the JIT work from
Richard> David Malcom?
I think Trevor answered this bit well but I had a bit more to add...
Richard> Just throwing in my mental notes from the Summit here. I really
Richard> wonder how libcc1 falls in into this picture a
On Thu, 31 Jul 2014, Richard Biener wrote:
> Actually after looking again I was wrong. main.c and toplev.c
> are the "driver". So if we can make all frontends shared objects
> with their only interface being their lang_hooks that would be nice
> (of course the middle-end still needs to make gazi
On Thu, Jul 31, 2014 at 12:44 PM, Trevor Saunders wrote:
> On Thu, Jul 31, 2014 at 10:01:15AM +0200, Richard Biener wrote:
>> On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law wrote:
>> > On 06/19/14 14:52, Tom Tromey wrote:
>> >>
>> >> Tom> I've edited this one down by removing the auto-generated stuff
On Thu, Jul 31, 2014 at 10:01:15AM +0200, Richard Biener wrote:
> On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law wrote:
> > On 06/19/14 14:52, Tom Tromey wrote:
> >>
> >> Tom> I've edited this one down by removing the auto-generated stuff , and
> >> Tom> then compressed it.
> >>
> >> Here's a new versi
On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law wrote:
> On 06/19/14 14:52, Tom Tromey wrote:
>>
>> Tom> I've edited this one down by removing the auto-generated stuff , and
>> Tom> then compressed it.
>>
>> Here's a new version of patch #5.
>> I've removed the generated code; let's see if it gets throu
On 06/19/14 14:52, Tom Tromey wrote:
Tom> I've edited this one down by removing the auto-generated stuff , and
Tom> then compressed it.
Here's a new version of patch #5.
I've removed the generated code; let's see if it gets through without
compression.
I think this addresses all the reviews:
*
On Tue, Jun 24, 2014 at 11:12:38AM -0600, Tom Tromey wrote:
> Trevor> hrm, I know basically nothing about the upcoming changes, but I would
> Trevor> have expected linking c++03 code against c++11 code would be fine
> Trevor> especially when the interface doesn't involve any stl.
>
> https:
Trevor> hrm, I know basically nothing about the upcoming changes, but I would
Trevor> have expected linking c++03 code against c++11 code would be fine
Trevor> especially when the interface doesn't involve any stl.
https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
This warns against mixing wi
On Mon, Jun 23, 2014 at 01:09:41PM -0600, Jeff Law wrote:
> On 06/20/14 09:33, Tom Tromey wrote:
> >>"Trevor" == Trevor Saunders writes:
> >
> >Trevor> I'm curious, what is the reason you choose not to write this in
> >C++11 or
> >Trevor> later? Its distributed with gcc, so the only case whe
On 06/20/14 09:33, Tom Tromey wrote:
"Trevor" == Trevor Saunders writes:
Trevor> I'm curious, what is the reason you choose not to write this in C++11 or
Trevor> later? Its distributed with gcc, so the only case where you aren't
Trevor> building with the in tree compiler and libraries is when
> "Trevor" == Trevor Saunders writes:
Trevor> I'm curious, what is the reason you choose not to write this in C++11 or
Trevor> later? Its distributed with gcc, so the only case where you aren't
Trevor> building with the in tree compiler and libraries is when your cross
Trevor> compiling gcc,
> "Jakub" == Jakub Jelinek writes:
Jakub> If you plan to implement this for other frontends (cc1plus,
Jakub> f951?) in the future, would that be still libcc1 and perhaps new
Jakub> plugins in there, or are we going to have new toplevel
Jakub> directories for each such a plugin?
We're plannin
On Thu, Jun 19, 2014 at 02:52:12PM -0600, Tom Tromey wrote:
> Tom> I've edited this one down by removing the auto-generated stuff , and
> Tom> then compressed it.
>
> Here's a new version of patch #5.
> I've removed the generated code; let's see if it gets through without
> compression.
>
> I thi
Joseph> I don't see anything obvious that would disable the plugin if
Joseph> plugins are unsupported (e.g. on Windows host) or disabled
Joseph> (--disable-plugin). Probably the relevant support from
Joseph> gcc/configure.ac needs to go somewhere it can be used at
Joseph> toplevel.
Here's the pat
> "Joseph" == Joseph S Myers writes:
Tom> This patch adds the plugin to the gcc tree and updates the
Tom> top-level configury.
Following up on your review.
Joseph> I don't see anything obvious that would disable the plugin if
Joseph> plugins are unsupported (e.g. on Windows host) or disable
On Jun 5, 2014, at 12:34 PM, Tom Tromey wrote:
> If you could enumerate the things you think are necessary to check, I
> can arrange for the plugin to not be built if those are not available.
So, I think it a single check on socketpair is likely good enough. If it is
present, likely all the res
> "Mike" == Mike Stump writes:
Mike> On May 16, 2014, at 11:48 AM, Tom Tromey wrote:
>> This patch adds the plugin to the gcc tree
Mike> So, this code isn’t as portable as gcc (I can run a native gcc
Mike> bootstrap on my binutils sim simulator for my target, and I’m a newlib
Mike> target),
On May 16, 2014, at 11:48 AM, Tom Tromey wrote:
> This patch adds the plugin to the gcc tree
So, this code isn’t as portable as gcc (I can run a native gcc bootstrap on my
binutils sim simulator for my target, and I’m a newlib target), so it needs
autoconf to explain if enough features are pres
On May 16, 2014, at 11:48 AM, Tom Tromey wrote:
> I've edited this one down by removing the auto-generated stuff , and
> then compressed it.
+ // remove the "const" and handle deallcation from pointer types.
sp: deallocation
> "Joseph" == Joseph S Myers writes:
>> + self->args.push_back ("gcc");
Joseph> seems wrong - at least you should use the appropriate compiler
Joseph> name after transformation for cross compilers /
Joseph> --program-transform-name.
Ok, we'll look into it.
Joseph> I'm not clear on which l
On Fri, 16 May 2014, Tom Tromey wrote:
> This patch adds the plugin to the gcc tree and updates the top-level
> configury.
I don't see anything obvious that would disable the plugin if plugins are
unsupported (e.g. on Windows host) or disabled (--disable-plugin).
Probably the relevant support
> "Tom" == Tom Tromey writes:
Tom> This patch series is half of a project to let gdb reuse gcc (which
Tom> half depends on which list you are seeing this on), so that users can
Tom> compile small snippets of code and evaluate them in the current
Tom> context of the inferior.
Jeff noted that
72 matches
Mail list logo
