On Mon, Apr 20, 2015 at 9:35 AM, Christian Bruel <christian.br...@st.com> wrote: > Hello Ramana > >>> >> >> Can you respin this now that we are in stage1 again ? >> >> Ramana >> > > Attached the rebased, rechecked set of patches. Original with comments > posted in > > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02460.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02461.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02463.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02467.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02468.html > > many thanks, > > Christian
A general note, please reply to each of the patches with a rebased patch as a separate email. Further more all your patches appear to have dos line endings so they don't seem to apply cleanly. Please don't have spurious headers in your patch submission - it then makes it hard to , please create it in a way that it is easily applied by someone trying it out. It looks like p4 needs a respin as I got a reject trying to apply the documentation patch to my tree while trying to apply it. I tried the following decoration on foo in gcc.target/arm/attr_arm.c int __attribute__((target("arm, fpu=vfpv4"))) foo(int a) { return a ? 1 : 5; } And the compiler accepts it just fine. Given that with LTO we are now using target attributes to decide inlining - I'm not convinced that the inline asm case goes away. In fact it only makes things worse so I'm almost convinced to forbid inlining from "arm" to "thumb" or vice-versa, which is a reversal of my earlier position. I hadn't twigged that LTO would reuse this infrastructure and it's probably simpler to prevent inlining in those cases. Thoughts ? So in essence I'm still playing with this and would like to iterate towards a quick solution. Ramana