On Thu, Jun 30, 2022 at 6:04 PM Andrew Carlotti via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> No testcase for this, since I haven't found a way to turn the incorrect
> attribute into incorrect codegen.
>
> Bootstrapped and tested on aarch64-none-linux gnu.
>
> gcc/
>
> * config/aarch64/aarch64-builtins.c
> (aarch64_get_attributes): Fix choice of pure/const attributes.
>
> ---
>
> diff --git a/gcc/config/aarch64/aarch64-builtins.cc
> b/gcc/config/aarch64/aarch64-builtins.cc
> index
> e0a741ac663188713e21f457affa57217d074783..877f54aab787862794413259cd36ca0fb7bd49c5
> 100644
> --- a/gcc/config/aarch64/aarch64-builtins.cc
> +++ b/gcc/config/aarch64/aarch64-builtins.cc
> @@ -1085,9 +1085,9 @@ aarch64_get_attributes (unsigned int f, machine_mode
> mode)
> if (!aarch64_modifies_global_state_p (f, mode))
> {
> if (aarch64_reads_global_state_p (f, mode))
> - attrs = aarch64_add_attribute ("pure", attrs);
> - else
> attrs = aarch64_add_attribute ("const", attrs);
> + else
> + attrs = aarch64_add_attribute ("pure", attrs);
that looks backwards. 'pure' allows read of global memory while
'const' does not. Is
aarch64_reads_global_state_p really backwards?
> }
>
> if (!flag_non_call_exceptions || !aarch64_could_trap_p (f, mode))
