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

Reply via email to