Greetings, and thanks for this very helpful synopsis. I'm wondering if there is a simple configure time test to detect when this has been fixed. If I just aborted using __builtin___clear_cache if it is in fact a noop on alpha, ppc, ppc64, and ia64, would this suffice? Take care, Richard Henderson <rth@xxxxxxxxxx> writes: > On 05/03/2012 10:51 AM, Camm Maguire wrote: >> The goal was to exercise the very helpful gcc __builtin___clear_cache >> support, and to avoid having to maintain our own assembler for all the >> different cpus in this regard. Clearly, it is easy to revert this on a >> per architecture basis if absolutely necessary. If gcc does or does not >> plan on fixing this, please let me know so gcl can adjust as needed. > > While we can probably fix this, you should know that __builtin_clear_cache > is highly tied to the implementation of trampolines for the target. Thus > there are at least 3 targets that do not handle this "properly": > > For alpha, we emit imb directly during the trampoline_init target hook. > > For powerpc32, the libgcc routine __clear_cache is unimplemented, but the > cache flushing for trampolines is inside the __trampoline_setup routine. > > For powerpc64 and ia64, the ABI for function calls allows trampolines to > be implemented without emitting any insns, and thus the icache need not be > flushed at all. And thus we never bothered implementing __builtin_clear_cache. > > So, the fact of the matter is that you can't reliably use this builtin for > arbitrary targets for any gcc version up to 4.7. Feel free to submit an > enhancement request via bugzilla so that we can remember to address this > for gcc 4.8. > -- Camm Maguire camm@xxxxxxxxxxxxxxxxx ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
