This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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] remove target dependency for atomicity.h on ix86


Loren James Rittle writes:
> > 2003-04-22  Matthias Klose <doko at debian dot org>
> >
> >	* config/cpu/i486/atomicity.h, config/cpu/generic/atomicity.h:
> >	Select implementation according to predefined __<cpu> macros.
> 
> I do not wish to dampen enthusiasm of someone that wants to fix this
> problem (and indeed I do believe that there is a deep problem here
> when one considers the way we do atomicity implementation selection at
> configure time verses non-multilib compilation flag changes).
> However, I must reject this patch for a more fundamental reason than
> that mentioned by Phil: all parts of your final program must be using
> the exact same implementation of atomicity or else you risk
> introducing subtle run-time errors (this includes everything the user
> compiled directly and available in the compiled library image).
> I.e. the current situation is reproducible bad (for the reason
> contained in the initial parenthetical statement) and I'd rather have
> that situation than introduce subtle non-reproducible errors.
> 
> If you really want to work on this problem until we have a solution we
> can install in time for gcc 3.4's release, then you will have my full
> support and attention.  I don't see how we could possibly fix this
> issue in time for 3.3 but I'm willing to be proven wrong.
>
> BTW, yes, IMHO, we've been screwed by using a C atomicity ABI in our
> C++ library in a manner that exposes the details of the implementation
> in headers used directly by users (and, yes, I replicated the mistake,
> or rather failed to fix it, when I attempted to fix the general
> portability issues with stl_mutex.h just before the 3.0 release).  If
> all use of the ABI was buried inside the compiled version of the
> library, then we could just multilib it (and, as a bonus, do it in a
> way that only the final program link options affected the selection).
> 
> Thanks,
> Loren

Thanks for the explanation. Please could you outline a possible
solution, not sure if I am able to do it then, but IMO it should be
fixed for 3.3. The ABI changes from 3.2 to 3.3 (because 3.2 didn't
have the generic implementation for i386). Does this count as a
regression? I'm asking, because i386-linux is listed as a primary
evaluation platform. On the other side I try to find out, if switching
from i386 to i486 as the default for Debian is possible/wanted.

	Matthias


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