On Fri, Jul 01, 2022 at 08:42:15AM +0200, Richard Biener wrote: > On Thu, Jun 30, 2022 at 6:04 PM Andrew Carlotti via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > 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?
Oh - the thing that's backwards is my understanding of what "pure" and "const" mean. Their meanings as GCC function attributes seem to be approximately the opposite way round to their meanings in general usage.