Re: [PATCH, ARM, libgcc] Enable longlong.h inline assembly for Thumb-2
On 08/03/12 03:36, Michael Hope wrote: Hi there, This patch enables the ARM inline assembly 64 bit add, subtract, and multiply instructions in libgcc when compiling for Thumb-2. The existing code enables them for ARM mode as Thumb-1 is missing the encodings. OK for 4.8? -- Michael ChangeLog: 2012-03-08 Michael Hope michael.h...@linaro.org * longlong.h [ARM] (add_ss, sub_ddmmss, umul_ppmm): Enable for Thumb-2. OK R.
[Patch ARM/ configury] Add fall-back check for gnu_unique_object - Default to this for arm-linux-gnueabi
Hi,
While investigating a report for odd behaviour with a C++ program, I
discovered that the automatic checking for gnu_unique_object is broken
during
bootstrap for arm-linux-gnueabi targets because on ARM '@' is a
comment character for the assembler.
I do realize this can be worked around with the configure time option
but it would be nice to fix this without
having to resort to the workaround everytime.
Fixed thusly - tested with bootstraps on both arm-linux-gnueabi and
verified that auto-host.h has the right definition.
Ok ?
regards,
Ramana
2012-03-07 Ramana Radhakrishnan ramana.radhakrish...@linaro.org
* config.gcc (target_type_format_char): New. Document it. Set it for
arm*-*-* .
* configure.ac (gnu_unique_option): Use target_type_format_char in test.
* configure: Regenerate .
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 185057)
+++ gcc/config.gcc (working copy)
@@ -184,6 +184,11 @@
# the --with-sysroot configure option or the
# --sysroot command line option is used this
# will be relative to the sysroot.
+# target_type_format_char
+# The default character to be used for formatting
+# the attribute in a
+# .type symbol_name, ${t_t_f_c}property
+# directive.
# The following variables are used in each case-construct to build up the
# outgoing variables:
@@ -235,6 +240,7 @@
need_64bit_hwint=
need_64bit_isa=
native_system_header_dir=/usr/include
+target_type_format_char=@
# Don't carry these over build-host-target. Please.
xm_file=
@@ -321,6 +327,7 @@
arm*-*-*)
cpu_type=arm
extra_headers=mmintrin.h arm_neon.h
+ target_type_format_char=%
c_target_objs=arm-c.o
cxx_target_objs=arm-c.o
extra_options=${extra_options} arm/arm-tables.opt
Index: gcc/configure
===
--- gcc/configure (revision 185057)
+++ gcc/configure (working copy)
@@ -26178,7 +26178,7 @@
then gcc_cv_as_gnu_unique_object=yes
fi
elif test x$gcc_cv_as != x; then
-$as_echo '.type foo, @gnu_unique_object' conftest.s
+$as_echo '.type foo, '$target_type_format_char'gnu_unique_object'
conftest.s
if { ac_try='$gcc_cv_as $gcc_cv_as_flags -o conftest.o conftest.s 5'
{ { eval echo \\$as_me\:${as_lineno-$LINENO}: \$ac_try\; } 5
(eval $ac_try) 25
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 185057)
+++ gcc/configure.ac(working copy)
@@ -4187,7 +4187,7 @@
esac],
[gcc_GAS_CHECK_FEATURE([gnu_unique_object], gcc_cv_as_gnu_unique_object,
[elf,2,19,52],,
- [.type foo, @gnu_unique_object],,
+ [.type foo, '$target_type_format_char'gnu_unique_object],,
# Also check for ld.so support, i.e. glibc 2.11 or higher.
[[if test x$host = x$build -a x$host = x$target
ldd --version 2/dev/null
Re: fix libstdc++/52433
On 03/08/2012 02:06 AM, Jonathan Wakely wrote: On 4 March 2012 12:56, Jonathan Wakely wrote: PR libstdc++/52433 * include/debug/safe_iterator.h (_Safe_iterator): Add move constructor and move assignment operator. * testsuite/23_containers/vector/debug/52433.cc: New. Tested 'make check check-debug' on x86_64 and committed to trunk. I plan to fix this for 4.7.1 and 4.6.4 as well This restores the debug mode checks when moving singular iterators. Thanks for the good work on this. By the way, this morning it occurred to me that we should probably also have debug-mode checks for self move-assignment (not just in _Safe_iterator)?!? Or I'm missing something? Thanks, Paolo.
[PATCH] Proper use of decl_function_context in dwar2out.c
Hi,
the following patch fixes an ICE for me when LTO building Firefox at
-O3 -g. The problem is that at one spot we use decl_function_context
as a predicate whether to use TREE_CONTEXT rather than using it's
result which can be determined in a much more elaborate way. In my
particular case TREE_CONTEXT is a type, not a function decl and
lookup_decl_die chokes on that, when it is fed the function result,
all seems fine.
Bootstrapped and tested on x86_64-linux. OK for trunk?
Also, I have not actually tried it but I suppose we'll be hitting this
problem with 4.7 as well. OK for the branch once 4.7.0 is out?
Thanks,
Martin
2012-03-07 Martin Jambor mjam...@suse.cz
* dwarf2out.c (dwarf2out_decl): Use result of decl_function_context
rather than DECL_CONTEXT.
Index: src/gcc/dwarf2out.c
===
--- src.orig/gcc/dwarf2out.c
+++ src/gcc/dwarf2out.c
@@ -19830,6 +19830,7 @@ void
dwarf2out_decl (tree decl)
{
dw_die_ref context_die = comp_unit_die ();
+ tree ctx_fndecl;
switch (TREE_CODE (decl))
{
@@ -19889,8 +19890,9 @@ dwarf2out_decl (tree decl)
return;
/* For local statics lookup proper context die. */
- if (TREE_STATIC (decl) decl_function_context (decl))
- context_die = lookup_decl_die (DECL_CONTEXT (decl));
+ if (TREE_STATIC (decl)
+ (ctx_fndecl = decl_function_context (decl)) != NULL_TREE)
+ context_die = lookup_decl_die (ctx_fndecl);
/* If we are in terse mode, don't generate any DIEs to represent any
variable declarations or definitions. */
Re: PATCH: Use word_mode to push/pop register for x86
On Tue, Mar 6, 2012 at 10:46 PM, H.J. Lu hongjiu...@intel.com wrote: push/pop in x86 only works on word_mode registers. This patch properly handles push/pop on registers in x86. Tested on Linux/x86-64. OK for trunk? 2012-03-06 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (setup_incoming_varargs_64): Use word_mode with integer parameters in registers. (gen_push): Push register in word_mode instead of Pmode. (ix86_emit_save_regs): Likewise. (ix86_emit_save_regs_using_mov): Save integer registers in word_mode. (gen_pop): Pop register in word_mode instead of Pmode. (ix86_emit_restore_regs_using_pop): Likewise. (ix86_expand_prologue): Replace Pmode with word_mode for push immediate. Use ix86_gen_pro_epilogue_adjust_stack. Save and restore RAX and R10 in word_mode. (ix86_emit_restore_regs_using_mov): Restore integer registers in word_mode. (ix86_expand_split_stack_prologue): Save R10_REG and restore in word_mode. (ix86_split_to_parts): Use word_mode with PUT_MODE for push. (ix86_split_long_move): Likewise. * config/i386/i386.md (W): New. (*pushmode2_prologue): Replace :P with :W. (*popmode1): Likewise. (*popmode1_epilogue): Likewise. (push/pop peephole2): Use word_mode scratch registers. The patch looks good to me. Based on the comment by Ian, I feel confident that prologue/epilogue changes are OK, too. But I didn't re-check all and every mode change here (since I can't test these changes by myself), so please double check them. Admittely, the patch doesn't break any x86 target. So, OK for mainline. Thanks, Uros.
Re: [PATCH 07/10] addr32: Use word_mode instead of Pmode in loop expand
On Fri, Mar 2, 2012 at 10:02 PM, H.J. Lu hongjiu...@intel.com wrote: This patches uses word_mode instead of Pmode in loop expand since word_mode may have bigger size than Pmode. OK for trunk? Thanks. H.J. --- 2012-03-02 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (ix86_expand_movmem): Use word_mode instead of Pmode on loop. (ix86_expand_setmem): Likwise. Jan, can you please comment on the changes in this patch? Thanks, Uros.
Re: fix libstdc++/52433
On 8 March 2012 10:22, Paolo Carlini wrote: By the way, this morning it occurred to me that we should probably also have debug-mode checks for self move-assignment (not just in _Safe_iterator)?!? Yes, nice idea, the library is allowed to assume it doesn't happen, but we can and should check it in debug mode.
[C++ Patch] Consistently forward 'complain'
Hi, this is the small clean up which I mentioned a few days ago. Booted and tested x86_64-linux. Thanks, Paolo. 2012-03-08 Paolo Carlini paolo.carl...@oracle.com * typeck.c (build_array_ref, cp_build_addr_expr_1, convert_ptrmem, build_ptrmemfunc): Consistently forward the tsubst_flags_t parameter. * call.c (resolve_args): Likewise. Index: typeck.c === --- typeck.c(revision 185096) +++ typeck.c(working copy) @@ -2884,7 +2884,7 @@ cp_build_array_ref (location_t loc, tree array, tr complain), cp_build_array_ref (loc, TREE_OPERAND (array, 2), idx, complain), - tf_warning_or_error); + complain); protected_set_expr_location (ret, loc); return ret; @@ -5033,7 +5033,7 @@ cp_build_addr_expr_1 (tree arg, bool strict_lvalue build_ptrmemfunc_type (argtype); val = build_ptrmemfunc (argtype, val, 0, /*c_cast_p=*/false, - tf_warning_or_error); + complain); } return val; @@ -5781,11 +5781,11 @@ convert_ptrmem (tree type, tree expr, bool allow_i EQ_EXPR, expr, build_int_cst (TREE_TYPE (expr), -1), -tf_warning_or_error); +complain); op1 = build_nop (ptrdiff_type_node, expr); op2 = cp_build_binary_op (input_location, PLUS_EXPR, op1, delta, - tf_warning_or_error); + complain); expr = fold_build3_loc (input_location, COND_EXPR, ptrdiff_type_node, cond, op1, op2); @@ -7208,7 +7208,7 @@ build_ptrmemfunc (tree type, tree pfn, int force, return pfn; else if (integer_zerop (n)) return build_reinterpret_cast (to_type, pfn, - tf_warning_or_error); + complain); } if (TREE_SIDE_EFFECTS (pfn)) @@ -7229,9 +7229,9 @@ build_ptrmemfunc (tree type, tree pfn, int force, if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta) n = cp_build_binary_op (input_location, LSHIFT_EXPR, n, integer_one_node, - tf_warning_or_error); + complain); delta = cp_build_binary_op (input_location, - PLUS_EXPR, delta, n, tf_warning_or_error); + PLUS_EXPR, delta, n, complain); return build_ptrmemfunc1 (to_type, delta, npfn); } @@ -7245,7 +7245,7 @@ build_ptrmemfunc (tree type, tree pfn, int force, } if (type_unknown_p (pfn)) -return instantiate_type (type, pfn, tf_warning_or_error); +return instantiate_type (type, pfn, complain); fn = TREE_OPERAND (pfn, 0); gcc_assert (TREE_CODE (fn) == FUNCTION_DECL Index: call.c === --- call.c (revision 185096) +++ call.c (working copy) @@ -3740,7 +3740,7 @@ resolve_args (VEC(tree,gc) *args, tsubst_flags_t c error (invalid use of void expression); return NULL; } - else if (invalid_nonstatic_memfn_p (arg, tf_warning_or_error)) + else if (invalid_nonstatic_memfn_p (arg, complain)) return NULL; } return args;
Re: libgo patch committed: Fill out syscall package for GNU/Linux
Ian Lance Taylor i...@google.com writes: Rainer Orth r...@cebitec.uni-bielefeld.de writes: Rainer Orth r...@cebitec.uni-bielefeld.de writes: Ian Lance Taylor i...@google.com writes: This patch to libgo fills out the syscall package for GNU/Linux to match all the functions in the syscall package in the master Go library. There is a test case for this patch at http://code.google.com/p/go/issues/detail?id=3071 . Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Unfortunately, this broke Solaris bootstrap: It also broke Linux/x86_64 bootstrap (CentOS 5.6): In file included from /usr/include/sys/ustat.h:30:0, from /usr/include/ustat.h:1, from sysinfo.c:91: /usr/include/bits/ustat.h:25:8: error: redefinition of 'struct ustat' In file included from /usr/include/linux/filter.h:8:0, from sysinfo.c:61: /usr/include/linux/types.h:156:8: note: originally defined here After some actual testing, this additional patch seems to be needed to fix the problem. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. This patch and the preceding one need to go onto the 4.7 branch, too, otherwise bootstrap on Solaris and CentOS 5.6 is broken. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [4.7/4.8 build] Fix R_386_TLS_LDM_PLT detection
On Thu, Mar 08, 2012 at 02:21:18PM +0100, Rainer Orth wrote: Given that HAVE_AS_IX86_TLSLDMPLT is only use for Solaris/x86 and fixes a stupid bug, I'd like to get this into both mainline and the 4.7 branch? Ok. 2012-03-06 Rainer Orth r...@cebitec.uni-bielefeld.de * configure.ac (gcc_cv_as_ix86_tlsldmplt): Add label. * configure: Regenerate. Jakub
[Patch,AVR]: Add w constraint alternative to addhi3
This patch adds a w alternative to *addhi3 and addhi3_clobber in order to
vote for class w. This is similar to the orgiginal addhi3 insn up to version
4.6. And there is no more explicit vote for l in addhi3_clobber, it's just
r.
Intention is to get a better usage of ADIW and SBIW instructions.
Would it be good to split the alternatives even more and add ? costs to non-w
registers?
Moreover, it might be advantageous to move addhi3_clobber up and before *addhi3?
Passed without regressions.
Ok for trunk?
Johann
* config/avr/avr.md (*addhi3, addhi3_clobber): Add w alternative
for constants in [-63,63].
Index: config/avr/avr.md
===
--- config/avr/avr.md (revision 185100)
+++ config/avr/avr.md (working copy)
@@ -1098,15 +1098,16 @@ (define_insn *addhi3_sp
(set_attr adjust_len addto_sp)])
(define_insn *addhi3
- [(set (match_operand:HI 0 register_operand =r,d,d)
-(plus:HI (match_operand:HI 1 register_operand %0,0,0)
- (match_operand:HI 2 nonmemory_operand r,s,n)))]
+ [(set (match_operand:HI 0 register_operand =r,d,!w,d)
+(plus:HI (match_operand:HI 1 register_operand %0,0,0 ,0)
+ (match_operand:HI 2 nonmemory_operand r,s,IJ,n)))]
{
static const char * const asm_code[] =
{
add %A0,%A2\;adc %B0,%B2,
subi %A0,lo8(-(%2))\;sbci %B0,hi8(-(%2)),
+,
};
@@ -1115,9 +1116,9 @@ (define_insn *addhi3
return avr_out_plus_noclobber (operands, NULL, NULL);
}
- [(set_attr length 2,2,2)
- (set_attr adjust_len *,*,out_plus_noclobber)
- (set_attr cc set_n,set_czn,out_plus_noclobber)])
+ [(set_attr length 2,2,2,2)
+ (set_attr adjust_len *,*,out_plus_noclobber,out_plus_noclobber)
+ (set_attr cc set_n,set_czn,out_plus_noclobber,out_plus_noclobber)])
;; Adding a constant to NO_LD_REGS might have lead to a reload of
;; that constant to LD_REGS. We don't add a scratch to *addhi3
@@ -1155,10 +1156,10 @@ (define_peephole2 ; addhi3_clobber
(clobber (match_dup 2))])])
(define_insn addhi3_clobber
- [(set (match_operand:HI 0 register_operand =d,l)
-(plus:HI (match_operand:HI 1 register_operand %0,0)
- (match_operand:HI 2 const_int_operand n,n)))
- (clobber (match_scratch:QI 3 =X,d))]
+ [(set (match_operand:HI 0 register_operand =!w,d,r)
+(plus:HI (match_operand:HI 1 register_operand %0,0,0)
+ (match_operand:HI 2 const_int_operand IJ,n,n)))
+ (clobber (match_scratch:QI 3 =X,X,d))]
{
gcc_assert (REGNO (operands[0]) == REGNO (operands[1]));
Re: [RFC]: Add support for pragma pointer_size
On Mar 7, 2012, at 7:42 PM, Joseph S. Myers wrote: On Wed, 7 Mar 2012, Tristan Gingold wrote: On Mar 6, 2012, at 6:34 PM, Joseph S. Myers wrote: On Tue, 6 Mar 2012, Tristan Gingold wrote: The patch is simple: the C front-end will now calls c_build_pointer_type (instead of build_pointer_type), which in turn calls build_pointer_type_for_mode using the right mode. There seem to be quite a lot of build_pointer_type calls in the C front end (and in c-common.c) that you haven't changed. Could you explain the rule for when a call should or should not be changed, and how it applies to all these calls? The global approach is to have the same effect as a default __attribute__((mode(SI/DImode))) on pointers declared by users so that layouts match. That's why only grokdeclarator is changed. There might be bugs with this approach (e.g. it looks like c-common.c:handle_noreturn_attribute doesn't preserve the mode of the pointer to function), but my understanding is that they also correspond to bugs of __attribute__((mode ())) applied to pointer. The later one isn't well tested and one advantage of the VMS port is that it will test it much more (as there are many pragma pointer_size in VMS headers). So those places would need to change to use build_pointer_type_for_mode as is done for composite types in c-typeck.c:composite_type, for example? Yes. I think the patch at least needs a (VMS-specific?) testcase that tests the new pragma (presuming the testsuite can be run for VMS targets) even if some cases can't be tested until they are fixed. Argh, that's an issue. We don't run the gcc test suite natively on VMS because there is no port of Dejagnu (if ever doable) to VMS. We haven't tried to test a cross-compiler (and running the executable on the VMS host) because an early attempt for another test suite pointed out slowness and reliability issues. VMS machines could be considered as slow from today's standard POV. I haven't found a method to run only the compile tests and skip the executing one. Is it possible to do that with the gcc test suite ? That's would be very useful to test cross compilers. But I am not worried about the tests of '#pragma pointer_size' per see, as there are very present in system headers and thus simply building a cross-compiler (and much more certainly if Ada is enabled) would thoroughly test it. So I think this patch is test by building the compiler (not now but as soon as I add the builtin macros that protect this pragma in VMS headers). For testing front-end handling of mixed sized pointers, I think we can fallback to the mode __attribute__ and enabling these tests on platforms that support it (mips64/linux, s390x). Is this approach ok to you ? Tristan.
Re: [WIP PATCH] Re: Inefficient end-of-loop value computation - missed optimization somewhere?
Richard Guenther wrote: On Tue, Feb 28, 2012 at 4:10 PM, Ulrich Weigand uweig...@de.ibm.com wrote: I'll still need to do proper testing and benchmarking, but I thought I'd post the patch anyway just as a heads-up ... Does this look reasonable to you? Yes, that looks reasonable. Though instead of unsigned_type_for please use build_nonstandard_integer_type instead (if the type is not already unsigned). unsigned_type_for does not necessarily preserve type-precision and may even return NULL. OK, I've changed the patch to use build_nonstandard_integer_type, and it still fixes the original problem. However, on further examination it turns out that this fix is not because the expression is actually simplified at tree level. Rather, it is just that because of some minor reassociation (the +1 is moved to the end), the *RTL* optimizers now see a (just as complex but) slightly different RTL sequence, and therefore combine now just happens to be able to fold everything together (using the RTL-level simplify_plus_minus machinery). Even worse, the patch causes a number of regressions: FAIL: gcc.dg/tree-ssa/loop-15.c scan-tree-dump-times optimized \\+ 0 FAIL: gcc.dg/tree-ssa/loop-15.c scan-tree-dump-times optimized n_. \\* n_. 1 FAIL: gcc.dg/vect/no-scevccp-noreassoc-outer-4.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 The loop-15.c problem is probably just a missed optimization elsewhere that can be fixed. The problem is that a loop-end value used to be computed as (n - 1) * n + n which got simplified via fold_plusminus_mult_expr to n * n. When computing in unsigned, however, the expression becomes something along the lines of [...] * (unsigned) n + (unsigned) n and the top-level of fold_binary_loc removes the *outermost* NOP_EXPRs resulting in [...] * (unsigned) n + n which fold_plusminus_mult_expr no longer recognizes as something it can handle (since (unsigned) n is not operand_equal_p to n). I think this can be fixed by having fold_plusminus_mult_expr call STRIP_NOPS on sub-operands, as is already done elsewhere in fold_binary_loc. This basically fixes the test case (due to some remaining casts, the scan-tree-dump patterns still don't match as-is, but the expected code is again generated). The no-scevccp-noreassoc-outer-4.c problem is more difficult, and would seem to point to a fundamental problem with performing the computation in unsigned mode. In this case, the end value of an inner loop forms part of a scalar evolution of the outer loop. When computing the end value in unsigned type, that scalar evolution is no longer detected. In part, this is because the scalar evolution machinery might need to be improved in handling casts. In particular, in some places it only does STRIP_USELESS_TYPE_CONVERSION; changing those to STRIP_NOPS makes it detect the evolution again. But I'm not fully convinced this is a safe change ... In any case, this still doesn't make the outer loop vectorizable, since it is no longer provably finite. Without the patch, this could be proven *because* the computation of the inner loop's end value used signed arithmetic which cannot overflow. By performing the computation in unsigned, this information is in fact lost. This would seem to indicate that unconditionally using unsigned arithmetic even if not strictly necessary might not always be the best solution either. I've gone back and looked that at the original problem that (start + 1) + (int)((unsigned int) ~start + (unsigned int) end) is not simplified by fold-const. Interestingly enough, it *is* valid to simplify this expression to just plain end, even with signed arithmetic, since the transformation does not introduce any new potential overflows. This is actually recognized in fold_binary_loc, but only one special case. See the code around the following comment: /* The only case we can still associate with two variables is if they are the same, modulo negation. */ Unfortunately, this handles only A and -A; it doesn't recognize that A+1 is in fact the negation of ~A ... There is also code in tree-ssa-forwprop.c:associate_plusminus that handles quite a number of special cases where re-association *is* allowed even for signed arithmetic: (A +- B) - A - +- B (A +- B) -+ B - A (CST +- A) +- CST - CST +- A (A + CST) +- CST - A + CST ~A + A - -1 ~A + 1 - -A A - (A +- B) - -+ B A +- (B +- A) - +- B CST +- (CST +- A) - CST +- A CST +- (A +- CST) - CST +- A A + ~A - -1 This handles some cases involving ~, but still not quite the case we need for this expression. In addition, the forward propagtion logic doesn't seem to handle casts very well (as opposed to fold-const, which makes liberal use of STRIP_NOPS). I'm wondering where to go from there: - Why are those special
[ping] Vectorizer patches for 4.8
Hello, Ira Rosen posted a couple of vectorizer patches intended for 4.8: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00191.html http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00223.html As she is no longer able to contribute to GCC, she has asked me to help push these upstream now that 4.8 is in stage 1. We've been carrying those patches for a while in our Linaro GCC builds for ARM, and they're showing significant improvements in certain embedded test cases. I've now retested both patches on i386-linux with no regressions; the PowerPC team has helped with retesting on powerpc64-linux with no regressions, and there are (as expected) no significant changes in PowerPC benchmark results either. OK to commit the two patches to mainline? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [i386, patch, RFC] HLE support in GCC
On Thu, Mar 8, 2012 at 12:44 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hi HJ,
I am working on that. Here's some clarification from Jakub:
I meant that e.g. instead of:
int
foo (int *p, int oldv, int newv)
{
__atomic_compare_exchange_n (p, oldv, newv, 0, __ATOMIC_ACQUIRE,
__ATOMIC_ACQUIRE);
return oldv;
}
if you want to generate xacquire lock cmpxchgl instead of just lock cmpxchgl
you could write
__atomic_compare_exchange_n (p, oldv, newv, 0, __ATOMIC_ACQUIRE |
__ATOMIC_HLE_XACQUIRE, __ATOMIC_ACQUIRE);
(dunno if we'd want the flag to be listed in both success and fail memmodel
variants, or just one, for most of other __atomic_* builtins there is just
one).
__ATOMIC_HLE_XACQUIRE and __ATOMIC_HLE_XRELEASE would be just predefined
macros like __ATOMIC_ACQUIRE etc. is.
Jakub
I don't think, we need to change FE for that...
Please note that __ATOMIC_HLE_XACQUIRE has nothing to do with
__ATOMIC_ACQUIRE. You can have
__ATOMIC_ACQUIRE | __ATOMIC_HLE_XRELEASE
K
That sounds a good idea. Will it require front-end and middle-end changes?
I assume they will be no-op for other backends.
--
H.J.
--
H.J.
Re: [i386, patch, RFC] HLE support in GCC
On Thu, Mar 08, 2012 at 07:04:03AM -0800, H.J. Lu wrote: I don't think, we need to change FE for that... Please note that __ATOMIC_HLE_XACQUIRE has nothing to do with __ATOMIC_ACQUIRE. You can have __ATOMIC_ACQUIRE | __ATOMIC_HLE_XRELEASE Yeah. And you don't need to change the FEs in any way, all that is needed is to change the middle-end/expansion (builtins.c - e.g. get_memmodel) and the backend (plus predefine the macros in the backend). Jakub
Re: [RFC]: Add support for pragma pointer_size
On Thu, 8 Mar 2012, Tristan Gingold wrote: Argh, that's an issue. We don't run the gcc test suite natively on VMS because there is no port of Dejagnu (if ever doable) to VMS. We haven't tried to test a cross-compiler (and running the executable on the VMS host) because an early attempt for another test suite pointed out slowness and reliability issues. VMS machines could be considered as slow from today's standard POV. I haven't found a method to run only the compile tests and skip the executing one. Is it possible to do that with the gcc test suite ? That's would be very useful to test cross compilers. Thanks for the explanation. I advise solving the unreliability issues for cross-testing to VMS (and living with the slowness), so that you can run the testsuite, but the patch is OK as-is. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH 02/10] addr32: Only handle zero-extended DImode addresses
On Sun, Mar 4, 2012 at 9:13 PM, Uros Bizjak ubiz...@gmail.com wrote: We only need to handle zero-extended addresses in DImode. OK for trunk? 2012-03-02 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (ix86_print_operand_address): Only handle zero-extended DImode addresses. OK. The patch was reverted due to PR target/52530. Uros.
Re: [PATCH][ARM] Improve use of conditional execution in thumb mode.
On 17/02/12 15:30, Andrew Stubbs wrote:
I've got a full test run going again.
OK for 4.8, again?
The test run revealed some bugs handling MINUS.
This update has been tested and passes a bootstrap and test with no
regressions. Indeed, it has actually corrected a failure in
gcc.target/arm/combine-movs.c.
OK?
Andrew
2012-03-08 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.c (thumb2_reorg): Add complete support
for 16-bit instructions.
* config/arm/thumb2.md: Delete obsolete flag-clobbering peepholes.
gcc/testsuite/
* gcc.target/arm/thumb-16bit-ops.c: New file.
* gcc.target/arm/thumb-ifcvt.c: New file.
---
gcc/config/arm/arm.c | 157 ---
gcc/config/arm/thumb2.md | 107 -
gcc/testsuite/gcc.target/arm/thumb-16bit-ops.c | 196
gcc/testsuite/gcc.target/arm/thumb-ifcvt.c | 19 ++
4 files changed, 344 insertions(+), 135 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/arm/thumb-16bit-ops.c
create mode 100644 gcc/testsuite/gcc.target/arm/thumb-ifcvt.c
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 0bded8d..44f99c1 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13246,47 +13246,148 @@ thumb2_reorg (void)
FOR_BB_INSNS_REVERSE (bb, insn)
{
if (NONJUMP_INSN_P (insn)
- !REGNO_REG_SET_P (live, CC_REGNUM))
+ !REGNO_REG_SET_P (live, CC_REGNUM)
+ GET_CODE (PATTERN (insn)) == SET)
{
+ enum {SKIP, CONV, SWAP_CONV} action = SKIP;
rtx pat = PATTERN (insn);
- if (GET_CODE (pat) == SET
- low_register_operand (XEXP (pat, 0), SImode)
- thumb_16bit_operator (XEXP (pat, 1), SImode)
- low_register_operand (XEXP (XEXP (pat, 1), 0), SImode)
- low_register_operand (XEXP (XEXP (pat, 1), 1), SImode))
+ rtx dst = XEXP (pat, 0);
+ rtx src = XEXP (pat, 1);
+ rtx op0 = NULL_RTX, op1 = NULL_RTX;
+
+ if (!OBJECT_P (src))
+ op0 = XEXP (src, 0);
+
+ if (BINARY_P (src))
+ op1 = XEXP (src, 1);
+
+ if (low_register_operand (dst, SImode))
{
- rtx dst = XEXP (pat, 0);
- rtx src = XEXP (pat, 1);
- rtx op0 = XEXP (src, 0);
- rtx op1 = (GET_RTX_CLASS (GET_CODE (src)) == RTX_COMM_ARITH
- ? XEXP (src, 1) : NULL);
-
- if (rtx_equal_p (dst, op0)
- || GET_CODE (src) == PLUS || GET_CODE (src) == MINUS)
+ switch (GET_CODE (src))
{
- rtx ccreg = gen_rtx_REG (CCmode, CC_REGNUM);
- rtx clobber = gen_rtx_CLOBBER (VOIDmode, ccreg);
- rtvec vec = gen_rtvec (2, pat, clobber);
+ case PLUS:
+ if (low_register_operand (op0, SImode))
+ {
+ /* ADDS Rd,Rn,Rm */
+ if (low_register_operand (op1, SImode))
+ action = CONV;
+ /* ADDS Rdn,#imm8 */
+ /* SUBS Rdn,#imm8 */
+ else if (rtx_equal_p (dst, op0)
+CONST_INT_P (op1)
+IN_RANGE (INTVAL (op1), -255, 255))
+ action = CONV;
+ /* ADDS Rd,Rn,#imm3 */
+ /* SUBS Rd,Rn,#imm3 */
+ else if (CONST_INT_P (op1)
+IN_RANGE (INTVAL (op1), -7, 7))
+ action = CONV;
+ }
+ break;
+
+ case MINUS:
+ /* RSBS Rd,Rn,#0
+ Not handled here: see NEG below. */
+ /* SUBS Rd,Rn,#imm3
+ SUBS Rdn,#imm8
+ Not handled here: see PLUS above. */
+ /* SUBS Rd,Rn,Rm */
+ if (low_register_operand (op0, SImode)
+ low_register_operand (op1, SImode))
+ action = CONV;
+ break;
+
+ case MULT:
+ /* MULS Rdm,Rn,Rdm
+ As an exception to the rule, this is only used
+ when optimizing for size since MULS is slow on all
+ known implementations. We do not even want to use
+ MULS in cold code, if optimizing for speed, so we
+ test the global flag here. */
+ if (!optimize_size)
+ break;
+ /* else fall through. */
+ case AND:
+ case IOR:
+ case XOR:
+ /* ANDS Rdn,Rm */
+ if (rtx_equal_p (dst, op0)
+ low_register_operand (op1, SImode))
+ action = CONV;
+ else if (rtx_equal_p (dst, op1)
+ low_register_operand (op0, SImode))
+ action = SWAP_CONV;
+ break;
+
+ case ASHIFTRT:
+ case ASHIFT:
+ case LSHIFTRT:
+ /* ASRS Rdn,Rm */
+ /* LSRS Rdn,Rm */
+ /* LSLS Rdn,Rm */
+ if (rtx_equal_p (dst, op0)
+ low_register_operand (op1, SImode))
+ action = CONV;
+ /* ASRS Rd,Rm,#imm5 */
+ /* LSRS Rd,Rm,#imm5 */
+ /* LSLS Rd,Rm,#imm5 */
+ else if (low_register_operand (op0, SImode)
+ CONST_INT_P (op1)
+ IN_RANGE (INTVAL (op1), 0, 31))
+ action = CONV;
+ break;
+
+ case ROTATERT:
+ /* RORS Rdn,Rm */
+ if (rtx_equal_p (dst, op0)
+ low_register_operand (op1, SImode))
+ action = CONV;
+ break;
- PATTERN (insn) = gen_rtx_PARALLEL (VOIDmode, vec);
- INSN_CODE (insn) = -1;
+ case NOT:
+ case NEG:
+ /*
[PATCH] Further VRP improvements
Hi!
This patch adds ASSERT_EXPRs for
if ((int) var cmp CST)
(for cmp , =, , =). As the testcase shows, various different tests
are folded into that form.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-03-08 Jakub Jelinek ja...@redhat.com
PR tree-optimization/51721
* tree-vrp.c (register_edge_assert_for_2): Add asserts for unsvar
if (int) unsvar cmp CST.
* gcc.dg/tree-ssa/vrp64.c: New test.
--- gcc/tree-vrp.c.jj 2012-03-06 17:02:12.0 +0100
+++ gcc/tree-vrp.c 2012-03-08 11:41:17.749509390 +0100
@@ -4462,8 +4462,6 @@ register_edge_assert_for_2 (tree name, e
}
}
- /* Similarly add asserts for NAME == CST and NAME being defined as
- NAME = NAME2 CST2. */
if (TREE_CODE_CLASS (comp_code) == tcc_comparison
TREE_CODE (val) == INTEGER_CST)
{
@@ -4472,7 +4470,61 @@ register_edge_assert_for_2 (tree name, e
tree val2 = NULL_TREE;
unsigned HOST_WIDE_INT mask[2] = { 0, 0 };
- /* Extract CST2 from the right shift. */
+ /* Add asserts for NAME cmp CST and NAME being defined
+as NAME = (int) NAME2. */
+ if (!TYPE_UNSIGNED (TREE_TYPE (val))
+ (comp_code == LE_EXPR || comp_code == LT_EXPR
+ || comp_code == GT_EXPR || comp_code == GE_EXPR)
+ gimple_assign_cast_p (def_stmt))
+ {
+ name2 = gimple_assign_rhs1 (def_stmt);
+ if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt))
+ INTEGRAL_TYPE_P (TREE_TYPE (name2))
+ TYPE_UNSIGNED (TREE_TYPE (name2))
+ (TYPE_PRECISION (TREE_TYPE (val))
+ == TYPE_PRECISION (TREE_TYPE (name2)))
+ (comp_code == LE_EXPR || comp_code == GT_EXPR
+ || !tree_int_cst_equal (val,
+ TYPE_MIN_VALUE (TREE_TYPE (val
+ live_on_edge (e, name2)
+ !has_single_use (name2))
+ {
+ tree tmp, cst;
+ enum tree_code new_comp_code = comp_code;
+
+ cst = fold_convert (TREE_TYPE (name2),
+ TYPE_MIN_VALUE (TREE_TYPE (val)));
+ /* Build an expression for the range test. */
+ tmp = build2 (PLUS_EXPR, TREE_TYPE (name2), name2, cst);
+ cst = fold_build2 (PLUS_EXPR, TREE_TYPE (name2), cst,
+fold_convert (TREE_TYPE (name2), val));
+ if (comp_code == LT_EXPR || comp_code == GE_EXPR)
+ {
+ new_comp_code = comp_code == LT_EXPR ? LE_EXPR : GT_EXPR;
+ cst = fold_build2 (MINUS_EXPR, TREE_TYPE (name2), cst,
+build_int_cst (TREE_TYPE (name2), 1));
+ }
+
+ if (dump_file)
+ {
+ fprintf (dump_file, Adding assert for );
+ print_generic_expr (dump_file, name2, 0);
+ fprintf (dump_file, from );
+ print_generic_expr (dump_file, tmp, 0);
+ fprintf (dump_file, \n);
+ }
+
+ register_new_assert_for (name2, tmp, new_comp_code, cst, NULL,
+ e, bsi);
+
+ retval = true;
+ }
+ }
+
+ /* Add asserts for NAME cmp CST and NAME being defined as
+NAME = NAME2 CST2.
+
+Extract CST2 from the right shift. */
if (is_gimple_assign (def_stmt)
gimple_assign_rhs_code (def_stmt) == RSHIFT_EXPR)
{
@@ -4500,7 +4552,6 @@ register_edge_assert_for_2 (tree name, e
val2 = fold_binary (LSHIFT_EXPR, TREE_TYPE (val), val, cst2);
}
}
-
if (val2 != NULL_TREE
TREE_CODE (val2) == INTEGER_CST
simple_cst_equal (fold_build2 (RSHIFT_EXPR,
--- gcc/testsuite/gcc.dg/tree-ssa/vrp64.c.jj2012-03-08 12:58:05.773797384
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp64.c 2012-03-08 12:57:26.0
+0100
@@ -0,0 +1,152 @@
+/* PR tree-optimization/51721 */
+/* { dg-do link } */
+/* { dg-options -O2 } */
+
+extern void link_error (void);
+
+#define BITSM1 (sizeof (int) * __CHAR_BIT__ - 1)
+
+void
+f1 (unsigned int s)
+{
+ if (s BITSM1 != 0)
+{
+ if (s == 0 || s == 5 || s == __INT_MAX__)
+ link_error ();
+}
+ else
+{
+ if (s == 1U + __INT_MAX__ || s == 6U + __INT_MAX__ || s == -1U)
+ link_error ();
+}
+}
+
+void
+f2 (int s)
+{
+ if (s BITSM1 == 0)
+{
+ if (s == -1 || s == -5 || s == -__INT_MAX__ - 1)
+ link_error ();
+}
+ else
+{
+ if (s == 0 || s == 5 || s == __INT_MAX__)
+ link_error ();
+}
+}
+
+void
+f3 (unsigned int s)
+{
+ if ((s (1U BITSM1)) != 0)
+{
+ if (s == 0 || s == 5 || s == __INT_MAX__)
+ link_error ();
+}
+ else
+{
+ if (s == 1U + __INT_MAX__ || s == 6U + __INT_MAX__ || s == -1U)
+ link_error ();
+}
+}
+
+void
+f4 (int s)
+{
+ if
Re: [PATCH][ARM] NEON DImode not
On 01/03/12 17:07, Richard Earnshaw wrote:
The RTL part of one_cmpldi2_internal and one_cmpldi2_neon are the same.
Given that we now have controls to determine when an alternative is
enabled it's generally better to have just one pattern here and turn on
the alternatives that are suitable rather than having multiple patterns.
You're already half doing this with the nota8 and onlya8 controls.
Ok, this patch unifies the two and emits the NEON instructions directly
from the arm.md pattern. I was under the impression that it is desirable
to keep the neon stuff in neon.md as far as possible.
OK?
Andrew
P.S. The insn_enabled code is not ideal, but the 'arch' attribute that
might normally deal with this is already in use. Alternative ways might
be to have a variation on the 'w' constraint ('W'?) that is conditional
on TARGET_NEON, or to have compound arch values (e.g. onlya8_neon)?
2012-03-08 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.md (one_cmpldi2): Add NEON support.
---
gcc/config/arm/arm.md | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 751997f..27a0f81 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -4207,11 +4207,16 @@
)
(define_insn_and_split one_cmpldi2
- [(set (match_operand:DI 0 s_register_operand =r,r)
- (not:DI (match_operand:DI 1 s_register_operand 0,r)))]
+ [(set (match_operand:DI 0 s_register_operand =w,r,r,?w)
+ (not:DI (match_operand:DI 1 s_register_operand w, 0, r, w)))]
TARGET_32BIT
- #
- TARGET_32BIT reload_completed
+ @
+ vmvn\t%P0, %P1
+ #
+ #
+ vmvn\t%P0, %P1
+ TARGET_32BIT reload_completed
+arm_general_register_operand (operands[0], DImode)
[(set (match_dup 0) (not:SI (match_dup 1)))
(set (match_dup 2) (not:SI (match_dup 3)))]
@@ -4221,8 +4226,17 @@
operands[3] = gen_highpart (SImode, operands[1]);
operands[1] = gen_lowpart (SImode, operands[1]);
}
- [(set_attr length 8)
- (set_attr predicable yes)]
+ [(set_attr length *,8,8,*)
+ (set_attr predicable yes)
+ (set_attr neon_type neon_int_1,*,*,neon_int_1)
+ (set_attr arch nota8,*,*,onlya8)
+ (set_attr_alternative insn_enabled
+ [(if_then_else (match_test TARGET_NEON)
+ (const_string yes) (const_string no))
+ (const_string yes)
+ (const_string yes)
+ (if_then_else (match_test TARGET_NEON)
+ (const_string yes) (const_string no))])]
)
(define_expand one_cmplsi2
Re: [C++ Patch] Consistently forward 'complain'
OK. Jason
Re: libgo patch committed: Fill out syscall package for GNU/Linux
Rainer Orth r...@cebitec.uni-bielefeld.de writes: This patch and the preceding one need to go onto the 4.7 branch, too, otherwise bootstrap on Solaris and CentOS 5.6 is broken. Thanks--I plan to prepare a large patch for the 4.7 branch tomorrow. Ian
Re: [PATCH][ARM] NEON DImode not
On 03/08/12 08:19, Andrew Stubbs wrote: + (set_attr arch nota8,*,*,onlya8) + (set_attr_alternative insn_enabled + [(if_then_else (match_test TARGET_NEON) +(const_string yes) (const_string no)) + (const_string yes) + (const_string yes) + (if_then_else (match_test TARGET_NEON) +(const_string yes) (const_string no))])] ) While this works, it might be better to add neon/neon_na8/neon_oa8 alternatives to the arch attribute, and adjust arch_enabled to match. Obviously this opinion is non-binding; Richard E might have other plans... r~
[google] [4.6] fix a bug in capping bb count scaling (issue5786054)
Hi,
This patch is for google-4_6 branch only.
It fixes a bug in r184378 which makes some capping escape (like
stale max_bb_count in cgraph node).
Tested with the internal benchmark that exposes this issue.
Tested with gcc bootstrap.
-Rong
2012-03-08 Rong Xu x...@google.com
* gcc/tree-inline.c (copy_cfg_body): fix the bug in r184378.
Google ref b/6105259.
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 185095)
+++ gcc/tree-inline.c (working copy)
@@ -2210,7 +2210,7 @@
struct cgraph_node *node = cgraph_node (callee_fndecl);
double f_max;
gcov_type max_count_scale;
- gcov_type max_src_bb_cnt;
+ gcov_type max_src_bb_cnt = 0;
gcov_type max_value = ((gcov_type) 1 ((sizeof(gcov_type) * 8) - 1));
max_value = ~max_value;
count_scale = (REG_BR_PROB_BASE * (double)count
@@ -2220,14 +2220,13 @@
This can happen for comdat functions where the counters are split.
It's more likely for recursive inlines. */
gcc_assert (node);
- max_src_bb_cnt = node-max_bb_count;
/* Find the maximum count value to that will be copied. */
FOR_EACH_BB_FN (bb, cfun_to_copy)
if (!blocks_to_copy || bitmap_bit_p (blocks_to_copy, bb-index))
{
-if (bb-count node-max_bb_count)
- max_src_bb_cnt = node-max_bb_count;
+if (bb-count max_src_bb_cnt)
+ max_src_bb_cnt = bb-count;
}
f_max = (double) max_value * REG_BR_PROB_BASE / max_src_bb_cnt - 1;
--
This patch is available for review at http://codereview.appspot.com/5786054
Re: [RFC]: Add support for pragma pointer_size
On 03/08/12 05:49, Tristan Gingold wrote: I haven't found a method to run only the compile tests and skip the executing one. Is it possible to do that with the gcc test suite ? That's would be very useful to test cross compilers. Set the simulator to be /bin/true. r~
Re: [google] [4.6] fix a bug in capping bb count scaling (issue5786054)
ok.
David
On Thu, Mar 8, 2012 at 10:04 AM, Rong Xu x...@google.com wrote:
Hi,
This patch is for google-4_6 branch only.
It fixes a bug in r184378 which makes some capping escape (like
stale max_bb_count in cgraph node).
Tested with the internal benchmark that exposes this issue.
Tested with gcc bootstrap.
-Rong
2012-03-08 Rong Xu x...@google.com
* gcc/tree-inline.c (copy_cfg_body): fix the bug in r184378.
Google ref b/6105259.
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 185095)
+++ gcc/tree-inline.c (working copy)
@@ -2210,7 +2210,7 @@
struct cgraph_node *node = cgraph_node (callee_fndecl);
double f_max;
gcov_type max_count_scale;
- gcov_type max_src_bb_cnt;
+ gcov_type max_src_bb_cnt = 0;
gcov_type max_value = ((gcov_type) 1 ((sizeof(gcov_type) * 8) - 1));
max_value = ~max_value;
count_scale = (REG_BR_PROB_BASE * (double)count
@@ -2220,14 +2220,13 @@
This can happen for comdat functions where the counters are split.
It's more likely for recursive inlines. */
gcc_assert (node);
- max_src_bb_cnt = node-max_bb_count;
/* Find the maximum count value to that will be copied. */
FOR_EACH_BB_FN (bb, cfun_to_copy)
if (!blocks_to_copy || bitmap_bit_p (blocks_to_copy, bb-index))
{
- if (bb-count node-max_bb_count)
- max_src_bb_cnt = node-max_bb_count;
+ if (bb-count max_src_bb_cnt)
+ max_src_bb_cnt = bb-count;
}
f_max = (double) max_value * REG_BR_PROB_BASE / max_src_bb_cnt - 1;
--
This patch is available for review at http://codereview.appspot.com/5786054
Re: [RFC]: Add support for pragma pointer_size
On Mar 8, 2012, at 5:49 AM, Tristan Gingold wrote: Argh, that's an issue. We don't run the gcc test suite natively on VMS because there is no port of Dejagnu (if ever doable) to VMS. We haven't tried to test a cross-compiler (and running the executable on the VMS host) because an early attempt for another test suite pointed out slowness and reliability issues. dejagnu slices through this type of testing just fine. dejagnu is also adept at handling reliability issues, its history is littered with unreliability and it is usually fairly easy to work around any unreliability. Selecting targets that happen to be in a `working' state, powercycling them, as needed, noticing when things go wrong, retrying things a few times, as sometimes, something doesn't just work and so on. Also, the cross testing can come in many flavors, you can use a simulator (if you have one) and do cross and test on simulator. You can do this, without the simulator and just fail all the execute tests, you can do canadian cross controlling host to native host testing. As for speed, well, it is all about latency and reliability, the lower the latency and the higher the reliability, the faster the testing, but, it is, what it is. The modern testsuite might be 8 hour range or more, but overnight testing is better than no testing. If you hide it behind a git send hook and stage everything through git and then push out from git as the testsuite passes... you should be able to achieve a nice work-flow. VMS machines could be considered as slow from today's standard POV. I haven't found a method to run only the compile tests and skip the executing one. Is it possible to do that with the gcc test suite ? If you configure a cross compiler and do a make check, you'll just get a fast fail on all the execute tests. If you just look for regressions, you'll notice this works just fine. Sit back, don't worry about the execution failures. When you wire up sim, just say the simulator is /bin/false or /bin/true (set_board_info sim /bin/false) Feel free to email me directly if you need additional pointers. It is fairly easy to setup, though, daunting, one has never done it before.
Re: [PATCH] Make powerpc honor PROCESSOR_DEFAULT{,64} in tm*.h files
David noticed that I set default_cpu twice in my previous patch. This patch
fixes that, and also updates the ChangeLog message to indicate fixing some
tests for using = 0 instead of 0, since processor 0 is a valid index. I've
bootstrapped both 4.7 and 4.8 with this new patch. Is it ok to install? As I
said, in the original message, we would like to install in 4.7 rather than
waiting for 4.7.1.
2012-03-08 Michael Meissner meiss...@the-meissners.org
* config/rs6000/linux64.h (OPTION_TARGET_CPU_DEFAULT): Do not
redefine to be NULL if the current bit-size is different from the
configured bit-size.
* config/rs6000/rs6000.c (rs6000_option_override_internal): If the
cpu is defaulted, use PROCESSOR_DEFAULT and PROCESSOR_DEFAULT64 to
set the default tuning. Add asserts to make sure the cpu and tune
indexes are defined. Fix tests for cpu/tune index to use = 0 to
test whether the index is set, instead of 0.
(rs6000_file_start): Do not reset the default cpu if the current
bit-size is different from the configured bit-size.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h (revision 185105)
+++ gcc/config/rs6000/linux64.h (working copy)
@@ -159,15 +159,6 @@ extern int dot_symbols;
} \
while (0)
-#ifdef RS6000_BI_ARCH
-
-#undef OPTION_TARGET_CPU_DEFAULT
-#defineOPTION_TARGET_CPU_DEFAULT \
- (((TARGET_DEFAULT ^ target_flags) MASK_64BIT) \
- ? (char *) 0 : TARGET_CPU_DEFAULT)
-
-#endif
-
#undef ASM_DEFAULT_SPEC
#undef ASM_SPEC
#undef LINK_OS_LINUX_SPEC
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 185105)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -2596,6 +2596,7 @@ static bool
rs6000_option_override_internal (bool global_init_p)
{
bool ret = true;
+ bool have_cpu = false;
const char *default_cpu = OPTION_TARGET_CPU_DEFAULT;
int set_masks;
int cpu_index;
@@ -2652,43 +2653,55 @@ rs6000_option_override_internal (bool gl
/* Don't override by the processor default if given explicitly. */
set_masks = ~target_flags_explicit;
- /* Identify the processor type. */
- if (!default_cpu)
-{
- if (TARGET_POWERPC64)
- default_cpu = powerpc64;
- else if (TARGET_POWERPC)
- default_cpu = powerpc;
-}
-
/* Process the -mcpu=xxx and -mtune=xxx argument. If the user changed
the cpu in a target attribute or pragma, but did not specify a tuning
option, use the cpu for the tuning option rather than the option specified
with -mtune on the command line. */
- if (rs6000_cpu_index 0)
-cpu_index = rs6000_cpu_index;
- else if (main_target_opt != NULL main_target_opt-x_rs6000_cpu_index 0)
-rs6000_cpu_index = cpu_index = main_target_opt-x_rs6000_cpu_index;
+ if (rs6000_cpu_index = 0)
+{
+ cpu_index = rs6000_cpu_index;
+ have_cpu = true;
+}
+ else if (main_target_opt != NULL main_target_opt-x_rs6000_cpu_index = 0)
+{
+ rs6000_cpu_index = cpu_index = main_target_opt-x_rs6000_cpu_index;
+ have_cpu = true;
+}
else
-rs6000_cpu_index = cpu_index = rs6000_cpu_name_lookup (default_cpu);
+{
+ if (!default_cpu)
+ default_cpu = (TARGET_POWERPC64 ? powerpc64 : powerpc);
+
+ rs6000_cpu_index = cpu_index = rs6000_cpu_name_lookup (default_cpu);
+}
- if (rs6000_tune_index 0)
+ gcc_assert (cpu_index = 0);
+
+ target_flags = ~set_masks;
+ target_flags |= (processor_target_table[cpu_index].target_enable
+ set_masks);
+
+ if (rs6000_tune_index = 0)
tune_index = rs6000_tune_index;
- else
+ else if (have_cpu)
rs6000_tune_index = tune_index = cpu_index;
-
- if (cpu_index = 0)
+ else
{
- target_flags = ~set_masks;
- target_flags |= (processor_target_table[cpu_index].target_enable
- set_masks);
+ size_t i;
+ enum processor_type tune_proc
+ = (TARGET_POWERPC64 ? PROCESSOR_DEFAULT64 : PROCESSOR_DEFAULT);
+
+ tune_index = -1;
+ for (i = 0; i ARRAY_SIZE (processor_target_table); i++)
+ if (processor_target_table[i].processor == tune_proc)
+ {
+ rs6000_tune_index = tune_index = i;
+ break;
+ }
}
- rs6000_cpu = ((tune_index = 0)
- ? processor_target_table[tune_index].processor
- : (TARGET_POWERPC64
- ? PROCESSOR_DEFAULT64
- : PROCESSOR_DEFAULT));
+ gcc_assert (tune_index = 0);
+ rs6000_cpu = processor_target_table[tune_index].processor;
if (rs6000_cpu == PROCESSOR_PPCE300C2 || rs6000_cpu ==
Re: [PATCH, i386] RTM support
On Tue, Mar 6, 2012 at 2:09 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Updated patch attached.
Technically OK, but let's wait for rth's comments about -mrtm option.
Thanks! Let's wait then.
break;
+ case INT_FTYPE_VOID:
Please add vertical space.
Added.
+(define_expand xbegin
+ [(set (match_operand:SI 0 register_operand =a)
+ (unspec_volatile:SI [(match_dup 1)] UNSPECV_XBEGIN))]
Wrong indent.
Indented.
+#ifdef __RTM__
+#include rtmintrin.h
+#endif
+
+#ifdef __RTM__
+#include xtestintrin.h
+#endif
Probably we don't need two separate #ifdefs.
This is not as suitable, since next feature HLE has this intruction as
well, so condition for xtests will be OR-ed with __HLE__
+/* Copyright (C) 2011 Free Software Foundation, Inc.
Please update copyright year.
Fixed.
+/* { dg-options -mrtm -O0 } */
+/* { dg-options -mrtm -O0 -dp } */
No need to pass -O0 (default) and -dp.
Fixed.
ChangeLog entries were not touched.
The patch is OK for mainline, if there are no further comments in next 24h.
Thanks,
Uros.
Re: [Patch, Fortran] PR 52469
On 08/03/2012 15:13, Tobias Burnus wrote: After a lengthy debugging, I finally found the issue. If I hadn't be concentrating that much on -fwhole-file and if I had had a closer look at the test case before, I hadn't wasted hours tracking this one down ... The problem is that a procedure pointer is used for the interface of a procedure-pointer component. Instead of using the tree declaration of the proc-pointer target, the proc-pointer declaration was used as type - which caused a mess. (The patch is clearer than what I wrote above.) As the test case in the PR works without -fwhole-file (which enabled by default since 4.6), it is a 4.6/4.7/4.8 regression. Build and regtested on x86-64-Linux. OK for the trunk and the 4.6 and 4.7* branch? (* for 4.7.1) Rather obvious (once the fix is known ;-)). OK. Thanks. Mikael.
Re: [patch] Cleanup fortran/convert.c
On 06/03/2012 21:41, Steven Bosscher wrote: Hi, This cleans up some remnants of the ancestors of fortran's convert.c, which was copied from GNAT IIRC. I would bootstraptest this, but trunk appears to be broken for x86_64-linux right now (ICE in patch_jump_insn). But I can post this for review, at least. OK for trunk, after bootstrap+test? Yes. Thanks. Mikael
Re: [PATCH] PR c++/50852 - Revisit dependant template parameter
On 03/08/2012 08:21 AM, Dodji Seketeli wrote: [Handle fix-up for level-reduced a template parameter pack] In the partial instantiation of the member template Aint::f, the level of the parameter pack Us is NOT reduced, even if it ought to be considered as morally reduced. The level of the parameter is reduced, right? It's just that we don't do any substitution of the pattern of the pack expansion, so we still have the unreduced version of the parameter there. I don't think we need morally reduced parameters. Jason
Re: Support for Runtime CPU type detection via builtins (issue5754058)
On Wed, Mar 7, 2012 at 5:51 AM, Richard Guenther richard.guent...@gmail.com wrote: On Wed, Mar 7, 2012 at 1:49 AM, Sriraman Tallam tmsri...@google.com wrote: Patch for CPU detection at run-time. === Patch for CPU detection at run-time, to be used in dispatching of multi-versioned functions. Please see this discussion: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01355.html when this patch for reviewed the last time. For more detailed description: http://gcc.gnu.org/ml/gcc/2012-03/msg00074.html One of the main concerns was about making CPU detection initialization a constructor. The main point raised was about constructor ordering. I have added a priority value to the CPU detection constructor to make it very high priority so that it is guaranteed to fire before every constructor without an explicitly marked priority value of 101. However, IFUNC initializers will still fire before this constructor, so the cpu initialization routine has to be explicitly called in such initializers for which I have added a builtin: __builtin_cpu_init (). This patch adds the following new builtins: * __builtin_cpu_init * __builtin_cpu_supports_cmov * __builtin_cpu_supports_mmx * __builtin_cpu_supports_popcount * __builtin_cpu_supports_sse * __builtin_cpu_supports_sse2 * __builtin_cpu_supports_sse3 * __builtin_cpu_supports_ssse3 * __builtin_cpu_supports_sse4_1 * __builtin_cpu_supports_sse4_2 * __builtin_cpu_is_amd * __builtin_cpu_is_intel_atom * __builtin_cpu_is_intel_core2 * __builtin_cpu_is_intel * __builtin_cpu_is_intel_corei7 * __builtin_cpu_is_intel_corei7_nehalem * __builtin_cpu_is_intel_corei7_westmere * __builtin_cpu_is_intel_corei7_sandybridge * __builtin_cpu_is_amdfam10 * __builtin_cpu_is_amdfam10_barcelona * __builtin_cpu_is_amdfam10_shanghai * __builtin_cpu_is_amdfam10_istanbul * __builtin_cpu_is_amdfam15_bdver1 * __builtin_cpu_is_amdfam15_bdver2 I think the non-feature detection functions are not necessary at all. They are useful if compiler needs to do auto versioning based on cpu model. Builtin functions are not exactly cheap, nor is the scheme you invent backward/forward compatible. Instead, why not add a single builtin function, __builtin_cpu_supports(const char *), and decode from a comma-separated list of features? Unknown features are simply not present. So I can write code with only a single configure check, This is a good idea. __builtin_is_cpu (const char* ); __builtin_cpu_supports (char char*); thanks, David for __builtin_cpu_supports, and cater for future features or older compilers. And of course that builtin would be even cross-platform. Implementation-wise I'll leave this to x86 maintainers to comment on. Richard. * config/i386/i386.c (build_struct_with_one_bit_fields): 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_platform_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_SUPPORTS_CMOV): New enum value. (IX86_BUILTIN_CPU_SUPPORTS_MMX): New enum value. (IX86_BUILTIN_CPU_SUPPORTS_POPCOUNT): New enum value. (IX86_BUILTIN_CPU_SUPPORTS_SSE): New enum value. (IX86_BUILTIN_CPU_SUPPORTS_SSE2): New enum value. (IX86_BUILTIN_CPU_SUPPORTS_SSE3): New enum value. (IX86_BUILTIN_CPU_SUPPORTS_SSSE3): New enum value. (IX86_BUILTIN_CPU_SUPPORTS_SSE4_1): New enum value. (IX86_BUILTIN_CPU_SUPPORTS_SSE4_2): New enum value. (IX86_BUILTIN_CPU_INIT): New enum value. (IX86_BUILTIN_CPU_IS_AMD): New enum value. (IX86_BUILTIN_CPU_IS_INTEL): New enum value. (IX86_BUILTIN_CPU_IS_INTEL_ATOM): New enum value. (IX86_BUILTIN_CPU_IS_INTEL_CORE2): New enum value. (IX86_BUILTIN_CPU_IS_INTEL_COREI7_NEHALEM): New enum value. (IX86_BUILTIN_CPU_IS_INTEL_COREI7_WESTMERE): New enum value. (IX86_BUILTIN_CPU_IS_INTEL_COREI7_SANDYBRIDGE): New enum value. (IX86_BUILTIN_CPU_IS_AMDFAM10_BARCELONA): New enum value. (IX86_BUILTIN_CPU_IS_AMDFAM10_SHANGHAI): New enum value. (IX86_BUILTIN_CPU_IS_AMDFAM10_ISTANBUL): New enum value. (IX86_BUILTIN_CPU_IS_AMDFAM15H_BDVER1): New enum value. (IX86_BUILTIN_CPU_IS_AMDFAM15H_BDVER2): 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
[PATCH, i386]: Simplify indirect_branch_operand predicate
Hello! No functional changes. 2012-03-08 Uros Bizjak ubiz...@gmail.com * config/i386/predicates.md (indirect_branch_operand): Simplify. Tested on x86_64-pc-linux-gnu, committed to mainline SVN. Uros. Index: predicates.md === --- predicates.md (revision 185107) +++ predicates.md (working copy) @@ -566,9 +566,9 @@ ;; Test for a valid operand for indirect branch. (define_predicate indirect_branch_operand - (if_then_else (match_test TARGET_X32) -(match_operand 0 register_operand) -(match_operand 0 nonimmediate_operand))) + (ior (match_operand 0 register_operand) + (and (not (match_test TARGET_X32)) + (match_operand 0 memory_operand ;; Test for a valid operand for a call instruction. (define_predicate call_insn_operand
Remove anachronistic docs about G++ template instantiation
The manual claims a future version of G++ will support a hybrid
instantiation model, which I don't think is still planned, and
describes extern templates as an extension when they are in C++11.
* doc/extend.texi (Template Instantiation): Remove anachronisms.
OK for trunk?
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index c770e35..91f429d 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -15184,16 +15184,7 @@ GNU/Linux or Solaris 2, or on Microsoft Windows, G++
supports the
Borland model. On other systems, G++ implements neither automatic
model.
-A future version of G++ will support a hybrid model whereby the compiler
-will emit any instantiations for which the template definition is
-included in the compile, and store template definitions and
-instantiation context information into the object file for the rest.
-The link wrapper will extract that information as necessary and invoke
-the compiler to produce the remaining instantiations. The linker will
-then combine duplicate instantiations.
-
-In the mean time, you have the following options for dealing with
-template instantiations:
+You have the following options for dealing with template instantiations:
@enumerate
@item
@@ -15255,9 +15246,10 @@ compile it without @option{-fno-implicit-templates} so
you get all of the
instances required by your explicit instantiations (but not by any
other files) without having to specify them as well.
-G++ has extended the template instantiation syntax given in the ISO
-standard to allow forward declaration of explicit instantiations
-(with @code{extern}), instantiation of the compiler support data for a
+The ISO C++ 2011 standard allows forward declaration of explicit
+instantiations (with @code{extern}). G++ supports explicit instantiation
+declarations in C++98 mode and has extended the template instantiation
+syntax to support instantiation of the compiler support data for a
template class (i.e.@: the vtable) without instantiating any of its
members (with @code{inline}), and instantiation of only the static data
members of a template class, without the support data or member
[pph] Merge fields and methods, etc. (issue5781061)
This patch provides three primary fixes.
* Merge structure fields and methods.
This merging is necessary because a field or method declaration may be
updated with a definition.
Tests x4keyed.cc, x4keyex.cc, and x4keyno.cc expose a problem with
callgraphs and are no longer passing. Test x7rtti.cc exposes the same
problem, but it was not passing before.
Test x4incomplete4321.cc exposes a problem with gimple expansion, but
it was not passing before.
Test x4incomplete4123.cc newly fails emitting an unneeded function.
Tests x4tmplclass2.cc, z4tmplclass1.cc, and z4tmplclass2.cc newly pass.
* Distinguish template type parameters in error output.
The problem here is that the merge names were the same for different
types. The change was to add the source location information as a
qualifier to the template parameter name in error pretty printing.
Control this with a TFF flag.
New tests x0dependent.h and x1dependent.cc pass.
* Remove gcc_assert in mangle.c added in the last patch.
We restore this assert mostly to reduce any future client merge
burden.
Test x6dynarray5.cc now fails differently
In addition there are some infrastructure changes.
* Add capability to add notes to the trace output. This capability is
used to emit merge names into the trace.
* Add functions pph_out_struct_function_for_decl and
pph_out_cgraph_node_for_decl to provide a better debugging handle on
symtab expansion.
Index: gcc/testsuite/ChangeLog.pph
2012-03-07 Lawrence Crowl cr...@google.com
* g++.dg/pph/x0dependent.h: New.
* g++.dg/pph/x1dependent.cc: New.
* g++.dg/pph/x4incomplete4123.cc: Mark xdiff on extra function.
* g++.dg/pph/x4incomplete4321.cc: Mark ICE on gimple.
* g++.dg/pph/x4keyed.cc: Mark ICE on cgraph.
* g++.dg/pph/x4keyex.cc: Mark ICE on cgraph.
* g++.dg/pph/x4keyno.cc: Mark ICE on cgraph.
* g++.dg/pph/x4tmplclass1.cc: Mark change in labels.
* g++.dg/pph/x4tmplclass2.cc: Mark xokay.
* g++.dg/pph/x6dynarray5.cc: Mark different ICE.
* g++.dg/pph/x7rtti.cc: Mark ICE on cgraph.
* g++.dg/pph/z4tmplclass1.cc: Mark xokay.
* g++.dg/pph/z4tmplclass2.cc: Mark xokay.
Index: gcc/cp/ChangeLog.pph
2012-03-07 Lawrence Crowl cr...@google.com
* cp-tree.h (TFF_LOC_FOR_TEMPLATE_PARMS): New.
* error.c (dump_location_qualifier): New.
(dump_type): Add source location qualifier to template type parameter
identifiers.
* mangle.c (write_template_arg_literal): Revert to prior code.
* pph-streamer.h (pph_trace_note): New.
* pph-core.c (pph_trace_note): New.
* pph-out.c (pph_out_struct_function_for_decl): New.
(pph_out_cgraph_node_for_decl): New.
(pph_out_symtab): Update to use functions above.
(pph_merge_name): Add TFF_LOC_FOR_TEMPLATE_PARMS for pretty name.
(pph_out_merge_name): Trace merge names.
(pph_out_merge_key_tree): Emit merge keys for class fields and methods.
* pph-in.c (pph_in_merge_key_tree_with_searcher): Merge in keys for
class fields and methods.
Index: gcc/testsuite/g++.dg/pph/x4keyno.cc
===
--- gcc/testsuite/g++.dg/pph/x4keyno.cc (revision 184901)
+++ gcc/testsuite/g++.dg/pph/x4keyno.cc (working copy)
@@ -1,4 +1,7 @@
-// pph asm xokay 32642
+// { dg-xfail-if ICE { *-*-* } { -fpph-map=pph.map } }
+// { dg-bogus x4keyno.cc:13:1: internal compiler error: in
cgraph_analyze_functions, at cgraphunit.c:1210 { xfail *-*-* } 0 }
+
+// was asm xokay 32642
#include x0keyno1.h
#include x0keyno2.h
Index: gcc/testsuite/g++.dg/pph/x6dynarray5.h
===
--- gcc/testsuite/g++.dg/pph/x6dynarray5.h (revision 184901)
+++ gcc/testsuite/g++.dg/pph/x6dynarray5.h (working copy)
@@ -3,7 +3,7 @@
// { dg-bogus bits/allocator.h:153:12: sorry, unimplemented: mangling
trait_expr { xfail *-*-* } 0 }
// { dg-bogus bits/stl_construct.h:98:12: sorry, unimplemented: mangling
trait_expr { xfail *-*-* } 0 }
// { dg-bogus bits/stl_tempbuf.h:183:12: sorry, unimplemented: mangling
trait_expr { xfail *-*-* } 0 }
-// { dg-bogus bits/cpp_type_traits.h:87:12: internal compiler error: in
write_template_arg_literal, at cp/mangle.c:2919 { xfail *-*-* } 0 }
+// { dg-bogus bits/cpp_type_traits.h:87:12: internal compiler error: tree
check: expected integer_cst, have const_decl in tree_int_cst_sgn, at
tree.c:6567 { xfail *-*-* } 0 }
#ifndef X6DYNARRAY5_H
#define X6DYNARRAY5_H
Index: gcc/testsuite/g++.dg/pph/x7rtti.cc
===
--- gcc/testsuite/g++.dg/pph/x7rtti.cc (revision 184901)
+++ gcc/testsuite/g++.dg/pph/x7rtti.cc (working copy)
@@ -1,7 +1,8 @@
-// {xfail-if UNKNOWN MACRO AND BOGUS RTTI { *-*-* } {
-fpph-map=pph.map } }
-// { dg-bogus x7rtti.cc:9:0: warning: .__STDC_IEC_559_COMPLEX__. redefined
{ xfail
[Patch, libfortran] PR 52434/48878/38199 Improve floating point formatted writes
Hi, the attached patch implements some improvements for formatted writes of floating point values. Currently libgfortran uses snprintf() to fill a buffer with a fixed amount of digits, regardless of the digits required, and then rounding or zero extending as needed. The patch changes this to first figure out the number of digits needed, then using snprintf() to fill the buffer with exactly the needed amount of digits (except when a ROUND= specifier is used, in that case more digits are generated). This has a few advantages: - As the performance cost of snprintf() increases roughly linearly with more digits (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199#c13 ), we needlessly waste cycles when we don't need all the digits. The attached write-many.f90 benchmark is almost twice as fast; best of five timings with current trunk: real0m2.055s with patch: real0m1.268s - Although we generate enough digits to be able to get back the original value exactly when reading, there are some (valid?) usecases where more digits are needed. Exhibit 1 is dyadic.f90 which prints a couple dyadic fractions which are exact both in binary and character representations. With current trunk: $ ./dyadic_f .0004940656458412465441765687928682213723650600 .99988897769753748434595763683 With patch: $ ./dyadic_f . 0 00494065645841246544176568792868221372365059802614324 76442558568250067550727020875186529983636163599237979656469544571773092665671035593979639877479601078187812630071319031140452 78458171678489821036887186360569987307230500063874091535649843873124733972731696151400317153853980741262385655911710266585566 8676818703956031062493194527159149245532930545654440112748012970541931989409080416563324524757147869014726780159355238611 55013480352649347201937902681071074917033322268447533357208324319360923828934583680601060115061698097530783422773183292479049 82524730776375927247874656084778203734469699533647017972677717585125660551199131504891101451037862738167250955837389733598993 664809941164205702637090279242767544565229087538682506419718265533447265625 .99988897769753748434595763683319091796875 For another example, Bob Corbett recently posted boz_corbett.f90 on c.l.f. With trunk: $ ./boz_corbett .67242062862241870125253556346435045576786000...E-4931 where ... is a very long string of zeros. With patch: $ ./boz_corbett .672420628622418701252535563464350455767864674589043138777375863685283014882452413061808444374167...E-4931 where ... is a very long string of digits. - With the patch, for the vast majority of Fortran programs which don't use the F2003 ROUND= specifier, we let snprintf() do the rounding (as we generate the correct number of digits to begin with). Thus isolating the user from potential bugs in the rounding logic in libgfortran, as well as the performance impacts of that same code. Note that GFortran previously did roundTiesToAway, whereas at least glibc snprintf() does roundTiesToEven, so some change in behavior is expected. Anyway, this is IMHO for the better, as it avoids biasing the magnitude upwards in some common cases. Also, roundTiesToAway is the default rounding mode for arithmetic. Regtested on x86_64-unknown-linux-gnu, Ok for trunk? 2012-03-09 Janne Blomqvist j...@gcc.gnu.org PR libfortran/52434 PR libfortran/48878 PR libfortran/38199 * io/unit.c (get_internal_unit): Default to ROUND_UNSPECIFIED. (init_units): Likewise. * io/write_float.def (determine_precision): New function. (output_float): Take into account buffer with %f format, no need for our own
Re:
On 08/03/12 14:55 , Han Shen(沈涵) wrote: +2012-03-02 Han Shen shen...@google.com mailto:shen...@google.com + + Backport r184357 from trunk + + 2012-02-17 Doug Kwan dougk...@google.com mailto:dougk...@google.com + + * contrib/testsuite-management/validate_failures.py + (GetMakefileValue): Check for cross compilers. + Looks fine. Thanks. Diego.
Go patch committed: Avoid zero-sized global variables
Jakub told me that some tests are failing when using GNU ld because GNU
ld issues an error if it sees a dynamic symbol which is a global
variable with zero size. Go permits types with zero size, and such
variables are not an error in Go. This patch avoids these variables at
the level of the gcc interface, by converting externally visible global
variables with zero size to have a 1 byte size instead. This required
changing the initialization and assignment code to avoid initializing
and assigning zero-sized values. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2012-03-08 Ian Lance Taylor i...@google.com
* go-gcc.cc (Gcc_backend::init_statement): Don't initialize a
zero-sized variable.
(go_non_zero_struct): New global variable.
(Gcc_backend::non_zero_size_type): New function.
(Gcc_backend::global_variable): Don't build an assignment for a
zero-sized value.
* go-c.h (go_non_zero_struct): Declare.
* config-lang.in (gtfiles): Add go-c.h.
Index: gcc/go/go-gcc.cc
===
--- gcc/go/go-gcc.cc (revision 184684)
+++ gcc/go/go-gcc.cc (working copy)
@@ -338,6 +338,9 @@ class Gcc_backend : public Backend
Btype*
fill_in_array(Btype*, Btype*, Bexpression*);
+
+ tree
+ non_zero_size_type(tree);
};
// A helper function.
@@ -870,9 +873,27 @@ Gcc_backend::init_statement(Bvariable* v
if (var_tree == error_mark_node || init_tree == error_mark_node)
return this-error_statement();
gcc_assert(TREE_CODE(var_tree) == VAR_DECL);
- DECL_INITIAL(var_tree) = init_tree;
- return this-make_statement(build1_loc(DECL_SOURCE_LOCATION(var_tree),
- DECL_EXPR, void_type_node, var_tree));
+
+ // To avoid problems with GNU ld, we don't make zero-sized
+ // externally visible variables. That might lead us to doing an
+ // initialization of a zero-sized expression to a non-zero sized
+ // variable, or vice-versa. Avoid crashes by omitting the
+ // initializer. Such initializations don't mean anything anyhow.
+ if (int_size_in_bytes(TREE_TYPE(var_tree)) != 0
+ init_tree != NULL_TREE
+ int_size_in_bytes(TREE_TYPE(init_tree)) != 0)
+{
+ DECL_INITIAL(var_tree) = init_tree;
+ init_tree = NULL_TREE;
+}
+
+ tree ret = build1_loc(DECL_SOURCE_LOCATION(var_tree), DECL_EXPR,
+ void_type_node, var_tree);
+ if (init_tree != NULL_TREE)
+ret = build2_loc(DECL_SOURCE_LOCATION(var_tree), COMPOUND_EXPR,
+ void_type_node, init_tree, ret);
+
+ return this-make_statement(ret);
}
// Assignment.
@@ -885,6 +906,18 @@ Gcc_backend::assignment_statement(Bexpre
tree rhs_tree = rhs-get_tree();
if (lhs_tree == error_mark_node || rhs_tree == error_mark_node)
return this-error_statement();
+
+ // To avoid problems with GNU ld, we don't make zero-sized
+ // externally visible variables. That might lead us to doing an
+ // assignment of a zero-sized expression to a non-zero sized
+ // expression; avoid crashes here by avoiding assignments of
+ // zero-sized expressions. Such assignments don't really mean
+ // anything anyhow.
+ if (int_size_in_bytes(TREE_TYPE(lhs_tree)) == 0
+ || int_size_in_bytes(TREE_TYPE(rhs_tree)) == 0)
+return this-compound_statement(this-expression_statement(lhs),
+this-expression_statement(rhs));
+
return this-make_statement(fold_build2_loc(location.gcc_location(),
MODIFY_EXPR,
void_type_node,
@@ -1178,6 +1211,48 @@ Gcc_backend::block_statement(Bblock* bbl
return this-make_statement(bind_tree);
}
+// This is not static because we declare it with GTY(()) in go-c.h.
+tree go_non_zero_struct;
+
+// Return a type corresponding to TYPE with non-zero size.
+
+tree
+Gcc_backend::non_zero_size_type(tree type)
+{
+ if (int_size_in_bytes(type) != 0)
+return type;
+
+ switch (TREE_CODE(type))
+{
+case RECORD_TYPE:
+ {
+ if (go_non_zero_struct == NULL_TREE)
+ {
+ type = make_node(RECORD_TYPE);
+ tree field = build_decl(UNKNOWN_LOCATION, FIELD_DECL,
+get_identifier(dummy),
+boolean_type_node);
+ DECL_CONTEXT(field) = type;
+ TYPE_FIELDS(type) = field;
+ layout_type(type);
+ go_non_zero_struct = type;
+ }
+ return go_non_zero_struct;
+ }
+
+case ARRAY_TYPE:
+ {
+ tree element_type = non_zero_size_type(TREE_TYPE(type));
+ return build_array_type_nelts(element_type, 1);
+ }
+
+default:
+ gcc_unreachable();
+}
+
+ gcc_unreachable();
+}
+
// Make a global variable.
Bvariable*
@@ -1193,6 +1268,10 @@ Gcc_backend::global_variable(const std::
if (type_tree == error_mark_node)
return this-error_variable();
+ // The GNU linker does not like dynamic variables with zero size.
+ if ((is_external || !is_hidden) int_size_in_bytes(type_tree) == 0)
+type_tree = this-non_zero_size_type(type_tree);
+
Re: [PATCH] gfortran testsuite: implicitly cleanup-modules
On 01/03/2012 22:09, Bernhard Reutner-Fischer wrote: Hi, By now we have quite some leftover modules in the testsuite, again. Given that the previous suggestion in this thread -- to have a separate script in contrib -- did not trigger any reaction, let me suggest the patch below instead. Teach the testsuite to cleanup the modules. We do this by grepping for the module names and implicitly deleting them when the test is finished. For the testcases that use modules from other files we introduce a keep-modules procedure that keeps either all (, i.e. empty list) or the given modules of the source file. A follow-up patch would remove the now superfluous cleanup-module calls in the remaining testcases. Since that patch is pretty big (~360k) i do not intend to send it in but want to apply it straight to the repo (it's just a sed '/cleanup-modules/d' on the testcases that do not occur in the below patch). Is it ok to reference ../doc in the ChangeLog entry below to keep the documentation change associated with the script itself? No, the changes are associated by being in the same commit (and their ChangeLog entries in the same subversion commit log). The patch was bootstrapped and regression tested using tcl-8.5 on x86_64-linux-gnu with no new regressions. Ok for trunk? According to http://tmml.sourceforge.net/doc/tcl/regexp.html you can use the -nocase option (= case insensitive) to simplify the regexp patterns. I noticed one whitespace inconsistency in keep-modules. Otherwise it looks good to me (but I'm not a testsuite maintainer). Mikael
[gimplefe] [patch] splits cpp_lshift and cpp_rshift tokens into discrete cpp_less and cpp_greater tokens respectively
Hi,
The current patch splits cpp_lshift and cpp_rshift tokens into
cpp_less and cpp_greater tokens respectively.The necessary changes due
to this are made throughout the parser. The changelog is as follows.
Up for review.
2012-03-08 Sandeep Soni soni.sande...@gmail.com
* parser.c (gl_lex_token): For every CPP_LSHIFT and CPP_RSHIFT tokens,
split the token into two discrete CPP_LESS and CPP_GREATER tokens
respectively.
(gl_split_token): New. The split function for the case above.
(gl_token_is_of_type): New. Checks if the tokens type is the expected
type.
(gp_parse_var_decl): Changing consumption of CPP_LSHIFT and CPP_RSHIFT
tokens into CPP_LESS and CPP_GREATER tokens.
(gp_parse_record_type): Ditto.
(gp_parse_union_type): Ditto.
(gp_parse_cond_stmt): Ditto.
(gp_parse_goto_stmt): Ditto.
(gp_parse_label_stmt): Ditto.
(gp_parse_switch_stmt): Ditto.
--
Cheers
Sandy
Index: gcc/gimple/parser.c
===
--- gcc/gimple/parser.c (revision 184993)
+++ gcc/gimple/parser.c (working copy)
@@ -494,7 +494,8 @@
{
gl_consume_expected_token (parser-lexer, CPP_LESS);
gl_consume_expected_token (parser-lexer, CPP_NAME);
- gl_consume_expected_token (parser-lexer, CPP_RSHIFT);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
}
/* Parse a gimple_cond tuple that is read from the reader PARSER. For now we only
@@ -516,9 +517,11 @@
static void
gp_parse_goto_stmt (gimple_parser *parser)
{
- gl_consume_expected_token (parser-lexer, CPP_LSHIFT);
+ gl_consume_expected_token (parser-lexer, CPP_LESS);
+ gl_consume_expected_token (parser-lexer, CPP_LESS);
gl_consume_expected_token (parser-lexer, CPP_NAME);
- gl_consume_expected_token (parser-lexer, CPP_RSHIFT);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
}
/* Parse a gimple_label tuple that is read from the reader PARSER. For now we only
@@ -527,9 +530,11 @@
static void
gp_parse_label_stmt (gimple_parser *parser)
{
- gl_consume_expected_token (parser-lexer, CPP_LSHIFT);
+ gl_consume_expected_token (parser-lexer, CPP_LESS);
+ gl_consume_expected_token (parser-lexer, CPP_LESS);
gl_consume_expected_token (parser-lexer, CPP_NAME);
- gl_consume_expected_token (parser-lexer, CPP_RSHIFT);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
}
/* Parse a gimple_switch tuple that is read from the reader PARSER. For now we only
@@ -547,25 +552,23 @@
gl_consume_expected_token (parser-lexer, CPP_COLON);
gl_consume_expected_token (parser-lexer, CPP_LESS);
gl_consume_expected_token (parser-lexer, CPP_NAME);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
while (!gl_at_eof (parser-lexer))
{
next_token = gl_consume_token (parser-lexer);
- if (next_token-type == CPP_GREATER)
+ if (next_token-type == CPP_COMMA)
{
- gl_consume_expected_token (parser-lexer, CPP_COMMA);
gl_consume_expected_token (parser-lexer, CPP_NAME);
gl_consume_expected_token (parser-lexer, CPP_NUMBER);
gl_consume_expected_token (parser-lexer, CPP_COLON);
gl_consume_expected_token (parser-lexer, CPP_LESS);
- gl_consume_expected_token (parser-lexer, CPP_NAME);
+ gl_consume_expected_token (parser-lexer, CPP_NAME);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
}
- else if (next_token-type == CPP_RSHIFT)
-{
- next_token = gl_consume_token (parser-lexer);
- break;
-}
+ else if (next_token-type == CPP_GREATER)
+break;
else
error_at (next_token-location,
Incorrect use of the gimple_switch statement);
@@ -715,14 +718,14 @@
static void
gp_parse_expect_field_decl (gimple_parser *parser)
{
- gl_consume_expected_token (parser-lexer, CPP_NAME);
gl_consume_expected_token (parser-lexer, CPP_LESS);
gl_consume_expected_token (parser-lexer, CPP_NAME);
gl_consume_expected_token (parser-lexer, CPP_COMMA);
gl_consume_expected_token (parser-lexer, CPP_NAME);
gl_consume_expected_token (parser-lexer, CPP_LESS);
gl_consume_expected_token (parser-lexer, CPP_NUMBER);
- gl_consume_expected_token (parser-lexer, CPP_RSHIFT);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
+ gl_consume_expected_token (parser-lexer, CPP_GREATER);
}
@@ -788,7 +791,9 @@
};
The tuple representation is done as :
- UNION_TYPE some_union,4,FIELD_DECLfirst_var,INTEGER_TYPE4,FIELD_DECLsecond_var,REAL_TYPE4
+ UNION_TYPE some_union,4,
+ FIELD_DECL first_var,INTEGER_TYPE4,
+ FIELD_DECLsecond_var,REAL_TYPE4
*/
/* Recognizer function for Union declarations. The union tuple is
[ARM] atomics for rtems, aka bare metal
On 03/08/12 10:02, Joel Sherrill wrote:
If so, it is just a matter of ifdef's to get the right code.
Ok.
Does arm-eabi have this support? We probably could
just use the same code.
There's scant bare metal support atm. For sufficiently new ARM core revisions,
gcc will inline operations. In order to get all of it, you have to target
ARMv7.
I threw this together today. It likely needs quite a bit of spit and polish:
* There's quite a bit of boiler plate that could be shared with lib1funcs.S.
* I know Richard E has cautioned me time and again about SWP, but
I have to assume that it's useful for at least some CPU revisions.
Knowing exactly when and where is the trick. E.g. it might be correct
to use them on arm-rtems, but not generically for arm-eabi.
* It might be cleaner to split this into multiple files, which can
be re-used in interesting ways. For instance, when targeting ARMv6
it might be a win to use some of these routines instead of linux-atomic.c,
particularly when lacking LDREX[BH].
* The __atomic_fetch_op and __atomic_op_fetch routines are missing.
* Given that this is bare metal, and pre-ARMv6 is certainly non-SMP, you
might well want to provide fallback versions of these routines that
disable interrupts.
* This has received only compile testing with the arm-rtemseabi multilibs.
There may well be bugs.
* It's quite likely that this actually belongs in the not-yet-extant libatomic
and not in libgcc at all.
r~
diff --git a/libgcc/config.host b/libgcc/config.host
index 257622a..251ecb6 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -359,7 +359,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
tm_file=$tm_file arm/bpabi-lib.h
case ${host} in
arm*-*-eabi* | arm*-*-rtemseabi*)
- tmake_file=${tmake_file} arm/t-bpabi
+ tmake_file=${tmake_file} arm/t-bpabi arm/t-atomic
extra_parts=crtbegin.o crtend.o crti.o crtn.o
;;
arm*-*-symbianelf*)
diff --git a/libgcc/config/arm/native-atomic.S
b/libgcc/config/arm/native-atomic.S
new file mode 100644
index 000..d646706
--- /dev/null
+++ b/libgcc/config/arm/native-atomic.S
@@ -0,0 +1,509 @@
+/* Atomic operations for ARM, assuming only native cpu support.
+ 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.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+http://www.gnu.org/licenses/. */
+
+
+#if defined(__ARM_ARCH_2__)
+# define __ARM_ARCH__ 2
+#endif
+
+#if defined(__ARM_ARCH_3__) || defined(__ARM_ARCH_3M__)
+# define __ARM_ARCH__ 3
+#endif
+
+#if defined(__ARM_ARCH_4__) || defined(__ARM_ARCH_4T__)
+# define __ARM_ARCH__ 4
+#endif
+
+#if defined(__ARM_ARCH_5__) || defined(__ARM_ARCH_5T__) \
+ || defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__) \
+ || defined(__ARM_ARCH_5TEJ__)
+# define __ARM_ARCH__ 5
+#endif
+
+#if defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) \
+ || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6Z__) \
+ || defined(__ARM_ARCH_6ZK__) || defined(__ARM_ARCH_6T2__) \
+ || defined(__ARM_ARCH_6M__)
+# define __ARM_ARCH__ 6
+#endif
+
+#if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) \
+ || defined(__ARM_ARCH_7R__) || defined(__ARM_ARCH_7M__) \
+ || defined(__ARM_ARCH_7EM__)
+# define __ARM_ARCH__ 7
+#endif
+
+#ifndef __ARM_ARCH__
+#error Unable to determine architecture.
+#endif
+
+#if __ARM_ARCH__ = 7 || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6ZK__)
+# define HAVE_STREX
+# define HAVE_STREXB
+# define HAVE_STREXH
+# define HAVE_STREXD
+#elif __ARM_ARCH__ == 6
+# define HAVE_STREX
+#elif __ARM_ARCH__ == 4 || __ARM_ARCH__ == 5
+/* This assumes that we are *not* running on ARM6+ SMP. */
+# define HAVE_SWP
+#endif
+
+#ifdef __ARM_EABI__
+/* Some attributes that are common to all routines in this file. */
+ /* Tag_ABI_align_needed: This code does not require 8-byte
+ alignment from the caller. */
+ /* .eabi_attribute 24, 0 -- default setting. */
+ /* Tag_ABI_align_preserved: This code preserves 8-byte
+ alignment in any callee. */
+ .eabi_attribute 25, 1
[google/integration] Add xfail file for powerpc64-grtev2-linux-gnu (issue5784062)
Hi Diego, This patch adds an XFAIL file for the powerpc64-grtev2-linux-gnu target. -Doug 2012-03-08 Doug Kwan dougk...@google.com * contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail: New file. Index: contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail === --- contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail (revision 0) +++ contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail (revision 0) @@ -0,0 +1,111 @@ +# *** gcc: +FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects +UNRESOLVED: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects +FAIL: gcc.c-torture/execute/builtins/memmove-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects +UNRESOLVED: gcc.c-torture/execute/builtins/memmove-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects +FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects +UNRESOLVED: gcc.c-torture/execute/builtins/mempcpy-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects +FAIL: gcc.c-torture/execute/20020226-1.c execution, -O0 +FAIL: gcc.c-torture/execute/20020226-1.c execution, -O1 +FAIL: gcc.c-torture/execute/20020226-1.c execution, -O2 +FAIL: gcc.c-torture/execute/20020226-1.c execution, -O3 -fomit-frame-pointer +FAIL: gcc.c-torture/execute/20020226-1.c execution, -O3 -g +FAIL: gcc.c-torture/execute/20020226-1.c execution, -Os +FAIL: gcc.c-torture/execute/20020226-1.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none +FAIL: gcc.c-torture/execute/20020508-1.c execution, -O0 +FAIL: gcc.c-torture/execute/20020508-1.c execution, -O1 +FAIL: gcc.c-torture/execute/20020508-1.c execution, -O2 +FAIL: gcc.c-torture/execute/20020508-1.c execution, -O3 -fomit-frame-pointer +FAIL: gcc.c-torture/execute/20020508-1.c execution, -O3 -g +FAIL: gcc.c-torture/execute/20020508-1.c execution, -Os +FAIL: gcc.c-torture/execute/20020508-1.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none +FAIL: gcc.c-torture/execute/pr52129.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects +UNRESOLVED: gcc.c-torture/execute/pr52129.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects +FAIL: gcc.dg/and-1.c scan-assembler-not nand +FAIL: gcc.dg/cleanup-10.c execution test +FAIL: gcc.dg/cleanup-11.c execution test +FAIL: gcc.dg/cleanup-8.c execution test +FAIL: gcc.dg/cleanup-9.c execution test +FAIL: gcc.dg/cproj-fails-with-broken-glibc.c execution test +FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = 2 +FAIL: gcc.dg/pr46728-6.c scan-assembler-not pow +FAIL: gcc.dg/torture/vec-cvt-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) + +# These are flaky when tested with QEMU (they exceed the timeout) +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O0 execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O1 execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O2 execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O3 -fomit-frame-pointer execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O3 -g execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -Os execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O0 -fpic execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O1 -fpic execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O2 -fpic execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O3 -fomit-frame-pointer -fpic execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O3 -g -fpic execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -Os -fpic execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O0 -fPIC execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O1 -fPIC execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O2 -fPIC execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O3 -fomit-frame-pointer -fPIC execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O3 -g -fPIC execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -Os -fPIC execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O0 -pie -fpie execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O1 -pie -fpie execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O2 -pie -fpie execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O3 -fomit-frame-pointer -pie -fpie execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O3 -g -pie -fpie execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -Os -pie -fpie execution test +flaky | FAIL: gcc.dg/torture/tls/tls-test.c -O0 -pie -fPIE execution test +flaky | FAIL:
Re: [google/integration] Add xfail file for powerpc64-grtev2-linux-gnu (issue5784062)
On 08/03/12 18:06 , Doug Kwan wrote: 2012-03-08 Doug Kwandougk...@google.com * contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail: New file. OK. Diego.
libgo patch committed: Don't crash if can't get line numbers
This patch to libgo avoids crashing the program if for some reason we
can't get line number information. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 27261b2b1db7 libgo/go/debug/elf/runtime.go
--- a/libgo/go/debug/elf/runtime.go Thu Mar 08 15:28:14 2012 -0800
+++ b/libgo/go/debug/elf/runtime.go Thu Mar 08 21:28:13 2012 -0800
@@ -129,7 +129,7 @@
// and line number for a PC value.
func funcFileLine(pc uintptr, function *string, file *string, line *int) bool {
openExecutable()
- if executable.dwarf == nil {
+ if executable == nil || executable.dwarf == nil {
return false
}
f, ln, err := executable.dwarf.FileLine(uint64(pc))
[google/integration] disable symbol hiding in libgcc for grtev3 targets (issue5792054)
To be submitted to google/integration and merged to google/{main,gcc-4_7}.
Would also like to have this considered for trunk, since this patch has no
impact on non-grtev3 targets.
Disable hiding of symbols in static libgcc libraries when built for GRTE v3.
This allows pthread_cancel to perform stack unwinding when libgcc_eh.a is
linked into dynamic executables. However, this opens up a hole wherein shared
libraries linked with -static-libgcc cannot be individually modified without
risk of breaking dependent libraries. That's okay in the GRTE v3 environment
because libgcc is compiled without -fPIC anyway.
See http://gcc.gnu.org/ml/gcc/2012-03/msg00104.html for details.
Google ref 5836136.
2012-03-08 Ollie Wild a...@google.com
* libgcc/Makefile.in (vis_hide): Move default initialization before
inclusion of $(tmake_file).
* libgcc/config.host (*-grtev3-*): Disable hiding of symbols in static
libraries.
* libgcc/config/t-static-no-vis-hide: New file.
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 23b72b9..41fbb96 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -334,6 +334,12 @@ LIBUNWIND =
SHLIBUNWIND_LINK =
SHLIBUNWIND_INSTALL =
+# For -fvisibility=hidden. We need both a -fvisibility=hidden on
+# the command line, and a #define to prevent libgcc2.h etc from
+# overriding that with #pragmas. This is set before including $(tmake_file)
+# so it can be overridden on a host-specific basis.
+vis_hide = @vis_hide@
+
tmake_file = @tmake_file@
include $(srcdir)/empty.mk $(tmake_file)
@@ -363,11 +369,6 @@ ifeq ($(enable_shared),yes)
install-libunwind = install-libunwind
endif
-# For -fvisibility=hidden. We need both a -fvisibility=hidden on
-# the command line, and a #define to prevent libgcc2.h etc from
-# overriding that with #pragmas.
-vis_hide = @vis_hide@
-
ifneq (,$(vis_hide))
# If we have -fvisibility=hidden, then we need to generate hide
diff --git a/libgcc/config.host b/libgcc/config.host
index 257622a..242fbd5 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1174,3 +1174,10 @@ i[34567]86-*-linux* | x86_64-*-linux*)
tm_file=${tm_file} i386/value-unwind.h
;;
esac
+
+case ${host} in
+*-grtev3-*)
+ # Don't hide symbols in static libraries.
+ tmake_file=${tmake_file} t-static-no-vis-hide
+ ;;
+esac
diff --git a/libgcc/config/t-static-no-vis-hide
b/libgcc/config/t-static-no-vis-hide
new file mode 100644
index 000..955ff35
--- /dev/null
+++ b/libgcc/config/t-static-no-vis-hide
@@ -0,0 +1,2 @@
+# Don't hide symbols in static libraries.
+vis_hide =
--
This patch is available for review at http://codereview.appspot.com/5792054
[BFIN] PR target/49862
Hi,
I have committed this patch on trunk for PR target/49862.
Regards,
Jie
PR target/49862
* config/bfin/bfin.c (hwloop_optimize): Fix unused variable
warnings.
(hwloop_pattern_reg): Fix set but not used warning.
(bfin_reorg_loops): Remove unused parameter.
(bfin_reorg): Update use of bfin_reorg_loops.
Index: config/bfin/bfin.c
===
--- config/bfin/bfin.c (revision 185124)
+++ config/bfin/bfin.c (working copy)
@@ -3411,14 +3411,12 @@ static bool
hwloop_optimize (hwloop_info loop)
{
basic_block bb;
- hwloop_info inner;
rtx insn, last_insn;
rtx loop_init, start_label, end_label;
rtx iter_reg, scratchreg, scratch_init, scratch_init_insn;
rtx lc_reg, lt_reg, lb_reg;
rtx seq, seq_end;
int length;
- unsigned ix;
bool clobber0, clobber1;
if (loop-depth MAX_LOOP_DEPTH)
@@ -3840,12 +3838,11 @@ hwloop_fail (hwloop_info loop)
static rtx
hwloop_pattern_reg (rtx insn)
{
- rtx pat, reg;
+ rtx reg;
if (!JUMP_P (insn) || recog_memoized (insn) != CODE_FOR_loop_end)
return NULL_RTX;
- pat = PATTERN (insn);
reg = SET_DEST (XVECEXP (PATTERN (insn), 0, 1));
if (!REG_P (reg))
return NULL_RTX;
@@ -3864,7 +3861,7 @@ static struct hw_doloop_hooks bfin_doloo
hardware loops are generated. */
static void
-bfin_reorg_loops (FILE *dump_file)
+bfin_reorg_loops (void)
{
reorg_loops (true, bfin_doloop_hooks);
}
@@ -4601,7 +4598,7 @@ bfin_reorg (void)
/* Doloop optimization */
if (cfun-machine-has_hardware_loops)
-bfin_reorg_loops (dump_file);
+bfin_reorg_loops ();
workaround_speculation ();
Re: [google/integration] disable symbol hiding in libgcc for grtev3 targets (issue 5792054)
http://codereview.appspot.com/5792054/diff/1/libgcc/config.host File libgcc/config.host (right): http://codereview.appspot.com/5792054/diff/1/libgcc/config.host#newcode1179 libgcc/config.host:1179: Perhaps *-grte* would be more future-proof? http://codereview.appspot.com/5792054/
Re: [google/integration] disable symbol hiding in libgcc for grtev3 targets (issue 5792054)
http://codereview.appspot.com/5792054/diff/1/libgcc/config.host File libgcc/config.host (right): http://codereview.appspot.com/5792054/diff/1/libgcc/config.host#newcode1179 libgcc/config.host:1179: On 2012/03/09 06:01:08, ppluzhnikov wrote: Perhaps *-grte* would be more future-proof? The GRTE v2 targets besides x86 already use *-grtev2-*. I'm reluctant to change the behavior of those existing targets. http://codereview.appspot.com/5792054/
libgo patch committed: Support DWARF versions 3 and 4
This patch to libgo extends the DWARF reader to handle DWARF versions 3
and 4. It also includes some patches to the line number reading code
based on tests using DWARF version 4. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 976886593e1f libgo/go/debug/dwarf/buf.go
--- a/libgo/go/debug/dwarf/buf.go Thu Mar 08 21:32:43 2012 -0800
+++ b/libgo/go/debug/dwarf/buf.go Thu Mar 08 22:32:23 2012 -0800
@@ -14,16 +14,16 @@
// Data buffer being decoded.
type buf struct {
dwarf*Data
+ u*unit
orderbinary.ByteOrder
name string
off Offset
data []byte
- addrsize int
err error
}
-func makeBuf(d *Data, name string, off Offset, data []byte, addrsize int) buf {
- return buf{d, d.order, name, off, data, addrsize, nil}
+func makeBuf(d *Data, u *unit, name string, off Offset, data []byte) buf {
+ return buf{d, u, d.order, name, off, data, nil}
}
func (b *buf) uint8() uint8 {
@@ -121,15 +121,17 @@
// Address-sized uint.
func (b *buf) addr() uint64 {
- switch b.addrsize {
- case 1:
- return uint64(b.uint8())
- case 2:
- return uint64(b.uint16())
- case 4:
- return uint64(b.uint32())
- case 8:
- return uint64(b.uint64())
+ if b.u != nil {
+ switch b.u.addrsize {
+ case 1:
+ return uint64(b.uint8())
+ case 2:
+ return uint64(b.uint16())
+ case 4:
+ return uint64(b.uint32())
+ case 8:
+ return uint64(b.uint64())
+ }
}
b.error(unknown address size)
return 0
diff -r 976886593e1f libgo/go/debug/dwarf/const.go
--- a/libgo/go/debug/dwarf/const.go Thu Mar 08 21:32:43 2012 -0800
+++ b/libgo/go/debug/dwarf/const.go Thu Mar 08 22:32:23 2012 -0800
@@ -207,6 +207,11 @@
formRef8format = 0x14
formRefUdataformat = 0x15
formIndirectformat = 0x16
+ // following are defined in DWARF 4
+ formSecOffset format = 0x17
+ formExprLoc format = 0x18
+ formFlagPresent format = 0x19
+ formRefSig8 format = 0x20
)
// A Tag is the classification (the type) of an Entry.
diff -r 976886593e1f libgo/go/debug/dwarf/entry.go
--- a/libgo/go/debug/dwarf/entry.go Thu Mar 08 21:32:43 2012 -0800
+++ b/libgo/go/debug/dwarf/entry.go Thu Mar 08 22:32:23 2012 -0800
@@ -40,7 +40,7 @@
} else {
data = data[off:]
}
- b := makeBuf(d, abbrev, 0, data, 0)
+ b := makeBuf(d, nil, abbrev, 0, data)
// Error handling is simplified by the buf getters
// returning an endless stream of 0s after an error.
@@ -182,13 +182,37 @@
case formUdata:
val = int64(b.uint())
+ // exprloc
+ case formExprLoc:
+ val = b.bytes(int(b.uint()))
+
// flag
case formFlag:
val = b.uint8() == 1
+ case formFlagPresent:
+ val = true
+
+ // lineptr, loclistptr, macptr, rangelistptr
+ case formSecOffset:
+ if b.u == nil {
+b.error(unknown size for DW_FORM_sec_offset)
+ } else if b.u.dwarf64 {
+val = Offset(b.uint64())
+ } else {
+val = Offset(b.uint32())
+ }
// reference to other entry
case formRefAddr:
- val = Offset(b.addr())
+ if b.u == nil {
+b.error(unknown version for DW_FORM_ref_addr)
+ } else if b.u.version == 2 {
+val = Offset(b.addr())
+ } else if b.u.dwarf64 {
+val = Offset(b.uint64())
+ } else {
+val = Offset(b.uint32())
+ }
case formRef1:
val = Offset(b.uint8()) + ubase
case formRef2:
@@ -199,6 +223,8 @@
val = Offset(b.uint64()) + ubase
case formRefUdata:
val = Offset(b.uint()) + ubase
+ case formRefSig8:
+ val = b.uint64()
// string
case formString:
@@ -208,7 +234,7 @@
if b.err != nil {
return nil
}
- b1 := makeBuf(b.dwarf, str, 0, b.dwarf.str, 0)
+ b1 := makeBuf(b.dwarf, b.u, str, 0, b.dwarf.str)
b1.skip(int(off))
val = b1.string()
if b1.err != nil {
@@ -251,7 +277,7 @@
r := Reader{d: d}
r.unit = i
u := d.unit[i]
- r.b = makeBuf(d, info, u.off, u.data, u.addrsize)
+ r.b = makeBuf(d, u, info, u.off, u.data)
return r
}
@@ -267,7 +293,7 @@
}
u := d.unit[0]
r.unit = 0
- r.b = makeBuf(r.d, info, u.off, u.data, u.addrsize)
+ r.b = makeBuf(r.d, u, info, u.off, u.data)
return
}
@@ -278,7 +304,7 @@
u = d.unit[i]
if u.off = off off u.off+Offset(len(u.data)) {
r.unit = i
- r.b = makeBuf(r.d, info, off, u.data[off-u.off:], u.addrsize)
+ r.b = makeBuf(r.d, u, info, off, u.data[off-u.off:])
return
}
}
@@ -290,7 +316,7 @@
for len(r.b.data) == 0 r.unit+1 len(r.d.unit) {
r.unit++
u := r.d.unit[r.unit]
- r.b = makeBuf(r.d, info, u.off, u.data, u.addrsize)
+ r.b = makeBuf(r.d, u, info, u.off, u.data)
}
}
diff -r 976886593e1f libgo/go/debug/dwarf/line.go
--- a/libgo/go/debug/dwarf/line.go Thu Mar 08 21:32:43 2012 -0800
+++ b/libgo/go/debug/dwarf/line.go Thu Mar 08 22:32:23 2012 -0800
@@ -74,9 +74,17 @@
// TODO: Handle AttrRanges and .debug_ranges.
_ = f
}
- if off, ok := e.Val(AttrStmtList).(int64); ok {
-u.lineoff = Offset(off)
-setLineOff = true
+ val := e.Val(AttrStmtList)
+ if val != nil {
+
Go patch committed: Fix sink receiver
This patch to the Go frontend fixes the handling of a function with a
sink receiver, as in
func (_ T) F()
I've added a test case for this to the master Go testsuite, which will
be copied into the gccgo testsuite in due course. Bootstrapped and ran
Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r f3b4795ea475 go/gogo.cc
--- a/go/gogo.cc Thu Mar 08 22:34:11 2012 -0800
+++ b/go/gogo.cc Thu Mar 08 22:35:23 2012 -0800
@@ -628,7 +628,7 @@
Variable* this_param = new Variable(receiver-type(), NULL, false,
true, true, location);
std::string rname = receiver-name();
- if (rname.empty())
+ if (rname.empty() || Gogo::is_sink_name(rname))
{
// We need to give receivers a name since they wind up in
// DECL_ARGUMENTS. FIXME.
@@ -638,8 +638,7 @@
++count;
rname = buf;
}
- if (!Gogo::is_sink_name(rname))
- block-bindings()-add_variable(rname, NULL, this_param);
+ block-bindings()-add_variable(rname, NULL, this_param);
}
const Typed_identifier_list* parameters = type-parameters();
