>
> Maybe it is better to break it into 2 patches:
>
> 1. Introduce config/i386/linux-common.h with any new functionalities
> 2. Add Android support.
>
> Thanks.
>
>
> H.J.
> ---
Hi,
The first part will just add empty file. What is the reason to do it?
Testing will not even reveal if I added it in
> On Mon, Apr 16, 2012 at 9:01 AM, Ilya Enkovich wrote:
>>>
>>> Maybe it is better to break it into 2 patches:
>>>
>>> 1. Introduce config/i386/linux-common.h with any new functionalities
>>> 2. Add Android support.
>>>
>>> Than
>>
>> It has nothing but defines for Android. It did not move any existing
>> code to this file.
>>
>
> Adding linux-common.h to i386 backend needs approval from
> i386 backend maintainer. If a patch also adds Android support,
> i386 backend maintainer may not feel comfortable to review it.
> How
> On Tue, Apr 17, 2012 at 3:16 PM, Uros Bizjak wrote:
>> On Tue, Apr 17, 2012 at 12:16 PM, Ilya Enkovich
>> wrote:
>>>>>
>>>>> It has nothing but defines for Android. It did not move any existing
>>>>> code to this file.
>>>&
Hello,
here is a port of Android support patch
(http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00944.html) for 4.7
branch. Is it OK?
Bootstrap and check passed on linux-x86_64.
Thanks,
Ilya
---
2012-04-24 Enkovich Ilya
* config/i386/linux-common.h: New.
* config.gcc: Add i386/
> On Tue, Apr 24, 2012 at 2:54 PM, Ilya Enkovich wrote:
>> Hello,
>>
>> here is a port of Android support patch
>> (http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00944.html) for 4.7
>> branch. Is it OK?
>
> This kind of re-org is not appropriate for the
> On Tue, Apr 24, 2012 at 3:44 PM, Ilya Enkovich wrote:
>>> On Tue, Apr 24, 2012 at 2:54 PM, Ilya Enkovich
>>> wrote:
>>>> Hello,
>>>>
>>>> here is a port of Android support patch
>>>> (http://gcc.gnu.org/ml/gcc-patches/2012-
Hello,
Here is a short patch to fix PR target/51287. Patch avoids
get_attr_type call for instructions which cannot be recognized.
Bootstrapped and checked on linux-x86_64. 252.eon also works fine with
this fix on Atom.
Could please someone review it?
Thanks,
Ilya
---
2011-11-24 Enkovich Ilya
2011/11/24 Uros Bizjak :
> Hello!
>
>> Here is a short patch to fix PR target/51287. Patch avoids
>> get_attr_type call for instructions which cannot be recognized.
>>
>> 2011-11-24 Enkovich Ilya
>>
>> PR target/51287
>> * i386.c (distance_non_agu_define_in_bb): Fix insn attr check.
Ping
2011/11/22 Ilya Enkovich :
> 2011/11/11 Eric Botcazou :
>>> I have already signed copyright agreement with the FSF. Will I need>> the
>>> separate one for this particular commit?>> No, if your contributions are
>>> already covered by a copyright a
2011/12/13 Vladimir Makarov :
> The following patch solves PR 21617 which is described on
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21617.
>
> Just adding number of necessary hard registers solves the problem but
> creates 2% SPEC2000 perlbmk degradation on x86. Fortunately, removing
> allocno
Hello,
> Hey, Jing, you broke the google/gcc-4_6 branch by checking the new
> header file into the wrong directory.
>
> Fixed via r184386.
>
google/gcc-4_6_2-mobile branch still has the same problem. Could
please someone fix it?
Thanks
Ilya
> Ollie
>
> On Fri, Feb 17, 2012 at 10:25 PM, Jing Yu
Hello,
Here is a patch which adds -mandroid option support to x86 target. OK
for google/gcc-4_6_2-mobile branch?
Thanks,
Ilya
--
2012-02-21 Enkovich Ilya
* config/i386/linux.h (LINUX_TARGET_CC1_SPEC): New.
(CC1_SPEC): Use LINUX_OR_ANDROID_CC.
(CC1PLUS_SPEC): Likewise.
Hello,
Here is a patch which enables stack protector feature for Android
targets. OK for google/gcc-4_6_2-mobile branch?
Thanks,
Ilya
--
2012-02-21 Enkovich Ilya
* gcc/configure.ac : Enable stack protector for
Android target.
* gcc/configure : Regenerated.
Index: gc
Hello,
Here is a ptch which enables exceptions and RTTI by default for
android targets like it is done in current NDK GCC 4.4.3 compiler. OK
for google/gcc-4_6_2-mobile branch.
Thanks,
Ilya
--
2012-02-21 Enkovich Ilya
* gcc/config/linux-android.h (ANDROID_CC1PLUS_SPEC): Enable
Hello,
Here is a patch to enable __ANDROID__ macro on x86 Android targets.
Currently it is enabled for ARM only. OK for google/gcc-4_6_2-mobile
branch?
Thanks
Ilya
--
2012-02-21 Enkovich Ilya
* gcc/config/i386/linux.h (TARGET_OS_CPP_BUILTINS): Add
ANDROID_TARGET_OS_CPP_BUILTI
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.
(CC1_SPEC): Use LINUX_OR_ANDROID_CC.
(CC1PLUS_SPEC): Likewise.
(LINUX_TARGET_LINK_SPEC): New.
Hello,
Here is a simple patch which enables exceptions and RTTI by default
for Android target. OK for trunk?
Thanks,
Ilya
--
2012-02-22 Enkovich Ilya
* gcc/config/linux-android.h (ANDROID_CC1PLUS_SPEC): Enable
exceptions and rtti by default.
diff --git a/gcc/config/linux-an
Hello,
Here is a one-line fix to enable __ANDROID__ macro on i386 Android
target. OK for trunk?
Thanks,
Ilya
--
2012-02-22 Enkovich Ilya
* gcc/config/i386/gnu-user.h (TARGET_OS_CPP_BUILTINS): Add
ANDROID_TARGET_OS_CPP_BUILTINS.
diff --git a/gcc/config/i386/gnu-user.h b/gcc/
> On Wed, Feb 22, 2012 at 6:59 AM, Ilya Enkovich wrote:
>> Hello,
>>
>> Here is a one-line fix to enable __ANDROID__ macro on i386 Android
>> target. OK for trunk?
>>
>> Thanks,
>> Ilya
>> --
>>
>> 2012-02-22 Enkovich Ilya
>>
> On Wed, Feb 22, 2012 at 3:57 PM, Ilya Enkovich wrote:
>> Hello,
>>
>> Here is a simple patch which enables exceptions and RTTI by default
>> for Android target. OK for trunk?
>
> Err - isn't that the default? Thus, simply delete the bogus spec?
>
>
> 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/
toolchain rebuild.
Ilya
>
> Questions/complaints/requests on Android limited C++ support, should
> go to Android forum.
> Questions about license concerns, should go to Android AOSP lawyer.
>
> Thanks,
> Jing
>
> On Fri, Feb 24, 2012 at 2:36 AM, Richard Guenther
> wrote:
&g
>
> Undef TARGET_OS_CPP_BUILTINS and define TARGET_OS_CPP_BUILTINS
> in linux.h with GNU_USER_TARGET_OS_CPP_BUILTINS and
> ANDROID_TARGET_OS_CPP_BUILTINS.
>
>
> --
> H.J.
Hello,
Here is a variant with linux.h modification. Does it look fine?
Thanks,
Ilya
--
2012-02-27 Enkovich Ilya
*
> 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
Hello William,
> However, it does not fix http://gcc.gnu.org/PR45671, which surprises me
> as it was marked as a duplicate of this one. Any thoughts on why this
> isn't sufficient to reassociate the linear chain of adds?
>
> Test case:
>
> int myfunction (int a, int b, int c, int d, int e, int f,
> Ilya, please mention PR middle-end/44382
> in ChangeLog.
>
Thanks for notice. Here is corrected ChangeLog:
gcc/
2011-07-12 Enkovich Ilya
PR middle-end/44382
* target.def (reassociation_width): New hook.
* doc/tm.texi.in (reassociation_width): New hook documentation.
>
> Well, if it is clearly a win to reassociate, you can always reassociate
> them by doing arithmetics in corresponding unsigned type and afterwards
> converting back to the signed type.
>
> Jakub
>
You are right. But in this case we again make all operands have
wrap-around type and thus d
2011/7/13 Jakub Jelinek :
>
> I disagree. Widening would result in worse code in most cases, as you need
> to sign extend all the operands. On the other side, I doubt you can
> actually usefully use the undefinedness of signed overflow for a series of
> 3 or more operands of the associative opera
2011/7/13 Michael Meissner :
> I just ran a spec 2006 run on the powerpc (32-bit) last night setting the
> reassociation to 2. I do see a win in bwaves, but unfortunately it is not
> enough of a win, and it is still a regression to GCC 4.5. However, I see some
> regressions in 3 other benchmarks
2011/7/14 Richard Guenther :
>
> Btw, rather than a new target hook and an option I suggest to use
> a --param which default you can modify in the backend.
>
> Richard.
>
Introduced target hook does not just define default value for option.
It is meant to make decision in each particular case. For
> One minor note, you will need to update doc/invoke.texi to document the new
> switch before checkin: -ftree-reassoc-width=
>
> --
> Michael Meissner, IBM
Thanks for the note! Here is fixed patch.
Ilya
--
gcc/
2011-07-14 Enkovich Ilya
PR middle-end/44382
* target.def (reasso
2011/7/14 Richard Guenther :
>
> But then how comes the option to override it is useful? It isn't dependent
> on the particular case. At least the option should be a --param.
>
> Richard.
>
Option is still useful if you want to try feature on platform with no
hook implemented and for other perfo
> 2011/7/14 Richard Guenther :
>>
>> But then how comes the option to override it is useful? It isn't dependent
>> on the particular case. At least the option should be a --param.
>>
>> Richard.
>>
>
> Option is still useful if you want to try feature on platform with no
> hook implemented and fo
>
> You need the target hook that tells how big the reassociation based on the
> type. Machines have different numbers of functional units, for example, maybe
> 3 integer units and 2 floating point units. For example, in the PowerPC, I
> would set the basic integer and binary floating point types
Hello Richard,
Thanks a lot for the review!
> it's not easy to follow the flow of this function, esp. I wonder
>
> + else
> + {
> + tree var = create_tmp_reg (TREE_TYPE (last_rhs1), "reassoc");
> + add_referenced_var (var);
> + stmts[i] = build_and_add_sum (var,
Hello,
Here is updated patch for tree reassoc phase. Update includes coding
style fixes, comments update, target hook arguments change. I also
moved a part of code from rewrite_expr_tree into separate function to
reuse it in rewrite_expr_tree_parallel for grouping operands with the
same rank.
Boo
1001 - 1037 of 1037 matches
Mail list logo
