> "Gabriel" == Gabriel Charette writes:
Gabriel> It nows exposes two libcpp functions to force the
Gabriel> source_location for tokens when desired.
I am not really a fan of this approach, but I see why you did it this
way -- anything else would be very invasive.
I can only approve the libc
On 08/18/2011 06:47 PM, Gabriel Charette wrote:
> Tom: ok for trunk?
>
> fortran@: The fortran change just reflects the fix from libcpp,
> fortran bootstrap and tests passed.
The Fortran change is OK.
Thanks for the patch!
Tobias
On 08/16/2011 02:37 AM, Gabriel Charette wrote:
Here is the upd
Tom: ok for trunk?
fortran@: The fortran change just reflects the fix from libcpp,
fortran bootstrap and tests passed.
Thanks,
Gabriel
On Wed, Aug 17, 2011 at 1:04 PM, Dodji Seketeli wrote:
> Hello Gabriel,
>
> gch...@google.com (Gabriel Charette) a écrit:
>
>> Here is the updated patch.
>>
>>
Hello Gabriel,
gch...@google.com (Gabriel Charette) a écrit:
> Here is the updated patch.
>
> It nows exposes two libcpp functions to force the source_location for tokens
> when desired.
>
> The lexer then checks for a value set by these functions in cpp_reader and
> acts accordingly when needi
Here is the updated patch.
It nows exposes two libcpp functions to force the source_location for tokens
when desired.
The lexer then checks for a value set by these functions in cpp_reader and acts
accordingly when needing a location for a new token (either using the
forced_location or calling
> I also removed LINEMAP_POSITION_FOR_COLUMN, it did the EXACT same thing as
> linemap_position_for_column, so maintaining both in parallel seems like
> overkill to me. The only thing I can think of is that it's more optimal as
> it's inlined (but if that's really needed we can always make
> li
On Thu, Aug 11, 2011 at 10:45 AM, Dodji Seketeli wrote:
>> As I mentioned, we have the same problem in pph where we need to force
>> a location (i.e. the lexer is assigning new locations, but we don't
>> want it to when we are replaying pre-processor tokens), so just a
>> "builtin_location" field
On Thu, Aug 11, 2011 at 10:14 AM, Richard Guenther
wrote:
> On Thu, Aug 11, 2011 at 6:54 PM, Gabriel Charette wrote:
>> On Thu, Aug 11, 2011 at 12:27 AM, Richard Guenther
>> wrote:
>>> On Wed, Aug 10, 2011 at 8:22 PM, Gabriel Charette wrote:
There was a bug where c_finish_options would cre
Gabriel Charette a écrit:
> That could work given _cpp_lex_direct does receive a cpp_reader as a
> parameter. We would need to add logic in _cpp_lex_direct to support
> this new field.
Correct.
>
> As I mentioned, we have the same problem in pph where we need to force
> a location (i.e. the lex
Gabriel Charette a écrit:
> On Thu, Aug 11, 2011 at 12:27 AM, Richard Guenther
> wrote:
>> On Wed, Aug 10, 2011 at 8:22 PM, Gabriel Charette wrote:
>>> There was a bug where c_finish_options would create some builtins and
>>> assign them source_locations in the linemap other than BUILTINS_LOCA
On Thu, Aug 11, 2011 at 6:54 PM, Gabriel Charette wrote:
> On Thu, Aug 11, 2011 at 12:27 AM, Richard Guenther
> wrote:
>> On Wed, Aug 10, 2011 at 8:22 PM, Gabriel Charette wrote:
>>> There was a bug where c_finish_options would create some builtins and
>>> assign them source_locations in the li
On Thu, Aug 11, 2011 at 12:27 AM, Richard Guenther
wrote:
> On Wed, Aug 10, 2011 at 8:22 PM, Gabriel Charette wrote:
>> There was a bug where c_finish_options would create some builtins and assign
>> them source_locations in the linemap other than BUILTINS_LOCATION == 1.
>>
>> Thus, when calling
On Thu, Aug 11, 2011 at 7:22 AM, Dodji Seketeli wrote:
> Hello,
>
> gch...@google.com (Gabriel Charette) a écrit:
>
>> diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
>> index 3227f7b..1af8e7b 100644
>> --- a/gcc/c-family/c-opts.c
>> +++ b/gcc/c-family/c-opts.c
>> @@ -1306,13 +1306,15 @
Hello,
gch...@google.com (Gabriel Charette) a écrit:
> diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
> index 3227f7b..1af8e7b 100644
> --- a/gcc/c-family/c-opts.c
> +++ b/gcc/c-family/c-opts.c
> @@ -1306,13 +1306,15 @@ c_finish_options (void)
> {
>size_t i;
>
> -
On Thu, Aug 11, 2011 at 09:32, Richard Guenther
wrote:
> Well, they both make sense - you should just not confuse them.
> DECL_IS_BUILTIN should probably renamed to
> DECL_HAS_BUILTIN_SOURCE_LOCATION or similar.
Exactly. The problem is that now they both *seem* to have the same semantics.
> I'
On Thu, Aug 11, 2011 at 3:01 PM, Diego Novillo wrote:
> On Thu, Aug 11, 2011 at 03:27, Richard Guenther
> wrote:
>> On Wed, Aug 10, 2011 at 8:22 PM, Gabriel Charette wrote:
>>> There was a bug where c_finish_options would create some builtins and
>>> assign them source_locations in the linemap
On Thu, Aug 11, 2011 at 03:27, Richard Guenther
wrote:
> On Wed, Aug 10, 2011 at 8:22 PM, Gabriel Charette wrote:
>> There was a bug where c_finish_options would create some builtins and assign
>> them source_locations in the linemap other than BUILTINS_LOCATION == 1.
>>
>> Thus, when calling DE
On Wed, Aug 10, 2011 at 8:22 PM, Gabriel Charette wrote:
> There was a bug where c_finish_options would create some builtins and assign
> them source_locations in the linemap other than BUILTINS_LOCATION == 1.
>
> Thus, when calling DECL_IS_BUILTIN to know if a decl is a builtin, some of
> them
Tested with bootstrap and full regression testing on x64.
On Wed, Aug 10, 2011 at 11:22 AM, Gabriel Charette wrote:
> There was a bug where c_finish_options would create some builtins and assign
> them source_locations in the linemap other than BUILTINS_LOCATION == 1.
>
> Thus, when calling DECL
There was a bug where c_finish_options would create some builtins and assign
them source_locations in the linemap other than BUILTINS_LOCATION == 1.
Thus, when calling DECL_IS_BUILTIN to know if a decl is a builtin, some of them
would return false as they had a source_location other than BUILTIN
20 matches
Mail list logo
