Re: Support for Runtime CPU type detection via builtins (issue5754058)
Hi,
i386 maintainers - Is this patch ok?
Thanks,
-Sri.
On Mon, Apr 2, 2012 at 5:48 PM, Sriraman Tallam tmsri...@google.com wrote:
On Mon, Apr 2, 2012 at 5:38 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sat, Mar 31, 2012 at 1:03 AM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, Mar 30, 2012 at 5:47 AM, Michael Matz m...@suse.de wrote:
Hi,
On Thu, 29 Mar 2012, Sriraman Tallam wrote:
+struct __processor_model
+{
+ /* Vendor. */
+ unsigned int __cpu_is_amd : 1;
+ unsigned int __cpu_is_intel : 1;
+ /* CPU type. */
+ unsigned int __cpu_is_intel_atom : 1;
+ unsigned int __cpu_is_intel_core2 : 1;
+ unsigned int __cpu_is_intel_corei7 : 1;
+ unsigned int __cpu_is_intel_corei7_nehalem : 1;
+ unsigned int __cpu_is_intel_corei7_westmere : 1;
+ unsigned int __cpu_is_intel_corei7_sandybridge : 1;
+ unsigned int __cpu_is_amdfam10h : 1;
+ unsigned int __cpu_is_amdfam10h_barcelona : 1;
+ unsigned int __cpu_is_amdfam10h_shanghai : 1;
+ unsigned int __cpu_is_amdfam10h_istanbul : 1;
+ unsigned int __cpu_is_amdfam15h_bdver1 : 1;
+ unsigned int __cpu_is_amdfam15h_bdver2 : 1;
+} __cpu_model;
It doesn't make sense for the model to be a bitfield, a processor will
have only ever exactly one model. Just make it an enum or even just an
int.
Not entirely true, nehalem and corei7 can be both set. However, I
modified this by dividing it into types and sub types and then did
what you said.
Uh... then I suppose you need to document somewhere what names
match to what cpuid family/model (supposedly thats where your two-layer
hierarchy comes from, which incidentially misses one layer, the vendor?)
Added documentation to extend.texi
Patch available for review here:
http://codereview.appspot.com/5754058
Thanks,
-Sri.
Richard.
* config/i386/i386.c (build_processor_features_struct): New function.
(build_processor_model_struct): New function.
(make_var_decl): New function.
(get_field_from_struct): New function.
(fold_builtin_target): New function.
(ix86_fold_builtin): New function.
(ix86_expand_builtin): Expand new builtins by folding them.
(make_cpu_type_builtin): New functions.
(ix86_init_platform_type_builtins): Make the new builtins.
(ix86_init_builtins): Make new builtins to detect CPU type.
(TARGET_FOLD_BUILTIN): New macro.
(IX86_BUILTIN_CPU_INIT): New enum value.
(IX86_BUILTIN_CPU_IS): New enum value.
(IX86_BUILTIN_CPU_SUPPORTS): New enum value.
* config/i386/i386-builtin-types.def: New function type.
* testsuite/gcc.target/builtin_target.c: New testcase.
* libgcc/config/i386/i386-cpuinfo.c: New file.
* libgcc/config/i386/t-cpuinfo: New file.
* libgcc/config.host: Include t-cpuinfo.
* libgcc/config/i386/libgcc-glibc.ver: Version symbols __cpu_model
and __cpu_features.
Patch available for review here:
http://codereview.appspot.com/5754058
Thanks,
-Sri.
Ciao,
Michael.
Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)
Did you ever dig up the Apple test cases from the APPLE LOCAL work I pointed you at earlier? Sorry, I read that as the internal tree at Apple not the apple branch at fsf. I'll look at it, thanks! They will be more comprehensive that any testing you've done, and, if you get them to all pass, the work should be closer to being complete. The feature needed a ton of testcases, a few didn't cut it. Worse, the test cases need to be target-endian-specific, and sizeof(int) agnostic.
Re: [PATCH] Fix PR18589
On Wed, 2012-03-28 at 15:57 +0200, Richard Guenther wrote:
On Tue, Mar 6, 2012 at 9:49 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi,
This is a re-post of the patch I posted for comments in January to
address http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18589. The patch
modifies reassociation to expose repeated factors from __builtin_pow*
calls, optimally reassociate repeated factors, and possibly reconstitute
__builtin_powi calls from the results of reassociation.
Bootstrapped and passes regression tests for powerpc64-linux-gnu. I
expect there may need to be some small changes, but I am targeting this
for trunk approval.
Thanks very much for the review,
Hmm. How much work would it be to extend the reassoc 'IL' to allow
a repeat factor per op? I realize what you do is all within what reassoc
already does though ideally we would not require any GIMPLE IL changes
for building up / optimizing the reassoc IL but only do so when we commit
changes.
Thanks,
Richard.
Hi Richard,
I've revised my patch along these lines; see the new version below.
While testing it I realized I could do a better job of reducing the
number of multiplies, so there are some changes to that logic as well,
and a couple of additional test cases. Regstrapped successfully on
powerpc64-linux.
Hope this looks better!
Thanks,
Bill
gcc:
2012-04-03 Bill Schmidt wschm...@linux.vnet.ibm.com
PR tree-optimization/18589
* tree-pass.h: Replace pass_reassoc with pass_early_reassoc and
pass_late_reassoc.
* passes.c (init_optimization_passes): Change pass_reassoc calls to
pass_early_reassoc and pass_late_reassoc.
* tree-ssa-reassoc.c (reassociate_stats): Add two fields.
(operand_entry): Add count field.
(early_reassoc): New static var.
(add_repeat_to_ops_vec): New function.
(completely_remove_stmt): Likewise.
(remove_def_if_absorbed_call): Likewise.
(remove_visited_stmt_chain): Remove feeding builtin pow/powi calls.
(acceptable_pow_call): New function.
(linearize_expr_tree): Look for builtin pow/powi calls and add operand
entries with repeat counts when found.
(repeat_factor_d): New struct and associated typedefs.
(repeat_factor_vec): New static vector variable.
(compare_repeat_factors): New function.
(get_reassoc_pow_ssa_name): Likewise.
(attempt_builtin_powi): Likewise.
(reassociate_bb): Attempt to create __builtin_powi calls, and multiply
their results by any leftover reassociated factors; remove builtin
pow/powi calls that were absorbed by reassociation.
(fini_reassoc): Two new calls to statistics_counter_event.
(execute_early_reassoc): New function.
(execute_late_reassoc): Likewise.
(pass_early_reassoc): Replace pass_reassoc, renamed to reassoc1,
call execute_early_reassoc.
(pass_late_reassoc): New gimple_opt_pass named reassoc2 that calls
execute_late_reassoc.
gcc/testsuite:
2012-04-03 Bill Schmidt wschm...@linux.vnet.ibm.com
PR tree-optimization/18589
* gcc.dg/pr46309.c: Change -fdump-tree-reassoc-details to
-fdump-tree-reassoc[12]-details.
* gcc.dg/tree-ssa/pr18589-1.c: New test.
* gcc.dg/tree-ssa/pr18589-2.c: Likewise.
* gcc.dg/tree-ssa/pr18589-3.c: Likewise.
* gcc.dg/tree-ssa/pr18589-4.c: Likewise.
* gcc.dg/tree-ssa/pr18589-5.c: Likewise.
* gcc.dg/tree-ssa/pr18589-6.c: Likewise.
* gcc.dg/tree-ssa/pr18589-7.c: Likewise.
* gcc.dg/tree-ssa/pr18589-8.c: Likewise.
* gcc.dg/tree-ssa/pr18589-9.c: Likewise.
* gcc.dg/tree-ssa/pr18589-10.c: Likewise.
Index: gcc/tree-pass.h
===
--- gcc/tree-pass.h (revision 186108)
+++ gcc/tree-pass.h (working copy)
@@ -441,7 +441,8 @@ extern struct gimple_opt_pass pass_copy_prop;
extern struct gimple_opt_pass pass_vrp;
extern struct gimple_opt_pass pass_uncprop;
extern struct gimple_opt_pass pass_return_slot;
-extern struct gimple_opt_pass pass_reassoc;
+extern struct gimple_opt_pass pass_early_reassoc;
+extern struct gimple_opt_pass pass_late_reassoc;
extern struct gimple_opt_pass pass_rebuild_cgraph_edges;
extern struct gimple_opt_pass pass_remove_cgraph_callee_edges;
extern struct gimple_opt_pass pass_build_cgraph_edges;
Index: gcc/testsuite/gcc.dg/pr46309.c
===
--- gcc/testsuite/gcc.dg/pr46309.c (revision 186108)
+++ gcc/testsuite/gcc.dg/pr46309.c (working copy)
@@ -1,6 +1,6 @@
/* PR tree-optimization/46309 */
/* { dg-do compile } */
-/* { dg-options -O2 -fdump-tree-reassoc-details } */
+/* { dg-options -O2 -fdump-tree-reassoc1-details
-fdump-tree-reassoc2-details } */
/* The transformation depends on BRANCH_COST being greater than 1
(see the
Re: [C Patch]: pr52543
Richard Sandiford rdsandif...@googlemail.com writes: Does anyone else have any thoughts before I make that change? I think that one of you should try to write a test case where it makes a difference, and add the test case to the testsuite. Ian
Re: [PATCH, i386, Android] -mandroid support for i386 target
On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich enkovich@gmail.com 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 compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional -m32 -mandroid multilib. I.e., the toolchain will have three multilibs in total: -m32 (default), -m64 and -m32 -mandroid. I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? I think I see your point. And it seems to make all this work I'll also have to rename i386/gnu-user.h into i386/gnu-user32.h and create i386/gnu-user.h with common definitions to be included by gnu-user[32|64].h. Otherwise I wont be able to use some definitions (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in linux64.h. Right? 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 headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. Thanks, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics Hi, I prepared version with common linux.h and gnu-user.h. Does it look OK? Bootstrapped and checked on linux-x86_64. There are so many duplicates in gnu-user64.h and gnu-user32.h. Please move all of them to gnu-user.h. Thanks. -- H.J. Hi, Here is a new version with all gnu-user32.h and gnu-user64.h common definitions moved to gnu-user.h. Bootstrapped and checked on linux-x86_64. Thanks, Ilya --- 2012-04-04 Enkovich Ilya ilya.enkov...@intel.com * config/i386/linux.h: Renamed to ... * config/i386/linux32.h: ... this. * config/i386/gnu-user.h: Renamed to ... * config/i386/gnu-user32.h: ... this. (CPP_SPEC): Removed. (CC1_SPEC): Removed. (ENDFILE_SPEC): Removed. (DEFAULT_PCC_STRUCT_RETURN): Removed. (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed. (TARGET_OS_CPP_BUILTINS): Removed. (LIBGCC2_HAS_TF_MODE): Removed. (LIBGCC2_TF_CEXT): Removed. (TF_SIZE): Removed. (TARGET_ASM_FILE_END): Removed. (STACK_CHECK_MOVING_SP): Removed. (STACK_CHECK_STATIC_BUILTIN): Removed. (TARGET_THREAD_SSP_OFFSET): Removed. (TARGET_CAN_SPLIT_STACK): Removed. (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed. (GNU_USER_TARGET_LINK_SPEC): New. (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. * config.gcc: Rename i386/linux.h to i386/linux32.h and i386/gnu-user.h to i386/gnu-user32.h. * config/i386/linux.h: New. * config/i386/gnu-user.h: New. * config/i386/linux64.h: Include i386/linux.h. * config/i386/gnu-user64.h: Include i386/gnu-user.h (CPP_SPEC): Removed. (CC1_SPEC): Removed. (ENDFILE_SPEC): Removed. (DEFAULT_PCC_STRUCT_RETURN): Removed. (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed. (TARGET_OS_CPP_BUILTINS): Removed. (LIBGCC2_HAS_TF_MODE): Removed. (LIBGCC2_TF_CEXT): Removed. (TF_SIZE): Removed. (TARGET_ASM_FILE_END): Removed. (STACK_CHECK_MOVING_SP): Removed. (STACK_CHECK_STATIC_BUILTIN): Removed. (TARGET_THREAD_SSP_OFFSET): Removed. (TARGET_CAN_SPLIT_STACK): Removed. (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed. (GNU_USER_TARGET_LINK_SPEC): New. (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. mandroid.patch Description: Binary data
Re: [PATCH, i386, Android] -mandroid support for i386 target
On 4/04/2012, at 2:56 AM, H.J. Lu wrote: On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich enkovich@gmail.com 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 headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. Thanks, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics Hi, I prepared version with common linux.h and gnu-user.h. Does it look OK? Bootstrapped and checked on linux-x86_64. There are so many duplicates in gnu-user64.h and gnu-user32.h. Please move all of them to gnu-user.h. Ilya, Why i386/gnu-user.h had to change at all? It seems like you trying to clean up/simplify stuff in i386/gnu-user.h, but in this case it seems (a) not required for the main purpose of this submission, and (b) excessive. Hi, Initially my patch introduced few macroses in i386/gnu-user.h to use them in i386/linux.h. After I created new i386/linux.h and included it into i386/linux64.h I got a build failure because new i386/linux.h used these new definition from i386/gnu-user.h and only i386/gnu-user64.h was included into tm.h. So, I renamed i386/gnu-user.h into i386/gnu-user32.h and created new i386/gnu-user.h with these missing definitions. Otherwise I would have to copy all changes made in i386/gnu-user.h to i386/gnu-user64.h. Thanks, Ilya As a side note, if it were up to me, I would merge current i386/linux.h and i386/linux64.h into one file -- i386/linux.h -- instead of having similar definitions spread around. But that would be a clean up in itself, and would require a separate submission. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)
On Apr 3, 2012, at 12:57 PM, DJ Delorie wrote: Did you ever dig up the Apple test cases from the APPLE LOCAL work I pointed you at earlier? Sorry, I read that as the internal tree at Apple not the apple branch at fsf. I'll look at it, thanks! Oh, I just checked the llvm-gcc-4.2 tree, which should have all the work in it, no testcases... Arg, never mind... sorry.
[Patch, Fortran] PRs 52751/40973 - don't set TREE_PUBLIC for PRIVATE module procs/vars
Dear all,
the attached patch only sets TREE_PUBLIC for module variables and module
procedures which have neither the PRIVATE attribute nor a C-binding
label. Seemingly, only NAG f95 does this for module variables and none
of my compilers does this for module procedures.
The main effect of this patch is a code size reduction as the compiler
might (even without -fwhole-program -flto) optimize unused
variables/procedures away. Additionally, the compiler might inline code
which it otherwise wouldn't do (due to the code size increase) or do
optimizations based on the value of the module variables (though, GCC
has room for improvement for optimizing static variables.)
Note: For C-binding variables without binding label (bind(C,
name='')), I don't use DECL_COMMON. That should be okay as DECL_COMMON
is only used to make sure that a variable can be initialized from either
C or Fortran. But without binding name, that's not possible from C,
hence, that's fine.
Build and regtested on x86-64-linux. (And currently regtesting again -
after a minor modification.)
OK for the trunk?
Tobias
2012-04-03 Tobias Burnus bur...@net-b.de
PR fortran/52751
* trans-decl.c (gfc_finish_var_decl): Don't set TREE_PUBLIC
for PRIVATE module variables without C-binding label.
PR fortran/40973
* trans-decl.c (build_function_decl): Ditto for procedures.
2012-04-03 Tobias Burnus bur...@net-b.de
PR fortran/40973
PR fortran/52751
* gfortran.dg/public_private_module_2.f90: New.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 8a1dd2e..23cf052 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -539,7 +539,7 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
if (sym-attr.cray_pointee)
return;
- if(sym-attr.is_bind_c == 1)
+ if(sym-attr.is_bind_c == 1 sym-binding_label)
{
/* We need to put variables that are bind(c) into the common
segment of the object file, because this is what C would do.
@@ -565,7 +565,8 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
/* TODO: Don't set sym-module for result or dummy variables. */
gcc_assert (current_function_decl == NULL_TREE || sym-result == sym);
/* This is the declaration of a module variable. */
- TREE_PUBLIC (decl) = 1;
+ if (sym-attr.access != ACCESS_PRIVATE)
+ TREE_PUBLIC (decl) = 1;
TREE_STATIC (decl) = 1;
}
@@ -1842,7 +1857,8 @@ build_function_decl (gfc_symbol * sym, bool global)
DECL_EXTERNAL (fndecl) = 0;
if (!current_function_decl
- !sym-attr.entry_master !sym-attr.is_main_program)
+ !sym-attr.entry_master !sym-attr.is_main_program
+ (sym-attr.access != ACCESS_PRIVATE || sym-binding_label))
TREE_PUBLIC (fndecl) = 1;
attributes = add_attributes_to_decl (attr, NULL_TREE);
--- /dev/null 2012-03-22 21:06:43.387787737 +0100
+++ gcc/gcc/testsuite/gfortran.dg/public_private_module_2.f90 2012-04-03 23:02:59.0 +0200
@@ -0,0 +1,70 @@
+! { dg-do compile }
+! { dg-options -O2 }
+!
+! PR fortran/52751 (top, module mod)
+! PR fortran/40973 (bottom, module m
+!
+! Ensure that (only) those module variables and procedures which are PRIVATE
+! and have no C-binding label are optimized away.
+!
+ module mod
+integer :: aa
+integer, private :: iii
+integer, private, bind(C) :: jj ! { dg-warning PRIVATE but has been given the binding label }
+integer, private, bind(C,name='lll') :: kk ! { dg-warning PRIVATE but has been given the binding label }
+integer, private, bind(C,name='') ::
+integer, bind(C) :: nnn
+integer, bind(C,name='oo') :: pp
+integer, bind(C,name='') :: qq
+ end module mod
+
+ ! { dg-final { scan-assembler __mod_MOD_aa } }
+ ! { dg-final { scan-assembler-not iii } }
+ ! { dg-final { scan-assembler jj } }
+ ! { dg-final { scan-assembler lll } }
+ ! { dg-final { scan-assembler-not kk } }
+ ! { dg-final { scan-assembler-not } }
+ ! { dg-final { scan-assembler nnn } }
+ ! { dg-final { scan-assembler oo } }
+ ! { dg-final { scan-assembler __mod_MOD_qq } }
+
+MODULE M
+ PRIVATE :: two, three, four, six
+ PUBLIC :: one, seven, eight, ten
+CONTAINS
+ SUBROUTINE one(a)
+integer :: a
+a = two()
+ END SUBROUTINE one
+ integer FUNCTION two()
+ two = 42
+ END FUNCTION two
+ integer FUNCTION three() bind(C) ! { dg-warning PRIVATE but has been given the binding label }
+ three = 43
+ END FUNCTION three
+ integer FUNCTION four() bind(C, name='five') ! { dg-warning PRIVATE but has been given the binding label }
+ four = 44
+ END FUNCTION four
+ integer FUNCTION six() bind(C, name='')
+ six = 46
+ END FUNCTION six
+ integer FUNCTION seven() bind(C)
+ seven = 46
+ END FUNCTION seven
+ integer FUNCTION eight() bind(C, name='nine')
+ eight = 48
+ END FUNCTION eight
+ integer FUNCTION ten() bind(C, name='')
+ ten = 48
+ END
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 4 April 2012 04:17, Andrew Haley a...@redhat.com wrote: On 04/03/2012 05:09 PM, Richard Earnshaw wrote: On 03/04/12 12:01, Jakub Jelinek wrote: On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote: If, so then there's only one way to sort out this mess. /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader The above scheme is a Debianism which no other distro is using. Jakub Not really, it's just a naming convention for where the config-specific dynamic loader lives. It doesn't affect where the remaining shared libraries live. The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros. This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad. I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64. (cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that) I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things. No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros. -- Michael [1] http://lists.linaro.org/pipermail/cross-distro/2012-March/000135.html and http://lists.linaro.org/pipermail/cross-distro/2012-April/thread.html
[SH] PR50751 - rework displacement calculations pt. 2
Hi,
The attached patch restructures the move insn displacement calculations
a bit more. The idea is to have the displacement addressing decision
making logic in a few simple functions and then re-use those in other
places, as opposed to having multiple special cases.
Tested against rev 185893 with...
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a-single/-mb,
-m4-single/-ml,-m4-single/-mb,
-m4a-single/-ml,-m4a-single/-mb}
...and no new failures.
I've also checked the CSiBE size results for a bunch of variants. There
is a slight overall code size increase, with a maximum of +0.03% on the
whole set for -m2 -ml/-mb -Os/-O2) due to some changes on how DImode
index range decisions are made.
OK?
Cheers,
Oleg
ChangeLog:
PR target/50751
* config/sh/sh.c (sh_find_mov_disp_adjust): Take machine_mode as
first argument instead of mode size. Move displacement
calculations to...
(mov_insn_size, max_mov_insn_displacement,
mov_insn_alignment_mask): ...these new functions.
(disp_adjust): Remove max_mov_disp field.
(sh_legitimate_index_p): Use max_mov_insn_displacement and
mov_insn_alignment_mask.
(sh_address_cost): Use max_mov_insn_displacement.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 185894)
+++ gcc/config/sh/sh.c (working copy)
@@ -302,6 +302,9 @@
static rtx sh_trampoline_adjust_address (rtx);
static void sh_conditional_register_usage (void);
static bool sh_legitimate_constant_p (enum machine_mode, rtx);
+static int mov_insn_size (enum machine_mode, bool);
+static int max_mov_insn_displacement (enum machine_mode, bool);
+static int mov_insn_alignment_mask (enum machine_mode, bool);
static void sh_init_sync_libfuncs (void) ATTRIBUTE_UNUSED;
@@ -3129,24 +3132,105 @@
}
}
-/* Compute the cost of an address. For the SH, all valid addresses are
- the same cost. Use a slightly higher cost for reg + reg addressing,
- since it increases pressure on r0. */
+/* Determine the size of the fundamental move insn that will be used
+ for the specified mode. */
+static inline int
+mov_insn_size (enum machine_mode mode, bool consider_sh2a)
+{
+ const int mode_sz = GET_MODE_SIZE (mode);
+
+ if ((consider_sh2a TARGET_SH2A_DOUBLE mode == DFmode)
+ || (TARGET_FMOVD mode == DFmode))
+return mode_sz;
+ else
+{
+ /* The max. available mode for actual move insns is SImode.
+ Larger accesses will be split into multiple loads/stores. */
+ const int max_mov_sz = GET_MODE_SIZE (SImode);
+ return mode_sz = max_mov_sz ? max_mov_sz : mode_sz;
+}
+}
+
+/* Determine the maximum possible displacement for a move insn for the
+ specified mode. */
+
static int
-sh_address_cost (rtx X,
- bool speed ATTRIBUTE_UNUSED)
+max_mov_insn_displacement (enum machine_mode mode, bool consider_sh2a)
{
- /* SH2A supports 4 byte displacement mov insns with higher offsets.
- Consider those as more expensive than 2 byte insns. */
- if (DISP_ADDR_P (X) GET_MODE (X) == QImode)
-return DISP_ADDR_OFFSET (X) 16 ? 0 : 1;
+ /* The 4 byte displacement move insns are the same as the 2 byte
+ versions but take a 12 bit displacement. All we need to do is to
+ scale the max. displacement value accordingly. */
+ const int disp_scale = consider_sh2a ? (4095 / 15) : 1;
- return (GET_CODE (X) == PLUS
- ! CONSTANT_P (XEXP (X, 1))
- ! TARGET_SHMEDIA ? 1 : 0);
+ /* FIXME: HImode with displacement addressing is not supported yet.
+ Make it purposefully fail for now. */
+ if (mode == HImode)
+return 0;
+
+ /* SH2A supports FPU move insns with 12 bit displacements.
+ Other variants to do not support any kind of displacements for
+ FPU move insns. */
+ if (! consider_sh2a TARGET_FPU_ANY GET_MODE_CLASS (mode) == MODE_FLOAT)
+return 0;
+ else
+{
+ const int mov_insn_sz = mov_insn_size (mode, consider_sh2a);
+ const int mode_sz = GET_MODE_SIZE (mode);
+ int r = 15 * mov_insn_sz * disp_scale;
+
+ /* If the mov insn will be split into multiple loads/stores, the
+ maximum possible displacement is a bit smaller. */
+ if (mode_sz mov_insn_sz)
+ r -= mode_sz - mov_insn_sz;
+ return r;
+}
}
+/* Determine the alignment mask for a move insn of the
+ specified mode. */
+
+static inline int
+mov_insn_alignment_mask (enum machine_mode mode, bool consider_sh2a)
+{
+ const int mov_insn_sz = mov_insn_size (mode, consider_sh2a);
+ return mov_insn_sz 0 ? (mov_insn_sz - 1) : 0;
+}
+
+/* Compute the cost of an address. */
+
+static int
+sh_address_cost (rtx x, bool speed ATTRIBUTE_UNUSED)
+{
+ /* 'reg + disp' addressing. */
+ if (DISP_ADDR_P (x))
+{
+ const HOST_WIDE_INT offset = DISP_ADDR_OFFSET (x);
+ const enum machine_mode mode = GET_MODE (x);
+
+ /* The displacement would fit into a 2 byte move
Re: [PATCH] SH: Fix m2a-single-only compilation error
I've just committed the patch in http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01970.html on trunk. Regards, kaz
C++ PATCH for c++/52796 (missed value-initialization with variadic templates)
A parenthesized initializer containing a pack expansion that expands to
0 elements is treated as value-initialization. We were handling that
properly for variable initializers, but not for mem-initializers in
constructors.
Tested x86_64-pc-linux-gnu, applying to trunk, 4.7 and 4.6.
commit 58c6706693964e81e846905cdd747a4aec015d09
Author: Jason Merrill ja...@redhat.com
Date: Tue Apr 3 15:31:39 2012 -0400
PR c++/52796
* pt.c (tsubst_initializer_list): A pack expansion with no elements
means value-initialization.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index aabe477..03acd5b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19470,6 +19470,7 @@ tsubst_initializer_list (tree t, tree argvec)
}
else
{
+ tree tmp;
decl = tsubst_copy (TREE_PURPOSE (t), argvec,
tf_warning_or_error, NULL_TREE);
@@ -19478,10 +19479,17 @@ tsubst_initializer_list (tree t, tree argvec)
in_base_initializer = 1;
init = TREE_VALUE (t);
+ tmp = init;
if (init != void_type_node)
init = tsubst_expr (init, argvec,
tf_warning_or_error, NULL_TREE,
/*integral_constant_expression_p=*/false);
+ if (init == NULL_TREE tmp != NULL_TREE)
+ /* If we had an initializer but it instantiated to nothing,
+ value-initialize the object. This will only occur when
+ the initializer was a pack expansion where the parameter
+ packs used in that expansion were of length zero. */
+ init = void_type_node;
in_base_initializer = 0;
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C b/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C
new file mode 100644
index 000..179919a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C
@@ -0,0 +1,24 @@
+// PR c++/52796
+// { dg-do run { target c++11 } }
+
+inline void *operator new(__SIZE_TYPE__ s, void *p) { return p; }
+
+struct A
+{
+ int i;
+ templateclass... Ts
+ A(Ts... ts): i(ts...) { }
+};
+
+static union {
+ unsigned char c[sizeof(A)];
+ int i;
+};
+
+int main()
+{
+ i = 0xdeadbeef;
+ new(c) A;
+ if (i != 0)
+__builtin_abort();
+}
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Tue, 3 Apr 2012, Michael Hope wrote:
+#define GLIBC_DYNAMIC_LINKER \
+ %{mhard-float: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{!mfloat-abi=hard:%{!mhard-float: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }}
(a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to
be handled in specs.
(b) You need to handle compilers configured with --with-float=hard, so
make the specs depend on the default ABI the compiler was configured with.
(c) Please include libc-ports on future submissions and provide both the
GCC patch and the glibc ports patch that have been tested to work together
to build and install the library in the given path; a patch to one
component like this cannot sensibly be considered in isolation. I imagine
you'll need appropriate ARM preconfigure support to detect what ABI the
compiler is using, much like the support for MIPS, so that the right
shlib-versions files are used. I try to follow all ARM glibc discussions
on libc-ports closely, as the ARM glibc maintainer; was there a previous
discussion of the dynamic linker naming issue there that I missed? (The
only previous relevant discussion that I recall is one on
patc...@eglibc.org starting at
http://www.eglibc.org/archives/patches/msg01017.html, regarding how the
dynamic linker should check that a library has the right ABI, and there
was no real followup on that after I indicated what would seem to be the
appropriate implementation approaches and places for subsequent
discussion.)
I have no idea whether shlib-versions files naming a file in a
subdirectory will work - but if not, you'd need to send a patch to
libc-alpha to support dynamic linkers in subdirectories, with appropriate
justification for why you are doing something different from all other
architectures.
(d) Existing practice for Power Architecture and MIPS at least is that
hard-float and soft-float *don't* use different library directories /
dynamic linkers.
(e) Existing practice for cases that do use different dynamic linkers is
to use a separate library directory, not just dynamic linker name, as in
lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
make two sets of libraries work in parallel if you have separate library
directories like that. So it would seem more appropriate to define a
directory libhf for ARM (meaning you need a binutils patch as well to
handle that directory, I think), and these different Debian-style names
could be implemented separately in a multiarch patch if someone submits
one that properly accounts for my review comments on previous patch
versions (failure to produce such a fixed patch being why Debian multiarch
directory support has not got into GCC so far).
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote: The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros. This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad. I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64. (cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that) I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things. Does the dynamic linker itself contain any routines that depend on the soft/hard ABI? That would quite surprise me, so I don't see the point of having different dynamic linkers for those ABIs. One dynamic linker should handle both just fine. No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros. Isn't e.g. Fedora 17/armv7hl a hard float based distro? Jakub
[patch] Fix PR52822 (stable_partition move-assigns object to itself) in trunk, 4.7, and 4.6
The attached patches fix http://gcc.gnu.org/PR52822, and have been tested with `make check-c++` on linux-x86_64. The trunk patch applies and tests cleanly on gcc-4_7-branch. The gcc-4_6-branch patch is significantly simpler, as Paolo suggested on the bug. The test is still inadequate, but given that there's no way to force get_temporary_buffer to return a short buffer, I'm not sure how to improve it. It might be possible to use set_memory_limits(), but that would require a very complex test program to make sure exactly the right operator new call fails. Jeffrey Yasskin pr52822_trunk.patch Description: Binary data pr52822_gcc46.patch Description: Binary data
libgo patch committed: Fix GNU/Linux netlink code for big-endian
This patch to libgo fixes the support for GNU/Linux netlink code, used
to retrieve network interfaces, for big-endian systems. Bootstrapped
and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to
mainline and 4.7 branch.
Ian
diff -r a2de1f2e5bf8 libgo/Makefile.am
--- a/libgo/Makefile.am Tue Apr 03 12:36:26 2012 -0700
+++ b/libgo/Makefile.am Tue Apr 03 16:41:49 2012 -0700
@@ -1559,6 +1559,7 @@
echo package syscall syscall_arch.go.tmp
echo 'const ARCH = '$(GOARCH)'' syscall_arch.go.tmp
echo 'const OS = '$(GOOS)'' syscall_arch.go.tmp
+ echo 'const BigEndian = $(GO_BIGENDIAN)' syscall_arch.go.tmp
$(SHELL) $(srcdir)/../move-if-change syscall_arch.go.tmp syscall_arch.go
$(STAMP) $@
diff -r a2de1f2e5bf8 libgo/configure.ac
--- a/libgo/configure.ac Tue Apr 03 12:36:26 2012 -0700
+++ b/libgo/configure.ac Tue Apr 03 16:41:49 2012 -0700
@@ -400,6 +400,12 @@
AC_SEARCH_LIBS([sched_yield], [rt])
AC_C_BIGENDIAN
+case $ac_cv_c_bigendian in
+ yes) GO_BIGENDIAN=true ;;
+ no) GO_BIGENDIAN=false ;;
+ *) AC_MSG_ERROR([unknown endianness]) ;;
+esac
+AC_SUBST(GO_BIGENDIAN)
GCC_CHECK_UNWIND_GETIPINFO
diff -r a2de1f2e5bf8 libgo/go/net/interface_linux.go
--- a/libgo/go/net/interface_linux.go Tue Apr 03 12:36:26 2012 -0700
+++ b/libgo/go/net/interface_linux.go Tue Apr 03 16:41:49 2012 -0700
@@ -64,7 +64,11 @@
case syscall.IFLA_IFNAME:
ifi.Name = string(a.Value[:len(a.Value)-1])
case syscall.IFLA_MTU:
- ifi.MTU = int(uint32(a.Value[3])24 | uint32(a.Value[2])16 | uint32(a.Value[1])8 | uint32(a.Value[0]))
+ if syscall.BigEndian {
+ifi.MTU = int(uint32(a.Value[0])24 | uint32(a.Value[1])16 | uint32(a.Value[2])8 | uint32(a.Value[3]))
+ } else {
+ifi.MTU = int(uint32(a.Value[3])24 | uint32(a.Value[2])16 | uint32(a.Value[1])8 | uint32(a.Value[0]))
+ }
}
}
return ifi
@@ -196,7 +200,12 @@
for i := 0; i+1 len(f[0]); i += 2 {
b[i/2], _ = xtoi2(f[0][i:i+2], 0)
}
-ifma := IPAddr{IP: IPv4(b[3], b[2], b[1], b[0])}
+var ifma IPAddr
+if syscall.BigEndian {
+ ifma = IPAddr{IP: IPv4(b[0], b[1], b[2], b[3])}
+} else {
+ ifma = IPAddr{IP: IPv4(b[3], b[2], b[1], b[0])}
+}
ifmat = append(ifmat, ifma.toAddr())
}
}
diff -r a2de1f2e5bf8 libgo/go/syscall/netlink_linux.go
--- a/libgo/go/syscall/netlink_linux.go Tue Apr 03 12:36:26 2012 -0700
+++ b/libgo/go/syscall/netlink_linux.go Tue Apr 03 16:41:49 2012 -0700
@@ -30,23 +30,43 @@
func (rr *NetlinkRouteRequest) toWireFormat() []byte {
b := make([]byte, rr.Header.Len)
- b[0] = byte(rr.Header.Len)
- b[1] = byte(rr.Header.Len 8)
- b[2] = byte(rr.Header.Len 16)
- b[3] = byte(rr.Header.Len 24)
- b[4] = byte(rr.Header.Type)
- b[5] = byte(rr.Header.Type 8)
- b[6] = byte(rr.Header.Flags)
- b[7] = byte(rr.Header.Flags 8)
- b[8] = byte(rr.Header.Seq)
- b[9] = byte(rr.Header.Seq 8)
- b[10] = byte(rr.Header.Seq 16)
- b[11] = byte(rr.Header.Seq 24)
- b[12] = byte(rr.Header.Pid)
- b[13] = byte(rr.Header.Pid 8)
- b[14] = byte(rr.Header.Pid 16)
- b[15] = byte(rr.Header.Pid 24)
- b[16] = byte(rr.Data.Family)
+ if BigEndian {
+ b[0] = byte(rr.Header.Len 24)
+ b[1] = byte(rr.Header.Len 16)
+ b[2] = byte(rr.Header.Len 8)
+ b[3] = byte(rr.Header.Len)
+ b[4] = byte(rr.Header.Type 8)
+ b[5] = byte(rr.Header.Type)
+ b[6] = byte(rr.Header.Flags 8)
+ b[7] = byte(rr.Header.Flags)
+ b[8] = byte(rr.Header.Seq 24)
+ b[9] = byte(rr.Header.Seq 16)
+ b[10] = byte(rr.Header.Seq 8)
+ b[11] = byte(rr.Header.Seq)
+ b[12] = byte(rr.Header.Pid 24)
+ b[13] = byte(rr.Header.Pid 16)
+ b[14] = byte(rr.Header.Pid 8)
+ b[15] = byte(rr.Header.Pid)
+ b[16] = byte(rr.Data.Family)
+ } else {
+ b[0] = byte(rr.Header.Len)
+ b[1] = byte(rr.Header.Len 8)
+ b[2] = byte(rr.Header.Len 16)
+ b[3] = byte(rr.Header.Len 24)
+ b[4] = byte(rr.Header.Type)
+ b[5] = byte(rr.Header.Type 8)
+ b[6] = byte(rr.Header.Flags)
+ b[7] = byte(rr.Header.Flags 8)
+ b[8] = byte(rr.Header.Seq)
+ b[9] = byte(rr.Header.Seq 8)
+ b[10] = byte(rr.Header.Seq 16)
+ b[11] = byte(rr.Header.Seq 24)
+ b[12] = byte(rr.Header.Pid)
+ b[13] = byte(rr.Header.Pid 8)
+ b[14] = byte(rr.Header.Pid 16)
+ b[15] = byte(rr.Header.Pid 24)
+ b[16] = byte(rr.Data.Family)
+ }
return b
}
Re: [google][4.6] back out change for pr49642 (issue5976073)
OK for google-4_6
Dehao
On Wed, Apr 4, 2012 at 8:36 AM, Rong Xu x...@google.com wrote:
Hi,
Google branch only.
Backout this change due to performance regression.
Tested with bootstrap.
Thanks,
-Rong
2012-04-03 Rong Xu x...@google.com
Google ref b/6284235.
Manually remove upstream patch for PR49642 and it's
test case due to performance regression.
* gcc/testsuite/gcc.dg/tree-ssa/pr49642.c: Remove.
* ipa-split.c (forbidden_dominators): Delete variable.
(check_forbidden_calls): Delete function.
(dominated_by_forbidden): Likewise.
(consider_split): Revert.
(execute_split_functions): Likewise.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr49642.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr49642.c (revision 186124)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr49642.c (working copy)
@@ -1,49 +0,0 @@
-/* Verify that ipa-split is disabled following __builtin_constant_p. */
-
-/* { dg-do compile } */
-/* { dg-options -O2 -fdump-tree-optimized } */
-
-typedef unsigned int u32;
-typedef unsigned long long u64;
-
-static inline __attribute__((always_inline)) __attribute__((const))
-int __ilog2_u32(u32 n)
-{
- int bit;
- asm (cntlzw %0,%1 : =r (bit) : r (n));
- return 31 - bit;
-}
-
-
-static inline __attribute__((always_inline)) __attribute__((const))
-int __ilog2_u64(u64 n)
-{
- int bit;
- asm (cntlzd %0,%1 : =r (bit) : r (n));
- return 63 - bit;
-}
-
-
-
-static u64 ehca_map_vaddr(void *caddr);
-
-struct ehca_shca {
- u32 hca_cap_mr_pgsize;
-};
-
-static u64 ehca_get_max_hwpage_size(struct ehca_shca *shca)
-{
- return 1UL ( __builtin_constant_p(shca-hca_cap_mr_pgsize) ? (
(shca-hca_cap_mr_pgsize) 1 ? ilog2_NaN() : (shca-hca_cap_mr_pgsize)
(1ULL 63) ? 63 : (shca-hca_cap_mr_pgsize) (1ULL 62) ? 62 :
(shca-hca_cap_mr_pgsize) (1ULL 61) ? 61 : (shca-hca_cap_mr_pgsize)
(1ULL 60) ? 60 : (shca-hca_cap_mr_pgsize) (1ULL 59) ? 59 :
(shca-hca_cap_mr_pgsize) (1ULL 58) ? 58 : (shca-hca_cap_mr_pgsize)
(1ULL 57) ? 57 : (shca-hca_cap_mr_pgsize) (1ULL 56) ? 56 :
(shca-hca_cap_mr_pgsize) (1ULL 55) ? 55 : (shca-hca_cap_mr_pgsize)
(1ULL 54) ? 54 : (shca-hca_cap_mr_pgsize) (1ULL 53) ? 53 :
(shca-hca_cap_mr_pgsize) (1ULL 52) ? 52 : (shca-hca_cap_mr_pgsize)
(1ULL 51) ? 51 : (shca-hca_cap_mr_pgsize) (1ULL 50) ? 50 :
(shca-hca_cap_mr_pgsize) (1ULL 49) ? 49 : (shca-hca_cap_mr_pgsize)
(1ULL 48) ? 48 : (shca-hca_cap_mr_pgsize) (1ULL 47) ? 47 :
(shca-hca_cap_mr_pgsize) (1ULL 46) ? 46 : (shca-h
ca_cap_mr_pgsize) (1ULL 45) ? 45 : (shca-hca_cap_mr_pgsize) (1ULL
44) ? 44 : (shca-hca_cap_mr_pgsize) (1ULL 43) ? 43 :
(shca-hca_cap_mr_pgsize) (1ULL 42) ? 42 : (shca-hca_cap_mr_pgsize)
(1ULL 41) ? 41 : (shca-hca_cap_mr_pgsize) (1ULL 40) ? 40 :
(shca-hca_cap_mr_pgsize) (1ULL 39) ? 39 : (shca-hca_cap_mr_pgsize)
(1ULL 38) ? 38 : (shca-hca_cap_mr_pgsize) (1ULL 37) ? 37 :
(shca-hca_cap_mr_pgsize) (1ULL 36) ? 36 : (shca-hca_cap_mr_pgsize)
(1ULL 35) ? 35 : (shca-hca_cap_mr_pgsize) (1ULL 34) ? 34 :
(shca-hca_cap_mr_pgsize) (1ULL 33) ? 33 : (shca-hca_cap_mr_pgsize)
(1ULL 32) ? 32 : (shca-hca_cap_mr_pgsize) (1ULL 31) ? 31 :
(shca-hca_cap_mr_pgsize) (1ULL 30) ? 30 : (shca-hca_cap_mr_pgsize)
(1ULL 29) ? 29 : (shca-hca_cap_mr_pgsize) (1ULL 28) ? 28 :
(shca-hca_cap_mr_pgsize) (1ULL 27) ? 27 : (shca-hca_cap_mr_pgsize)
(1ULL 26) ? 26 : (shca-hca_cap_mr_pgsize) (1ULL
25) ? 25 : (shca-hca_cap_mr_pgsize) (1ULL 24) ? 24 :
(shca-hca_cap_mr_pgsize) (1ULL 23) ? 23 : (shca-hca_cap_mr_pgsize)
(1ULL 22) ? 22 : (shca-hca_cap_mr_pgsize) (1ULL 21) ? 21 :
(shca-hca_cap_mr_pgsize) (1ULL 20) ? 20 : (shca-hca_cap_mr_pgsize)
(1ULL 19) ? 19 : (shca-hca_cap_mr_pgsize) (1ULL 18) ? 18 :
(shca-hca_cap_mr_pgsize) (1ULL 17) ? 17 : (shca-hca_cap_mr_pgsize)
(1ULL 16) ? 16 : (shca-hca_cap_mr_pgsize) (1ULL 15) ? 15 :
(shca-hca_cap_mr_pgsize) (1ULL 14) ? 14 : (shca-hca_cap_mr_pgsize)
(1ULL 13) ? 13 : (shca-hca_cap_mr_pgsize) (1ULL 12) ? 12 :
(shca-hca_cap_mr_pgsize) (1ULL 11) ? 11 : (shca-hca_cap_mr_pgsize)
(1ULL 10) ? 10 : (shca-hca_cap_mr_pgsize) (1ULL 9) ? 9 :
(shca-hca_cap_mr_pgsize) (1ULL 8) ? 8 : (shca-hca_cap_mr_pgsize)
(1ULL 7) ? 7 : (shca-hca_cap_mr_pgsize) (1ULL 6) ? 6 :
(shca-hca_cap_mr_pgsize) (1ULL 5) ? 5 : (shca-hca_cap_mr_pgsize)
(1ULL 4) ? 4 : (shca-hca_cap_mr_pgsize) (1ULL 3) ? 3 :
(shca-hca_cap_mr_pgsize) (1ULL 2) ? 2 : (shca-hca_cap_mr_pgsize)
(1ULL 1) ? 1 : (shca-hca_cap_mr_pgsize) (1ULL 0) ? 0 :
ilog2_NaN() ) : (sizeof(shca-hca_cap_mr_pgsize) = 4) ?
__ilog2_u32(shca-hca_cap_mr_pgsize) : __ilog2_u64(shca-hca_cap_mr_pgsize) );
-}
-
-int x(struct ehca_shca *shca) {
- return ehca_get_max_hwpage_size(shca);
-}
-
-int y(struct ehca_shca *shca)
-{
-
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
Em 3 de abril de 2012 20:48, Michael Hope michael.h...@linaro.org escreveu: On 4 April 2012 11:11, Jakub Jelinek ja...@redhat.com wrote: On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote: The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros. This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad. I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64. (cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that) I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things. Does the dynamic linker itself contain any routines that depend on the soft/hard ABI? That would quite surprise me, so I don't see the point of having different dynamic linkers for those ABIs. One dynamic linker should handle both just fine. No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros. Isn't e.g. Fedora 17/armv7hl a hard float based distro? Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo. None have been released yet. Here's my understanding: Fedora 17: * ARM is a secondary architecture * Alpha 1 release is out * Has both a ARMv5 soft float and ARMv7 hard float build Ubuntu Precise: * ARM is a primary architecture * Beta 2 is out * ARMv7 hard float by default with ARMv7 softfp being community supported Debian: * ARM is a primary architecture * Has a ARMv4T soft float and in-development ARMv7 hard float openSUSE: * Kicked off at a hackfest in September 2011 * Have a ARMv5T soft float and ARMv7 hard float build Gentoo: * I'm unsure (help?) * The Gentoo manual suggests ARMv7 softfp is the default I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be good to have to be able to run binaries for either without resorting to a chroot, and only testing purposes. Bumping major or calling it ld-linux-foo.so.3 is out of question? -- Michael ___ cross-distro mailing list cross-dis...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro Paulo
PATCH: PR debug/52857: DW_OP_GNU_regval_type is generated with INVALID_REGNUM
Hi, As the testcase in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857 shows, for (subreg:SI (plus:DI (reg/f:DI 16 argp) (const_int -128 [0xff80])) 0) we generates DW_OP_GNU_regval_type with INVALID_REGNUM. This patch checks dbx_reg_number for INVALID_REGNUM before using it. OK for trunk and 4.7? Thanks. H.J. --- 2012-04-03 H.J. Lu hongjiu...@intel.com PR debug/52857 * dwarf2out.c (mem_loc_descriptor): Don't generate DW_OP_GNU_regval_type with INVALID_REGNUM. diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index ca88fc5..935c86f 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -11664,7 +11664,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode, if (dwarf_strict) break; - if (REGNO (rtl) FIRST_PSEUDO_REGISTER) + if (REGNO (rtl) FIRST_PSEUDO_REGISTER + || dbx_reg_number (rtl) == INVALID_REGNUM) break; type_die = base_type_for_mode (mode, GET_MODE_CLASS (mode) == MODE_INT);
Re: rs6000 toc reference rtl again
On Tue, Apr 03, 2012 at 07:49:04PM +0100, Richard Sandiford wrote: Alan Modra amo...@gmail.com writes: Now that we are back in stage1, I'd like to apply http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to toc reference rtl in order to properly specify r2 dependencies. More commentary in that url. I'm reposting the patch here since the old one no longer applies cleanly, and I've added some ENABLE_CHECKING code in rs6000_delegitimize_address. Sorry to be a pain, but I don't think HIGH is supposed contain regs either. Both HIGH and CONST are supposed to be true constants. Eh, so the existing use of CONST is wrong then. ;-) I'm proposing (unspec [(symbol_ref sym) (reg r2)] UNSPEC_TOCREL) for the small model, and (high (unspec [(symbol_ref sym) (reg r2)] UNSPEC_TOCREL))) (lo_sum (reg hi) (unspec [(symbol_ref sym) (reg r2)] UNSPEC_TOCREL)) for medium/large model. You can see why I'd like to keep it this way; The medium/large rtl is a natural split of the small rtl. (I'm going to experiment with splitting the small rtl after reload for medium/large to see whether that helps our usage of call-saved regs in loops.) I'm not wedded to the representation, *but* we do want gcc to treat the high part as a constant. That's important because we don't ever want reload saving the high part to a stack slot! Which is what does happen if you don't somehow tell gcc it is a constant. Besides, the high part *is* a constant within any given function. So is the low part for that matter. The only reason I want r2 mentioned in this rtl is for register liveness, eg. so that a load of a function pointer (which loads r2) for an indirect call doesn't get scheduled before any uses of the old r2. The alternative of removing r2 from the unspec and attaching a (use (reg r2)) to all instructions that have this addressing form might be clean but will require major duplication of patterns in rs6000.md, won't it? -- Alan Modra Australia Development Lab, IBM
PATCH: Define TRY_EMPTY_VM_SPACE for Linux/x32
Hi, This patch defines TRY_EMPTY_VM_SPACE for Linux/x32. Tested on Linux/x32. OK for trunk? Thanks. H.J. --- 2012-04-03 H.J. Lu hongjiu...@intel.com * config/host-linux.c (TRY_EMPTY_VM_SPACE): Defined to 0x6000 for x32. diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c index 94b7a0b..b89df46 100644 --- a/gcc/config/host-linux.c +++ b/gcc/config/host-linux.c @@ -68,8 +68,14 @@ # define TRY_EMPTY_VM_SPACE0x100 #elif defined(__ia64) # define TRY_EMPTY_VM_SPACE0x2001 -#elif defined(__x86_64) +/* __LP64__ is defined for LP64 after GCC 3.3. If __LP64__ isn't + defined for GCC 4.0 or newer, it must be x32. */ +#elif defined(__x86_64) (defined(__LP64__) \ + || !defined(__GNUC__) \ + || __GNUC__ 4) # define TRY_EMPTY_VM_SPACE0x10 +#elif defined(__x86_64) +# define TRY_EMPTY_VM_SPACE0x6000 #elif defined(__i386) # define TRY_EMPTY_VM_SPACE0x6000 #elif defined(__powerpc__)
Re: [RS6000] Stack tie fix.
On Tue, Apr 03, 2012 at 01:05:08PM -0400, David Edelsohn wrote: On Tue, Apr 3, 2012 at 10:55 AM, Olivier Hainque hain...@adacore.com wrote: On Apr 3, 2012, at 16:34 , Olivier Hainque wrote: Thanks a lot for following up on this one. Coincidentally, I was just about to submit the alternate approach we had discussed about, after David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html. This is of course a much heavier hammer so it would be nice if we can indeed have a subtler way out :-) To clarify: the heavier approach is the one I was about to submit (minor variation of Joseph's proposal in the thread just referenced), and the subtler way out is the one you are proposing here. We can give Alan's patch a try. I'm not sure if it is sufficient given the experience of IBM's XL compiler. I also would rather not use the heavier hammer, but I don't want to leave a latent bug. I'll see whether my approach fixes pr30282 for gcc-4.4 which has known deficiencies in alias analysis. Olivier, would you be kind enough to backport and test against other versions of gcc that needed your bigger hammer? -- Alan Modra Australia Development Lab, IBM
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
2012/4/4 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 3 de abril de 2012 20:48, Michael Hope michael.h...@linaro.org escreveu: snip Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo. None have been released yet. Here's my understanding: Fedora 17: * ARM is a secondary architecture * Alpha 1 release is out * Has both a ARMv5 soft float and ARMv7 hard float build Ubuntu Precise: * ARM is a primary architecture * Beta 2 is out * ARMv7 hard float by default with ARMv7 softfp being community supported Debian: * ARM is a primary architecture * Has a ARMv4T soft float and in-development ARMv7 hard float openSUSE: * Kicked off at a hackfest in September 2011 * Have a ARMv5T soft float and ARMv7 hard float build Gentoo: * I'm unsure (help?) * The Gentoo manual suggests ARMv7 softfp is the default I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be good to have to be able to run binaries for either without resorting to a chroot, and only testing purposes. Bumping major or calling it ld-linux-foo.so.3 is out of question? I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part. -- Michael
Re: [google] Work around PR52796 by replacing empty packs with explicit overloads. (issue5971053)
On 04/01/2012 12:38 PM, Diego Novillo wrote: I'm not sure it makes sense to propose it for gcc-4_6-branch. Jason/Ben, any opinions on PR 52796 and what should we do for gcc-4_6-branch? Fixed. :) Jason
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 4 April 2012 10:56, Joseph S. Myers jos...@codesourcery.com wrote:
On Tue, 3 Apr 2012, Michael Hope wrote:
+#define GLIBC_DYNAMIC_LINKER \
+ %{mhard-float: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+ %{!mfloat-abi=hard:%{!mhard-float: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }}
(a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to
be handled in specs.
Fixed.
(b) You need to handle compilers configured with --with-float=hard, so
make the specs depend on the default ABI the compiler was configured with.
GCC seems to take configure time options into account when evaluating
a spec file.
Tested by building a default, --with-float=hard, and
--with-float=softfp compiler then checking the loader path for all
combinations of {,-mglibc,-mbionic,-muclibc} x
{,-mhard-float,-msoft-float,-mfloat-abi=hard,-mfloat-abi=softfp}.
(c) Please include libc-ports on future submissions and provide both the
GCC patch and the glibc ports patch that have been tested to work together
to build and install the library in the given path; a patch to one
component like this cannot sensibly be considered in isolation. I imagine
you'll need appropriate ARM preconfigure support to detect what ABI the
compiler is using, much like the support for MIPS, so that the right
shlib-versions files are used.
Agreed.
I try to follow all ARM glibc discussions
on libc-ports closely, as the ARM glibc maintainer; was there a previous
discussion of the dynamic linker naming issue there that I missed?
Steve McIntyre is driving this inside Debian. I'll ping him on the
GLIBC support.
The tricky one is new GCC with old GLIBC. GCC may have to do a
configure time test and fall back to /lib/ld-linux.so.3 if the hard
float loader is missing.
(The only previous relevant discussion that I recall is one on
patc...@eglibc.org starting at
http://www.eglibc.org/archives/patches/msg01017.html, regarding how the
dynamic linker should check that a library has the right ABI, and there
was no real followup on that after I indicated what would seem to be the
appropriate implementation approaches and places for subsequent
discussion.)
The patch above changes the loader to catch a mixed installation and
reject mixing incompatible libraries. The static linker does this
currently but it's not essential.
I have no idea whether shlib-versions files naming a file in a
subdirectory will work - but if not, you'd need to send a patch to
libc-alpha to support dynamic linkers in subdirectories, with appropriate
justification for why you are doing something different from all other
architectures.
Understood. For now this is just a path. There's more infrastructure
work needed if the path includes a directory.
(d) Existing practice for Power Architecture and MIPS at least is that
hard-float and soft-float *don't* use different library directories /
dynamic linkers.
The goal is to have a standard loader path for all hard float distros
and, similar to how you can have a mixed 32/64 bit installation, allow
mixed softfp/hard float installations for distros that want it. This
is a new requirement and ARM is the first one exposed to it. I assume
Debian would push for similar changes on MIPS and PowerPC.
Do the MIPS or PowerPC loaders detect the ABI and change the library
path based on that? I couldn't tell from the code.
(e) Existing practice for cases that do use different dynamic linkers is
to use a separate library directory, not just dynamic linker name, as in
lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
make two sets of libraries work in parallel if you have separate library
directories like that.
Is this required, or should it be left to the distro to choose? Once
the loader is in control then it can account for any distro specific
features, which may be the standard /lib and /usr/lib for single ABI
distros like Fedora or /usr/lib/$tuple for multiarch distros like
Ubuntu and Debian.
So it would seem more appropriate to define a directory libhf for ARM
(meaning you need a binutils patch as well to
handle that directory, I think)
I'd like to leave that discussion for now. The Debian goal is to
support incompatible ABIs and, past that, incompatible architectures.
libhf is ambiguous as you could have a MIPS hard float library
installed on the same system as an ARM hard float library.
and these different Debian-style names
could be implemented separately in a multiarch patch if someone submits
one that properly accounts for my review comments on previous patch
versions (failure to produce such a fixed patch being why Debian multiarch
directory support has not got into GCC so far).
Agreed. Note that this loader path discussion is unrelated to
multiarch. It came from the same people so there's a family
resemblance.
(BTW Dann, apologies for stealing your patch)
-- Michael
2012-04-03 Michael Hope
Re: [google] Work around PR52796 by replacing empty packs with explicit overloads. (issue5971053)
On 04/01/2012 12:38 PM, Diego Novillo wrote: I'm not sure it makes sense to propose it for gcc-4_6-branch. Jason/Ben, any opinions on PR 52796 and what should we do for gcc-4_6-branch? Fixed. :) I'm so relieved, seriously. Thanks, Paolo
Re: [PATCH] Dissociate store_expr's temp from exp so that it is not marked as addressable
Yes, either way I suppose. The following also looks dangerous to me: /* If OFFSET is making OP0 more aligned than BIGGEST_ALIGNMENT, record its alignment as BIGGEST_ALIGNMENT. */ if (MEM_P (op0) bitpos == 0 offset != 0 is_aligning_offset (offset, tem)) set_mem_align (op0, BIGGEST_ALIGNMENT); Maybe we can fall through most of the rest of the function if we canonicalized in the above way? Eric? Probably not, I'm afraid. I agree that the above call to set_mem_align is potentially problematic if we previously allocated the temp. Moreover, I think that the other temp allocation around line 9840 is problematic too. On the other hand, we could avoid skipping set_mem_attributes entirely by passing the type instead of the expression. So I'd set a flag for the first temp allocation, skip the set_mem_align call if it is set and pass the type instead of the expression in the final call to set_mem_attributes if it is set. And I'd handle the second temp allocation independently and pass the type here too. -- Eric Botcazou
Re: [PATCH] Dissociate store_expr's temp from exp so that it is not marked as addressable
On Tue, 3 Apr 2012, Eric Botcazou wrote: Yes, either way I suppose. The following also looks dangerous to me: /* If OFFSET is making OP0 more aligned than BIGGEST_ALIGNMENT, record its alignment as BIGGEST_ALIGNMENT. */ if (MEM_P (op0) bitpos == 0 offset != 0 is_aligning_offset (offset, tem)) set_mem_align (op0, BIGGEST_ALIGNMENT); Maybe we can fall through most of the rest of the function if we canonicalized in the above way? Eric? Probably not, I'm afraid. I agree that the above call to set_mem_align is potentially problematic if we previously allocated the temp. Moreover, I think that the other temp allocation around line 9840 is problematic too. On the other hand, we could avoid skipping set_mem_attributes entirely by passing the type instead of the expression. So I'd set a flag for the first temp allocation, skip the set_mem_align call if it is set and pass the type instead of the expression in the final call to set_mem_attributes if it is set. And I'd handle the second temp allocation independently and pass the type here too. Yeah, that sounds reasonable. Richard.
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
Hmm, yeah. Or something like Index: expr.c === --- expr.c (revision 186082) +++ expr.c (working copy) @@ -4490,8 +4490,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b bitoffset += (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1) - tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1)); - *bitstart = bitpos - bitoffset; - *bitend = *bitstart + tree_low_cst (DECL_SIZE (repr), 1) - 1; + *bitstart = bitpos (HOST_WIDE_INT) bitoffset ? 0 : bitpos - bitoffset; + *bitend = bitpos + tree_low_cst (DECL_SIZE (repr), 1) - bitoffset - 1; } /* Returns true if the MEM_REF REF refers to an object that does not which conservatively truncates the bitrange. What do you think about allowing get_bit_range to adjust offset and bitpos? tem = get_inner_reference (to, bitsize, bitpos, offset, mode1, unsignedp, volatilep, true); if (TREE_CODE (to) == COMPONENT_REF DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1))) get_bit_range (bitregion_start, bitregion_end, offset, bitpos, to); so as to have a really non-negative bitregion_start/bitregion_end? It would assert that offset is already non-null in that case. -- Eric Botcazou
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
On Tue, 3 Apr 2012, Eric Botcazou wrote: Hmm, yeah. Or something like Index: expr.c === --- expr.c (revision 186082) +++ expr.c (working copy) @@ -4490,8 +4490,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b bitoffset += (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1) - tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1)); - *bitstart = bitpos - bitoffset; - *bitend = *bitstart + tree_low_cst (DECL_SIZE (repr), 1) - 1; + *bitstart = bitpos (HOST_WIDE_INT) bitoffset ? 0 : bitpos - bitoffset; + *bitend = bitpos + tree_low_cst (DECL_SIZE (repr), 1) - bitoffset - 1; } /* Returns true if the MEM_REF REF refers to an object that does not which conservatively truncates the bitrange. What do you think about allowing get_bit_range to adjust offset and bitpos? tem = get_inner_reference (to, bitsize, bitpos, offset, mode1, unsignedp, volatilep, true); if (TREE_CODE (to) == COMPONENT_REF DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1))) get_bit_range (bitregion_start, bitregion_end, offset, bitpos, to); so as to have a really non-negative bitregion_start/bitregion_end? It would assert that offset is already non-null in that case. For the case in question offset is (D.2640_7 + -1) * 20 + 16. I wonder why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added to bitpos by get_inner_reference (that is what get_bit_range assumes ...). The FIELD_DECL is arg 1 field_decl 0x75c5 n type integer_type 0x75c4f2a0 natural___XDLU_0__2147483647 unsigned external packed bit-field nonaddressable SI file pack18_pkg.ads line 10 col 7 size integer_cst 0x75ae4c80 constant visited 31 unit size integer_cst 0x75ae4260 4 align 1 offset_align 128 offset integer_cst 0x75ae4420 constant visited 16 bit offset integer_cst 0x75ae4560 constant visited 1 bit_field_type integer_type 0x75c4f2a0 natural___XDLU_0__2147483647 context record_type 0x75c4f0a8 pack18_pkg__rec and TREE_OPERAND (to, 2) is NULL and component_ref_field_offset returns 16. In the alias-oracle variants we add constant field-offsets to the bitposition part (at least that avoids the need to dissect the constant part of the offset from the non-constant part). So, how would you make sure this works? Match the fact that get_inner_reference does _not_ add DECL_FIELD_OFFSET to bitpos, and, if DECL_FIELD_OFFSET is an INTEGER_CST simply subtract that from offset and add it to bitpos? I suppose that would work. Though doing that in get_inner_reference for DECL_BIT_FIELD_TYPE fields may make sense as well. Richard.
Re: [PATCH] Don't ignore failures from compute_data_dependences_for_loop in build_rdg (PR tree-optimization/52835)
On Mon, Apr 2, 2012 at 11:53 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
On the following testcase compute_data_dependences_for_loop
fails, but build_rdg ignores its return value and happily goes
on as if it didn't fail, optimizing away a call.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/4.7?
Ok.
Thanks,
Richard.
2012-04-02 Jakub Jelinek ja...@redhat.com
PR tree-optimization/52835
* tree-data-ref.c (build_rdg): Return NULL if
compute_data_dependences_for_loop failed.
* gfortran.dg/pr52835.f90: New test.
--- gcc/tree-data-ref.c.jj 2012-03-20 08:51:32.0 +0100
+++ gcc/tree-data-ref.c 2012-04-02 21:30:13.783378347 +0200
@@ -5129,20 +5129,19 @@ build_rdg (struct loop *loop,
VEC (data_reference_p, heap) **datarefs)
{
struct graph *rdg = NULL;
- VEC (gimple, heap) *stmts = VEC_alloc (gimple, heap, 10);
- compute_data_dependences_for_loop (loop, false, loop_nest, datarefs,
- dependence_relations);
-
- if (known_dependences_p (*dependence_relations))
+ if (compute_data_dependences_for_loop (loop, false, loop_nest, datarefs,
+ dependence_relations)
+ known_dependences_p (*dependence_relations))
{
+ VEC (gimple, heap) *stmts = VEC_alloc (gimple, heap, 10);
stmts_from_loop (loop, stmts);
rdg = build_empty_rdg (VEC_length (gimple, stmts));
create_rdg_vertices (rdg, stmts);
create_rdg_edges (rdg, *dependence_relations);
+ VEC_free (gimple, heap, stmts);
}
- VEC_free (gimple, heap, stmts);
return rdg;
}
--- gcc/testsuite/gfortran.dg/pr52835.f90.jj 2012-04-02 21:35:42.616505464
+0200
+++ gcc/testsuite/gfortran.dg/pr52835.f90 2012-04-02 21:35:08.0
+0200
@@ -0,0 +1,16 @@
+! PR tree-optimization/52835
+! { dg-do compile }
+! { dg-options -O3 -fdump-tree-optimized }
+
+subroutine foo (x, y, z, n)
+ integer :: n, i
+ real :: x(n), y(n), z(n)
+ do i = 1, n
+ z(i) = 0.0
+ y(i) = 0.0
+ call bar (y(i), z(i), x(i))
+ end do
+end subroutine
+
+! { dg-final { scan-tree-dump bar optimized } }
+! { dg-final { cleanup-tree-dump optimized } }
Jakub
[RS6000] Stack tie fix.
This patch merges the rs6000 stack_tie and frame_tie rtl, so that we
now should use a tie insn that mentions all base regs involved in
register saves and restores. That should avoid any alias analysis
problems eg. http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01156.html.
I chose to put the regs of interest on the destination of the fake
set, rather than in the source as is currently done, because I figure
that relying on the compiler to not reorder reads is fragile. Here's
an example of the new stack tie:
(set (mem:BLK (unspec:SI [(reg:SI 1) (reg:SI 12)] UNSPEC_TIE))
(const_int 0))
Some notes:
- I tried putting the mem on both source and destination of the set,
but that runs afoul of rtl dead code elimination.
- The rs6000_emit_epilogue places that called gen_frame_tie and
gen_stack_tie both used alias set 0 mems. I believe this was
unnecessarily restrictive.
- CODE_FOR_stack_tie is mentioned in rs6000.c but not
CODE_FOR_frame_tie. Removing frame_tie fixes this sched bug too.
Bootstrapped and regression tested powerpc-linux with usual -O2
BOOT_CFLAGS and also -Os, and testcases from pr44199, pr30282, pr52828,
the url above and http://gcc.gnu.org/ml/gcc/2011-03/msg00123.html
examined for sanity. OK to apply?
PR target/52828
* config/rs6000/rs6000.c (rs6000_emit_stack_tie): Rewrite with
tie regs on destination of set. Delete forward declaration.
(rs6000_emit_stack_reset): Update rs6000_emit_stack_tie calls.
(rs6000_emit_prologue): Likewise.
(rs6000_emit_epilogue): Likewise. Use in place of gen_frame_tie
and gen_stack_tie.
* config/rs6000/predicates.md (tie_operand): New.
* config/rs6000/rs6000.md (restore_stack_block): Generate new
stack tie rtl.
(restore_stack_nonlocal): Likewise.
(stack_tie): Update.
(frame_tie): Delete.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 185830)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -925,7 +925,6 @@ static const char *rs6000_invalid_within_doloop (c
static bool rs6000_legitimate_address_p (enum machine_mode, rtx, bool);
static bool rs6000_debug_legitimate_address_p (enum machine_mode, rtx, bool);
static rtx rs6000_generate_compare (rtx, enum machine_mode);
-static void rs6000_emit_stack_tie (void);
static bool spe_func_has_64bit_regs_p (void);
static rtx gen_frame_mem_offset (enum machine_mode, rtx, int);
static unsigned rs6000_hash_constant (rtx);
@@ -18517,12 +18516,28 @@ rs6000_aix_asm_output_dwarf_table_ref (char * fram
and the change to the stack pointer. */
static void
-rs6000_emit_stack_tie (void)
+rs6000_emit_stack_tie (rtx fp, bool hard_frame_needed)
{
- rtx mem = gen_frame_mem (BLKmode,
- gen_rtx_REG (Pmode, STACK_POINTER_REGNUM));
+ rtx u;
+ rtvec p;
+ int i;
- emit_insn (gen_stack_tie (mem));
+ if (REGNO (fp) == STACK_POINTER_REGNUM
+ || (hard_frame_needed
+ REGNO (fp) == HARD_FRAME_POINTER_REGNUM))
+fp = NULL_RTX;
+
+ p = rtvec_alloc (1 + hard_frame_needed + (fp != NULL_RTX));
+
+ i = 0;
+ RTVEC_ELT (p, i++) = gen_rtx_REG (Pmode, STACK_POINTER_REGNUM);
+ if (hard_frame_needed)
+RTVEC_ELT (p, i++) = gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM);
+ if (fp != NULL_RTX)
+RTVEC_ELT (p, i++) = fp;
+ u = gen_rtx_UNSPEC (Pmode, p, UNSPEC_TIE);
+
+ emit_insn (gen_stack_tie (gen_frame_mem (BLKmode, u)));
}
/* Emit the correct code for allocating stack space, as insns.
@@ -19142,7 +19157,7 @@ rs6000_emit_stack_reset (rs6000_stack_t *info,
|| (TARGET_SPE_ABI
info-spe_64bit_regs_used != 0
info-first_gp_reg_save != 32))
-rs6000_emit_stack_tie ();
+rs6000_emit_stack_tie (frame_reg_rtx, frame_pointer_needed);
if (frame_reg_rtx != sp_reg_rtx)
{
@@ -19362,7 +19377,7 @@ rs6000_emit_prologue (void)
}
rs6000_emit_allocate_stack (info-total_size, copy_reg);
if (frame_reg_rtx != sp_reg_rtx)
- rs6000_emit_stack_tie ();
+ rs6000_emit_stack_tie (frame_reg_rtx, false);
}
/* Handle world saves specially here. */
@@ -19866,7 +19881,7 @@ rs6000_emit_prologue (void)
sp_offset = info-total_size;
rs6000_emit_allocate_stack (info-total_size, copy_reg);
if (frame_reg_rtx != sp_reg_rtx)
- rs6000_emit_stack_tie ();
+ rs6000_emit_stack_tie (frame_reg_rtx, false);
}
/* Set frame pointer, if needed. */
@@ -20437,13 +20452,7 @@ rs6000_emit_epilogue (int sibcall)
/* Prevent reordering memory accesses against stack pointer restore. */
else if (cfun-calls_alloca
|| offset_below_red_zone_p (-info-total_size))
- {
- rtx mem1 = gen_rtx_MEM (BLKmode, hard_frame_pointer_rtx);
- rtx mem2 = gen_rtx_MEM (BLKmode, sp_reg_rtx);
- MEM_NOTRAP_P (mem1) = 1;
- MEM_NOTRAP_P (mem2) = 1;
-
Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)
On Mon, Apr 2, 2012 at 9:41 PM, DJ Delorie d...@redhat.com wrote: Ping 6... It's now been over EIGHT MONTHS since I posted the patch, back in stage 1 for 4.7. Can someone please review and/or approve this before gcc 4.8's stage 1 is closed? This is needed as a first step for ABI compatibility for rx-elf. If it's required for ABI compatibility why is this an attribute and not a target hook? Ping 5... Ping 4... Ping 3? It's been months with no feedback... Ping 2 ? http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00529.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01246.html http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00636.html
[vms/committed]: Handle #pragma __nomember_alignment byte
Hi,
this patch handles the 'byte' alignment that appears in standard VMS headers
when a C++ compiler is used.
It also force the support of parameterless variadic functions to be compatible
with standard VMS headers.
Committed on trunk after ia64-hp-openvms cross build.
Tristan.
2012-04-03 Tristan Gingold ging...@adacore.com
* config/vms/vms-c.c (vms_pragma_nomember_alignment): Handle
'byte' alignment.
(vms_c_common_override_options): Allow parameterless variadic
functions.
Index: gcc/config/vms/vms-c.c
===
--- gcc/config/vms/vms-c.c (revision 186100)
+++ gcc/config/vms/vms-c.c (working copy)
@@ -120,7 +120,9 @@
if (arg[0] == '_' arg[1] == '_')
arg += 2;
- if (strcmp (arg, word) == 0)
+ if (strcmp (arg, byte) == 0)
+maximum_field_alignment = 1 * BITS_PER_UNIT;
+ else if (strcmp (arg, word) == 0)
maximum_field_alignment = 2 * BITS_PER_UNIT;
else if (strcmp (arg, longword) == 0)
maximum_field_alignment = 4 * BITS_PER_UNIT;
@@ -453,6 +455,9 @@
void
vms_c_common_override_options (void)
{
+ /* Allow variadic functions without parameters (as declared in starlet). */
+ flag_allow_parameterless_variadic_functions = TRUE;
+
/* Initialize c_default_pointer_mode. */
switch (flag_vms_pointer_size)
{
Re: [PATCH] Dissociate store_expr's temp from exp so that it is not marked as addressable
Yeah, that sounds reasonable. There is a further subtlety in the second temp allocation when the expression doesn't use the alias set of its type. In that case, we cannot pass the type to set_mem_attributes. In fact, since assign_stack_temp_for_type already calls the appropriate set_mem_* routines, the best thing to do might be to remove the call to set_mem_attributes altogether in that case. -- Eric Botcazou
[Patch]: use mmap.m4 in gcc/configure
Hi,
the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the same
as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except the case
of the first three letters). This patch makes gcc/configure.ac uses
config/mmap.m4 instead of its own version.
Also, I modified config/mmap.m4 to match *vms* instead of vms* like all other
configuration scripts (because the official name is now openvms).
Tested by building for ia64-hp-openvms and by visual inspection of the
generated configure (only the *vms* lines changed).
Ok for trunk ?
Tristan.
config/
2012-04-03 Tristan Gingold ging...@adacore.com
* mmap.m4: Use *vms* instead of vms*.
gcc/
2012-04-03 Tristan Gingold ging...@adacore.com
* configure.ac: Use GCC_AC_FUNC_MMAP_BLACKLIST instead
of gcc_AC_FUNC_MMAP_BLACKLIST.
* aclocal.m4: Include mmap.m4
* acinclude.m4 (gcc_AC_FUNC_MMAP_BLACKLIST): Remove.
* Makefile.in (aclocal_deps): Add mmap.m4.
* configure: Regenerate.
libitm/
2012-04-03 Tristan Gingold ging...@adacore.com
* configure: Regenerate.
diff --git a/config/mmap.m4 b/config/mmap.m4
index 39d79af..fba0d9d 100644
--- a/config/mmap.m4
+++ b/config/mmap.m4
@@ -24,7 +24,7 @@ else
# read() to the same fd. The only system known to have a problem here
# is VMS, where text files have record structure.
case $host_os in
- vms* | ultrix*)
+ *vms* | ultrix*)
gcc_cv_func_mmap_file=no ;;
*)
gcc_cv_func_mmap_file=yes;;
@@ -42,7 +42,7 @@ else
# Systems known to be in this category are Windows (all variants),
# VMS, and Darwin.
case $host_os in
- vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
+ *vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
gcc_cv_func_mmap_dev_zero=no ;;
*)
gcc_cv_func_mmap_dev_zero=yes;;
@@ -74,7 +74,7 @@ else
# above for use of /dev/zero.
# Systems known to be in this category are Windows, VMS, and SCO Unix.
case $host_os in
- vms* | cygwin* | pe | mingw* | sco* | udk* )
+ *vms* | cygwin* | pe | mingw* | sco* | udk* )
gcc_cv_func_mmap_anon=no ;;
*)
gcc_cv_func_mmap_anon=yes;;
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index f5fa0c3..8fd8208 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1650,6 +1650,7 @@ aclocal_deps = \
$(srcdir)/../config/unwind_ipinfo.m4 \
$(srcdir)/../config/warnings.m4 \
$(srcdir)/../config/dfp.m4 \
+ $(srcdir)/../config/mmap.m4 \
$(srcdir)/acinclude.m4
$(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/aclocal.m4
diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
index 84b828f..c24464b 100644
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -221,99 +221,6 @@ test -z $INSTALL_DATA INSTALL_DATA='${INSTALL} -m 644'
AC_SUBST(INSTALL_DATA)dnl
])
-# mmap(2) blacklisting. Some platforms provide the mmap library routine
-# but don't support all of the features we need from it.
-AC_DEFUN([gcc_AC_FUNC_MMAP_BLACKLIST],
-[
-AC_CHECK_HEADER([sys/mman.h],
- [gcc_header_sys_mman_h=yes], [gcc_header_sys_mman_h=no])
-AC_CHECK_FUNC([mmap], [gcc_func_mmap=yes], [gcc_func_mmap=no])
-if test $gcc_header_sys_mman_h != yes \
- || test $gcc_func_mmap != yes; then
- gcc_cv_func_mmap_file=no
- gcc_cv_func_mmap_dev_zero=no
- gcc_cv_func_mmap_anon=no
-else
- AC_CACHE_CHECK([whether read-only mmap of a plain file works],
- gcc_cv_func_mmap_file,
- [# Add a system to this blacklist if
- # mmap(0, stat_size, PROT_READ, MAP_PRIVATE, fd, 0) doesn't return a
- # memory area containing the same data that you'd get if you applied
- # read() to the same fd. The only system known to have a problem here
- # is VMS, where text files have record structure.
- case $host_os in
- vms* | ultrix*)
-gcc_cv_func_mmap_file=no ;;
- *)
-gcc_cv_func_mmap_file=yes;;
- esac])
- AC_CACHE_CHECK([whether mmap from /dev/zero works],
- gcc_cv_func_mmap_dev_zero,
- [# Add a system to this blacklist if it has mmap() but /dev/zero
- # does not exist, or if mmapping /dev/zero does not give anonymous
- # zeroed pages with both the following properties:
- # 1. If you map N consecutive pages in with one call, and then
- #unmap any subset of those pages, the pages that were not
- #explicitly unmapped remain accessible.
- # 2. If you map two adjacent blocks of memory and then unmap them
- #both at once, they must both go away.
- # Systems known to be in this category are Windows (all variants),
- # VMS, and Darwin.
- case $host_os in
- vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
-gcc_cv_func_mmap_dev_zero=no ;;
- *)
-gcc_cv_func_mmap_dev_zero=yes;;
- esac])
-
- # Unlike /dev/zero, the MAP_ANON(YMOUS) defines can be probed for.
- AC_CACHE_CHECK([for MAP_ANON(YMOUS)],
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 04/02/2012 10:06 PM, dann frazier wrote:
On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
On 29/03/12 20:34, dann frazier wrote:
This is an updated version of a patch Debian and Ubuntu are using to
use an alternate linker path for hardfloat binaries. The difference
with this one is that it covers the case where no float flag
was passed in, defaulting to the softfloat path.
2012-03-29 dann frazier dann.fraz...@canonical.com
* config/arm/linux-elf.h: Use alternate linker path
for hardfloat ABI
Index: gcc/config/arm/linux-elf.h
===
--- gcc/config/arm/linux-elf.h (revision 185708)
+++ gcc/config/arm/linux-elf.h (working copy)
@@ -59,14 +59,21 @@
#define LIBGCC_SPEC %{mfloat-abi=soft*:-lfloat} -lgcc
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2
+#define LINUX_DYNAMIC_LINKER_SF /lib/ld-linux.so.3
+#define LINUX_DYNAMIC_LINKER_HF /lib/arm-linux-gnueabihf/ld-linux.so.3
#define LINUX_TARGET_LINK_SPEC %{h*} \
%{static:-Bstatic} \
%{shared:-shared} \
%{symbolic:-Bsymbolic} \
%{rdynamic:-export-dynamic} \
- -dynamic-linker GNU_USER_DYNAMIC_LINKER \
+ %{msoft-float:-dynamic-linker LINUX_DYNAMIC_LINKER_SF } \
+ %{mfloat-abi=soft*:-dynamic-linker LINUX_DYNAMIC_LINKER_SF } \
+ %{mhard-float:-dynamic-linker LINUX_DYNAMIC_LINKER_HF } \
+ %{mfloat-abi=hard:-dynamic-linker LINUX_DYNAMIC_LINKER_HF } \
+ %{!mfloat-abi: \
+ %{!msoft-float: \
+ %{!mhard-float:-dynamic-linker LINUX_DYNAMIC_LINKER_SF }}} \
-X \
%{mbig-endian:-EB} %{mlittle-endian:-EL} \
SUBTARGET_EXTRA_LINK_SPEC
Looks to me as though this will break the old Linux ABI. While we've
marked that as deprecated, it hasn't been removed as yet. So I think
this patch either needs to wait until that removal has taken place, or
provide the relevant updates to maintain the old ABI support.
Thanks for your review. You're right, this does appear to break the
old ABI - that was a misunderstanding on my part. I think this fixes
the problem:
But what about those of us who are using hard-float but not the
Debian liker path? It'll break, surely. This looks to be like
it's Debian-specific.
Andrew.
Index: gcc/config/arm/linux-elf.h
===
--- gcc/config/arm/linux-elf.h(revision 185708)
+++ gcc/config/arm/linux-elf.h(working copy)
@@ -60,13 +60,17 @@
#define LIBGCC_SPEC %{mfloat-abi=soft*:-lfloat} -lgcc
#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2
+#define LINUX_DYNAMIC_LINKER_HF /lib/arm-linux-gnueabihf/ld-linux.so.3
#define LINUX_TARGET_LINK_SPEC %{h*} \
%{static:-Bstatic} \
%{shared:-shared} \
%{symbolic:-Bsymbolic} \
%{rdynamic:-export-dynamic} \
- -dynamic-linker GNU_USER_DYNAMIC_LINKER \
+ %{mhard-float:-dynamic-linker LINUX_DYNAMIC_LINKER_HF } \
+ %{mfloat-abi=hard:-dynamic-linker LINUX_DYNAMIC_LINKER_HF } \
+ %{!mfloat-abi: \
+ %{!mhard-float:-dynamic-linker GNU_USER_DYNAMIC_LINKER }} \
-X \
%{mbig-endian:-EB} %{mlittle-endian:-EL} \
SUBTARGET_EXTRA_LINK_SPEC
Re: [PATCH, RTL] Fix PR 51106
On Mon, Apr 02, 2012 at 06:56:25PM +0400, Andrey Belevantsev wrote: After Richi's RTL generation related cleanups went it, the extra cleanup_cfg call was added so we are no longer lucky to have the proper fallthru edge in this case. The PR trail has the patch to purge_dead_edges making it consider this situation, but I still prefer the below patch that fixes only the invalid asm case. The reason is that I think it unlikely that after initial RTL expansion (of which the instantiate virtual regs pass seems to be the part) we will get the problematic situation. However, I'm happy to test the PR trail patch, too. I don't like blindly changing edge into FALLTHRU, generally the edge could be abnormal, or EH, etc. and making that fallthru is not a good idea. I'd prefer if wherever the fallthru edge is removed the other normal edge(s) are adjusted. Jakub
Re: [Patch]: use mmap.m4 in gcc/configure
Il 03/04/2012 11:25, Tristan Gingold ha scritto: Hi, the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the same as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except the case of the first three letters). This patch makes gcc/configure.ac uses config/mmap.m4 instead of its own version. Also, I modified config/mmap.m4 to match *vms* instead of vms* like all other configuration scripts (because the official name is now openvms). Tested by building for ia64-hp-openvms and by visual inspection of the generated configure (only the *vms* lines changed). Ok for trunk ? Tristan. config/ 2012-04-03 Tristan Gingold ging...@adacore.com * mmap.m4: Use *vms* instead of vms*. gcc/ 2012-04-03 Tristan Gingold ging...@adacore.com * configure.ac: Use GCC_AC_FUNC_MMAP_BLACKLIST instead of gcc_AC_FUNC_MMAP_BLACKLIST. * aclocal.m4: Include mmap.m4 aclocal.m4 is supposed to be automatically generated, can you check that nothing strange happens if you configure with --enable-maintainer-mode and do touch acinclude.m4 make aclocal.m4 in the GCC directory? * acinclude.m4 (gcc_AC_FUNC_MMAP_BLACKLIST): Remove. * Makefile.in (aclocal_deps): Add mmap.m4. * configure: Regenerate. libitm/ 2012-04-03 Tristan Gingold ging...@adacore.com * configure: Regenerate. Ok. Paolo
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote: If, so then there's only one way to sort out this mess. /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader The above scheme is a Debianism which no other distro is using. Jakub
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
For the case in question offset is (D.2640_7 + -1) * 20 + 16. I wonder
why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added
to bitpos by get_inner_reference (that is what get_bit_range assumes ...).
DECL_FIELD_OFFSET is added to offset and DECL_FIELD_BIT_OFFSET to bitpos.
So, how would you make sure this works? Match the fact that
get_inner_reference does _not_ add DECL_FIELD_OFFSET to bitpos,
and, if DECL_FIELD_OFFSET is an INTEGER_CST simply subtract that
from offset and add it to bitpos? I suppose that would work.
Yes, but the amount is simply the negative bitstart (which is a multiple of
BITS_PER_UNIT). This is the same kind of adjustment now done at the end of
get_inner_reference to avoid negative bit positions there too.
Though doing that in get_inner_reference for DECL_BIT_FIELD_TYPE
fields may make sense as well.
That would be more complicated, as we would need to split the offset into
variable and fixed part.
Tentative patch attached, regtested for Ada on x86 and x86-64. I'll do a full
testing cycle if it is approved.
* expr.c (get_bit_range): Add OFFSET parameter and adjust BITPOS.
Change type of BITOFFSET to signed. Make sure the lower bound of
the computed range is non-negative by adjusting OFFSET and BITPOS.
(expand_assignment): Adjust call to get_bit_range.
--
Eric Botcazou
Index: expr.c
===
--- expr.c (revision 186054)
+++ expr.c (working copy)
@@ -4431,19 +4431,22 @@ optimize_bitfield_assignment_op (unsigne
/* In the C++ memory model, consecutive bit fields in a structure are
considered one memory location.
- Given a COMPONENT_REF EXP at bit position BITPOS, this function
+ Given a COMPONENT_REF EXP at position (OFFSET, BITPOS), this function
returns the bit range of consecutive bits in which this COMPONENT_REF
- belongs in. The values are returned in *BITSTART and *BITEND.
+ belongs in. The values are returned in *BITSTART and *BITEND. Both
+ OFFSET and BITPOS may be adjusted in the process.
+
If the access does not need to be restricted 0 is returned in
*BITSTART and *BITEND. */
static void
get_bit_range (unsigned HOST_WIDE_INT *bitstart,
unsigned HOST_WIDE_INT *bitend,
- tree exp,
- HOST_WIDE_INT bitpos)
+ tree *offset,
+ HOST_WIDE_INT *bitpos,
+ tree exp)
{
- unsigned HOST_WIDE_INT bitoffset;
+ HOST_WIDE_INT bitoffset;
tree field, repr;
gcc_assert (TREE_CODE (exp) == COMPONENT_REF);
@@ -4490,7 +4493,25 @@ get_bit_range (unsigned HOST_WIDE_INT *b
bitoffset += (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1)
- tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1));
- *bitstart = bitpos - bitoffset;
+ /* If the adjustment is larger than bitpos, we would have a negative bit
+ position for the lower bound and this may wreak havoc later. This can
+ occur only if we have a non-null offset, so adjust offset and bitpos
+ to make the lower bound non-negative. */
+ if (bitoffset *bitpos)
+{
+ HOST_WIDE_INT adjust = bitoffset - *bitpos;
+
+ gcc_assert ((adjust % BITS_PER_UNIT) == 0);
+ gcc_assert (*offset != NULL_TREE);
+
+ *bitpos += adjust;
+ *offset
+ = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
+ *bitstart = 0;
+}
+ else
+*bitstart = *bitpos - bitoffset;
+
*bitend = *bitstart + tree_low_cst (DECL_SIZE (repr), 1) - 1;
}
@@ -4595,7 +4616,7 @@ expand_assignment (tree to, tree from, b
if (TREE_CODE (to) == COMPONENT_REF
DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
- get_bit_range (bitregion_start, bitregion_end, to, bitpos);
+ get_bit_range (bitregion_start, bitregion_end, offset, bitpos, to);
/* If we are going to use store_bit_field and extract_bit_field,
make sure to_rtx will be safe for multiple use. */
[PATCH] Fix PR52808
The following patch fixes PR52808 - the issue is as in the
duplicate_block fixme comment - if we are destroying a loop
by means of adding another entry we have to do that. Thus
tracer needs to cleanup the cfg after it finished (a good idea
anyway). And jump threading needs to tell cfg manipulation it
behaves well when threading a loop latch edge.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-04-03 Richard Guenther rguent...@suse.de
PR tree-optimization/52808
* tracer.c (tail_duplicate): Return whether we have duplicated
any block.
(tracer): If we have duplicated any block, cleanup the CFG.
* cfghooks.c (duplicate_block): If we duplicated a loop
header but not its loop, destroy the loop because it now has
multiple entries.
* tree-ssa-threadupdate.c (thread_through_loop_header): Tell
the cfg manipulation routines we are not creating a multiple
entry loop.
* gcc.dg/pr52808.c: New testcase.
Index: gcc/tracer.c
===
--- gcc/tracer.c(revision 186066)
+++ gcc/tracer.c(working copy)
@@ -59,7 +59,6 @@ static bool better_p (const_edge, const_
static edge find_best_successor (basic_block);
static edge find_best_predecessor (basic_block);
static int find_trace (basic_block, basic_block *);
-static void tail_duplicate (void);
/* Minimal outgoing edge probability considered for superblock formation. */
static int probability_cutoff;
@@ -224,7 +223,7 @@ find_trace (basic_block bb, basic_block
/* Look for basic blocks in frequency order, construct traces and tail
duplicate
if profitable. */
-static void
+static bool
tail_duplicate (void)
{
fibnode_t *blocks = XCNEWVEC (fibnode_t, last_basic_block);
@@ -236,6 +235,7 @@ tail_duplicate (void)
gcov_type cover_insns;
int max_dup_insns;
basic_block bb;
+ bool changed = false;
/* Create an oversized sbitmap to reduce the chance that we need to
resize it. */
@@ -332,6 +332,7 @@ tail_duplicate (void)
bb2-index, copy-index, copy-frequency);
bb2 = copy;
+ changed = true;
}
mark_bb_seen (bb2);
bb = bb2;
@@ -353,6 +354,8 @@ tail_duplicate (void)
free (trace);
free (counts);
fibheap_delete (heap);
+
+ return changed;
}
/* Main entry point to this file. */
@@ -360,6 +363,8 @@ tail_duplicate (void)
static unsigned int
tracer (void)
{
+ bool changed;
+
gcc_assert (current_ir_type () == IR_GIMPLE);
if (n_basic_blocks = NUM_FIXED_BLOCKS + 1)
@@ -370,15 +375,14 @@ tracer (void)
dump_flow_info (dump_file, dump_flags);
/* Trace formation is done on the fly inside tail_duplicate */
- tail_duplicate ();
+ changed = tail_duplicate ();
+ if (changed)
+free_dominance_info (CDI_DOMINATORS);
- /* FIXME: We really only need to do this when we know tail duplication
-has altered the CFG. */
- free_dominance_info (CDI_DOMINATORS);
if (dump_file)
dump_flow_info (dump_file, dump_flags);
- return 0;
+ return changed ? TODO_cleanup_cfg : 0;
}
static bool
Index: gcc/cfghooks.c
===
--- gcc/cfghooks.c (revision 186066)
+++ gcc/cfghooks.c (working copy)
@@ -1009,18 +1009,28 @@ duplicate_block (basic_block bb, edge e,
{
struct loop *cloop = bb-loop_father;
struct loop *copy = get_loop_copy (cloop);
- add_bb_to_loop (new_bb, copy ? copy : cloop);
- /* If we copied the loop latch block but not the loop, adjust
-loop state.
-??? If we copied the loop header block but not the loop
-we might either have created a loop copy or a loop with
-multiple entries. In both cases we probably have to
-ditch the loops and arrange for a fixup. */
+ /* If we copied the loop header block but not the loop
+we have created a loop with multiple entries. Ditch the loop,
+add the new block to the outer loop and arrange for a fixup. */
if (!copy
- cloop-latch == bb)
+ cloop-header == bb)
{
+ add_bb_to_loop (new_bb, loop_outer (cloop));
+ cloop-header = NULL;
cloop-latch = NULL;
- loops_state_set (LOOPS_MAY_HAVE_MULTIPLE_LATCHES);
+ loops_state_set (LOOPS_NEED_FIXUP);
+ }
+ else
+ {
+ add_bb_to_loop (new_bb, copy ? copy : cloop);
+ /* If we copied the loop latch block but not the loop, adjust
+loop state. */
+ if (!copy
+ cloop-latch == bb)
+ {
+ cloop-latch = NULL;
+ loops_state_set (LOOPS_MAY_HAVE_MULTIPLE_LATCHES);
+ }
}
}
Index: gcc/testsuite/gcc.dg/pr52808.c
===
---
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
On Tue, 3 Apr 2012, Eric Botcazou wrote: For the case in question offset is (D.2640_7 + -1) * 20 + 16. I wonder why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added to bitpos by get_inner_reference (that is what get_bit_range assumes ...). DECL_FIELD_OFFSET is added to offset and DECL_FIELD_BIT_OFFSET to bitpos. So, how would you make sure this works? Match the fact that get_inner_reference does _not_ add DECL_FIELD_OFFSET to bitpos, and, if DECL_FIELD_OFFSET is an INTEGER_CST simply subtract that from offset and add it to bitpos? I suppose that would work. Yes, but the amount is simply the negative bitstart (which is a multiple of BITS_PER_UNIT). This is the same kind of adjustment now done at the end of get_inner_reference to avoid negative bit positions there too. Though doing that in get_inner_reference for DECL_BIT_FIELD_TYPE fields may make sense as well. That would be more complicated, as we would need to split the offset into variable and fixed part. Tentative patch attached, regtested for Ada on x86 and x86-64. I'll do a full testing cycle if it is approved. Yes, the patch is ok. Thanks, Richard. * expr.c (get_bit_range): Add OFFSET parameter and adjust BITPOS. Change type of BITOFFSET to signed. Make sure the lower bound of the computed range is non-negative by adjusting OFFSET and BITPOS. (expand_assignment): Adjust call to get_bit_range.
[Patch, Fortran] PR52729 - fix module-proc decl access for BLOCK/SELECT TYPE
A rather obvious patch.
The module procedure had the FL_PROCEDURE due its use (CALL sub or
func()) - but no interface and no type. Thus, there was no attempt to
search for the symbol in the parent namespace, which causes failures.
Build and tested on x86-84-linux.
OK for the trunk?
Tobias
PS: I lost track. Are there patches which still have to be reviewed?
2012-04-03 Tobias Burnus bur...@net-b.de
PR fortran/52729
* resolve.c (resolve_symbol): Fix searching for parent NS decl.
2012-04-03 Tobias Burnus bur...@net-b.de
PR fortran/52729
* gfortran.dg/block_11.f90: New.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index b63a0c6..910d322 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12246,7 +12277,10 @@ resolve_symbol (gfc_symbol *sym)
symbol_attribute class_attr;
gfc_array_spec *as;
- if (sym-attr.flavor == FL_UNKNOWN)
+ if (sym-attr.flavor == FL_UNKNOWN
+ || (sym-attr.flavor == FL_PROCEDURE !sym-attr.intrinsic
+ !sym-attr.generic !sym-attr.external
+ sym-attr.if_source == IFSRC_UNKNOWN))
{
/* If we find that a flavorless symbol is an interface in one of the
@@ -12270,9 +12303,10 @@ resolve_symbol (gfc_symbol *sym)
/* Otherwise give it a flavor according to such attributes as
it has. */
- if (sym-attr.external == 0 sym-attr.intrinsic == 0)
+ if (sym-attr.flavor == FL_UNKNOWN sym-attr.external == 0
+ sym-attr.intrinsic == 0)
sym-attr.flavor = FL_VARIABLE;
- else
+ else if (sym-attr.flavor == FL_UNKNOWN)
{
sym-attr.flavor = FL_PROCEDURE;
if (sym-attr.dimension)
--- /dev/null 2012-03-22 21:06:43.387787737 +0100
+++ gcc/gcc/testsuite/gfortran.dg/block_11.f90 2012-04-03 10:52:27.0 +0200
@@ -0,0 +1,68 @@
+! { dg-do link }
+!
+! PR fortran/52729
+!
+! Based on a contribution of Andrew Benson
+!
+module testMod
+ type testType
+ end type testType
+contains
+ subroutine testSub()
+implicit none
+procedure(double precision ), pointer :: r
+class(testType ), pointer :: testObject
+double precision :: testVal
+
+! Failed as testFunc was BT_UNKNOWN
+select type (testObject)
+class is (testType)
+ testVal=testFunc()
+ r = testFunc
+end select
+return
+ end subroutine testSub
+
+ double precision function testFunc()
+implicit none
+return
+ end function testFunc
+end module testMod
+
+module testMod2
+ implicit none
+contains
+ subroutine testSub()
+procedure(double precision ), pointer :: r
+double precision :: testVal
+! Failed as testFunc was BT_UNKNOWN
+block
+ r = testFunc
+ testVal=testFunc()
+end block
+ end subroutine testSub
+
+ double precision function testFunc()
+ end function testFunc
+end module testMod2
+
+module m3
+ implicit none
+contains
+ subroutine my_test()
+procedure(), pointer :: ptr
+! Before the fix, one had the link error
+! undefined reference to `sub.1909'
+block
+ ptr = sub
+ call sub()
+end block
+ end subroutine my_test
+ subroutine sub(a)
+integer, optional :: a
+ end subroutine sub
+end module m3
+
+end
+
+! { dg-final { cleanup-modules testmod testmod2 m3 } }
[Patch, Fortran]: Fix libgfortran.h error for VMS
Hi, unfortunately VMS doesn't like to include complex.h after math.h, while the reverse is allowed. The reason is that math.h (unless ANSI_C_SOURCE is defined but that hides many math functions) declares cabs/cabsf/cabsl for a structure representing a complex number, which is not compatible with the declarations in complex.h The simplest path is simply to reverse the include order in libgfortran.h. I know that this is somewhat VMS specific, and I welcome better ideas. Tested by building gfortran for x86_64-darwin and ia64-hp-openvms. Ok for trunk ? Tristan. libgfortran/ 2012-04-03 Tristan Gingold ging...@adacore.com * libgfortran.h: Include complex.h before math.h diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h index be5f133..ea20e14 100644 --- a/libgfortran/libgfortran.h +++ b/libgfortran/libgfortran.h @@ -42,11 +42,19 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #include config.h #include stdio.h -#include math.h #include stddef.h #include float.h #include stdarg.h +#if HAVE_COMPLEX_H +/* Must appear before math.h on VMS systems. */ +# include complex.h +#else +#define complex __complex__ +#endif + +#include math.h + /* If we're support quad-precision floating-point type, include the header to our support library. */ #ifdef HAVE_FLOAT128 @@ -66,12 +74,6 @@ extern long double __strtold (const char *, char **); #define gfc_strtold strtold #endif -#if HAVE_COMPLEX_H -# include complex.h -#else -#define complex __complex__ -#endif - #include ../gcc/fortran/libgfortran.h #include c99_protos.h
Re: [google] Fix PR52822 in google's gcc-4.6 branch (issue5975063)
On 4/2/12 6:25 PM, Jeffrey Yasskin wrote: 2012-04-02 Jeffrey Yasskinjyass...@google.com * libstdc++-v3/include/bits/stl_algo.h (__stable_partition_adaptive): Avoid move-assigning an object to itself by explicitly testing for identity. * libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc: Test vectors, which have a destructive self-move-assignment. * libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc (test02): Test with rvalstruct, which explicitly checks self-move-assignment. This is OK for google/gcc-4_6, if trunk review requests changes, you can backport them later. Diego.
Fw: [PATCH] Allow printing of escaped curly braces in assembler directives with operands
Hi,
ping?
--
Siddhesh
Begin forwarded message:
Date: Tue, 27 Mar 2012 10:51:37 +0530
From: Siddhesh Poyarekar siddh...@redhat.com
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Allow printing of escaped curly braces in assembler
directives with operands
Hi,
An assembler directive with an operand is filtered through
output_asm_insn (or asm_fprintf for gcc internal asm() directives) to
expand the operand values in the assembler as well as to choose
dialects if present. This patch is concerned primarily with the
dialects, since their syntax prevent inclusion of assembler strings
with curly braces, causing them to be interpreted as dialects.
The attached patch allows printing of curly braces in assembler by
preceding them with a \\. So to print the following code into assembler:
.pushsection .foo; .asciz div { width : 50%% | height=10px }; .long
42; .popsection
The following code needs to be used with this patch:
void f()
{
asm ( .pushsection \.foo\; .asciz \div \\{ width : 50%% |
height=10px \\} \; .long %c0; .popsection : : i(42) ); }
The other option to \\ (since it doesn't look as clean) was to use %
as an escape character, but I was not sure if that is a better looking
option or a worse looking one. I don't mind resubmitting the patch to
use %{ and %} to print curly braces if that is acceptable.
It is still possible to print curly braces in asm string literals
without operands since they do not undergo any transformation.
The patch does not introduce any regressions. I have tested this with
x86_64 and i686 and it works well with both of them.
Regards,
Siddhesh
gcc/ChangeLog:
2012-03-27 Siddhesh Poyarekar siddh...@redhat.com
* final.c (output_asm_insn, asm_fprintf): Print curly braces if
preceded by an escaped backslash (\\).
testsuite/ChangeLog:
2012-03-27 Siddhesh Poyarekar siddh...@redhat.com
* gcc.dg/asm-braces.c: New test case.
diff --git a/gcc/final.c b/gcc/final.c
index 718caf1..2393c0f 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -3444,6 +3444,12 @@ output_asm_insn (const char *templ, rtx *operands)
output_operand_lossage (invalid %%-code);
break;
+ /* Escaped braces. Print them as is. */
+ case '\\':
+if (*p == '{' || *p == '}')
+ c = *p++;
+/* FALLTHROUGH */
+
default:
putc (c, asm_out_file);
}
@@ -3955,6 +3961,12 @@ asm_fprintf (FILE *file, const char *p, ...)
}
break;
+ /* Escaped braces. Print them as is. */
+ case '\\':
+if (*p == '{' || *p == '}')
+ c = *p++;
+/* FALLTHROUGH */
+
default:
putc (c, file);
}
diff --git a/gcc/testsuite/gcc.dg/asm-braces.c b/gcc/testsuite/gcc.dg/asm-braces.c
new file mode 100644
index 000..4f428c8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asm-braces.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options } */
+
+void f()
+{
+ asm ( .pushsection \.foo\; .asciz \div \\{ width : 50%% | height = 10px \\} \; .long %c0; .popsection : : i(42) );
+}
+
+/* { dg-final { scan-assembler div { width : 50%% | height = 10px } } } */
--
1.7.7.6
Re: [C Patch]: pr52543
Kenneth Zadeck zad...@naturalbridge.com writes:
+#define FORCE_LOWERING
Don't think you meant to keep this.
-/* Return whether X is a simple object which we can take a word_mode
- subreg of. */
+static struct {
+
+ /* This pass can transform 4 different operations: move, ashift,
+ lshiftrt, and zero_extend. There is a boolean vector for move
+ splitting that is indexed by mode and is true for each mode that is
+ to have its copies split. The other three operations are only done
+ for one mode so they are only controlled by a single boolean .*/
Comment out of date.
+ bool move_modes_to_split[MAX_MACHINE_MODE];
+
+ /* Other splitting operations to be done on the this platform. */
+ bool splitting_ashift[MAX_BITS_PER_WORD];
+ bool splitting_lshiftrt[MAX_BITS_PER_WORD];
+ bool splitting_zext;
+
+ bool something_to_do;
+
+ /* Precomputed cost values used to determine if lowering shift
+ operations is profitable. */
+ int word_mode_move_cost;
+ int move_zero_cost;
+} target_info;
This isn't right. The point is that there is supposed to be one instance
of this structure per target, along the lines of target_expmed.
Yes, it's clunky. Hopefully the move to C++ will allow a more elegant
approach.
+/* Return true if it is profitable to lower and shift by SHIFT_AMT.
+ CODE can be either ASHIFT or LSHIFTRT. */
+static bool
+profitable_shift_p (enum rtx_code code, int shift_amt)
+{
+ rtx trg = gen_rtx_REG (GET_MODE_WIDER_MODE (word_mode),
FIRST_PSEUDO_REGISTER);
+ rtx src = gen_rtx_REG (GET_MODE_WIDER_MODE (word_mode),
FIRST_PSEUDO_REGISTER + 1);
+ int wide_cost
+= insn_rtx_cost (gen_rtx_SET (VOIDmode, trg,
+ gen_rtx_fmt_ee (code, GET_MODE_WIDER_MODE
(word_mode),
+ src, GEN_INT (shift_amt))),
+ true);
Lines still too long. (You really need an 80-char-wide editor.
It's the future.)
More importantly, I'd not noticed last time that you're glossing
over the size/speed choice. That's important, and in general
is made on a per-bb basis. So I think we need to cache both
the size and speed costs.
+#ifdef FORCE_LOWERING
+ return true;
+#endif
+
+#ifdef LOG_COSTS
+ fprintf (stderr, shift code %d, shift amt %d, wide_cost %d\n,
+code, shift_amt, wide_cost);
+#endif
+ if (shift_amt == BITS_PER_WORD)
+return wide_cost
+ = target_info.word_mode_move_cost + target_info.move_zero_cost;
+ else
+{
+ int narrow_cost;
+
+ trg = gen_rtx_REG (word_mode, FIRST_PSEUDO_REGISTER);
+ src = gen_rtx_REG (word_mode, FIRST_PSEUDO_REGISTER + 1);
+ narrow_cost
+ = insn_rtx_cost (gen_rtx_SET
+ (VOIDmode, trg,
+ gen_rtx_fmt_ee (code, word_mode,
+ src,
+ GEN_INT (shift_amt - BITS_PER_WORD))),
+true);
+
+#ifdef LOG_COSTS
+ fprintf (stderr, narrow_cost %d\n, narrow_cost);
+#endif
+ return wide_cost narrow_cost + target_info.move_zero_cost;
Should be =.
I think it'd be better to only create the rtx once and simply replace
the shift amount for each test.
+/* Initialize pass once per execution. This envolves determining
once per target
+ which operations on the machine are profitable. If none are found,
+ then the pass just returns when called. */
+
+void
+init_lower_subreg (void)
+{
+ rtx trg = gen_rtx_REG (word_mode, FIRST_PSEUDO_REGISTER);
+ rtx pat;
+ unsigned int i;
+ int factor;
+
+ memset (target_info, 0, sizeof target_info);
+
+ target_info.word_mode_move_cost = compute_move_cost (word_mode);
+ target_info.move_zero_cost
+= insn_rtx_cost (gen_rtx_SET (VOIDmode, trg,
+ CONST0_RTX (word_mode)), true);
+
+#ifdef LOG_COSTS
+ fprintf (stderr, word mode move cost %d\n,
target_info.word_mode_move_cost);
+ fprintf (stderr, move 0 cost %d\n, target_info.move_zero_cost);
+#endif
+ for (i = 0; i MAX_MACHINE_MODE; i++)
+{
+ int t;
+ factor = GET_MODE_SIZE (i) / UNITS_PER_WORD;
+
+ if (factor = 1)
+ continue;
+
+ t = compute_move_cost ((enum machine_mode) i);
+
+#ifdef LOG_COSTS
+ fprintf (stderr, mode %s, move cost %d, factor %d\n,
+mode_name[i], t, factor);
+#endif
+ if (t = target_info.word_mode_move_cost * factor)
+ {
+ target_info.move_modes_to_split[i] = true;
+ target_info.something_to_do = true;
+ }
+#ifdef FORCE_LOWERING
+ target_info.move_modes_to_split[i] = true;
+ target_info.something_to_do = true;
+#endif
+}
The code is a bit inconsistent about whether the costs are calculated
when FORCE_LOWERING is true. Here you calculate anyway, but in the
shift case you skip.
+
+ /* For the moves and shifts, the only case
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Tue, Apr 03, 2012 at 03:29:06PM +1200, Michael Hope wrote:
On 3 April 2012 09:06, dann frazier dann.fraz...@canonical.com wrote:
On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
On 29/03/12 20:34, dann frazier wrote:
This is an updated version of a patch Debian and Ubuntu are using to
use an alternate linker path for hardfloat binaries. The difference
with this one is that it covers the case where no float flag
was passed in, defaulting to the softfloat path.
Hi Dann. The change should be in the EABI specific linux-eabi.h
instead of the shared/OABI linux-elf.h. It breaks support for uClibc
and Bionic by always using the GLIBC loader in hard float mode. The
final line in the spec is missing a '=hard' and always adds
/lib/ld-linux.so.3.
How about:
2012-04-03 Michael Hope michael.h...@linaro.org
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float loader.
Nice, thanks Michael. I'd looked at doing something similar, but I
wasn't sure that defining GLIBC_DYNAMIC_LINKER to a spec macro would
work :)
-dann
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..8498472 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,12 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT
/lib/arm-linux-gnueabihf/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER \
+ %{mhard-float: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{!mfloat-abi=hard:%{!mhard-float: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }}
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
which works for the following test cases:
gcc -mhard-float foo.c = /lib/arm-linux-gnueabihf/ld-linux.so.3
gcc -mfloat-abi=hard foo.c = /lib/arm-linux-gnueabihf/ld-linux.so.3
gcc -msoft-float foo.c = /lib/ld-linux.so.3
gcc -mfloat-abi=softfp foo.c = /lib/ld-linux.so.3
gcc -mbionic = /system/bin/linker
gcc -mbionic -mhard-float = /system/bin/linker
gcc -muclibc = /lib/ld-uClibc.so.0
gcc -muclibc -mhard-float = /lib/ld-uClibc.so.0
-- Michael
Re: [RS6000] Stack tie fix.
Hello Alan,
Thanks a lot for following up on this one. Coincidentally, I was just
about to submit the alternate approach we had discussed about, after
David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html.
We have experienced with it for a while on our gcc-4.5 series of
compilers and we are working on a transition to gcc 4.7.
This is of course a much heavier hammer so it would be nice if we can
indeed have a subtler way out :-)
Olivier
On Apr 3, 2012, at 10:40 , Alan Modra wrote:
This patch merges the rs6000 stack_tie and frame_tie rtl, so that we
now should use a tie insn that mentions all base regs involved in
register saves and restores. That should avoid any alias analysis
problems eg. http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01156.html.
I chose to put the regs of interest on the destination of the fake
set, rather than in the source as is currently done, because I figure
that relying on the compiler to not reorder reads is fragile. Here's
an example of the new stack tie:
(set (mem:BLK (unspec:SI [(reg:SI 1) (reg:SI 12)] UNSPEC_TIE))
(const_int 0))
Some notes:
- I tried putting the mem on both source and destination of the set,
but that runs afoul of rtl dead code elimination.
- The rs6000_emit_epilogue places that called gen_frame_tie and
gen_stack_tie both used alias set 0 mems. I believe this was
unnecessarily restrictive.
- CODE_FOR_stack_tie is mentioned in rs6000.c but not
CODE_FOR_frame_tie. Removing frame_tie fixes this sched bug too.
Bootstrapped and regression tested powerpc-linux with usual -O2
BOOT_CFLAGS and also -Os, and testcases from pr44199, pr30282, pr52828,
the url above and http://gcc.gnu.org/ml/gcc/2011-03/msg00123.html
examined for sanity. OK to apply?
PR target/52828
* config/rs6000/rs6000.c (rs6000_emit_stack_tie): Rewrite with
tie regs on destination of set. Delete forward declaration.
(rs6000_emit_stack_reset): Update rs6000_emit_stack_tie calls.
(rs6000_emit_prologue): Likewise.
(rs6000_emit_epilogue): Likewise. Use in place of gen_frame_tie
and gen_stack_tie.
* config/rs6000/predicates.md (tie_operand): New.
* config/rs6000/rs6000.md (restore_stack_block): Generate new
stack tie rtl.
(restore_stack_nonlocal): Likewise.
(stack_tie): Update.
(frame_tie): Delete.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c(revision 185830)
+++ gcc/config/rs6000/rs6000.c(working copy)
@@ -925,7 +925,6 @@ static const char *rs6000_invalid_within_doloop (c
static bool rs6000_legitimate_address_p (enum machine_mode, rtx, bool);
static bool rs6000_debug_legitimate_address_p (enum machine_mode, rtx, bool);
static rtx rs6000_generate_compare (rtx, enum machine_mode);
-static void rs6000_emit_stack_tie (void);
static bool spe_func_has_64bit_regs_p (void);
static rtx gen_frame_mem_offset (enum machine_mode, rtx, int);
static unsigned rs6000_hash_constant (rtx);
@@ -18517,12 +18516,28 @@ rs6000_aix_asm_output_dwarf_table_ref (char * fram
and the change to the stack pointer. */
static void
-rs6000_emit_stack_tie (void)
+rs6000_emit_stack_tie (rtx fp, bool hard_frame_needed)
{
- rtx mem = gen_frame_mem (BLKmode,
-gen_rtx_REG (Pmode, STACK_POINTER_REGNUM));
+ rtx u;
+ rtvec p;
+ int i;
- emit_insn (gen_stack_tie (mem));
+ if (REGNO (fp) == STACK_POINTER_REGNUM
+ || (hard_frame_needed
+REGNO (fp) == HARD_FRAME_POINTER_REGNUM))
+fp = NULL_RTX;
+
+ p = rtvec_alloc (1 + hard_frame_needed + (fp != NULL_RTX));
+
+ i = 0;
+ RTVEC_ELT (p, i++) = gen_rtx_REG (Pmode, STACK_POINTER_REGNUM);
+ if (hard_frame_needed)
+RTVEC_ELT (p, i++) = gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM);
+ if (fp != NULL_RTX)
+RTVEC_ELT (p, i++) = fp;
+ u = gen_rtx_UNSPEC (Pmode, p, UNSPEC_TIE);
+
+ emit_insn (gen_stack_tie (gen_frame_mem (BLKmode, u)));
}
/* Emit the correct code for allocating stack space, as insns.
@@ -19142,7 +19157,7 @@ rs6000_emit_stack_reset (rs6000_stack_t *info,
|| (TARGET_SPE_ABI
info-spe_64bit_regs_used != 0
info-first_gp_reg_save != 32))
-rs6000_emit_stack_tie ();
+rs6000_emit_stack_tie (frame_reg_rtx, frame_pointer_needed);
if (frame_reg_rtx != sp_reg_rtx)
{
@@ -19362,7 +19377,7 @@ rs6000_emit_prologue (void)
}
rs6000_emit_allocate_stack (info-total_size, copy_reg);
if (frame_reg_rtx != sp_reg_rtx)
- rs6000_emit_stack_tie ();
+ rs6000_emit_stack_tie (frame_reg_rtx, false);
}
/* Handle world saves specially here. */
@@ -19866,7 +19881,7 @@ rs6000_emit_prologue (void)
sp_offset = info-total_size;
rs6000_emit_allocate_stack (info-total_size, copy_reg);
if (frame_reg_rtx != sp_reg_rtx)
- rs6000_emit_stack_tie ();
+
PING: PATCH: Backport x32 support to libtool
On Thu, Mar 29, 2012 at 7:34 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Mar 3, 2012 at 9:54 AM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
This patch backports x32 support to libtool:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=88992fe6771ec3258bde1b03314ce579da0ac2d5
OK to install?
Thanks.
H.J.
---
ommit 0d8c092cac25c3bce5dbfc1981b84df91b3f6086
Author: H.J. Lu hjl.to...@gmail.com
Date: Mon Dec 12 13:03:14 2011 -0800
Add x32 support to libtool.m4
2011-12-12 H.J. Lu hongjiu...@intel.com
* libtool.m4 (_LT_ENABLE_LOCK): Support x32.
diff --git a/ChangeLog.x32 b/ChangeLog.x32
new file mode 100644
index 000..b6e01ee
--- /dev/null
+++ b/ChangeLog.x32
@@ -0,0 +1,3 @@
+2011-12-12 H.J. Lu hongjiu...@intel.com
+
+ * libtool.m4 (_LT_ENABLE_LOCK): Support x32.
diff --git a/libtool.m4 b/libtool.m4
index 67321a7..a7f99ac 100644
--- a/libtool.m4
+++ b/libtool.m4
@@ -1232,7 +1232,14 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
LD=${LD-ld} -m elf_i386_fbsd
;;
x86_64-*linux*)
- LD=${LD-ld} -m elf_i386
+ case `/usr/bin/file conftest.o` in
+ *x86-64*)
+ LD=${LD-ld} -m elf32_x86_64
+ ;;
+ *)
+ LD=${LD-ld} -m elf_i386
+ ;;
+ esac
;;
ppc64-*linux*|powerpc64-*linux*)
LD=${LD-ld} -m elf32ppclinux
Hi Ralf,
Can you review this patch?
Thanks.
PING.
--
H.J.
Re: [RS6000] Stack tie fix.
On Apr 3, 2012, at 16:34 , Olivier Hainque wrote: Thanks a lot for following up on this one. Coincidentally, I was just about to submit the alternate approach we had discussed about, after David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html. This is of course a much heavier hammer so it would be nice if we can indeed have a subtler way out :-) I realized that this last sentence is ambiguous ... To clarify: the heavier approach is the one I was about to submit (minor variation of Joseph's proposal in the thread just referenced), and the subtler way out is the one you are proposing here. Olivier
Re: [PATCH, i386, Android] -mandroid support for i386 target
On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich enkovich@gmail.com 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 compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional -m32 -mandroid multilib. I.e., the toolchain will have three multilibs in total: -m32 (default), -m64 and -m32 -mandroid. I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? I think I see your point. And it seems to make all this work I'll also have to rename i386/gnu-user.h into i386/gnu-user32.h and create i386/gnu-user.h with common definitions to be included by gnu-user[32|64].h. Otherwise I wont be able to use some definitions (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in linux64.h. Right? 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 headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. Thanks, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics Hi, I prepared version with common linux.h and gnu-user.h. Does it look OK? Bootstrapped and checked on linux-x86_64. There are so many duplicates in gnu-user64.h and gnu-user32.h. Please move all of them to gnu-user.h. Thanks. -- H.J.
Re: [C Patch]: pr52543
Richard,
thanks, for doing the changes.In particular, i did not really
understand how the target stuff was supposed to work.
I have one issue with the changes that you made.
I had actually decided that the speed/size decision was not relevant to
this patch.The problem is that since this is a global optimization
which propagates the info across the entire web of moves, you really
want/need to use the same cost metric everywhere. (of course, making
the speed/size decision on the global optimization level would be fine;
my issue is with the choice being at the bb level.)So now you are
going to have some moves in a web saying yes while others saying no.
The ones that say no will dominate. It is unlikely you will get what
you want (the important nodes really running fast) out of this, assuming
you have a target where the decision could go either way.
Aside from this, everything looks very good.
Kenny
On 04/03/2012 09:53 AM, Richard Sandiford wrote:
Index: gcc/lower-subreg.h
===
--- /dev/null 2012-01-03 10:09:21.739576622 +
+++ gcc/lower-subreg.h 2012-04-03 14:38:35.397879009 +0100
@@ -0,0 +1,59 @@
+/* Target-dependent costs for lower-subreg.c.
+ Copyright (C) 2012 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option; any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+http://www.gnu.org/licenses/. */
+
+#ifndef LOWER_SUBREG_H
+#define LOWER_SUBREG_H 1
+
+/* Information about whether, and where, lower-subreg should be applied. */
+struct lower_subreg_choices {
+ /* A boolean vector for move splitting that is indexed by mode and is
+ true for each mode that is to have its copies split. */
+ bool move_modes_to_split[MAX_MACHINE_MODE];
+
+ /* True if zero-extensions from word_mode to twice_word_mode should
+ be split. */
+ bool splitting_zext;
+
+ /* Index X is true if twice_word_mode shifts by X + BITS_PER_WORD
+ should be split. */
+ bool splitting_ashift[MAX_BITS_PER_WORD];
+ bool splitting_lshiftrt[MAX_BITS_PER_WORD];
+
+ /* True if there is at least one mode that is worth splitting. */
+ bool something_to_do;
+};
+
+/* Target-specific information for the subreg lowering pass. */
+struct target_lower_subreg {
+ /* An integer mode that is twice as wide as word_mode. */
+ enum machine_mode x_twice_word_mode;
+
+ /* What we have decided to do when optimizing for size (index 0)
+ and speed (index 1). */
+ struct lower_subreg_choices x_choices[2];
+};
+
+extern struct target_lower_subreg default_target_lower_subreg;
+#if SWITCHABLE_TARGET
+extern struct target_lower_subreg *this_target_lower_subreg;
+#else
+#define this_target_lower_subreg (default_target_lower_subreg)
+#endif
+
+#endif
Index: gcc/target-globals.h
===
--- gcc/target-globals.h2010-07-29 13:10:13.0 +0100
+++ gcc/target-globals.h2012-04-02 12:07:41.323231941 +0100
@@ -35,6 +35,7 @@ #define TARGET_GLOBALS_H 1
extern struct target_builtins *this_target_builtins;
extern struct target_gcse *this_target_gcse;
extern struct target_bb_reorder *this_target_bb_reorder;
+extern struct target_lower_subreg *this_target_lower_subreg;
struct GTY(()) target_globals {
struct target_flag_state *GTY((skip)) flag_state;
@@ -51,6 +52,7 @@ struct GTY(()) target_globals {
struct target_builtins *GTY((skip)) builtins;
struct target_gcse *GTY((skip)) gcse;
struct target_bb_reorder *GTY((skip)) bb_reorder;
+ struct target_lower_subreg *GTY((skip)) lower_subreg;
};
extern struct target_globals default_target_globals;
@@ -74,6 +76,7 @@ restore_target_globals (struct target_gl
this_target_builtins = g-builtins;
this_target_gcse = g-gcse;
this_target_bb_reorder = g-bb_reorder;
+ this_target_lower_subreg = g-lower_subreg;
}
#endif
Index: gcc/target-globals.c
===
--- gcc/target-globals.c2011-03-18 13:09:16.0 +
+++ gcc/target-globals.c2012-04-02 12:06:44.026273230 +0100
@@ -40,6 +40,7 @@ Software Foundation; either version 3, o
#include builtins.h
#include gcse.h
#include bb-reorder.h
+#include lower-subreg.h
#if SWITCHABLE_TARGET
struct target_globals default_target_globals = {
@@ -56,7 +57,8 @@ struct target_globals default_target_glo
default_target_ira_int,
Re: [PATCH H8300] Added -mno-exr option in case of function with monitor attribute
Hello Jeff, Thank you for reviewing the patch. First, do you have an assignment on file with the FSF We do have a corporate assignment for KPIT. It was signed by Bradley Kuhn from FSF side and Dhananjay Deshpande from KPIT side, during April 2003. In a mail, Peter Brown from FSF has mentioned ticket number #22417 which was associated with this corporate assignment. However, we do not have any assignment for individuals here. Please let me know whether we need to get it done for individuals as well. My recollection was -mint32 was supported on the original H8/300; is there something in particular that makes you want to issue an error for that case? My assumption was based on t-h8300 file. In this file, combination of h8300 and int32 is not considered for MULTILIB_OPTIONS. Did I misinterpret it? In that case I will remove the respective hunk from the patch and will repost it. In h8300.opt, rather than say Push exr on stack, would it make more sense to say [Do not] Push extended registers on stack in monitor functions? Thank you for this suggestion. I have made this change. Please find the updated patch attached here. Thanks and Regards, Sandeep Kumar Singh, KPIT Cummins InfoSystems Ltd. Pune, India patch-EXR.patch Description: patch-EXR.patch ChangeLog.patch Description: ChangeLog.patch
Re: [Patch, Fortran]: Fix libgfortran.h error for VMS
On 04/03/2012 02:42 PM, Tristan Gingold wrote: The simplest path is simply to reverse the include order in libgfortran.h. I know that this is somewhat VMS specific, and I welcome better ideas. Well, changing the order is not that bad than one has to try hard to find a better solution. (Unless, it fails on other systems with the new order.) Tested by building gfortran for x86_64-darwin and ia64-hp-openvms. OK. Thanks for the patch. Tobias
[wwwdocs] Buildstat update for 4.4
Latest results for 4.4.x -tgc Testresults for 4.4.7: powerpc-apple-darwin8.11.0 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/buildstat.html,v retrieving revision 1.25 diff -u -r1.25 buildstat.html --- buildstat.html 21 Aug 2011 13:22:56 - 1.25 +++ buildstat.html 3 Apr 2012 16:06:23 - @@ -344,6 +344,7 @@ tdpowerpc-apple-darwin8.11.0/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01661.html;4.4.7/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg00888.html;4.4.6/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg00887.html;4.4.4/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg03013.html;4.4.4/a
[wwwdocs] Buildstat update for 4.5
Latest results for 4.5.x -tgc Testresults for 4.5.3: i386-pc-solaris2.8 (2) Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/buildstat.html,v retrieving revision 1.13 diff -u -r1.13 buildstat.html --- buildstat.html 21 Aug 2011 18:23:07 - 1.13 +++ buildstat.html 3 Apr 2012 16:05:33 - @@ -129,6 +129,8 @@ tdi386-pc-solaris2.8/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01359.html;4.5.3/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01215.html;4.5.3/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00795.html;4.5.3/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01977.html;4.5.2/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01703.html;4.5.2/a,
[wwwdocs] Buildstat update for 4.6
Latest results for 4.6.x -tgc Testresults for 4.6.3: i386-pc-solaris2.8 (2) i386-pc-solaris2.10 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/buildstat.html,v retrieving revision 1.10 diff -u -r1.10 buildstat.html --- buildstat.html 18 Mar 2012 14:47:29 - 1.10 +++ buildstat.html 3 Apr 2012 16:04:48 - @@ -108,6 +108,8 @@ tdi386-pc-solaris2.8/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02401.html;4.6.3/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html;4.6.3/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01757.html;4.6.3/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html;4.6.2/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html;4.6.1/a, @@ -134,6 +136,7 @@ tdi386-pc-solaris2.10/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01817.html;4.6.3/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02468.html;4.6.2/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00327.html;4.6.1/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02738.html;4.6.0/a,
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 03/04/12 12:01, Jakub Jelinek wrote: On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote: If, so then there's only one way to sort out this mess. /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader The above scheme is a Debianism which no other distro is using. Jakub Not really, it's just a naming convention for where the config-specific dynamic loader lives. It doesn't affect where the remaining shared libraries live. The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros. This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad. R.
[wwwdocs] Buildstat update for 4.7
First round of results for 4.7.x -tgc Testresults for 4.7.0: alpha-dec-osf5.1b hppa2.0w-hp-hpux11.11 i386-apple-darwin10.8.0 i386-pc-solaris2.8 (2) i386-pc-solaris2.9 i386-pc-solaris2.10 i386-pc-solaris2.11 powerpc-apple-darwin8.11.0 sparc-sun-solaris2.8 (2) sparc-sun-solaris2.9 sparc-sun-solaris2.11 x86_64-apple-darwin10.8.0 x86_64-apple-darwin11.3.0 x86_64-unknown-linux-gnu (2) Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/buildstat.html,v retrieving revision 1.1 diff -u -r1.1 buildstat.html --- buildstat.html 2 Mar 2012 10:20:03 - 1.1 +++ buildstat.html 3 Apr 2012 16:04:41 - @@ -20,5 +20,122 @@ a href=http://gcc.gnu.org/install/finalinstall.html; Installing GCC: Final Installation/a./p +table + +tr +tdalpha-dec-osf5.1b/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02967.html;4.7.0/a +/td +/tr + +tdhppa2.0w-hp-hpux11.11/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg00080.html;4.7.0/a +/td +/tr + +tr +tdi386-apple-darwin10.8.0/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02742.html;4.7.0/a +/td +/tr + +tr +tdi386-pc-solaris2.8/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02998.html;4.7.0/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02619.html;4.7.0/a +/td +/tr + +tr +tdi386-pc-solaris2.9/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02618.html;4.7.0/a +/td +/tr + +tr +tdi386-pc-solaris2.10/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02526.html;4.7.0/a +/td +/tr + +tr +tdi386-pc-solaris2.11/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02519.html;4.7.0/a +/td +/tr + +tdpowerpc-apple-darwin8.11.0/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02890.html;4.7.0/a +/td +/tr + +tr +tdsparc-sun-solaris2.8/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02928.html;4.7.0/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02621.html;4.7.0/a +/td +/tr + +tr +tdsparc-sun-solaris2.9/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02620.html;4.7.0/a +/td +/tr + +tr +tdsparc-sun-solaris2.11/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02536.html;4.7.0/a +/td +/tr + +tr +tdx86_64-apple-darwin10.8.0/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02708.html;4.7.0/a +/td +/tr + +tr +tdx86_64-apple-darwin11.3.0/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02630.html;4.7.0/a +/td +/tr + +tr +tdx86_64-unknown-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02853.html;4.7.0/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02514.html;4.7.0/a +/td +/tr + +/table + /body /html
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 04/03/2012 05:09 PM, Richard Earnshaw wrote: On 03/04/12 12:01, Jakub Jelinek wrote: On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote: If, so then there's only one way to sort out this mess. /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader The above scheme is a Debianism which no other distro is using. Jakub Not really, it's just a naming convention for where the config-specific dynamic loader lives. It doesn't affect where the remaining shared libraries live. The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros. This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad. I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64. Andrew.
Re: [C Patch]: pr52543
Richard Sandiford rdsandif...@googlemail.com writes: What do you think? The patch looks OK to me with these changes, but I'd like to leave it for 48 hours to see if Ian has any comments. The patch looks fine to me. Thanks. Ian 2012-04-03 Kenneth Zadeck zad...@naturalbridge.com Richard Sandiford r.sandif...@uk.ibm.com * Makefile.in (lower-subreg.o, target-globals.o): Depend on lower-subreg.h. * lower-subreg.h: New file. * target-globals.h (this_target_lower_subreg): Declare. (target_globals): Add lower_subreg; (restore_target_globals): Restore this_target_lower_subreg. * target-globals.c: Include it. (default_target_globals): Add default_target_lower_subreg. (save_target_globals): Initialize target_lower_subreg. * rtl.h (init_lower_subreg): Added declaration. * toplev.c (backend_init_target): Call initializer for lower-subreg pass. * lower-subreg.c (LOG_COSTS, FORCE_LOWERING): New macros. (default_target_lower_subreg): New variable. (this_target_lower_subreg): Likewise. (twice_word_mode, choices): New macros. (shift_cost, compute_splitting_shift, compute_costs) (init_lower_subreg): New functions. (resolve_simple_move): Add speed_p argument. Check choices. (find_pseudo_copy): Don't check the mode size here. (resolve_simple_move): Assert the mode size. (find_decomposable_shift_zext): Add speed_p argument and return a bool. Check choices. (resolve_shift_zext): Add comment. (dump_shift_choices, dump_choices): New functions. (decompose_multiword_subregs): Dump list of profitable transformations. Add code to skip non profitable transformations. Update calls to simple_move and find_decomposable_shift_zext.
Re: [PATCH H8300] Added -mno-exr option in case of function with monitor attribute
On 04/03/2012 09:40 AM, Sandeep Kumar Singh wrote: First, do you have an assignment on file with the FSF We do have a corporate assignment for KPIT. Excellent. Thanks for verifying. My recollection was -mint32 was supported on the original H8/300; is there something in particular that makes you want to issue an error for that case? My assumption was based on t-h8300 file. In this file, combination of h8300 and int32 is not considered for MULTILIB_OPTIONS. Did I misinterpret it? In that case I will remove the respective hunk from the patch and will repost it. Hmm, my memory must be faulty... You're absolutely correct, based on the multilibs -mint32 isn't supported on the H8/300. [law@stumpy gcc]$ ./xgcc -B./ -print-multi-lib .; h8300h;@mh h8300s;@ms h8sx;@msx h8300h/normal;@mh@mn h8300h/int32;@mh@mint32 h8300h/normal/int32;@mh@mn@mint32 h8300s/normal;@ms@mn h8300s/int32;@ms@mint32 h8300s/normal/int32;@ms@mn@mint32 h8sx/normal;@msx@mn h8sx/int32;@msx@mint32 h8sx/normal/int32;@msx@mn@mint32 In h8300.opt, rather than say Push exr on stack, would it make more sense to say [Do not] Push extended registers on stack in monitor functions? Thank you for this suggestion. I have made this change. Please find the updated patch attached here. I'll get it installed momentarily. Thanks, jeff
Re: [RS6000] Stack tie fix.
On Tue, Apr 3, 2012 at 10:55 AM, Olivier Hainque hain...@adacore.com wrote: On Apr 3, 2012, at 16:34 , Olivier Hainque wrote: Thanks a lot for following up on this one. Coincidentally, I was just about to submit the alternate approach we had discussed about, after David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html. This is of course a much heavier hammer so it would be nice if we can indeed have a subtler way out :-) To clarify: the heavier approach is the one I was about to submit (minor variation of Joseph's proposal in the thread just referenced), and the subtler way out is the one you are proposing here. We can give Alan's patch a try. I'm not sure if it is sufficient given the experience of IBM's XL compiler. I also would rather not use the heavier hammer, but I don't want to leave a latent bug. Thanks, David
Re: [PATCH] PR bootstrap/52623 Disable libquadmath on AIX
On Mon, Mar 26, 2012 at 7:40 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Fri, 23 Mar 2012, David Edelsohn wrote:
The build process of libquadmath sometimes encounters problems on AIX
due to multilib and LD_LIBRARY_PATH interfering with GCC's own library
dependencies. Libquadmath is not used on AIX, so this patch adds it
to noconfigdirs.
Please include this explanation in a comment on the powerpc-*-aix* |
rs6000-*-aix* case. Existing directory-disabling cases may be
uncommented, but new ones ought to have comments explaining the reason for
disabling the library.
Is the following okay?
Thanks, David
Index: configure.ac
===
--- configure.ac(revision 186108)
+++ configure.ac(working copy)
@@ -509,6 +509,15 @@
fi
fi
+# Disable libquadmath for some systems.
+case ${target} in
+ # libquadmath is unused on AIX and libquadmath build process use of
+ # LD_LIBRARY_PATH can break AIX bootstrap.
+ powerpc-*-aix* | rs6000-*-aix*)
+noconfigdirs=$noconfigdirs target-libquadmath
+;;
+esac
+
# Disable libssp for some systems.
case ${target} in
avr-*-*)
Re: rs6000 toc reference rtl again
On Tue, Mar 27, 2012 at 3:54 AM, Alan Modra amo...@gmail.com wrote: Now that we are back in stage1, I'd like to apply http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to toc reference rtl in order to properly specify r2 dependencies. More commentary in that url. I'm reposting the patch here since the old one no longer applies cleanly, and I've added some ENABLE_CHECKING code in rs6000_delegitimize_address. Bootstrapped and regression tested powerpc64-linux. OK for mainline? * cselib.c (preserve_only_constants): Remove HIGH rtx containing value references. * cprop.c (cprop_constant_p): Return false for HIGH rtx containing value references. * config/rs6000/predicates.md (input_operand): Match unspec. Remove redundant tests. * rs6000-protos.h (toc_relative_expr_p): Update prototype. * const/rs6000/rs6000.c (tocrel_base, tocrel_offset): Make const. (legitimate_constant_pool_address_p): Move TARGET_TOC test and register checks to.. (toc_relative_expr_p): ..here. Add strict param. Match new rtl generated by create_TOC_reference. (rs6000_delegitimize_address): Handle new rtl for toc refs. (rs6000_cannot_force_const_mem, rs6000_find_base_term): Likewise. (use_toc_relative_ref): New function, split out from.. (rs6000_emit_move): ..here. Remove redundant tests. (rs6000_legitimize_reload_address): Formatting. Remove redundant code. Use use_toc_relative_ref. (print_operand): Formatting, style. Adjust for toc changes. (print_operand_address): Likewise. (rs6000_output_addr_const_extra): Likewise. (create_TOC_reference): Put TOC_REGISTER in UNSPEC_TOCREL rather than a PLUS. Use this formulation for both high and low part of -mcmodel=medium/large toc reference too. * config/rs6000/rs6000.md (tls_gd, tls_gd_high): Similarly avoid a PLUS in high part of addresses here. (tls_ld, tls_ld_high, tls_got_dtprel, tls_got_dtprel_high): Likewise. (tls_got_tprel, tls_got_tprel_high, largetoc_high): Likewise. (largetoc_high, largetoc_low): Move earlier. Cope when no base reg available. Now that PPC bootstrap appears to be fixed, this patch is okay to apply. However, I cannot approve the cselib.c and cprop.c changes. Thanks, David
Re: [Patch, fortran] PR 49010/24518 MOD/MODULO fixes
PING**2 On Wed, Mar 21, 2012 at 23:45, Janne Blomqvist blomqvist.ja...@gmail.com wrote: PING On Wed, Mar 14, 2012 at 01:03, Janne Blomqvist blomqvist.ja...@gmail.com wrote: Hi, the attached patch implements a few fixes and cleanups for the MOD and MODULO intrinsics. - When the arguments are constant, use mpfr_fmod instead of the naive algorithms which are numerically unstable for large arguments. This extends the PR 24518 fix to constant arguments as well, and makes the compile-time evaluation match the runtime implementation which also uses fmod in the same manner. - Remove the old fallback path for the case builtin_fmod is not available, as the builtin is AFAICS always available. The patch does not per se fix the corner-case bug as reported in PR 49010, in fact it makes it worse in a way as with the patch the result if the arguments are parameters is the same as the runtime result (previously, the compile-time result was correct). But, I think we should leave it as it is. Due to the reasons above, we're not using the naive algorithms anyway, and IMHO -0.0 is quite a good approximation for +0.0 anyway. One might even argue that due to the numerical instability, specifying the naive algorithms is a bug in the standard. The patch adds notes to the documentation about the usage of fmod, so users interested in corner-case behavior can look up how that function is supposed to behave on their target. FWIW, AFAICS MPFR and glibc fmod conform to the behavior specified in C99 Annex F. Regtested on x86_64-unknown-linux-gnu, Ok for trunk? 2012-03-14 Janne Blomqvist j...@gcc.gnu.org PR fortran/49010 PR fortran/24518 * intrinsic.texi (MOD,MODULO): Mention usage of fmod instead of naive algorithm. * simplify.c (gfc_simplify_mod): Use mpfr_fmod. (gfc_simplify_modulo): Likewise. * trans-intrinsic.c (gfc_conv_intrinsic_mod): Remove fallback as builtin_fmod is always available. -- Janne Blomqvist -- Janne Blomqvist -- Janne Blomqvist
libgo patch committed: Fix testsuite on PPC
The libgo testsuite looks for functions that match a certain name. On
PPC functions are in the data segment, not the text segment. This patch
to the testsuite script makes the script look in the data segment for
functions on PPC. Bootstrapped and ran libgo testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch.
Ian
diff -r 5016046ebbfe libgo/Makefile.am
--- a/libgo/Makefile.am Fri Mar 30 15:30:22 2012 -0700
+++ b/libgo/Makefile.am Tue Apr 03 10:54:59 2012 -0700
@@ -1808,9 +1808,9 @@
prefix=`if test $(@D) = regexp; then echo regexp-test; else dirname $(@D); fi`; \
test $${prefix} != . || prefix=$(@D); \
if test $(use_dejagnu) = yes; then \
- $(SHELL) $(srcdir)/testsuite/gotest --dejagnu=yes --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --prefix=libgo_$${prefix} --pkgfiles=$(go_$(subst /,_,$(@D))_files) --testname=$(@D) $(GOTESTFLAGS); \
+ $(SHELL) $(srcdir)/testsuite/gotest --dejagnu=yes --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --prefix=libgo_$${prefix} --pkgfiles=$(go_$(subst /,_,$(@D))_files) --testname=$(@D) --goarch=$(GOARCH) $(GOTESTFLAGS); \
else \
- if $(SHELL) $(srcdir)/testsuite/gotest --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --prefix=libgo_$${prefix} --pkgfiles=$(go_$(subst /,_,$(@D))_files) $(GOTESTFLAGS) $@-testlog 21; then \
+ if $(SHELL) $(srcdir)/testsuite/gotest --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --prefix=libgo_$${prefix} --pkgfiles=$(go_$(subst /,_,$(@D))_files) --goarch=$(GOARCH) $(GOTESTFLAGS) $@-testlog 21; then \
echo PASS: $(@D) $@-testlog; \
echo PASS: $(@D); \
echo PASS: $(@D) $@-testsum; \
diff -r 5016046ebbfe libgo/testsuite/gotest
--- a/libgo/testsuite/gotest Fri Mar 30 15:30:22 2012 -0700
+++ b/libgo/testsuite/gotest Tue Apr 03 10:54:59 2012 -0700
@@ -32,6 +32,7 @@
keep=false
prefix=
dejagnu=no
+GOARCH=
timeout=240
testname=
trace=false
@@ -86,6 +87,15 @@
dejagnu=`echo $1 | sed -e 's/^--dejagnu=//'`
shift
;;
+ x--goarch)
+ GOARCH=$2
+ shift
+ shift
+ ;;
+ x--goarch=*)
+ GOARCH=`echo $1 | sed -e 's/^--goarch=//'`
+ shift
+ ;;
x--timeout)
timeout=$2
shift
@@ -326,13 +336,18 @@
}
{
+ text=T
+ case $GOARCH in
+ ppc*) text=D ;;
+ esac
+
# test functions are named TestFoo
# the grep -v eliminates methods and other special names
# that have multiple dots.
pattern='Test([^a-z].*)?'
# The -p option tells GNU nm not to sort.
# The -v option tells Solaris nm to sort by value.
- tests=$($NM -p -v _gotest_.o $xofile | egrep ' T .*\.'$pattern'$' | grep -v '\..*\..*\.' | fgrep -v '$' | sed 's/.* //' | sed 's/.*\.\(.*\.\)/\1/')
+ tests=$($NM -p -v _gotest_.o $xofile | egrep $text .*\.$pattern'$' | grep -v '\..*\..*\.' | fgrep -v '$' | sed 's/.* //' | sed 's/.*\.\(.*\.\)/\1/')
if [ x$tests = x ]; then
echo 'gotest: warning: no tests matching '$pattern in _gotest_.o $xofile 12
exit 2
Re: rs6000 toc reference rtl again
Alan Modra amo...@gmail.com writes: Now that we are back in stage1, I'd like to apply http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to toc reference rtl in order to properly specify r2 dependencies. More commentary in that url. I'm reposting the patch here since the old one no longer applies cleanly, and I've added some ENABLE_CHECKING code in rs6000_delegitimize_address. Sorry to be a pain, but I don't think HIGH is supposed contain regs either. Both HIGH and CONST are supposed to be true constants. It's fine to have a non-HIGH expression as the first operand to a LO_SUM though. Alpha and MIPS use this for small data, where the first LO_SUM operand is the small data pointer. It can also be an arbitrary rtx like a PLUS. Richard
Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)
If it's required for ABI compatibility why is this an attribute and not a target hook? The ABI uses a #pragma; after this is in I'll do a target-specific pragma handler to set the attribute. Plus, when I originally proposed the idea, I was told it was generic so make it an attribute ;-)
Re: [C Patch]: pr52543
Kenneth Zadeck zad...@naturalbridge.com writes: Richard, thanks, for doing the changes.In particular, i did not really understand how the target stuff was supposed to work. I have one issue with the changes that you made. I had actually decided that the speed/size decision was not relevant to this patch.The problem is that since this is a global optimization which propagates the info across the entire web of moves, you really want/need to use the same cost metric everywhere. (of course, making the speed/size decision on the global optimization level would be fine; my issue is with the choice being at the bb level.)So now you are going to have some moves in a web saying yes while others saying no. The ones that say no will dominate. It is unlikely you will get what you want (the important nodes really running fast) out of this, assuming you have a target where the decision could go either way. Yeah, I suppose that's true. The problem is that both ways are wrong really. If we just use the function-level speed setting, there'll be times where a cold-only web will be optimised as hot. But as you say, if we apply the bb-level setting, cold blocks can hold back the hot blocks. And I don't particularly relish the idea of trying to joust between the two. So yeah, applying it on a function-by-function basis is probably better. Does anyone else have any thoughts before I make that change? Richard
Re: [PATCH, i386, Android] -mandroid support for i386 target
On 4/04/2012, at 2:56 AM, H.J. Lu wrote: On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich enkovich@gmail.com 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 headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. Thanks, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics Hi, I prepared version with common linux.h and gnu-user.h. Does it look OK? Bootstrapped and checked on linux-x86_64. There are so many duplicates in gnu-user64.h and gnu-user32.h. Please move all of them to gnu-user.h. Ilya, Why i386/gnu-user.h had to change at all? It seems like you trying to clean up/simplify stuff in i386/gnu-user.h, but in this case it seems (a) not required for the main purpose of this submission, and (b) excessive. As a side note, if it were up to me, I would merge current i386/linux.h and i386/linux64.h into one file -- i386/linux.h -- instead of having similar definitions spread around. But that would be a clean up in itself, and would require a separate submission. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
libgo patch committed: Add some more networking constants
This libgo patch changes mksysinfo.sh to add some more networking
constants. This is really just a snapshot, there are more to come,
based on differences between gccgo and the master Go library.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 888f1f45a4aa libgo/configure.ac
--- a/libgo/configure.ac Tue Apr 03 10:56:09 2012 -0700
+++ b/libgo/configure.ac Tue Apr 03 12:33:57 2012 -0700
@@ -453,7 +453,7 @@
;;
esac
-AC_CHECK_HEADERS(sys/mman.h syscall.h sys/epoll.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h sys/prctl.h sys/mount.h sys/vfs.h sys/statfs.h sys/timex.h sys/sysinfo.h utime.h linux/reboot.h)
+AC_CHECK_HEADERS(sys/mman.h syscall.h sys/epoll.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h net/if_arp.h sys/prctl.h sys/mount.h sys/vfs.h sys/statfs.h sys/timex.h sys/sysinfo.h utime.h linux/reboot.h)
AC_CHECK_HEADERS([linux/filter.h linux/netlink.h linux/rtnetlink.h], [], [],
[#ifdef HAVE_SYS_SOCKET_H
diff -r 888f1f45a4aa libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Tue Apr 03 10:56:09 2012 -0700
+++ b/libgo/mksysinfo.sh Tue Apr 03 12:33:57 2012 -0700
@@ -94,6 +94,9 @@
#if defined(HAVE_NET_IF_H)
#include net/if.h
#endif
+#if defined(HAVE_NET_IF_ARP_H)
+#include net/if_arp.h
+#endif
#if defined(HAVE_SYS_MOUNT_H)
#include sys/mount.h
#endif
@@ -211,7 +214,7 @@
fi
# Networking constants.
-egrep '^const _(AF|SOCK|SOL|SO|IPPROTO|TCP|IP|IPV6)_' gen-sysinfo.go |
+egrep '^const _(AF|ARPHRD|SOCK|SOL|SO|IPPROTO|TCP|IP|IPV6)_' gen-sysinfo.go |
sed -e 's/^\(const \)_\([^= ]*\)\(.*\)$/\1\2 = _\2/' ${OUT}
grep '^const _SOMAXCONN' gen-sysinfo.go |
sed -e 's/^\(const \)_\(SOMAXCONN[^= ]*\)\(.*\)$/\1\2 = _\2/' \
@@ -710,6 +713,10 @@
# The routing message flags.
grep '^const _RTA' gen-sysinfo.go | \
sed -e 's/^\(const \)_\(RTA[^= ]*\)\(.*\)$/\1\2 = _\2/' ${OUT}
+grep '^const _RTF' gen-sysinfo.go | \
+sed -e 's/^\(const \)_\(RTF[^= ]*\)\(.*\)$/\1\2 = _\2/' ${OUT}
+grep '^const _RTCF' gen-sysinfo.go | \
+sed -e 's/^\(const \)_\(RTCF[^= ]*\)\(.*\)$/\1\2 = _\2/' ${OUT}
grep '^const _RTM' gen-sysinfo.go | \
sed -e 's/^\(const \)_\(RTM[^= ]*\)\(.*\)$/\1\2 = _\2/' ${OUT}
@@ -938,6 +945,10 @@
-e 's/_sock_filter/SockFilter/' \
${OUT}
+# The GNU/Linux filter flags.
+grep '^const _BPF_' gen-sysinfo.go | \
+ sed -e 's/^\(const \)_\(BPF_[^= ]*\)\(.*\)$/\1\2 = _\2/' ${OUT}
+
# The Solaris 11 Update 1 _zone_net_addr_t struct.
grep '^type _zone_net_addr_t ' gen-sysinfo.go | \
sed -e 's/_in6_addr/[16]byte/' \
PATCH: [x32] libitm failures on x32
Hi,
We need to use long long instead of long in gtm_jmpbuf for x86_64 since
long in x32 is 32bits. OK for trunk and 4.7 branch?
Thanks.
H.J.
---
2012-04-03 H.J. Lu hongjiu...@intel.com
PR libitm/52854
* config/x86/target.h (gtm_jmpbuf): Replace long with long long
for x86-64.
diff --git a/libitm/config/x86/target.h b/libitm/config/x86/target.h
index 1d81a47..5c7e6fb 100644
--- a/libitm/config/x86/target.h
+++ b/libitm/config/x86/target.h
@@ -29,13 +29,13 @@ namespace GTM HIDDEN {
typedef struct gtm_jmpbuf
{
void *cfa;
- unsigned long rbx;
- unsigned long rbp;
- unsigned long r12;
- unsigned long r13;
- unsigned long r14;
- unsigned long r15;
- unsigned long rip;
+ unsigned long long rbx;
+ unsigned long long rbp;
+ unsigned long long r12;
+ unsigned long long r13;
+ unsigned long long r14;
+ unsigned long long r15;
+ unsigned long long rip;
} gtm_jmpbuf;
#else
typedef struct gtm_jmpbuf
