Adding gcc@gcc.gnu.org
On Wed, Jun 29, 2011 at 6:08 PM, Gabriel Charette wrote:
>
> What's the purpose of weak_global_object_name? Defined in gcc/varasm.c
> grepping from the base of the source recursively I only find this:
> ./gcc/ChangeLog-1998: * varasm.c (assemble_sta
6 PM, Andrew Pinski wrote:
> On Wed, Jun 29, 2011 at 6:13 PM, Gabriel Charette wrote:
>> Adding gcc@gcc.gnu.org
>>
>> On Wed, Jun 29, 2011 at 6:08 PM, Gabriel Charette wrote:
>>>
>>> What's the purpose of weak_global_object_name? Defined in gcc/v
Aaah my bad!
Thanks,
Gab
On Wed, Jun 29, 2011 at 6:45 PM, Andrew Pinski wrote:
> On Wed, Jun 29, 2011 at 6:44 PM, Gabriel Charette wrote:
>> Well looking at notice_global_symbol:
>>
>> The comments says that weak_global_object_name is set in it, but there
>> i
Hey Diego,
as we just talked over the phone, here is the diff I had sitting in my
stash to ask the pph cache to replace the next cache insert by the
given pointer (while still reading what's in the stream).
To use it simply call pph_cache_replace_next_by(stream, your_new_pointer)
and immediately
Hey guys,
so the asm diff we are seeing in c1builtin-integral is not something
we are not streaming out, or any other logic being wrong in the pph.
The problem is: we define a dg-options entry in the header file which
tells deja-gnu to add flags to the compilation (so far so good...)
The problem
test pass (since now we are using
no additional flags across all compilations)
Gab
On Mon, Jul 18, 2011 at 5:29 PM, Gabriel Charette wrote:
> Hey guys,
>
> so the asm diff we are seeing in c1builtin-integral is not something
> we are not streaming out, or any other logic being wrong in th
On Mon, Jul 18, 2011 at 5:52 PM, Diego Novillo wrote:
> On Mon, Jul 18, 2011 at 20:45, Gabriel Charette wrote:
>> To demonstrate my point:
>> add /* { dg-options "-ffinite-math-only -fno-math-errno" } */
>> to c1builin-integral.cc
>>
>> and watch the
Hi,
@tromey: We have a question for you: the problem is detailed here and
our question to you is at the bottom. Thanks!
So the line problem we are having in pph is much bigger then we
originally thought.
The problem is:
As we've had issues with before: the chain of name bindings in any
cpp_bindi
Thanks for the quick reply Tom,
On Fri, Jul 22, 2011 at 1:39 PM, Tom Tromey wrote:
>>>>>> "Gabriel" == Gabriel Charette writes:
>
> Gabriel> @tromey: We have a question for you: the problem is detailed
> Gabriel> here and our question to you is a
On Sat, Jul 23, 2011 at 8:51 AM, Dodji Seketeli wrote:
> Gabriel Charette a écrit:
>
>>> Gabriel> @tromey: I hear you are the person in the know when it comes down
>>> to
>>> Gabriel> linemaps, do you have any hint on how we could rebuild a valid
>>
Alright, so after looking even more at the linemap code, here is what
I'm thinking now:
So the main problem is:
with the linemap logic is that linemap_line_start adds a new table
entry if line_delta < 0 (I don't understand why this is needed, my
assumption is that it is because the rest of the log
On Tue, Jul 26, 2011 at 4:25 AM, Dodji Seketeli wrote:
> Gabriel Charette a écrit:
>
>> Alright, so after looking even more at the linemap code, here is what
>> I'm thinking now:
>>
>> So the main problem is:
>> with the linemap logic is that linema
izing it's expanded location, saving space in the pph).
Let me know what you think,
Gabriel
On Tue, Jul 26, 2011 at 11:10 AM, Gabriel Charette wrote:
> On Tue, Jul 26, 2011 at 4:25 AM, Dodji Seketeli wrote:
>> Gabriel Charette a écrit:
>>
>>> Alright, so after loo
I think I wasn't clear in the way I expressed my assumptions in my last email:
On Wed, Jul 27, 2011 at 1:11 AM, Dodji Seketeli wrote:
>
> Gabriel Charette a écrit:
>
> > From what I understand, the source_locations allocated for
> > everything in a given set of head
>>
>> Hence, given that they only depend on start_location, I just have to
>> calculate an offset between the serialized start_location and the
>> start_location as it would be (highest_location + 1) in the C file
>> including the header, and offset all of the source_locations on each
>> token comi
Re-sending as plain text for gcc@gcc.gnu.org ...
Hi,
I have a question about the line 0 hack on line 13232 of gcc/cp/decl.c
(or just text search for "Hack", it's the only place it's found in
that file...).
From my revision history, Steven introduced this in 2005, an
I have removed the hack and the test output is identical to the clean
build test output.
See issue4835047 for the patch.
Gabriel
On Mon, Aug 1, 2011 at 2:56 PM, Gabriel Charette wrote:
> Re-sending as plain text for gcc@gcc.gnu.org ...
>
>
>
> H
17 matches
Mail list logo
