On Fri, Sep 11, 2020, 5:02 PM Joel Sherrill <j...@rtems.org> wrote: > > > On Fri, Sep 11, 2020 at 4:36 PM Janne Blomqvist <blomqvist.ja...@gmail.com> > wrote: > >> On Fri, Sep 11, 2020 at 6:52 PM Joel Sherrill <j...@rtems.org> wrote: >> > >> > Hi >> > >> > Over at RTEMS, we ran into a case where the C++ atomics may not be right >> > for one of the lower level x86 models. We will investigate whether it >> can >> > be made right but this has led to the discussion of dropping older >> models >> > and setting a new minimum model. Right now, our base is a i386 w/FPU. >> The >> > best rationale we have for selecting a new floor is GCC atomics support. >> > >> > With that in mind, what's the lowest/oldest i386 CPU model we >> > should consider as the new base model? >> >> We sort-of discussed this issue back when the Linux kernel dropped >> support for i386. See thread starting at >> https://gcc.gnu.org/legacy-ml/gcc/2012-12/msg00079.html (a thread >> where you participated as well) >> > > Wow time flies! That was eight years ago and Dr Dewar was still alive. :( > > I guess the embedded x86 side has started to hit the wall also. Looks > like we should move to at least the i486 has a baseline. >
I think I tripped across a mistake in i386/t-rtems. It is old enough that it was written to use -mcpu but currently uses -mtune. Shouldn't that -march? As written, I think it is getting default model code tuned for a higher model when we want code compatible with the higher model like other multilibs. Thoughts? Thanks --joel > Thanks. > > --joel > >> >> >> >> -- >> Janne Blomqvist >> >
