Re: PATCH (libstdc++-v3 mainline): Re-enable i386/atomicity.h

[martin at v dot loewis dot de (Martin v. Löwis)]

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"?

> 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.

That you can use, in the same executable, both the i386 and the i486
way of locking? No way.

> 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.

> 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.

> This does beg the question of how much performance is lost with the
> subroutine call.

50%

> 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?

Regards,
Martin