https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592
--- Comment #10 from Taylor R Campbell <campbell+gcc-bugzilla at mumble dot net> --- (In reply to Eric Botcazou from comment #9) > > I don't understand, how would that help? As I understand it, whenever > > `-mcpu=v7', the memory model is just ignored -- even if we set it to TSO -- > > because all rules that depend on it are gated on TARGET_V8 || TARGET_V9 or > > simila > > Well, the subject of the PR is "GCC should default to TSO memory model when > compiling for sparc32" so you'll get exactly that. But defaulting to TSO doesn't seem to help with generating LDSTUB in sparcv7-only instruction streams, unless I misunderstand how this is different from trying to combine `-mcpu' and `-mmemory-model'? > So you want to mix memory models and synchronization instructions with > -mcpu=v7, although they were introduced in the V8 architecture? Correct. The idea is to have a way to generate code that works both on sparcv7 -- by avoiding v8-only instructions like SMUL/UMUL, as `-mcpu=v7' does -- and on sparcv8 -- by generating LDSTUB instructions where store-before-load ordering is needed, as `-mcpu=v8 -mmemory-model=tso' does. I tried to spell this request as `-mcpu=v7 -mmemory-model=tso' but that doesn't generate the LDSTUB instructions needed for store-before-load ordering. (Note that LDSTUB is available in v7 -- what's new in v8 is the relaxation of store-before-load order of TSO, in contrast to SC. So these requirements aren't contradictory.) Is that how Linux and Solaris work by default? I wasn't able to elicit that behaviour by combining explicit `-mcpu' and `-mmemory-model' options, so I assumed that it wouldn't be possible for it to be the default -- and I don't see how it could work given how the code generation rules for memory barriers are gated on TARGET_V8 || TARGET_V9 or similar.
