This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
recall correctly).

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.

Yes.  

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

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.

> Regards,
> Martin

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]