>
> This is a big change. Maybe it is better to break it into 2
> parts:
>
> 1. Introduce gnu-user32.h only, which can be reviewed by x86 backend
> maintainers. Another possibility is to add gnu-user-common.h instead of
> gnu-user32.h so that no changes to config.gcc are needed.
> 2. Add Android
On Tue, Apr 3, 2012 at 2:02 PM, Ilya Enkovich wrote:
>> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>
>> The point is that one can build a toolchain for i686-linux-gnu that will
>> support both 32-bit and 64-bit multi
Ping.
On Apr 4, 2012 at 1:02, Ilya Enkovich wrote:
>> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>
>> The point is that one can build a toolchain for i686-linux-gnu that will
>> support both 32-bit and 64-bit multil
> On 4/04/2012, at 2:56 AM, H.J. Lu wrote:
>
>> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
It's simpler that you think. The target headers ($tm_file in config.gcc
-- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h,
which serves as proxy to all t
> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
>>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>>
>
> The point is that one can build a toolchain for i686-linux-gnu that will
> support both 32-bit and 64-bit multilibs. The 32-bit multilib will be
> used by default, a
On 4/04/2012, at 2:56 AM, H.J. Lu wrote:
> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
>>>
>>> It's simpler that you think. The target headers ($tm_file in config.gcc --
>>> gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which
>>> serves as proxy to all those he
On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>
The point is that one can build a toolchain for i686-linux-gnu that will
support both 32-bit and 64-bit multilibs. The 32-bit multilib will be
used by default, and compi
> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>
>>>
>>> The point is that one can build a toolchain for i686-linux-gnu that will
>>> support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used
>>> by default, and compilation for 64-bit user-space can be requested with
>>> -m64
On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>
>> The point is that one can build a toolchain for i686-linux-gnu that will
>> support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used
>> by default, and compilation for 64-bit user-space can be requested with -m64
>> option
On Mon, Apr 2, 2012 at 7:16 AM, Ilya Enkovich wrote:
>> On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote:
>>
As is, it appears this patch did not see much testing, I'm pretty sure it
breaks building shared libraries and PIE executable for Linux.
>>>
>>> I do not expect any changes in compi
> On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote:
>
>>> As is, it appears this patch did not see much testing, I'm pretty sure it
>>> breaks building shared libraries and PIE executable for Linux.
>>
>> I do not expect any changes in compiler behavior for non Android
>> targets. I bootstrapped and
On 30/03/2012, at 6:48 AM, Jan Hubicka wrote:
>> 2012-02-27 Enkovich Ilya
>>
>> * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New.
>> (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC.
>> (GNU_USER_TARGET_LINK_SPEC): New.
>> (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
>>
On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote:
>> As is, it appears this patch did not see much testing, I'm pretty sure it
>> breaks building shared libraries and PIE executable for Linux.
>
> I do not expect any changes in compiler behavior for non Android
> targets. I bootstrapped and checked
On Sun, Apr 1, 2012 at 8:23 AM, Ilya Enkovich wrote:
>> i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is
>> used for multilib-enabled x86 toolchains. Placing below definitions in
>> i386/linux.h will not allow adding an Android as an additional multilib to
>> -m32/-m6
Hello Honza,
>> 2012-02-27 Enkovich Ilya
>>
>> * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New.
>> (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC.
>> (GNU_USER_TARGET_LINK_SPEC): New.
>> (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
>> (GNU_USER_TARGET_MATHFIL
Hello Maxim,
Thanks a lot for review. My comments are below.
> On 28/02/2012, at 3:41 AM, Ilya Enkovich wrote:
>
>>> You should keep those *_SPEC and define them with new
>>> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
>>> by other non-linux targets. In linux.h, you undef *_SPEC
>>> b
> 2012-02-27 Enkovich Ilya
>
> * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New.
> (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC.
> (GNU_USER_TARGET_LINK_SPEC): New.
> (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
> (GNU_USER_TARGET_MATHFILE_SPEC): New.
>
On 28/02/2012, at 3:41 AM, Ilya Enkovich wrote:
>> You should keep those *_SPEC and define them with new
>> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
>> by other non-linux targets. In linux.h, you undef *_SPEC
>> before defining them.
>>
>>
>> --
>> H.J.
>
> Thanks for the note. H
This patch looks good for Android toolchain. But I am not a maintainer.
Can any x86 backend maintainer help to review the patch?
Thanks,
Jing
On Tue, Mar 27, 2012 at 6:55 AM, Ilya Enkovich wrote:
> Ping
>
> 13 марта 2012 г. 15:13 пользователь Ilya Enkovich
> написал:
>> Ping
>>
>> 27 февраля 20
Ping
13 марта 2012 г. 15:13 пользователь Ilya Enkovich
написал:
> Ping
>
> 27 февраля 2012 г. 6:41 пользователь Ilya Enkovich
> написал:
>>> You should keep those *_SPEC and define them with new
>>> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
>>> by other non-linux targets. In linux.
Ping
27 февраля 2012 г. 6:41 пользователь Ilya Enkovich
написал:
>> You should keep those *_SPEC and define them with new
>> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
>> by other non-linux targets. In linux.h, you undef *_SPEC
>> before defining them.
>>
>>
>> --
>> H.J.
>
> Thanks
> You should keep those *_SPEC and define them with new
> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
> by other non-linux targets. In linux.h, you undef *_SPEC
> before defining them.
>
>
> --
> H.J.
Thanks for the note. Here is fixed version. Is it OK now?
Thanks,
Ilya
--
2012-02-27
On Fri, Feb 24, 2012 at 7:17 AM, Ilya Enkovich wrote:
>> On Wed, Feb 22, 2012 at 6:54 AM, Ilya Enkovich
>> wrote:
>>> Hello,
>>>
>>> This patch adds -mandroid support to i386 target. OK for trunk?
>>>
>>> Thanks,
>>> Ilya
>>> --
>>>
>>> 2012-02-22 Enkovich Ilya
>>>
>>> * config/i386/gn
> On Wed, Feb 22, 2012 at 6:54 AM, Ilya Enkovich wrote:
>> Hello,
>>
>> This patch adds -mandroid support to i386 target. OK for trunk?
>>
>> Thanks,
>> Ilya
>> --
>>
>> 2012-02-22 Enkovich Ilya
>>
>> * config/i386/gnu-user.h (LINUX_TARGET_CC1_SPEC): New.
>
> I don't think you should def
On Wed, Feb 22, 2012 at 6:54 AM, Ilya Enkovich wrote:
> Hello,
>
> This patch adds -mandroid support to i386 target. OK for trunk?
>
> Thanks,
> Ilya
> --
>
> 2012-02-22 Enkovich Ilya
>
> * config/i386/gnu-user.h (LINUX_TARGET_CC1_SPEC): New.
I don't think you should define LINUX_* in g
25 matches
Mail list logo
