[+iant]
Ian: can you approve the go changes in this patch?
It's a change in the linemap that reflects in functions used by go,
but that shouldn't have any effect on the go compiler's behaviour.
As a side thought, I'm getting random failures in the go test suite,
in my last run the difference was that
go.go-torture/execute/select-1.go failed in the clean build test and
passed in the patched build...
Every full test run I do I get different sets of differences, I've had
identical runs too, I highly doubt this is due to my patch.
On Fri, Aug 12, 2011 at 11:27 AM, Tom Tromey <tro...@redhat.com> wrote:
>>>>>> "Gabriel" == Gabriel Charette <gch...@google.com> writes:
>
> Gabriel> Removed LINEMAP_POSITION_FOR_COLUMN, it did the EXACT same
> Gabriel> thing as linemap_position_for_column, so maintaining both in
> Gabriel> parallel seems like overkill to me. The only thing I can think
> Gabriel> of is that it's more optimal as it's inlined (but if that's
> Gabriel> really needed we can always make linemap_position_for_column an
> Gabriel> inline function directly).
>
> I am sympathetic to this, but nobody is likely to do the performance
> tests post-patch.
>
> The libcpp parts are ok if it doesn't cause a noticeable slowdown in the
> GCC bootstrap.
>
I just did performance test and the results were identical before and after.
> I can't approve the changes outside of libcpp.
> Also, you didn't write a ChangeLog entry for those.
>
Here is the ChangeLog including gcc/go changes, added iant to get
approval for the go changes:
2011-08-11 Gabriel Charette <gch...@google.com>
libcpp/ChangeLog
* include/line-map.h (LINEMAP_POSITION_FOR_COLUMN): Remove.
Update all users to use linemap_position_for_column instead.
gcc/go/ChangeLog
* gofrontend/lex.cc (Lex::location): Update to use
linemap_position_for_column instead.
(Lex::earlier_location): Likewise.
Thanks,
Gabriel
