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] |
Agreed. The problem essentially is interoperability between library code and user code (with i386, user code tries to use mutexes, and the library code atomic builtins)I see this point in a slightly different way. It all depends on whether the atomics (implemented in terms of underlying builtins) are part of the library, i.e., exported, or not. If they are part of the library, then the user code, irrespective of the -march, will call into the library and all will be fine. If, on the other hand, the atomics are inlined, then the issue is for our *headers* to recognize the actual -march (via __GCC_ATOMIC_BUILTINS, I can't see any other way...) and do the right thing.
Options are: 1) inline atomics only, no exports 2) don't inline any atomics, force link to exported 3) inline atomics only and have compatibility exports
The way I see it, every which way we get get into dicy situations.
Option 1:
a) configured for i686, user tries to use with -march="-i386". This
will blow up, regardless of __GCC_ATOMIC_BUILTINS, because of the
inlined builtins in the *.cc files compiled into libstdc++.a or libstdc+
+.so have instructions not on this arch. Thus, any linkage will fail.
b) configured for i386, user tries to use with -march="i686". ThisI think it will not work at all, for reasons similar to a)
will not blow up, but won't be optimal because all the library bits are compiled without the advanced atomics. The user will only get the
builtins on header files.
Option 2:Here I disagree. Why blow up? The library has been compiled in a consistent way, and the compiler expanded inline the builtins as part of the code generation of the exported atomics. The latter are exported and called by the user code. As I said earlier today, the only problem I could see, in principle, would ensue from calling conventions different for i386 and i686, but I don't think this is the case: in fact, right now, we can certainly build the library passing i686 and then link default compiled (i386) user code to it (you did that yesterday, for example).
a) configured for i686, user tries to use with -march="-i386". Blow up.
Possible work around would be to put just the atomics in a separate
library, which is dynamically selected based on the -march value in
use. This won't work for anything except for toy projects.
b) configured for i386, user tries to use with -march="i686". Won't getDefinitely, the slow (suited for i386) atomics are called.
benefit of atomics, -march is a no-op.
Option 3: all the issues with Option 1.
Let's face it: i486+ and i386 are related, but separate arches. Same
for sparc families.
I agree ;) The main problem is: 1- We don't want to build two times the packages of our distributions. 2 (secondary) - We have an ABI and compulsory exports.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |