This is the mail archive of the
mailing list for the GCC project.
Re: PATCH (libstdc++-v3 mainline): Re-enable i386/atomicity.h
"Martin v. Löwis" wrote:
> Joel Sherrill <joel.sherrill@OARcorp.com> writes:
> > There may not be many i386 configured Linux distributions out there but
> > all embedded i386 targets are broken because i386-elf and i386-rtems
> > are used.
> What do you mean with "are broken"? That they currently don't work
> with gcc 3.2 because it uses the lock instruction that isn't supported
> on that processor? If so, this would just supports my point: Since you
> there can't be any working binaries for these targets at the moment,
> binary compatibility would not be an issue.
> Or did you mean something else by "are broken"?
I mean that any attempt to produce a working executable will fail
because you will have a program that attempts to execute an illegal
instruction. These programs will get a fault (exception 6 if I
So I agree with you that there are no i386 ABI issues. This is a
"functioning at all" problem. It is broken in the sense that it
simply does not work.
> > Can we have an i386/atomicity.h which works in parallel with the
> > i486/atomicity?
> What do you mean with "work in parallel"? That gcc has supports both
> configurations, in a single gcc source tree? Certainly.
My ideal goal would be for each multilib variant to get the best
implementation but that is beyond the scope of a 3.3 fix. This would
require moving the code out of a .h file or adding multilib'ed
.h files. Neither is happening anytime soon.
> That you can use, in the same executable, both the i386 and the i486
> way of locking? No way.
I do not expect this at all.
> > Right. And embedded i386 targets aren't going away in the foreseeable
> > future. So gcc can't abandon them.
> I'm not proposing anything like that.
I'm clear on that now.
> > This is why I was arguing for this code being NOT in a .h but in a
> > C/C++ file which can be properly compiled for the target.
> That also gives a 50% performance slowdown. In addition, it breaks
> binary compatibility with i486 gcc 3.2.
And technically 3.2.x gcc broke compatability with 3.2 for i386 target.
>From what I can tell from RTEMS user's bug reports, this crept in
around 3.2.1 but was OK in 3.2. This is a minor issue to me at this
point. I just want a functioning 3.3 for i386 targets.
FWIW embedded people tend to rebuild everything when a new toolset
is installed so ABI compability is a minor problem.
> > This does beg the question of how much performance is lost with the
> > subroutine call.
And this is too much
> > For gcc 3.3, I would be extremely pleased if there were simply
> > i386 and i486 atomicity.h files so that all x86 targets work.
> It looks like it is right now, no?
Yes. Given the current constraints, it is the optimal solution.
Thanks for your work.
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985