[PATCH, ARM] attribute target (thumb,arm) [0/6] respin (4th)
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. lets go... rebased (4th time since 2014 !), no conflicts. so here is the attribute revisited / rebased , so - thumb1 is now supported - -mflip-thump option added for testing. - inlining is allowed between modes. This set of patches was tested on arm-none-eabi as: no regressions with: arm-sim/ arm-sim/-march=armv7-a arm-sim/-mthumb arm-sim/-mthumb/-march=armv7-a a few artifacts, all of them analyzed, with arm-sim/-mflip-thumb/ arm-sim/-mflip-thumb//-march=armv7-a arm-sim/-mflip-thumb//-mthumb arm-sim/-mflip-thumb//-mthumb/-march=armv7-a Artifacts are analyzed, they are mostly the fault of the testsuite being unable to mix modes in the expected results (e.g thumb[1,2] or arm tests predicates, mix setjmp/longjump between modes...) The support is split as followed: [1/6] Reorganized arm_option_override to dynamically redefine the flags depending on the attribute mode. [2/6] Reorganized macro settings to be set/unset for each #pragma targets [3/6] Change ARM_DECLARE_FUNCTION_NAME into a function [4/6] Implement hooks to support attribute target [5/6] Implement #pragma target [6/6] Add -mflip-thumb option for testing thanks Christian
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
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
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
On 04/30/2015 09:43 AM, Ramana Radhakrishnan wrote:
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.
OK, thanks for the suggestions and sorry for the p4 reject. The sources
are moving fast and I have hard times catching up with re-bases.
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.
Indeed, it's a mistake for now. attributes other the arm/thumb ones
shall be rejected (eventually with a not yet implemented warning for
the fpu, error for the others.) until we extend it.
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.
I can resurrect the inline check chunk. FYI, with a few small examples
arm/thumb attribute is correctly handled by LTO
Thoughts ?
So in essence I'm still playing with this and would like to iterate
towards a quick solution.
thanks, that would be good if we could land the arm/thumb attribute and
start the fpu extensions separately. (I'm currently playing with
fpu=neon but it will take time to have something solid).
Christian
Ramana
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
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.
OK, thanks for the suggestions and sorry for the p4 reject. The sources
are moving fast and I have hard times catching up with re-bases.
I understand.
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.
Indeed, it's a mistake for now. attributes other the arm/thumb ones
shall be rejected (eventually with a not yet implemented warning for
the fpu, error for the others.) until we extend it.
Yep - funnily enough if you remove arm and just use fpu=vfpv4, I
think you get an error.
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.
I can resurrect the inline check chunk. FYI, with a few small examples
arm/thumb attribute is correctly handled by LTO
Yes it would work with normal C code as it does normally - I'm worried
about functions with inline asm. We've just increased the inlining scope
with lto and that would mean things are a bit more painful ?
Thoughts ?
So in essence I'm still playing with this and would like to iterate
towards a quick solution.
thanks, that would be good if we could land the arm/thumb attribute and
start the fpu extensions separately. (I'm currently playing with
fpu=neon but it will take time to have something solid).
Absolutely - I'd rather spend the time first in polishing this up.
Extending it for other options can be something you look at separately.
BTW I was pointed at a PR for this yesterday by a colleague -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884
So, lets use that as the PR for this work.
regards
Ramana
Christian
Ramana
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
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
2014-09-23 Christian Bruel christian.br...@st.com
* config/arm/arm.h (arm_option_override): Reoganized and split.
(arm_option_params_internal); New function.
(arm_option_check_internal): New function.
(arm_option_override_internal): New function.
(restrict_default): New boolean.
(thumb_code, thumb1_code): Remove.
* config/arm/arm.h (TREE_TARGET_THUMB, TREE_TARGET_THUMB1): New macros.
(TREE_TARGET_THUM2, TREE_TARGET_ARM): Likewise.
(thumb_code, thumb1_code): Remove.
* config/arm/arm.md (is_thumb, is_thumb1): Check TARGET flag.
diff -ruN '--exclude=.svn' a/gcc/gcc/config/arm/arm.c a1/gcc/gcc/config/arm/arm.c
--- a/gcc/gcc/config/arm/arm.c 2015-02-04 09:14:26.120602737 +0100
+++ a1/gcc/gcc/config/arm/arm.c 2015-02-05 09:19:32.853338616 +0100
@@ -846,12 +846,6 @@
/* Nonzero if tuning for Cortex-A9. */
int arm_tune_cortex_a9 = 0;
-/* Nonzero if generating Thumb instructions. */
-int thumb_code = 0;
-
-/* Nonzero if generating Thumb-1 instructions. */
-int thumb1_code = 0;
-
/* Nonzero if we should define __THUMB_INTERWORK__ in the
preprocessor.
XXX This is a bit of a hack, it's intended to help work around
@@ -2623,6 +2617,148 @@
return std_gimplify_va_arg_expr (valist, type, pre_p, post_p);
}
+/* Check any incompatible options that the user has specified. */
+static void
+arm_option_check_internal (struct gcc_options *opts)
+{
+ /* Make sure that the processor choice does not conflict with any of the
+ other command line choices. */
+ if (TREE_TARGET_ARM (opts) !(insn_flags FL_NOTM))
+error (target CPU does not support ARM mode);
+
+ /* TARGET_BACKTRACE calls leaf_function_p, which causes a crash if done
+ from here where no function is being compiled currently. */
+ if ((TARGET_TPCS_FRAME || TARGET_TPCS_LEAF_FRAME) TREE_TARGET_ARM (opts))
+warning (0, enabling backtrace support is only meaningful when compiling for the Thumb);
+
+ if (TREE_TARGET_ARM (opts) TARGET_CALLEE_INTERWORKING)
+warning (0, enabling callee interworking support is only meaningful when compiling for the Thumb);
+
+ /* If this target is normally configured to use APCS frames, warn if they
+ are turned off and debugging is turned on. */
+ if (TREE_TARGET_ARM (opts)
+ write_symbols != NO_DEBUG
+ !TARGET_APCS_FRAME
+ (TARGET_DEFAULT MASK_APCS_FRAME))
+warning (0, -g with -mno-apcs-frame may not give sensible debugging);
+
+ /* iWMMXt unsupported under Thumb mode. */
+ if (TREE_TARGET_THUMB (opts) TARGET_IWMMXT)
+error (iWMMXt unsupported under Thumb mode);
+
+ if (TARGET_HARD_TP TREE_TARGET_THUMB1 (opts))
+error (can not use -mtp=cp15 with 16-bit Thumb);
+
+ if (TREE_TARGET_THUMB (opts) TARGET_VXWORKS_RTP flag_pic)
+{
+ error (RTP PIC is incompatible with Thumb);
+ flag_pic = 0;
+}
+
+ /* We only support -mslow-flash-data on armv7-m targets. */
+ if (target_slow_flash_data
+ ((!(arm_arch7 !arm_arch_notm) !arm_arch7em)
+ || (TREE_TARGET_THUMB1 (opts) || flag_pic || TARGET_NEON)))
+error (-mslow-flash-data only supports non-pic code on armv7-m targets);
+}
+
+/* Check any params depending on attributes that the user has specified. */
+static void
+arm_option_params_internal (struct gcc_options *opts)
+{
+ /* If we are not using the default (ARM mode) section anchor offset
+ ranges, then set the correct ranges now. */
+ if (TREE_TARGET_THUMB1 (opts))
+{
+ /* Thumb-1 LDR instructions cannot have negative offsets.
+ Permissible positive offset ranges are 5-bit (for byte loads),
+ 6-bit (for halfword loads), or 7-bit (for word loads).
+ Empirical results suggest a 7-bit anchor range gives the best
+ overall code size. */
+ targetm.min_anchor_offset = 0;
+ targetm.max_anchor_offset = 127;
+}
+ else if (TREE_TARGET_THUMB2 (opts))
+{
+ /* The minimum is set such that the total size of the block
+ for a particular anchor is 248 + 1 + 4095 bytes, which is
+ divisible by eight, ensuring natural spacing of anchors. */
+ targetm.min_anchor_offset = -248;
+ targetm.max_anchor_offset = 4095;
+}
+ else
+{
+ targetm.min_anchor_offset = TARGET_MIN_ANCHOR_OFFSET;
+ targetm.max_anchor_offset = TARGET_MAX_ANCHOR_OFFSET;
+}
+
+ if (optimize_size)
+{
+ /* If optimizing for size, bump the number of
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
On Mon, Feb 9, 2015 at 12:34 PM, Christian Bruel christian.br...@st.com wrote: Hello, I'd like to ping with a respin of the 7 patches for the attribute target (thumb,arm) [0-6] : 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 In order to fix the various conflicts that have happened since, please find attached the re-based patches to trunk rev #220529 (respectively from above p0.patch, p1.patch, p2,patch, p3.patch, p4,patch, p5,patch, p6,patch). I understand the difficulty of reviewing those due to the code reorganization, but maintaining them are really a pain since a conflict happens at almost every update in the ARM back-end :-( Comments, questions are welcome, Many thanks Christian Can you respin this now that we are in stage1 again ? Ramana
ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
Hello,
I'd like to ping with a respin of the 7 patches for
the attribute target (thumb,arm) [0-6] :
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
In order to fix the various conflicts that have happened since, please
find attached the re-based patches to trunk rev #220529 (respectively
from above p0.patch, p1.patch, p2,patch, p3.patch, p4,patch, p5,patch,
p6,patch).
I understand the difficulty of reviewing those due to the code
reorganization, but maintaining them are really a pain since a conflict
happens at almost every update in the ARM back-end :-(
Comments, questions are welcome,
Many thanks
Christian
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 220436)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2015-02-06 Christian Bruel christian.br...@st.com
+
+ PR target/64835
+ * config/i386/i386.c (ix86_default_align): New function.
+ (ix86_override_options_after_change): Call ix86_default_align.
+ (TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): New hook.
+ (ix86_override_options_after_change): New function.
+
2015-02-04 Jan Hubicka hubi...@ucw.cz
Trevor Saunders tsaund...@mozilla.com
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 220436)
+++ gcc/config/i386/i386.c (working copy)
@@ -3105,6 +3105,35 @@
}
+/* Default align_* from the processor table. */
+
+static void
+ix86_default_align (struct gcc_options *opts)
+{
+ if (opts-x_align_loops == 0)
+{
+ opts-x_align_loops = processor_target_table[ix86_tune].align_loop;
+ align_loops_max_skip = processor_target_table[ix86_tune].align_loop_max_skip;
+}
+ if (opts-x_align_jumps == 0)
+{
+ opts-x_align_jumps = processor_target_table[ix86_tune].align_jump;
+ align_jumps_max_skip = processor_target_table[ix86_tune].align_jump_max_skip;
+}
+ if (opts-x_align_functions == 0)
+{
+ opts-x_align_functions = processor_target_table[ix86_tune].align_func;
+}
+}
+
+/* Implement TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE hook. */
+
+static void
+ix86_override_options_after_change (void)
+{
+ ix86_default_align (global_options);
+}
+
/* Override various settings based on options. If MAIN_ARGS_P, the
options are from the command line, otherwise they are from
attributes. */
@@ -3902,20 +3931,7 @@
opts-x_ix86_regparm = REGPARM_MAX;
/* Default align_* from the processor table. */
- if (opts-x_align_loops == 0)
-{
- opts-x_align_loops = processor_target_table[ix86_tune].align_loop;
- align_loops_max_skip = processor_target_table[ix86_tune].align_loop_max_skip;
-}
- if (opts-x_align_jumps == 0)
-{
- opts-x_align_jumps = processor_target_table[ix86_tune].align_jump;
- align_jumps_max_skip = processor_target_table[ix86_tune].align_jump_max_skip;
-}
- if (opts-x_align_functions == 0)
-{
- opts-x_align_functions = processor_target_table[ix86_tune].align_func;
-}
+ ix86_default_align (opts);
/* Provide default for -mbranch-cost= value. */
if (!opts_set-x_ix86_branch_cost)
@@ -51928,6 +51944,9 @@
#undef TARGET_PROMOTE_FUNCTION_MODE
#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
+#undef TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
+#define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE ix86_override_options_after_change
+
#undef TARGET_MEMBER_TYPE_FORCES_BLK
#define TARGET_MEMBER_TYPE_FORCES_BLK ix86_member_type_forces_blk
Index: gcc/dwarf2cfi.c
===
--- gcc/dwarf2cfi.c (revision 220436)
+++ gcc/dwarf2cfi.c (working copy)
@@ -2941,7 +2941,6 @@
dw_trace_info cie_trace;
dw_stack_pointer_regnum = DWARF_FRAME_REGNUM (STACK_POINTER_REGNUM);
- dw_frame_pointer_regnum = DWARF_FRAME_REGNUM (HARD_FRAME_POINTER_REGNUM);
memset (cie_trace, 0, sizeof (cie_trace));
cur_trace = cie_trace;
@@ -2994,6 +2993,9 @@
static unsigned int
execute_dwarf2_frame (void)
{
+ /* Different HARD_FRAME_POINTER_REGNUM might coexist in the same file. */
+ dw_frame_pointer_regnum = DWARF_FRAME_REGNUM (HARD_FRAME_POINTER_REGNUM);
+
/* The first time we're called, compute the incoming frame state. */
if (cie_cfi_vec == NULL)
create_cie_data ();
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c (revision 220436)
+++ gcc/ipa-inline.c (working copy)
@@ -489,7 +489,7 @@
else if (opt_for_fn (callee-decl, optimize_size)
opt_for_fn (caller-decl, optimize_size)
||
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
In order to fix the various conflicts that have happened since, please find attached the re-based patches to trunk rev #220529 (respectively from above p0.patch, p1.patch, p2,patch, p3.patch, p4,patch, p5,patch, p6,patch). oops, please don't review p0.patch here. This last one will be reviewed separately by the i386 and middle-end maintainers. It was posted now accidentally and is useful only for testing. Thanks Christian
Re: [PATCH, ARM] attribute target (thumb,arm) [0/6]
Hi Ramana, On 11/27/2014 11:36 AM, Ramana Radhakrishnan wrote: On Wed, Nov 19, 2014 at 2:54 PM, Christian Bruel christian.br...@st.com wrote: On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote: On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel christian.br...@st.com wrote: I think I missed the stage3, Anyway would it be OK for stage1 when it reopens ? Since you submitted this well during stage1 and given that these patches address comments from earlier in the review process we should aim to get these in for 5.0. If at some point during the review process it looks risky and there needs to be significant rework we can always stop. It's on the list of patches to be reviewed and I will find some dedicated time later this week to set down and review / play with the patches in an attempt to move this forward as it is a reasonably large chunk of work. Thanks, also I forgot to mention that you need https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01231.html to play with the attribute. Will be part of the same shot. Isn't that Ok'd for committing ? Why then isn't it applied ? yes it was, it is in my single changeset with the attribute target since itś the only way to trigger the issue. Cheers Christian Ramana Christian Thanks for continuing to work on these patches and addressing the earlier review comments. regards Ramana Christian
Re: [PATCH, ARM] attribute target (thumb,arm) [0/6]
On Wed, Nov 19, 2014 at 2:54 PM, Christian Bruel christian.br...@st.com wrote: On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote: On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel christian.br...@st.com wrote: I think I missed the stage3, Anyway would it be OK for stage1 when it reopens ? Since you submitted this well during stage1 and given that these patches address comments from earlier in the review process we should aim to get these in for 5.0. If at some point during the review process it looks risky and there needs to be significant rework we can always stop. It's on the list of patches to be reviewed and I will find some dedicated time later this week to set down and review / play with the patches in an attempt to move this forward as it is a reasonably large chunk of work. Thanks, also I forgot to mention that you need https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01231.html to play with the attribute. Will be part of the same shot. Isn't that Ok'd for committing ? Why then isn't it applied ? Ramana Christian Thanks for continuing to work on these patches and addressing the earlier review comments. regards Ramana Christian
[PATCH, ARM] attribute target (thumb,arm) [0/6]
Hello Ramana, Here is the attribute revisited after your comments, so - thumb1 is now supported - -mflip-thump option added for testing. - inlining is allowed between modes. This set of patches was tested on rev#217709 as: no regressions with: arm-sim/ arm-sim/-march=armv7-a arm-sim/-mthumb arm-sim/-mthumb/-march=armv7-a a few artifacts, all of them analyzed, with arm-sim/-mflip-thumb/ arm-sim/-mflip-thumb//-march=armv7-a arm-sim/-mflip-thumb//-mthumb arm-sim/-mflip-thumb//-mthumb/-march=armv7-a Artifacts are analyzed, they are mostly the fault of the testsuite being unable to mix modes in the expected results (e.g thumb[1,2] or arm tests predicates, mix setjmp/longjump between modes...) The support is split as followed: [1/6] Reorganized arm_option_override to dynamically redefine the flags depending on the attribute mode. [2/6] Reorganized macro settings to be set/unset for each #pragma targets [3/6] Change ARM_DECLARE_FUNCTION_NAME into a function [4/6] Implement hooks to support attribute target [5/6] Implement #pragma target [6/6] Add -mflip-thumb option for testing I think I missed the stage3, Anyway would it be OK for stage1 when it reopens ? Christian
Re: [PATCH, ARM] attribute target (thumb,arm) [0/6]
On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel christian.br...@st.com wrote: I think I missed the stage3, Anyway would it be OK for stage1 when it reopens ? Since you submitted this well during stage1 and given that these patches address comments from earlier in the review process we should aim to get these in for 5.0. If at some point during the review process it looks risky and there needs to be significant rework we can always stop. It's on the list of patches to be reviewed and I will find some dedicated time later this week to set down and review / play with the patches in an attempt to move this forward as it is a reasonably large chunk of work. Thanks for continuing to work on these patches and addressing the earlier review comments. regards Ramana Christian
Re: [PATCH, ARM] attribute target (thumb,arm) [0/6]
On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote: On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel christian.br...@st.com wrote: I think I missed the stage3, Anyway would it be OK for stage1 when it reopens ? Since you submitted this well during stage1 and given that these patches address comments from earlier in the review process we should aim to get these in for 5.0. If at some point during the review process it looks risky and there needs to be significant rework we can always stop. It's on the list of patches to be reviewed and I will find some dedicated time later this week to set down and review / play with the patches in an attempt to move this forward as it is a reasonably large chunk of work. Thanks, also I forgot to mention that you need https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01231.html to play with the attribute. Will be part of the same shot. Christian Thanks for continuing to work on these patches and addressing the earlier review comments. regards Ramana Christian
