Patch RFC: Avoid recursive insert into const_desc_htab

Richard Biener richard.guenther@gmail.com
Thu Feb 21 12:19:00 GMT 2019


On Wed, Feb 20, 2019 at 6:53 PM Ian Lance Taylor <iant@golang.org> wrote:
>
> The underlying cause of PR 89170 is a bug that appears to have existed
> since 2001, when the function decode_addr_const was changed to call
> output_constant_def.  The problem is that output_constant_def calls
> compare_constant, and when compare_constant sees an ADDR_EXPR, it
> calls decode_addr_const.  So it is possible for output_constant_def to
> call itself recursively while adding a value to the hash table.  This
> only happens if there are already some constants in the hash table
> with the same hash code, because that is the only case in which
> compare_constant can call decode_addr_constant.  This works fine if
> the value whose address is taken is already in the hash table.  And it
> works fine if the address is not in the hash table, but adding the
> address does not cause the hash table to grow.
>
> But if we call output_constant_def with a constant that includes an
> ADDR_EXPR, and if there is already a constant in the hash table with
> the same hash code, and if decode_addr_constant calls
> output_constant_def recursively with a constant that is not already in
> the hash table, and if adding that constant causes the hash table to
> grow, then the outer call to output_constant_def will wind up looking
> at the wrong hash bucket.  The effect is that output_constant_def will
> return an rtx for a different constant.
>
> This unlikely sequence of events actually happened building libgo's
> net/http test on PPC64, causing a miscompilation leading to a test
> failure filed as PR 89170.
>
> I plan to commit this patch to fix the problem.  I didn't add a test
> case since the sequence of events is so hard to recreate.  I added a
> check that will detect any future recursive insertion into the hash
> table.
>
> Bootstrapped and tested on x86_64-pc-linux-gnu.  Since I haven't
> looked at this part of the code in many years, I'll wait a bit to see
> if anybody has any comments on the patch.

Looks reasonable.  Factoring the common code in
output_constant_def and tree_output_constant_def might be
worth it.

Richard.

> Ian
>
>
> 2019-02-20  Ian Lance Taylor  <iant@golang.org>
>
> PR go/89170
> * varasm.c (decode_addr_const): Call lookup_constant_def rather
> than output_constant_def.
> (const_desc_htab_inserting): New static variable.
> (output_constant_def): Call output_addressed_constants.  Check and
> set const_desc_htab_inserting.
> (tree_output_constant_def): Likewise.



More information about the Gcc-patches mailing list