On Wednesday, August 23 2017, Pedro Alves wrote:
> On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote:
>> Hi there,
>>
>> This is a series of two patches, one for GDB and one for GCC, which aims
>> to improve the detection and handling of triplets present on compiler
>> names. The motivation fo
On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote:
> Hi there,
>
> This is a series of two patches, one for GDB and one for GCC, which aims
> to improve the detection and handling of triplets present on compiler
> names. The motivation for this series was mostly the fact that GDB's
> "compile"
On Wednesday, August 23 2017, Pedro Alves wrote:
> On 08/23/2017 02:07 PM, Sergio Durigan Junior wrote:
>> On Wednesday, August 23 2017, Pedro Alves wrote:
>>
>>> On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote:
The GCC patch improves the libcc1::compiler_triplet_regexp::find and
li
On 08/23/2017 02:07 PM, Sergio Durigan Junior wrote:
> On Wednesday, August 23 2017, Pedro Alves wrote:
>
>> On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote:
>>> The GCC patch improves the libcc1::compiler_triplet_regexp::find and
>>> libcp1::compiler_triplet_regexp::find methods by first try
On Wednesday, August 23 2017, Pedro Alves wrote:
> On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote:
>> The GCC patch improves the libcc1::compiler_triplet_regexp::find and
>> libcp1::compiler_triplet_regexp::find methods by first trying to match
>> the triplet in the compiler name and correctl
On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote:
> The GCC patch improves the libcc1::compiler_triplet_regexp::find and
> libcp1::compiler_triplet_regexp::find methods by first trying to match
> the triplet in the compiler name and correctly discarding the triplet
> part of the regexp if the ma
On 05/29/2017 04:21 PM, Alexandre Oliva wrote:
Here's what I'm checking in, trunk and gcc-7-branch. Regstrapped on
x86_64-linux-gnu and i686-linux-gnu.
[libcc1] drop unused field from C++ lang_identifier
for gcc/cp/ChangeLog
* cp-tree.h (lang_identifier): Drop oracle_looked_up, unus
On May 28, 2017, Alexandre Oliva wrote:
> Oh, no! I put it there temporarily, very early in the project, because
> I couldn't find a better place (I looked for available bits elsewhere,
> and I recall I couldn't find any); at the end we moved to a hash_set
> (see query_oracle below), that makes
On May 26, 2017, Richard Biener wrote:
> On Mon, Jan 30, 2017 at 11:31 PM, Alexandre Oliva wrote:
> bool oracle_looked_up;
> that increased lang_identifier size by 8 bytes while there's "plenty" of free
> bits in tree_base (bonus point if you can reap a lang_flag).
Oh, no! I put it there te
On Thu, Jan 26, 2017 at 9:11 PM, Alexandre Oliva wrote:
> - introduced, new_friend can be called after the befriended class is
> + introduced, new_friend can be called after the befriending class is
s/new/add/ in the comment, too.
> +/* Build a template-dependent template type id (e.g., T).
Here are the incremental changes that, together, address all of your
feedback (thanks!), but separated in logically-related patches. In a
separate message, I'll post an updated, consolidated patch.
Rename ansi_*opname; export cp_literal_operator_id
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
ind
On Tue, Jan 24, 2017 at 3:43 PM, Alexandre Oliva wrote:
> On Jan 24, 2017, Jason Merrill wrote:
>> On Mon, Jan 23, 2017 at 7:21 PM, Alexandre Oliva wrote:
>>> On Jan 23, 2017, Jason Merrill wrote:
>>>
>>> + If the newly-created namespace is to be an inline namespace, after
>>> + pus
On Jan 24, 2017, Jason Merrill wrote:
> On Mon, Jan 23, 2017 at 7:21 PM, Alexandre Oliva wrote:
>> On Jan 23, 2017, Jason Merrill wrote:
>>
>> + If the newly-created namespace is to be an inline namespace, after
>> + push_namespace, get the nested namespace decl with
>> + get
On Mon, Jan 23, 2017 at 7:21 PM, Alexandre Oliva wrote:
> On Jan 23, 2017, Jason Merrill wrote:
>
> + If the newly-created namespace is to be an inline namespace, after
> + push_namespace, get the nested namespace decl with
> + get_current_binding_level, pop back to the enclosin
On Jan 23, 2017, Jason Merrill wrote:
> Better to fix an inconsistent API now than leave it to confuse future
> developers, I would think.
Here's an incremental patch to the API, with all the proposed name
changes to make the whole thing more consistent (the conventions are
made explicit at the
On Jan 22, 2017, Alexandre Oliva wrote:
> On Jan 13, 2017, Jason Merrill wrote:
>> On 09/23/2016 08:41 PM, Alexandre Oliva wrote:
>>> +/* Create a modified version of a function type that has default
>>> + values for some of its arguments. The returned type should ONLY be
>>> + used to defi
On Jan 23, 2017, Jason Merrill wrote:
> On Sun, Jan 22, 2017 at 6:06 PM, Alexandre Oliva wrote:
>> On Jan 13, 2017, Jason Merrill wrote:
>>
>>> On 09/23/2016 08:41 PM, Alexandre Oliva wrote:
+static tree global_friend_list;
>>
>>> This should be a hash_set rather than a TREE_LIST.
>>
>>
On Sun, Jan 22, 2017 at 6:06 PM, Alexandre Oliva wrote:
> On Jan 13, 2017, Jason Merrill wrote:
>
>> On 09/23/2016 08:41 PM, Alexandre Oliva wrote:
>>> +static tree global_friend_list;
>
>> This should be a hash_set rather than a TREE_LIST.
>
> You sure? At least in the libcc1 use scenario, this
On Sun, 22 Jan 2017, Alexandre Oliva wrote:
> On Jan 13, 2017, Jason Merrill wrote:
>
> > On 09/23/2016 08:41 PM, Alexandre Oliva wrote:
> >> +static tree global_friend_list;
>
> > This should be a hash_set rather than a TREE_LIST.
>
> You sure? At least in the libcc1 use scenario, this is go
On Jan 13, 2017, Jason Merrill wrote:
> On 09/23/2016 08:41 PM, Alexandre Oliva wrote:
>> +static tree global_friend_list;
> This should be a hash_set rather than a TREE_LIST.
You sure? At least in the libcc1 use scenario, this is going to have a
single entry. I didn't even have to make it a
On Jan 13, 2017, Jason Merrill wrote:
> Again, sorry for the delay, and thank you for the continued pings.
Thanks for the detailed review, and sorry about the delayed response.
It caught me on the way out for a family vacation trip, and I could only
see it when I got back home today. I'll have
Again, sorry for the delay, and thank you for the continued pings. Did
you see my earlier review of the dwarf2out changes?
On 09/23/2016 08:41 PM, Alexandre Oliva wrote:
+/* Scopes (functions, classes, or templates) in the TREE_VALUE of
+ GLOBAL_FRIEND_LIST are regarded as friends of every c
On Dec 14, 2016, Alexandre Oliva wrote:
> On Oct 19, 2016, Alexandre Oliva wrote:
>> On Sep 23, 2016, Alexandre Oliva wrote:
>>> This patchset adds support for the C++ language to libcc1.
>>> It updates a few patches for libcc1 by Jan Kratochvil, posted long ago
>>> but IIRC not reviewed; it up
On Oct 19, 2016, Alexandre Oliva wrote:
> On Sep 23, 2016, Alexandre Oliva wrote:
>> This patchset adds support for the C++ language to libcc1.
>> It updates a few patches for libcc1 by Jan Kratochvil, posted long ago
>> but IIRC not reviewed; it updates a patch that adds support for
>> represen
On Sep 23, 2016, Alexandre Oliva wrote:
> This patchset adds support for the C++ language to libcc1.
> It updates a few patches for libcc1 by Jan Kratochvil, posted long ago
> but IIRC not reviewed; it updates a patch that adds support for
> representing aliases and trampolines in dwarf2+ debug i
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_UN
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
This is a synonym for AF_LOCAL. Although A
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 b
On 10/29/2014 09:10 PM, Jakub Jelinek wrote:
> On Wed, Oct 29, 2014 at 11:45:51AM +0100, Jakub Jelinek wrote:
>> On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote:
>>> On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
shouldn't libcc1 be in build_tools instead?
I mean, it is a li
On 10/29/14 08:32, Phil Muldoon wrote:
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
On Wed, Oct 29, 2014 at 11:45:51AM +0100, Jakub Jelinek wrote:
> On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote:
> > On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
> > > shouldn't libcc1 be in build_tools instead?
> > > I mean, it is a library meant to be dlopened by gdb and 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="
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 fixinclude
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 d
On 10/29/2014 11:58 AM, Phil Muldoon wrote:
> My archaeology into the source repository has not revealed why
> we needed bootstrap. Perhaps we included it out of a sense of
> paranoia for testing. I've CC'd Tom on this, so he may have an
> opinion or insight. From my point of view, I see no valu
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 d
On 10/29/2014 11:45 AM, Jakub Jelinek wrote:
> On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote:
>> On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
>>> shouldn't libcc1 be in build_tools instead?
>>> I mean, it is a library meant to be dlopened by gdb and gcc
>>> plugin that uses that l
On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote:
> On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
> > shouldn't libcc1 be in build_tools instead?
> > I mean, it is a library meant to be dlopened by gdb and gcc
> > plugin that uses that library, so in canadian-cross should be
> > for the
On 10/29/2014 11:31 AM, 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
39 matches
Mail list logo
