[PATCH] PR 63721 IPA ICF cause atomic-comp-swap-release-acquire.c ICE

Jeff Law law@redhat.com
Thu Nov 6 23:22:00 GMT 2014


On 11/05/14 07:09, Jiong Wang wrote:
> the same ICE will happen on x86-64, if compile with -O2 -fPIC.
>
> the reason is for the following two functions, they are identical, so
> IPA-ICF
> pass try to transform the second function to call the first one directly.
>
> int
> atomic_compare_exchange_STRONG_RELEASE_ACQUIRE (int a, int b)
> {
>    return __atomic_compare_exchange (&v, &a, &b,
>                      STRONG, __ATOMIC_RELEASE,
>                      __ATOMIC_ACQUIRE);
> }
>
> int
> atomic_compare_exchange_n_STRONG_RELEASE_ACQUIRE (int a, int b)
> {
>    return __atomic_compare_exchange_n (&v, &a, b,
>                        STRONG, __ATOMIC_RELEASE,
>                        __ATOMIC_ACQUIRE);
> }
>
> while during this transformation, looks like there are something wrong
> with the
> function argument handling. take "a" for example, because later there
> are "&a",
> so it's marked as addressable. while after transformation, if we turn the
> second function into
>
> int atomic_compare_exchange_n_STRONG_RELEASE_ACQUIRE (int a, int b)
> {
>    return atomic_compare_exchange_STRONG_RELEASE_ACQUIRE (a, b)
> }
>
> then argument a is no longer addressable.
>
> so, in cgraph_node::release_body, when making the wrapper, except
> clearing the
> function body, we should also clear the addressable flag for function args
> because they are decided by the function body which is cleared.
>
> bootstrap ok on x86-64 and no regression.
> bootstrap ok on aarch64 juno.
> ICE gone away on arm & x86-64
>
> ok for trunk?
>
> gcc/
>
>    PR  tree-optimization/63721
>    * cgraph.c (cgraph_node::release_body): Clear addressable flag for
> function args.
While I understand the need to clear the addressable flag, I think 
release_body probably isn't the best place to do this.  Seems to me that 
ought to happen when we emit the thunk or otherwise transform the body 
into something that doesn't take the address of those parameters.

jeff



More information about the Gcc-patches mailing list