[fortran, patch] Allow displaying backtraces from user code
PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an enhancement request for a way to display backtraces from user code. I'm against adding yet another nonstandard intrinsic for this purpose (which is how Intel Fortran does it), but I would like to offer the following solution to the issue, as I think it can be useful in some cases (and the way I suggest should not be a maintainance burden for us): -- export _gfortran_show_backtrace() from libgfortran (instead of it being an internal function) -- add documentation on how to call this function from user-code using BIND(C) Patch was bootstrapped and regtested on x86_64-apple-darwin11, also tested with "make info html pdf". OK for trunk? FX traceback2.ChangeLog Description: Binary data traceback2.diff Description: Binary data
Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113
Dear Tobias, This is certainly OK for 4.8. I have a couple of remarks: (i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time since! At the moment it does not cause any problems because of the extremely limited use of the dtype 'type'. Whilst the array descriptor revamp will eliminate such worries, we should be mindful of this; and (ii) By making such substantial use of scan-tree-dump-times in the dg-run test case, you are potentially building in instability against future development, I suppose? Are the runtime tests not sufficient? Thanks for this early upgrade! Paul On Fri, Mar 2, 2012 at 12:28 PM, Tobias Burnus wrote: > TYPE(*) is Fortran's equivalent to C's "void *buffer". It may only be used > for dummy arguments and essentially might only either be passed on, or > appear in PRESENT, LBOUND/UBOUND/SHAPE/SIZE/IS_CONTIGUOUS - and most useful: > in C_LOC. > > > Note: For scalar TYPE(*) and for assumed-size dummies, only the address is > passed on. But for dimension(:) and TS29113's new (but unimplemented) > dimension(..) an array descriptor is passed. In that case, one might recover > the type from the array descriptor - at least for intrinsic types. > > > TYPE(*) is useful for, e.g., MPI (and used in the MPI v3 draft spec): There, > one simply takes an argument of any type and transfers some bytes from it - > without needing to know the type. TYPE(*) avoids to create hundreds of > useless explicit interfaces for all kind of data types (and missing derived > types that way) - or TS29113 avoids the alternative: Not using explicit > interfaces (causing argument checking issues and prevents the use of > BIND(C).) > > > See PR (or first test case) for a usage example. For a pure Fortran use, one > could imagine: > > subroutine send(buf, size) > use iso_c_binding, only: c_signed_char, c_size_t > type(*) :: buf(*) > integer(c_size_t) :: size > integer(c_signed_char) :: ibuf(size) > call c_f_pointer (c_loc(buf), ibuf, shape=[size]) > ! ... use ibuf ... > end > > [This example currently fails as "c_loc(buf)" is rejected. Several BIND(C) > restrictions were removed in F2008 and especially in TS29113, but gfortran > has not yet removed them.] > > > For more details, see: > > * TS 29113 draft: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1904.pdf > (Status: Went as PDTR through one round of voting by the ISO members, was > updated at the last J3 meeting and is now the subject of a one-month WG5 > ballot that ends on 19 March 2012. The schedule is that it will then be > forwarded to SC22, which initiates a DTS ballot such that the final version > will be published in September by ISO.) > > * MPIv3 draft (of 2011-12-15): > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-report-F2008-2011-12-15-changeonlyplustickets_majorpages.pdf > > Build and regtested on x86-64-linux. > OK for the 4.8 trunk? > > Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [PATCH, wwwdocs] Detail more ARM-specific changes
On Fri, 2 Mar 2012, Richard Earnshaw wrote: > This patch documents some more of the changes that have occurred on > ARM this year. I've also re-worded a couple of the existing changes > recorded there to try and improve the clarity to users. That's quite a bit of a list of improvements. Nice! > OK? Yes. The only change I'd like to suggest is on the last line of the patch replacing "on Linux, kernel versions 3.1" by "Linux kernel versions 3.1" to make sure we are only taking about the kernel, not GNU/Linux. Thanks, Gerald
Re: ifcvt cond_exec support rewrite
On 30/09/2011, at 1:11 AM, Bernd Schmidt wrote:
...
>
> The following patch rewrites essentially all the cond_exec support in
> ifcvt; reviewing is probably easier if it's thought of as new code.
Kudos for improving if-conversion!
I reviewed this patch to the extent I know ifcvt.c, which is below your level
of understanding. The new implementation looks good to me, and my review
mostly focuses on making the code more understandable to someone without the
in-depth knowledge of optimization.
> A
> large overview comment is added to basic-block.h.
I suggest moving this comment to ifcvt.c as it really describes the
optimization, not the underlying data structures.
Also, are there any publications describing the new implementation or is this
your own masterpiece? If there are papers relevant to your new implementation,
please add references to them.
...
>
> This patch was bootstrapped on ia64-linux; a slightly earlier version
> was regression tested and had a random guality failure that goes away
> with this one (gcc & g++ tested again). It's also been tested on c6x-elf
> along the way (currently testing again for the latest version and
> looking OK so far), and it's in our 4.5 c6x tree.
For which targets is this optimization enabled for (as in "is not a no-op")?
Is it only IA64, FRV and C6X? [I think at least ARM should also be affected.]
If it's only ia64, frv and c6x, then you are in the clear with testing. If the
optimization can change code for other targets (arm, x86, ppc, mips), then we
need to do more testing to make sure correctness and performance do not
regress. I'm ready to help with the testing and benchmarking.
> Index: gcc/ifcvt.c
> ===
> *** gcc/ifcvt.c (revision 178854)
> --- gcc/ifcvt.c (working copy)
...
> + cond_exec_discard_added_insns ();
> cancel_changes (0);
> ! return false;
> ! }
> !
> ! /* Given an IF-THEN or IF-THEN-ELSE block with possibly nested
> !sub-blocks in CE_ROOT, attempt to convert as much of the tree as
> !possible to conditional execution. Return TRUE if we were
> !successful at converting the block. */
> !
> ! static int
> ! cond_exec_process_if_block (ce_if_block_t *ce_root)
> ! {
> ! bool retval = false;
> ! basic_block bb, prev_bb = NULL;
> ! ce_blocks_info_t *blkinfo;
> ! int n_blocks;
> ! unsigned i;
> ! HARD_REG_SET set_anywhere;
> !
> ! /* Verify that all blocks are adjacent. This isn't really a
> ! requirement, but only because rtl_move_block is unimplemented.
> ! Later. */
What does this 'Later' mean?
> ! FOR_EACH_VEC_ELT (basic_block, ce_root->targets, i, bb)
> ! {
> ! if (prev_bb && prev_bb->next_bb != bb)
> ! return false;
> !
> ! prev_bb = bb;
> ! }
...
> ! /* After finding an if header CE_INFO with discover_if_header, this function
> !can be used to recursively examine the then, else, and join blocks to see
> !if they are themselves if blocks. OUTER_JOIN should be NULL for the
> !outermost if-block we're examining; on recursive calls it holds the
> join_bb
> !of the parent if-block.
> !Return true if we found a recognizable blocks structure. */
>
> ! static bool
> ! ce_discover_if_structure (ce_if_block_t *ce_info, basic_block outer_join)
This is a HUGE function. Please try splitting it up into several smaller
functions or making (its structure || steps that it makes) more apparent in
other ways.
...
>
> ! /* Try to avoid building up extremely large if trees only to find that
> ! they would be too expensive to convert. The numbers are arbitrarily
> ! chosen to ensure reasonable compile times for extreme test cases
> without
> ! preventing useful optimizations. */
> ! if (n_basic_blocks > 100
> ! /* Avoid the special case from above. */
> ! && (then_bb == NULL || EDGE_COUNT (then_bb->succs) > 0))
> ! {
> ! VEC (basic_block, heap) *dom_vec;
> ! basic_block bb;
> ! int count = 0;
> ! dom_vec = get_dominated_to_depth (CDI_DOMINATORS, test_bb, 0);
> ! FOR_EACH_VEC_ELT (basic_block, dom_vec, i, bb)
> ! if (dominated_by_p (CDI_POST_DOMINATORS, bb, join_bb))
> ! count++;
> ! VEC_free (basic_block, heap, dom_vec);
> ! if (count > 40)
> ! return false;
> ! }
Please replace the magic numbers '100' and '40' above with parameters or, at
least, constants with descriptive names.
...
>
> ! if (sub_info != NULL && sub_info->join_bb == join_bb
> ! /* We cannot do this if we have matching pieces of code, as these
> must be
> ! predicated with the parent's condition (which, hence, must be in a
> ! different register). */
"We cannot do this ... " -- what "this" refers to?
...
> Index: gcc/basic-block.h
> ===
> *** gcc/basic-block.h (revision 178854)
> --- gcc/basic-block.h (w
Re: [4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1
Richard Henderson wrote: > For proper binary compatibility, we should probably introduce that asap. > You forgot two things in your patch, gen_int_mode and the fact that we > still have to return a boolean (0/1) value. > > Also in order for the binary compatibility to work right, you'd want to > have the SH test-and-set-trueval set appropriately asap. Kaz, I assume > you'd agree that 0x80 is a good value for the "tas.b" insn? We don't > necessarily need to support tas.b right away, but getting trueval set > right is imperative. Yes, 0x80 is an appropriate value as you and oleg have suggested. Regards, kaz
[fortran, patch] Fix handling of backtrace options in the library
Hi all, I'll offer my first patch to the new 4.8 trunk. I noticed that the -fbacktrace option and the GFORTRAN_ERROR_BACKTRACE environment variable are somewhat inconsistently handled. Currently, the environment variabled doesn't actually override the compilation option, as it should. So, I set to change that (checking both options.backtrace and compile_options.backtrace instead of only the latter) when I realized that we could improve this further by moving the checking code: it is currently located in the set_options() function, which is called from the main Fortran routine (call generated by the front-end). This means that it's not triggered if the main program is C. So, by moving it in the main initialization routine, we can ensure that an executable with a C main program but run using GFORTRAN_ERROR_BACKTRACE=Y will actually generate backtraces for Fortran errors, which I think is the cool thing to do. Full disclosure: I removed the function maybe_find_addr2line() because it's not needed anymore now the code was regrouped. However, I'll note that I don't understand why it was useful before, and that I think the comment on top of it was wrong (variable "options" could be seen in the function, it was just shadowed by the local function argument!). Thus, while I was at it, I renamed the options argument to set_options(), just to make sure we didn't have a problem of this sort in the future. The change was bootstrapped and regtested on x86_64-apple-darwin11, but is an area not covered by the testsuite. I have manually checked that running various types of abort, both in a pure Fortran code and a mixed C/Fortran (with C main), with all combinations -fno-backtrace/GFORTRAN_ERROR_BACKTRACE, behaved as expected. OK to commit to trunk? FX traceback.diff Description: Binary data traceback.ChangeLog Description: Binary data
[PATCH 10/10] addr32: Add *zero_extendsidi2_x32.
Hi,
This is the last patch for Pmode == SImod in x32. In x32, the return value
of the symbol address must be zero-extended to DImode, This patch adds
*zero_extendsidi2_x32 to load the address of a symbol in SImode and
zero-extend it to DImode. It works for x32 since the address size is 32bit.
OK for trunk?
Thanks.
H.J.
---
2012-03-02 H.J. Lu
* config/i386/i386.md (*zero_extendsidi2_x32): New.
* config/i386/predicates.md (x86_64_symbolic_immediate_operand):
Likewise.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 1595491..d008815 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3407,6 +3407,17 @@
(set_attr "prefix_0f" "0,*,*,*,*,*")
(set_attr "mode" "SI,DI,DI,DI,TI,TI")])
+(define_insn "*zero_extendsidi2_x32"
+ [(set (match_operand:DI 0 "register_operand" "=r")
+ (zero_extend:DI
+ (match_operand:SI 1 "x86_64_symbolic_immediate_operand" "")))]
+ "TARGET_X32"
+ "mov\t{%1, %k0|%k0, %1}"
+ [(set_attr "type" "imovx")
+ (set_attr "prefix" "orig")
+ (set_attr "prefix_0f" "0")
+ (set_attr "mode" "SI")])
+
(define_split
[(set (match_operand:DI 0 "memory_operand" "")
(zero_extend:DI (match_dup 0)))]
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 32f73da..21cf3bb 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -333,6 +333,53 @@
return false;
})
+;; Return true if OP is either a symbol reference or a sum of a symbol
+;; reference and a constant in x86-64 small mode, which can be stored
+;; in the zero extended immediate field.
+(define_predicate "x86_64_symbolic_immediate_operand"
+ (match_code "symbol_ref,const")
+{
+ /* Only small model is allowed. */
+ if (ix86_cmodel != CM_SMALL)
+return false;
+
+ switch (GET_CODE (op))
+{
+case SYMBOL_REF:
+ /* TLS symbols are not constant. */
+ if (SYMBOL_REF_TLS_MODEL (op))
+ return false;
+ return true;
+
+case CONST:
+ op = XEXP (op, 0);
+ if (GET_CODE (op) == PLUS)
+ {
+ rtx op1 = XEXP (op, 0);
+ rtx op2 = XEXP (op, 1);
+
+ switch (GET_CODE (op1))
+ {
+ case SYMBOL_REF:
+ /* TLS symbols are not constant. */
+ if (SYMBOL_REF_TLS_MODEL (op1))
+ return false;
+ if (CONST_INT_P (op2))
+ return true;
+ break;
+
+ default:
+ return false;
+ }
+ }
+ break;
+
+default:
+ gcc_unreachable ();
+}
+ return false;
+})
+
;; Return true if OP is general operand representable on x86_64.
(define_predicate "x86_64_general_operand"
(if_then_else (match_test "TARGET_64BIT")
--
1.7.6.5
[PATCH 09/10] addr32: Set Pmode to SImode for x32.
Hi,
This patch switches Pmode to SImode for x32. It uses proper patterns
for x32. OK for trunk?
Thanks.
H.J.
---
2012-03-02 H.J. Lu
* config/i386/i386.c (ix86_option_override_internal): Properly
set ix86_gen_leave and ix86_gen_monitor. Check Pmode == DImode.
(legitimize_tls_address): For x32, call gen_tls_global_dynamic_x32
and gen_tls_local_dynamic_base_x32.
* config/i386/i386.h (Pmode): Check TARGET_LP64 instead of
TARGET_64BIT.
* config/i386/i386.md (PTR): Removed.
(x86_64_mode): New.
(*tls_global_dynamic_64): Renamed to ...
(*tls_global_dynamic_): This.
(tls_global_dynamic_64): Renamed to ...
(tls_global_dynamic_): This.
(*tls_local_dynamic_base_64): Renamed to ...
(*tls_local_dynamic_base_): This.
(tls_local_dynamic_base_64): Renamed to ...
(tls_local_dynamic_base_): This.
(stack_protect_set_): Replace ":PTR" with ":P".
(stack_tls_protect_set_): Likewise.
(stack_tls_protect_test_): Likewise.
* config/i386/sse.md (sse3_monitor64): Renamed to ...
(sse3_monitor_): This.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 191c8b5..3979167 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3748,11 +3748,23 @@ ix86_option_override_internal (bool main_args_p)
if (TARGET_64BIT)
{
ix86_gen_leave = gen_leave_rex64;
+ if (TARGET_X32)
+ ix86_gen_monitor = gen_sse3_monitor_x32;
+ else
+ ix86_gen_monitor = gen_sse3_monitor_64;
+}
+ else
+{
+ ix86_gen_leave = gen_leave;
+ ix86_gen_monitor = gen_sse3_monitor;
+}
+
+ if (Pmode == DImode)
+{
ix86_gen_add3 = gen_adddi3;
ix86_gen_sub3 = gen_subdi3;
ix86_gen_sub3_carry = gen_subdi3_carry;
ix86_gen_one_cmpl2 = gen_one_cmpldi2;
- ix86_gen_monitor = gen_sse3_monitor64;
ix86_gen_andsp = gen_anddi3;
ix86_gen_allocate_stack_worker = gen_allocate_stack_worker_probe_di;
ix86_gen_adjust_stack_and_probe = gen_adjust_stack_and_probedi;
@@ -3760,12 +3772,10 @@ ix86_option_override_internal (bool main_args_p)
}
else
{
- ix86_gen_leave = gen_leave;
ix86_gen_add3 = gen_addsi3;
ix86_gen_sub3 = gen_subsi3;
ix86_gen_sub3_carry = gen_subsi3_carry;
ix86_gen_one_cmpl2 = gen_one_cmplsi2;
- ix86_gen_monitor = gen_sse3_monitor;
ix86_gen_andsp = gen_andsi3;
ix86_gen_allocate_stack_worker = gen_allocate_stack_worker_probe_si;
ix86_gen_adjust_stack_and_probe = gen_adjust_stack_and_probesi;
@@ -12533,7 +12543,12 @@ legitimize_tls_address (rtx x, enum tls_model model,
bool for_mov)
rtx rax = gen_rtx_REG (Pmode, AX_REG), insns;
start_sequence ();
- emit_call_insn (gen_tls_global_dynamic_64 (rax, x, caddr));
+ if (TARGET_X32)
+ emit_call_insn (gen_tls_global_dynamic_x32 (rax, x,
+ caddr));
+ else
+ emit_call_insn (gen_tls_global_dynamic_64 (rax, x,
+ caddr));
insns = get_insns ();
end_sequence ();
@@ -12581,7 +12596,12 @@ legitimize_tls_address (rtx x, enum tls_model model,
bool for_mov)
rtx rax = gen_rtx_REG (Pmode, AX_REG), insns, eqv;
start_sequence ();
- emit_call_insn (gen_tls_local_dynamic_base_64 (rax, caddr));
+ if (TARGET_X32)
+ emit_call_insn (gen_tls_local_dynamic_base_x32 (rax,
+ caddr));
+ else
+ emit_call_insn (gen_tls_local_dynamic_base_64 (rax,
+ caddr));
insns = get_insns ();
end_sequence ();
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 7721c46..4c6e5fd 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1744,7 +1744,7 @@ do {
\
/* Specify the machine mode that pointers have.
After generation of rtl, the compiler makes no further distinction
between pointers and any other objects of this machine mode. */
-#define Pmode (TARGET_64BIT ? DImode : SImode)
+#define Pmode (TARGET_LP64 ? DImode : SImode)
/* A C expression whose value is zero if pointers that need to be extended
from being `POINTER_SIZE' bits wide to `Pmode' are sign-extended and
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 35b2673..1595491 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -897,10 +897,8 @@
(define_mode_iterator W
[(SI "word_mode == SImode") (DI "word_mode == DImode")])
-;; This mode iterator allows :PTR to be used for patterns that operate on
-;; ptr_mode sized quantities.
Re: libgo patch committed: Fill out syscall package for GNU/Linux
Rainer Orth writes:
> Rainer Orth writes:
>
>> Ian Lance Taylor 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
Thanks for the note. I committed this patch in an attempt to fix these
problems.
Ian
diff -r 0f5b89756b90 libgo/configure.ac
--- a/libgo/configure.ac Fri Mar 02 12:47:45 2012 -0800
+++ b/libgo/configure.ac Fri Mar 02 13:06:49 2012 -0800
@@ -453,7 +453,7 @@
;;
esac
-AC_CHECK_HEADERS(sys/mman.h syscall.h sys/epoll.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h sys/prctl.h sys/mount.h sys/vfs.h sys/statfs.h sys/timex.h sys/sysinfo.h ustat.h utime.h linux/reboot.h)
+AC_CHECK_HEADERS(sys/mman.h syscall.h sys/epoll.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h sys/prctl.h sys/mount.h sys/vfs.h sys/statfs.h sys/timex.h sys/sysinfo.h utime.h linux/reboot.h)
AC_CHECK_HEADERS([linux/filter.h linux/netlink.h linux/rtnetlink.h], [], [],
[#ifdef HAVE_SYS_SOCKET_H
@@ -461,6 +461,21 @@
#endif
])
+AC_CACHE_CHECK([whether can be used],
+[libgo_cv_c_ustat_h],
+AC_COMPILE_IFELSE(
+[AC_LANG_SOURCE([
+#include
+#ifdef HAVE_LINUX_FILTER_H
+#include
+#endif
+#include
+])], [libgo_cv_c_ustat_h=yes], [libgo_cv_c_ustat_h=no]))
+if test $libgo_cv_c_ustat_h = yes; then
+ AC_DEFINE(HAVE_USTAT_H, 1,
+[Define to 1 if you have the header file and it works.])
+fi
+
AM_CONDITIONAL(HAVE_SYS_MMAN_H, test "$ac_cv_header_sys_mman_h" = yes)
AC_CHECK_FUNCS(strerror_r strsignal wait4 mincore setenv)
diff -r 0f5b89756b90 libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Fri Mar 02 12:47:45 2012 -0800
+++ b/libgo/mksysinfo.sh Fri Mar 02 13:06:49 2012 -0800
@@ -895,6 +895,11 @@
-e 's/f_fname/Fname/' \
-e 's/f_fpack/Fpack/' \
>> ${OUT}
+# Force it to be defined, as on some older GNU/Linux systems the
+# header file fails when using with .
+if ! grep 'type _ustat ' gen-sysinfo.go >/dev/null 2>&1; then
+ echo 'type Ustat_t struct { Tfree int32; Tinoe uint64; Fname [5+1]int8; Fpack [5+1]int8; }' >> ${OUT}
+fi
# The utimbuf struct.
grep '^type _utimbuf ' gen-sysinfo.go | \
[PATCH 08/10] addr32: Check Pmode instead of TARGET_64BIT
Hi, Since stack register may be in SImode for TARGET_64BIT, this patch checks Pmode to adjust stack in proper mode. OK for trunk? Thanks. H.J. --- 2012-03-02 H.J. Lu * config/i386/i386.c (pro_epilogue_adjust_stack): Check Pmode instead of TARGET_64BIT. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 67aaaea..191c8b5 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -9304,7 +9304,7 @@ pro_epilogue_adjust_stack (rtx dest, rtx src, rtx offset, rtx insn; bool add_frame_related_expr = false; - if (! TARGET_64BIT) + if (Pmode == SImode) insn = gen_pro_epilogue_adjust_stack_si_add (dest, src, offset); else if (x86_64_immediate_operand (offset, DImode)) insn = gen_pro_epilogue_adjust_stack_di_add (dest, src, offset); -- 1.7.6.5
[PATCH 07/10] addr32: Use word_mode instead of Pmode in loop expand
Hi, 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 * config/i386/i386.c (ix86_expand_movmem): Use word_mode instead of Pmode on loop. (ix86_expand_setmem): Likwise. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 47fa36a..67aaaea 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -22239,13 +22239,13 @@ ix86_expand_movmem (rtx dst, rtx src, rtx count_exp, rtx align_exp, break; case loop: expand_set_or_movmem_via_loop (dst, src, destreg, srcreg, NULL, -count_exp, Pmode, 1, expected_size); +count_exp, word_mode, 1, expected_size); break; case unrolled_loop: /* Unroll only by factor of 2 in 32bit mode, since we don't have enough registers for 4 temporaries anyway. */ expand_set_or_movmem_via_loop (dst, src, destreg, srcreg, NULL, -count_exp, Pmode, TARGET_64BIT ? 4 : 2, +count_exp, word_mode, TARGET_64BIT ? 4 : 2, expected_size); break; case rep_prefix_8_byte: @@ -22457,11 +22457,11 @@ ix86_expand_setmem (rtx dst, rtx count_exp, rtx val_exp, rtx align_exp, gcc_unreachable (); case loop: need_zero_guard = true; - size_needed = GET_MODE_SIZE (Pmode); + size_needed = GET_MODE_SIZE (word_mode); break; case unrolled_loop: need_zero_guard = true; - size_needed = GET_MODE_SIZE (Pmode) * 4; + size_needed = GET_MODE_SIZE (word_mode) * 4; break; case rep_prefix_8_byte: size_needed = 8; @@ -22632,11 +22632,11 @@ ix86_expand_setmem (rtx dst, rtx count_exp, rtx val_exp, rtx align_exp, break; case loop: expand_set_or_movmem_via_loop (dst, NULL, destreg, NULL, promoted_val, -count_exp, Pmode, 1, expected_size); +count_exp, word_mode, 1, expected_size); break; case unrolled_loop: expand_set_or_movmem_via_loop (dst, NULL, destreg, NULL, promoted_val, -count_exp, Pmode, 4, expected_size); +count_exp, word_mode, 4, expected_size); break; case rep_prefix_8_byte: expand_setmem_via_rep_stos (dst, destreg, promoted_val, count_exp, -- 1.7.6.5
[PATCH 06/10] addr32: Check Pmode to set adjust_stack_insn
Since stack register may be in SImode for TARGET_64BIT, this patch checks Pmode to set adjust_stack_insn. OK for trunk? Thanks. H.J. -- 2012-03-02 H.J. Lu * config/i386/i386.c (ix86_expand_prologue): Check Pmode to set adjust_stack_insn. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index d6ec6ff..47fa36a 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -10338,7 +10338,7 @@ ix86_expand_prologue (void) emit_insn (ix86_gen_allocate_stack_worker (eax, eax)); /* Use the fact that AX still contains ALLOCATE. */ - adjust_stack_insn = (TARGET_64BIT + adjust_stack_insn = (Pmode == DImode ? gen_pro_epilogue_adjust_stack_di_sub : gen_pro_epilogue_adjust_stack_si_sub); -- 1.7.6.5
[PATCH 05/10] addr32: Load TP into register for TLS_MODEL_LOCAL_EXEC modes in x32
Hi,
Since the 0x67 address prefix only zeros out the upper 32bits of the
(reg) part in address fs:(reg), we can't use fs:(reg) as memory operand
for x32 with Pmode == SImode. We have to load the address into a
register first and use it as memory operand. Tested on Linux/x86-64.
OK for trunk?
Thanks.
H.J.
2012-03-02 H.J. Lu
* config/i386/i386.c (legitimize_tls_address): Load TP into
register for TLS_MODEL_LOCAL_EXEC modes in x32.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 7cb8fda..d6ec6ff 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -12687,7 +12687,16 @@ legitimize_tls_address (rtx x, enum tls_model model,
bool for_mov)
if (TARGET_64BIT || TARGET_ANY_GNU_TLS)
{
base = get_thread_pointer (for_mov || !TARGET_TLS_DIRECT_SEG_REFS);
- return gen_rtx_PLUS (Pmode, base, off);
+ if (Pmode != word_mode)
+ {
+ /* Since address override works only on the (reg) part in
+fs:(reg), we can't use it as memory operand. */
+ rtx reg = gen_reg_rtx (Pmode);
+ emit_move_insn (reg, base);
+ return gen_rtx_PLUS (Pmode, reg, off);
+ }
+ else
+ return gen_rtx_PLUS (Pmode, base, off);
}
else
{
--
1.7.6.5
Re: libgo patch committed: Update to weekly.2012-02-14 release
Rainer Orth writes: > The first mmap arg is caddr_t (char *), while byte * is uint8 *. > Casting to void * fixes this. Thanks. Committed. Ian
PING PATCH: Assert DWARF register size <= saved reg size
On Fri, Nov 11, 2011 at 11:04 AM, H.J. Lu wrote:
> Hi,
>
> I am working on 32bit Pmode for x32:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50797
>
> It removes all LEAs, which convert 32bit address to 64bit, and uses 0x67
> address prefix instead. I got 5% speed up in SPEC CPU 2K/2006.
>
> But assert in _Unwind_SetGRValue:
>
> gcc_assert (dwarf_reg_size_table[index] == sizeof (_Unwind_Context_Reg_Val));
>
> failed on return column since init_return_column_size use Pmode, not
> word_mode. In this case, _Unwind_Context_Reg_Val is 64bit, but return
> column size is 32bit. This patch changes it to assert DWARF register
> size <= saved reg size. OK for trunk?
>
> Thanks.
>
>
> H.J.
> ---
> 2011-11-11 H.J. Lu
>
> * unwind-dw2.c (_Unwind_SetGRValue): Assert DWARF register size
> <= saved reg size.
>
> diff --git a/libgcc/unwind-dw2.c b/libgcc/unwind-dw2.c
> index 475ad00..db1c757 100644
> --- a/libgcc/unwind-dw2.c
> +++ b/libgcc/unwind-dw2.c
> @@ -294,7 +294,8 @@ _Unwind_SetGRValue (struct _Unwind_Context *context, int
> index,
> {
> index = DWARF_REG_TO_UNWIND_COLUMN (index);
> gcc_assert (index < (int) sizeof(dwarf_reg_size_table));
> - gcc_assert (dwarf_reg_size_table[index] == sizeof
> (_Unwind_Context_Reg_Val));
> + /* Return column size may be smaller than _Unwind_Context_Reg_Va. */
> + gcc_assert (dwarf_reg_size_table[index] <= sizeof
> (_Unwind_Context_Reg_Val));
>
> context->by_value[index] = 1;
> context->reg[index] = _Unwind_Get_Unwind_Context_Reg_Val (val);
Now trunk is in stage 1. Jason, is this OK for trunk?
Thanks.
--
H.J.
[contrib] Fix match pattern for summary lines in validate_failures.py (issue5728047)
This fixes an edge case in parsing summary lines. Some times, the
description field is missing (e.g., 'FAIL: libstdc++/abi_check'), so
the space that the pattern was looking for does not exist.
I've changed it to match any whitespace, which includes '\n'. I also
made it print the line that it fails to parse, in case there are other
problems like this in the future.
David, this should fix the failure you were getting in your merge.
Let me know if it doesn't.
2012-03-02 Diego Novillo
* testsuite-management/validate_failures.py (class TestResult): Fix
match pattern for the summary line. If there is a parsing failure,
show the line we failed to parse.
diff --git a/contrib/testsuite-management/validate_failures.py
b/contrib/testsuite-management/validate_failures.py
index 072de79..7bc5089 100755
--- a/contrib/testsuite-management/validate_failures.py
+++ b/contrib/testsuite-management/validate_failures.py
@@ -97,10 +97,14 @@ class TestResult(object):
self.attrs = ''
if '|' in summary_line:
(self.attrs, summary_line) = summary_line.split('|', 1)
- (self.state,
- self.name,
- self.description) = re.match(r' *([A-Z]+): ([^ ]+) (.*)',
-summary_line).groups()
+ try:
+(self.state,
+ self.name,
+ self.description) = re.match(r' *([A-Z]+): (\S+)\s(.*)',
+ summary_line).groups()
+ except:
+print 'Failed to parse summary line: "%s"' % summary_line
+raise
self.attrs = self.attrs.strip()
self.state = self.state.strip()
self.description = self.description.strip()
--
This patch is available for review at http://codereview.appspot.com/5728047
Re: [4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1
On Fri, 2012-03-02 at 12:34 -0800, Richard Henderson wrote: > On 03/02/2012 12:27 PM, Oleg Endo wrote: > > + This value is used by optabs.c atomic op expansion code as well as in > > + sync.md. It must be defined as signed char here or else the movqi > > + pattern will refuse to load it as a QImode constant. */ > > +#undef TARGET_ATOMIC_TEST_AND_SET_TRUEVAL > > +#define TARGET_ATOMIC_TEST_AND_SET_TRUEVAL ((signed char)0x80) > > The fix to use gen_mode_int obviates the need for the (signed char) hack. > Ah right, sorry again. Then I'll rather wait with the whole tas.b patch until the optabs changes are in. Cheers, Oleg
[PATCH 02/10] addr32: Only handle zero-extended DImode addresses
Hi, We only need to handle zero-extended addresses in DImode. OK for trunk? BTW, all my 10 addr32 patches are tested on Linux/x86-64. Thanks. H.J. --- 2012-03-02 H.J. Lu * config/i386/i386.c (ix86_print_operand_address): Only handle zero-extended DImode addresses. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 2cbfb64..7cb8fda 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -14511,7 +14511,7 @@ ix86_print_operand_address (FILE *file, rtx addr) /* Print SImode registers for zero-extended addresses to force addr32 prefix. Otherwise print DImode registers to avoid it. */ - if (TARGET_64BIT) + if (TARGET_64BIT && GET_MODE (addr) == DImode) code = ((GET_CODE (addr) == ZERO_EXTEND || GET_CODE (addr) == AND) ? 'l' -- 1.7.6.5
[PATCH 02/10] addr32: Output REX prefix for UNSPEC_GOTNTPOFF
X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
by checking
movq foo@gottpoff(%rip), %reg
and
addq foo@gottpoff(%rip), %reg
It uses the REX prefix to avoid the last byte of the previous
instruction. With 32bit Pmode, we may not have the REX prefix and
the last byte of the previous instruction may be an offset, which
may look like a REX prefix. IE->LE optimization will generate corrupted
binary. This patch makes sure we always output an REX pfrefix for
UNSPEC_GOTNTPOFF. OK for trunk?
Thanks.
H.J.
2012-03-02 H.J. Lu
* config/i386/i386-protos.h (ix86_output_rex_prefix_p): New.
* config/i386/i386.c (ix86_output_rex_prefix_p): Likewise.
* config/i386/i386.md (*movsi_internal): Output REX prefix if
needed.
(*add_1): Likewise.
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 630112f..a9b9d3f 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -277,6 +277,8 @@ extern void x86_output_aligned_bss (FILE *, tree, const
char *,
extern void x86_elf_aligned_common (FILE *, const char *,
unsigned HOST_WIDE_INT, int);
+extern bool ix86_output_rex_prefix_p (rtx, rtx);
+
#ifdef RTX_CODE
extern void ix86_fp_comparison_codes (enum rtx_code code, enum rtx_code *,
enum rtx_code *, enum rtx_code *);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index ac9c714..2cbfb64 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -14670,6 +14670,29 @@ i386_asm_output_addr_const_extra (FILE *file, rtx x)
return true;
}
+
+/* Since x64-64 linker IE->LE transition requires a REX prefix, we
+ output a REX prefix if there isn't one. */
+
+bool
+ix86_output_rex_prefix_p (rtx dest, rtx op)
+{
+ if (!TARGET_X32
+ || GET_MODE (dest) != SImode
+ || REX_INT_REG_P (dest)
+ || !MEM_P (op))
+return false;
+
+ op = XEXP (op, 0);
+ if (GET_CODE (op) != CONST)
+return false;
+
+ op = XEXP (op, 0);
+ if (GET_CODE (op) != UNSPEC)
+return false;
+
+ return XINT (op, 1) == UNSPEC_GOTNTPOFF;
+}
/* Split one or more double-mode RTL references into pairs of half-mode
references. The RTL can be REG, offsettable MEM, integer constant, or
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 8fc7918..35b2673 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2211,7 +2211,13 @@
if (ix86_use_lea_for_mov (insn, operands))
return "lea{l}\t{%a1, %0|%0, %a1}";
else
- return "mov{l}\t{%1, %0|%0, %1}";
+ {
+ /* Output REX prefix if needed. */
+ if (ix86_output_rex_prefix_p (operands[0], operands[1]))
+ return "rex mov{l}\t{%1, %0|%0, %1}";
+ else
+ return "mov{l}\t{%1, %0|%0, %1}";
+ }
}
}
[(set (attr "type")
@@ -5540,7 +5546,11 @@
if (x86_maybe_negate_const_int (&operands[2], mode))
return "sub{}\t{%2, %0|%0, %2}";
- return "add{}\t{%2, %0|%0, %2}";
+ /* Output REX prefix if needed. */
+ if (ix86_output_rex_prefix_p (operands[0], operands[2]))
+ return "rex add{}\t{%2, %0|%0, %2}";
+ else
+ return "add{}\t{%2, %0|%0, %2}";
}
}
[(set (attr "type")
--
1.7.6.5
Re: [4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1
On 03/02/2012 12:27 PM, Oleg Endo wrote: > + This value is used by optabs.c atomic op expansion code as well as in > + sync.md. It must be defined as signed char here or else the movqi > + pattern will refuse to load it as a QImode constant. */ > +#undef TARGET_ATOMIC_TEST_AND_SET_TRUEVAL > +#define TARGET_ATOMIC_TEST_AND_SET_TRUEVAL ((signed char)0x80) The fix to use gen_mode_int obviates the need for the (signed char) hack. r~
[patch] Fix debug info of nested inline functions
Hi Jason,
you may remember a patch I posted and over which we exchanged a few messages:
first message: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02143.html
last message: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01289.html
I eventually dropped the ball and nothing was installed, although we had almost
reached an agreement.
The problem is still present as of today on the mainline, so I think now is a
good time to solve it once for all. We were disagreeing on the last hunk of
the latest revision of the patch:
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01286.html
and you suggested to iterate over DECL_CONTEXT instead of die_parent to find an
appropriate parent in order to attach the DIE on the limbo list to.
I confirm that we need to iterate, as the immediate DECL_CONTEXT is an abtract
instance for the testcase. The attached patch implements this and generates
exactly the same debug info for the testcase as the original patch.
Tested on x86_64-suse-linux, OK for the mainline?
2012-03-02 Eric Botcazou
* dwarf2out.c (gen_subprogram_die): Emit a definition of nested
functions within an abstract instance of their parent.
(gen_inlined_subroutine_die): Return if the origin is to be ignored.
(function_possibly_abstracted_p): New static function.
(process_scope_var): Do not emit concrete instances of abstracted
nested functions from here.
(gen_decl_die): Emit the abstract instance if the function is possibly
abstracted and not only possibly inlined.
(dwarf2out_finish): Skip an abtract parent instance and iterate over
the context to find the first non-abstract parent instance to attach
concrete instances on the limbo list to it.
--
Eric Botcazou
Index: dwarf2out.c
===
--- dwarf2out.c (revision 184668)
+++ dwarf2out.c (working copy)
@@ -17173,7 +17173,13 @@ gen_subprogram_die (tree decl, dw_die_re
dw_die_ref subr_die;
tree outer_scope;
dw_die_ref old_die = lookup_decl_die (decl);
- int declaration = (current_function_decl != decl
+ /* Emit an abstract instance of nested functions within an abstract instance
+ of their parent. */
+ int declaration = ((decl != current_function_decl
+ && !(DECL_INITIAL (decl) != NULL_TREE
+ && DECL_ABSTRACT (decl)
+ && current_function_decl
+ && DECL_ABSTRACT (current_function_decl)))
|| class_or_namespace_scope_p (context_die));
premark_used_types ();
@@ -18198,6 +18204,8 @@ gen_inlined_subroutine_die (tree stmt, d
gcc_assert (! BLOCK_ABSTRACT (stmt));
decl = block_ultimate_origin (stmt);
+ if (DECL_IGNORED_P (decl))
+return;
/* Emit info for the abstract instance first, if we haven't yet. We
must emit this even if the block is abstract, otherwise when we
@@ -19158,8 +19166,25 @@ gen_block_die (tree stmt, dw_die_ref con
decls_for_scope (stmt, context_die, depth);
}
+/* Return true if an abstract instance of function DECL can be generated in
+ the debug information. */
+
+static bool
+function_possibly_abstracted_p (tree decl)
+{
+ while (decl)
+{
+ if (cgraph_function_possibly_inlined_p (decl))
+ return true;
+ decl = decl_function_context (decl);
+}
+
+ return false;
+}
+
/* Process variable DECL (or variable with origin ORIGIN) within
block STMT and add it to CONTEXT_DIE. */
+
static void
process_scope_var (tree stmt, tree decl, tree origin, dw_die_ref context_die)
{
@@ -19177,8 +19202,15 @@ process_scope_var (tree stmt, tree decl,
if (die != NULL && die->die_parent == NULL)
add_child_die (context_die, die);
else if (TREE_CODE (decl_or_origin) == IMPORTED_DECL)
-dwarf2out_imported_module_or_decl_1 (decl_or_origin, DECL_NAME (decl_or_origin),
+dwarf2out_imported_module_or_decl_1 (decl_or_origin,
+ DECL_NAME (decl_or_origin),
stmt, context_die);
+ /* Do not emit concrete instances of abstracted nested functions without
+ actual instances. */
+ else if (TREE_CODE (decl_or_origin) == FUNCTION_DECL
+ && die
+ && get_AT (die, DW_AT_inline))
+;
else
gen_decl_die (decl, origin, context_die);
}
@@ -19525,11 +19557,11 @@ gen_decl_die (tree decl, tree origin, dw
? DECL_ORIGIN (origin)
: DECL_ABSTRACT_ORIGIN (decl));
- /* If we're emitting an out-of-line copy of an inline function,
+ /* If we're emitting an out-of-line copy of an abstracted function,
emit info for the abstract instance and set up to refer to it. */
- else if (cgraph_function_possibly_inlined_p (decl)
- && ! DECL_ABSTRACT (decl)
- && ! class_or_namespace_scope_p (context_die)
+ else if (!DECL_ABSTRACT (decl)
+ && function_possibly_abstracted_p (decl)
+ && !class_or_namespace_scope_p (context_die)
/* dwarf2out_abstract_function won't emit a die if this is just
a declaration. We must avoid se
Re: PATCH [1/n] addr32: Properly use Pmode and word_mode
On Sat, Nov 12, 2011 at 9:32 AM, Uros Bizjak wrote: > On Sat, Nov 12, 2011 at 3:19 AM, H.J. Lu wrote: > >> The current x32 implementation uses LEAs to convert 32bit address to >> 64bit. However, we can use addr32 prefix to use 32bit address directly. >> It improves performance by 5% in SPEC CPU 2K/2006. All changes are done >> in x86 backend, except for a smaill unwind library assert change: >> >> http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01555.html >> >> due to return column size difference. >> >> For x86-64, Pmode can be 32bit or 64bit, but word_mode is always 64bit. >> push/pop only work on word_mode. Also string instructions take Pmode >> pointers. >> >> I will submit a set of patches to use 32bit Pmode for x32. This is >> the first patch to properly use Pmode and word_mode. It also adds >> addr32 prefix to string instructions if needed. OK for trunk? > > Not for stage3. > > Uros. Now trunk in stage1. The patch is at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01572.html OK for trunk? Thanks. -- H.J.
Re: [4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1
On Fri, 2012-03-02 at 10:11 -0800, Richard Henderson wrote: > For proper binary compatibility, we should probably introduce that asap. > You forgot two things in your patch, gen_int_mode and the fact that we > still have to return a boolean (0/1) value. Ah, yes, of course! > > Also in order for the binary compatibility to work right, you'd want to > have the SH test-and-set-trueval set appropriately asap. Kaz, I assume > you'd agree that 0x80 is a good value for the "tas.b" insn? We don't > necessarily need to support tas.b right away, but getting trueval set > right is imperative. > > I'm in the process of sanity testing this on x86_64 with trueval set to 0x80. > Jakub, ok for 4.7 branch if it passes? > Since we're now back to stage 1 again, I'm about to commit this one ... http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00085.html So the SH tas.b instruction support should be there from 4.8. Attached is the hunk from the tas.b patch for 4.8 to define TARGET_ATOMIC_TEST_AND_SET_TRUEVAL. Cheers, Oleg Index: gcc/config/sh/sh.h === --- gcc/config/sh/sh.h (revision 184669) +++ gcc/config/sh/sh.h (working copy) @@ -2475,4 +2475,11 @@ /* FIXME: middle-end support for highpart optimizations is missing. */ #define high_life_started reload_in_progress +/* The tas.b instruction sets the 7th bit in the byte, i.e. 0x80. + This value is used by optabs.c atomic op expansion code as well as in + sync.md. It must be defined as signed char here or else the movqi + pattern will refuse to load it as a QImode constant. */ +#undef TARGET_ATOMIC_TEST_AND_SET_TRUEVAL +#define TARGET_ATOMIC_TEST_AND_SET_TRUEVAL ((signed char)0x80) + #endif /* ! GCC_SH_H */
PATCH: Update gcc.target/i386/pr52146.c to allow $-18874240
Hi,
X32 may generate
movl$-18874240, %eax
movl(%eax), %eax
This patchs allows $-18874240. OK for trunk?
Thanks.
H.J.
---
2012-02-10 H.J. Lu
PR target/52146
* gcc.target/i386/pr52146.c: Update final-scan to allow $-18874240.
diff --git a/gcc/testsuite/gcc.target/i386/pr52146.c
b/gcc/testsuite/gcc.target/i386/pr52146.c
index a4804e6..4eb91c0 100644
--- a/gcc/testsuite/gcc.target/i386/pr52146.c
+++ b/gcc/testsuite/gcc.target/i386/pr52146.c
@@ -15,4 +15,4 @@ test2 (void)
*apic_tpr_addr = 0;
}
-/* { dg-final { scan-assembler-not "-18874240" } } */
+/* { dg-final { scan-assembler-not "\[,\\t \]+-18874240" } } */
--
1.7.6.5
libgo patch committed: Update to weekly.2012-02-22 release
I have committed a patch to update libgo to the weekly.2012-02-22
release. As usual this e-mail message only includes the changes to
gccgo-specific files. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r a2b8eab75cae libgo/MERGE
--- a/libgo/MERGE Fri Mar 02 08:23:02 2012 -0800
+++ b/libgo/MERGE Fri Mar 02 10:14:12 2012 -0800
@@ -1,4 +1,4 @@
-43cf9b39b647
+96bd78e7d35e
The first line of this file holds the Mercurial revision number of the
last merge done from the master library sources.
diff -r a2b8eab75cae libgo/Makefile.am
--- a/libgo/Makefile.am Fri Mar 02 08:23:02 2012 -0800
+++ b/libgo/Makefile.am Fri Mar 02 10:14:12 2012 -0800
@@ -504,7 +504,7 @@
mv -f $@.tmp $@
sema.c: $(srcdir)/runtime/sema.goc goc2c
- ./goc2c --gcc --go-prefix libgo_runtime $< > $@.tmp
+ ./goc2c --gcc --go-prefix libgo_sync $< > $@.tmp
mv -f $@.tmp $@
sigqueue.c: $(srcdir)/runtime/sigqueue.goc goc2c
@@ -847,6 +847,7 @@
go/sync/cond.go \
go/sync/mutex.go \
go/sync/once.go \
+ go/sync/runtime.go \
go/sync/rwmutex.go \
go/sync/waitgroup.go
@@ -878,6 +879,7 @@
go/time/tick.go \
go/time/time.go \
go/time/zoneinfo.go \
+ go/time/zoneinfo_read.go \
go/time/zoneinfo_unix.go
go_unicode_files = \
@@ -1091,6 +1093,7 @@
go/exp/norm/composition.go \
go/exp/norm/forminfo.go \
go/exp/norm/input.go \
+ go/exp/norm/iter.go \
go/exp/norm/normalize.go \
go/exp/norm/readwriter.go \
go/exp/norm/tables.go \
@@ -1132,7 +1135,8 @@
go/go/doc/example.go \
go/go/doc/exports.go \
go/go/doc/filter.go \
- go/go/doc/reader.go
+ go/go/doc/reader.go \
+ go/go/doc/synopsis.go
go_go_parser_files = \
go/go/parser/interface.go \
go/go/parser/parser.go
@@ -1159,7 +1163,6 @@
go_html_template_files = \
go/html/template/attr.go \
- go/html/template/clone.go \
go/html/template/content.go \
go/html/template/context.go \
go/html/template/css.go \
diff -r a2b8eab75cae libgo/runtime/malloc.goc
--- a/libgo/runtime/malloc.goc Fri Mar 02 08:23:02 2012 -0800
+++ b/libgo/runtime/malloc.goc Fri Mar 02 10:14:12 2012 -0800
@@ -19,6 +19,7 @@
#include "go-type.h"
MHeap runtime_mheap;
+
extern MStats mstats; // defined in extern.go
extern volatile int32 runtime_MemProfileRate
@@ -429,18 +430,6 @@
ret = runtime_mallocgc(typ->__size, flag, 1, 1);
}
-func Alloc(n uintptr) (p *byte) {
- p = runtime_malloc(n);
-}
-
-func Free(p *byte) {
- runtime_free(p);
-}
-
-func Lookup(p *byte) (base *byte, size uintptr) {
- runtime_mlookup(p, &base, &size, nil);
-}
-
func GC() {
runtime_gc(1);
}
diff -r a2b8eab75cae libgo/runtime/malloc.h
--- a/libgo/runtime/malloc.h Fri Mar 02 08:23:02 2012 -0800
+++ b/libgo/runtime/malloc.h Fri Mar 02 10:14:12 2012 -0800
@@ -205,6 +205,7 @@
uint64 heap_sys; // bytes obtained from system
uint64 heap_idle; // bytes in idle spans
uint64 heap_inuse; // bytes in non-idle spans
+ uint64 heap_released; // bytes released to the OS
uint64 heap_objects; // total number of allocated objects
// Statistics about allocation of low-level fixed-size structures.
@@ -220,6 +221,7 @@
// Statistics about garbage collector.
// Protected by stopping the world during GC.
uint64 next_gc; // next GC (in heap_alloc time)
+ uint64 last_gc; // last GC (in absolute time)
uint64 pause_total_ns;
uint64 pause_ns[256];
uint32 numgc;
@@ -304,14 +306,16 @@
{
MSpan *next; // in a span linked list
MSpan *prev; // in a span linked list
- MSpan *allnext; // in the list of all spans
+ MSpan *allnext; // in the list of all spans
PageID start; // starting page number
uintptr npages; // number of pages in span
MLink *freelist; // list of free objects
uint32 ref; // number of allocated objects in this span
uint32 sizeclass; // size class
uint32 state; // MSpanInUse etc
- byte *limit; // end of data in span
+ int64 unusedsince; // First time spotted by GC in MSpanFree state
+ uintptr npreleased; // number of pages released to the OS
+ byte *limit; // end of data in span
};
void runtime_MSpan_Init(MSpan *span, PageID start, uintptr npages);
@@ -381,6 +385,7 @@
void runtime_MGetSizeClassInfo(int32 sizeclass, uintptr *size, int32 *npages, int32 *nobj);
void* runtime_MHeap_SysAlloc(MHeap *h, uintptr n);
void runtime_MHeap_MapBits(MHeap *h);
+void runtime_MHeap_Scavenger(void*);
void* runtime_mallocgc(uintptr size, uint32 flag, int32 dogc, int32 zeroed);
int32 runtime_mlookup(void *v, byte **base, uintptr *size, MSpan **s);
@@ -406,19 +411,11 @@
void runtime_MProf_Malloc(void*, uintptr);
void runtime_MProf_Free(void*, uintptr);
+void runtime_MProf_GC(void);
void runtime_MProf_Mark(void (*scan)(byte *, int64));
int32 runtime_helpgc(bool*);
void runtime_gchelper(void);
-// Malloc profiling settings.
-// Must match definition in extern.go.
-enum {
- MProf_None = 0,
- MProf_Sample = 1,
- MProf_All = 2,
-};
-extern int32 runtime_malloc_profile;
-
struct __go_func_type;
bool runtime_getfinalizer(void *p, bool de
Re: libgo patch committed: Update to weekly.2012-02-14 release
Ian Lance Taylor writes:
> I have committed a patch to libgo to update to the weekly.2012-02-14
> release. As usual, in this e-mail message I only include the patches to
> files specific to the gccgo version of libgo. Bootstrapped and ran Go
> testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
This broke Solaris 10 (and probably 9 also) bootstrap:
/vol/gcc/src/hg/trunk/local/libgo/runtime/mem.c: In function 'mmap_fixed':
/vol/gcc/src/hg/trunk/local/libgo/runtime/mem.c:47:2: error: pointer targets in
passing argument 1 of 'mmap' differ in signedness [-Werror=pointer-sign]
In file included from /vol/gcc/src/hg/trunk/local/libgo/runtime/runtime.h:23:0,
from /vol/gcc/src/hg/trunk/local/libgo/runtime/mem.c:8:
/usr/include/sys/mman.h:168:16: note: expected 'caddr_t' but argument is of
type 'byte *'
/vol/gcc/src/hg/trunk/local/libgo/runtime/mem.c:53:3: error: pointer targets in
passing argument 1 of 'mmap' differ in signedness [-Werror=pointer-sign]
In file included from /vol/gcc/src/hg/trunk/local/libgo/runtime/runtime.h:23:0,
from /vol/gcc/src/hg/trunk/local/libgo/runtime/mem.c:8:
/usr/include/sys/mman.h:168:16: note: expected 'caddr_t' but argument is of
type 'byte *'
cc1: all warnings being treated as errors
The first mmap arg is caddr_t (char *), while byte * is uint8 *.
Casting to void * fixes this.
Rainer
# HG changeset patch
# Parent 3c65bd27734429765e18be13aeb46e624807b984
Cast mmap addr to void *
diff --git a/libgo/runtime/mem.c b/libgo/runtime/mem.c
--- a/libgo/runtime/mem.c
+++ b/libgo/runtime/mem.c
@@ -44,13 +44,13 @@ mmap_fixed(byte *v, uintptr n, int32 pro
{
void *p;
- p = runtime_mmap(v, n, prot, flags, fd, offset);
+ p = runtime_mmap((void *)v, n, prot, flags, fd, offset);
if(p != v && addrspace_free(v, n)) {
// On some systems, mmap ignores v without
// MAP_FIXED, so retry if the address space is free.
if(p != MAP_FAILED)
runtime_munmap(p, n);
- p = runtime_mmap(v, n, prot, flags|MAP_FIXED, fd, offset);
+ p = runtime_mmap((void *)v, n, prot, flags|MAP_FIXED, fd, offset);
}
return p;
}
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libgo patch committed: Fill out syscall package for GNU/Linux
Rainer Orth writes: > Ian Lance Taylor 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 Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, rs6000] Add support for the POWER7 dcffix instruction
On Wed, 2012-02-01 at 23:09 -0500, David Edelsohn wrote: > On Wed, Feb 1, 2012 at 10:00 PM, Peter Bergner wrote: > > The POWER Toolchain IPC team who is adding POWER7 support to valgrind > > reminded me that Power ISA 2.06 added a new convert from integer to > > decimal64 dfp instruction. The following patch adds support for it. > > > > This passed bootstrap and regression testing with no regressions. > > Is this ok? If so, when can this be committed? Now or stage1? > > Stage 1. Now that we're in stage1, I have now committed this to trunk. Thanks. Peter
PATCH: Add Linux/x32 support to Ada
Hi, This patch adds Linux/x32 support to Ada. It sets LIBGNAT_TARGET_PAIRS similar to Linux/x86-64 and replaces system-linux-x86_64.ads with system-linux-x86.ads. It also adds "orl $0x0,(%esp)" check for SIGSEGV probe and sets __gnat_default_libgcc_subdir to libx32 for x32. Tested on Linux/x32 with the following Ada test failures: FAIL: gnat.dg/curr_task.adb execution test FAIL: gnat.dg/lto8.adb (test for excess errors) FAIL: gnat.dg/requeue1.adb execution test FAIL: gnat.dg/test_image.adb execution test FAIL: gnat.dg/timer_cancel.adb execution test FAIL: gnat.dg/specs/addr1.ads (test for bogus messages, line 24) FAIL: gnat.dg/specs/addr1.ads (test for excess errors) FAIL: gnat.dg/specs/atomic1.ads (test for errors, line 9) FAIL: gnat.dg/specs/atomic1.ads (test for errors, line 13) OK for trunk? Thanks. H.J. --- 2012-03-02 H.J. Lu * init.c (__gnat_adjust_context_for_raise): Also check "orq $0x0,(%esp)" for x32. * link.c (__gnat_default_libgcc_subdir): set to libx32 for x32. * gcc-interface/Makefile.in (arch): Set to x32 if MULTISUBDIR is /x32. Support x32. diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in index 5fa6ffa..19d9eb0 100644 --- a/gcc/ada/gcc-interface/Makefile.in +++ b/gcc/ada/gcc-interface/Makefile.in @@ -349,6 +349,10 @@ GNATMAKE_OBJS = a-except.o ali.o ali-util.o aspects.o s-casuti.o alloc.o \ ifeq ($(strip $(filter-out %x86_64, $(arch))),) ifeq ($(strip $(MULTISUBDIR)),/32) arch:=i686 + else +ifeq ($(strip $(MULTISUBDIR)),/x32) + arch:=x32 +endif endif endif @@ -2134,6 +2138,43 @@ ifeq ($(strip $(filter-out %x86_64 linux%,$(arch) $(osys))),) LIBRARY_VERSION := $(LIB_VERSION) endif +ifeq ($(strip $(filter-out %x32 linux%,$(arch) $(osys))),) + LIBGNAT_TARGET_PAIRS = \ + a-exetim.adbgregs[REG_ESP] += 4096 + 4 * sizeof (unsigned long); #elif defined (__x86_64__) - unsigned long *pc = (unsigned long *)mcontext->gregs[REG_RIP]; - /* The pattern is "orq $0x0,(%rsp)" for a probe in 64-bit mode. */ - if (signo == SIGSEGV && pc && (*pc & 0xff) == 0x00240c8348) + unsigned long long *pc = (unsigned long long *)mcontext->gregs[REG_RIP]; + if (signo == SIGSEGV && pc + /* The pattern is "orq $0x0,(%rsp)" for a probe in 64-bit mode. */ + && ((*pc & 0xffLL) == 0x00240c8348LL +# ifndef __LP64__ + /* The pattern may also be "orl $0x0,(%esp)" for a probe in x32 +mode. */ + || (*pc & 0xLL) == 0x00240c83LL +# endif +)) mcontext->gregs[REG_RSP] += 4096 + 4 * sizeof (unsigned long); #elif defined (__ia64__) /* ??? The IA-64 unwinder doesn't compensate for signals. */ diff --git a/gcc/ada/link.c b/gcc/ada/link.c index 8bcad27..3648878 100644 --- a/gcc/ada/link.c +++ b/gcc/ada/link.c @@ -187,7 +187,11 @@ unsigned char __gnat_using_gnu_linker = 1; const char *__gnat_object_library_extension = ".a"; unsigned char __gnat_separate_run_path_options = 0; #if defined (__x86_64) +# if defined __LP64__ const char *__gnat_default_libgcc_subdir = "lib64"; +# else +const char *__gnat_default_libgcc_subdir = "libx32"; +# endif #else const char *__gnat_default_libgcc_subdir = "lib"; #endif
[pph] Merge template specializations. (issue5726044)
This patch merges template specializations. * Factored searching out of pph_in_merge_key_tree via a function parameter. Its name is now pph_in_merge_key_tree_with_searcher. The decl searching now resides in pph_in_search_key_decl_on_chain and the type searching now resides in pph_in_search_key_type_in_var. Added two convenience functions pph_in_merge_key_decl_on_chain and pph_in_merge_key_type_in_var to enable concise replacement of calls to pph_in_merge_key_tree.. * Split pph_out/in_global_binding to place the specialization keys between the global keys and the global bodies. * Changed the template state in/out functions to be non-specific to specific tables, but specific to keys or bodies. * Added strptrmap.h and strptrmap.c for searching for existing specializations. * Several routines in pph-out.c and pph-in.c needed for specialization merging have been made extern for pt.c. The major test changes are as follows. * Several ICEs are now gone, most of which are replaced by other errors. * More instances of a bogus error on a void atomic intrinsic. * Unimplemented trait mangling in x6dynarray5.h, which also causes all includers to fail. * Test abi/mangle17.C changes behavior. It emits errors for the an equivalent but different piece of code. I will address this problem later. Test cleanups are as follows. * Some compilation failures add a 'documentary' xfail-if. The syntax is exactly like "dg-xfail-if", but without the "dg-". This change enables searching for "xfail-if". * Some assembly comparisons add or modify a 'xfail' comment to an 'xfail-if' comment. This change enables searching for "xfail-if". * The dg-pph.exp test controller now searches for xfail-if rather than dg-xfail-if to catch expected fails with no exess errors. * Some tests have had their xfail-if comment string clarified. * Some tests used dg-excess-errors. These have been removed in favor of stating the exact failures. * Some compilation dg-bogus patterns have been moved to the offending * Some compilation problems have been isolated to a single line and statement, which enables the above. line. * One test has changed trailing include text into a comment. Tested on x64. Index: gcc/testsuite/ChangeLog.pph 2012-03-01 Lawrence Crowl * lib/dg-pph.exp: Change search for dg-xfail-if to xfail-if. * g++.dg/pph/d0include-next.h: Put dg-warning in comment. * g++.dg/pph/x2incomplete4.cc: Add documentary xfail-if. * g++.dg/pph/x4incomplete4321.cc: Change documentary to xfail-if. * g++.dg/pph/x4tmplclass2.cc: Change documentary to xfail-if. * g++.dg/pph/x4tmplfuncinln.cc: Mark pph asm xokay. * g++.dg/pph/x4tmplfuncninl.cc: Mark pph asm xokay. * g++.dg/pph/x5dynarray7.h: Add documentary xfail-if. * g++.dg/pph/x6dynarray3.cc: Add documentary xfail-if. * g++.dg/pph/x6dynarray4.cc: Change to xfail on included pph. * g++.dg/pph/x6dynarray5.h: Change to xfail on included pph. * g++.dg/pph/x6dynarray6.h: Add documentary xfail-if. * g++.dg/pph/x6rtti.cc: Remove excess-errors filter. Add bogus rtti mismatch. Make xfail-if documentary. * g++.dg/pph/x7dynarray5.cc: Change to xfail on included pph. (The bogus void intrinsic comes fail-over to reading the textual header.) * g++.dg/pph/x7dynarray6.cc: Change to xfail on bogus void intrinsic. * g++.dg/pph/x7dynarray7.cc: Remove excess-errors filter. Add bogus void intrinsic. Change xfail-if message. * g++.dg/pph/x7rtti.cc: Add documentary xfail-if. Separate failures to separate statements. Put dg-bogus on offending lines. * g++.dg/pph/z4nontrivinit.cc: Change documentary to xfail-if. * g++.dg/pph/z4tmplclass1.cc: Change in failing asm output. Change documentary to xfail-if. * g++.dg/pph/z4tmplclass2.cc: Change in failing asm output. Change documentary to xfail-if. * g++.dg/pph/z4tmplfuncinln.cc: Mark pph asm xokay. * g++.dg/pph/z4tmplfuncninl.cc: Mark pph asm xokay. Index: gcc/cp/ChangeLog.pph 2012-03-01 Lawrence Crowl * pph-core.c (pph_include_handler): Make warning message a single line. * Make-lang.in (cp/pt.o): Depend on strptrmap.h. * pph.h (pph_out_merge_key_tree): Made extern. (pph_in_string): Made extern. (typedef pph_merge_searcher): New. (pph_in_merge_key_tree_with_searcher): Made extern. (pph_out_pending_templates_list): Removed. (pph_out_spec_entry_tables): Removed. (pph_in_pending_templates_list): Removed. (pph_in_spec_entry_tables): Removed. (pph_out_merge_key_template_state): New. (pph_out_merge_body_template_state): New. (pph_in_merge_key_template_state): New. (pph_in_merge_body_template_state): New. * pt.c (#include "strptrmap.h"): New. (pph_out_pending_templates_list): Move dump to higher level. (pph_in_pending_templates_list): Make
Re: [PATCH, rs6000][trunk,4.7,4.6,4.5] Fix PR52457, wrong code for -O1 -m32 -mcpu=power7
On Fri, 2012-03-02 at 11:19 -0500, David Edelsohn wrote: > On Fri, Mar 2, 2012 at 10:57 AM, Peter Bergner wrote: > > The patch below fixes a typo in the vsx_set_ pattern that causes > > wrong code to be generated when using -mcpu=power7. This passed bootstrap > > and regression testing on trunk using powerpc64-linux. Ok for trunk? > > > > This is also broken on the 4.7, 4.6 and 4.5 branches, is this ok for > > those release branches once the branches are open for fixes and my > > bootstrapping/regtesting are complete? > > > >* gcc/config/rs6000/vsx.md (vsx_set_): Reorder operands. > >* gcc/testsuite/gcc.target/powerpc/pr52457.c: New test. > > Okay everywhere, but please make sure that Richi and Jakub are okay > with the patch for GCC 4.7. Ok, I have committed the patch to trunk and the 4.7 branch given Jakub's ok in his email. I'll commit the patch to the 4.6 and 4.5 branches once my testing has completed. Thanks. Peter
backports for PR target/49461 and PR boehm-gc/52179
I've checked in the backports for PR target/49461 and PR boehm-gc/52179 into
the 4.6.x release branch. Thanks Jack.
Index: boehm-gc/configure.ac
===
--- boehm-gc/configure.ac (revision 184807)
+++ boehm-gc/configure.ac (working copy)
@@ -392,6 +392,7 @@ esac
oldLIBS="$LIBS"
LIBS="$LIBS $THREADLIBS"
AC_CHECK_FUNCS([pthread_getattr_np])
+AC_CHECK_FUNCS([pthread_get_stackaddr_np])
LIBS="$oldLIBS"
# Configuration of machine-dependent code
Index: boehm-gc/include/gc_config.h.in
===
--- boehm-gc/include/gc_config.h.in (revision 184807)
+++ boehm-gc/include/gc_config.h.in (working copy)
@@ -87,6 +87,9 @@
/* Define to 1 if you have the `pthread_getattr_np' function. */
#undef HAVE_PTHREAD_GETATTR_NP
+/* Define to 1 if you have the `pthread_get_stackaddr_np_np' function. */
+#undef HAVE_PTHREAD_GET_STACKADDR_NP
+
/* Define to 1 if you have the header file. */
#undef HAVE_STDINT_H
Index: boehm-gc/include/private/gcconfig.h
===
--- boehm-gc/include/private/gcconfig.h (revision 184807)
+++ boehm-gc/include/private/gcconfig.h (working copy)
@@ -1331,7 +1331,11 @@
These aren't used when dyld support is enabled (it is by default) */
# define DATASTART ((ptr_t) get_etext())
# define DATAEND ((ptr_t) get_end())
-# define STACKBOTTOM ((ptr_t) 0xc000)
+# ifdef HAVE_PTHREAD_GET_STACKADDR_NP
+# define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self())
+# else
+# define STACKBOTTOM ((ptr_t) 0xc000)
+# endif
# define USE_MMAP
# define USE_MMAP_ANON
# define USE_ASM_PUSH_REGS
@@ -2011,7 +2015,11 @@
These aren't used when dyld support is enabled (it is by default) */
# define DATASTART ((ptr_t) get_etext())
# define DATAEND ((ptr_t) get_end())
-# define STACKBOTTOM ((ptr_t) 0x7fff5fc0)
+# ifdef HAVE_PTHREAD_GET_STACKADDR_NP
+# define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self())
+# else
+# define STACKBOTTOM ((ptr_t) 0x7fff5fc0)
+# endif
# define USE_MMAP
# define USE_MMAP_ANON
# ifdef GC_DARWIN_THREADS
Index: boehm-gc/ChangeLog
===
--- boehm-gc/ChangeLog (revision 184807)
+++ boehm-gc/ChangeLog (working copy)
@@ -1,3 +1,17 @@
+2012-03-02 Jack Howarth
+
+ Backport from mainline
+ 2012-02-23 Patrick Marlier
+ Jack Howarth
+
+ PR boehm-gc/52179
+ * include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP.
+ * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with
+ pthread_get_stackaddr_np when available.
+ * configure.ac (THREADS): Check availability of
+ pthread_get_stackaddr_np.
+ * configure: Regenerate.
+
2012-03-01 Release Manager
* GCC 4.6.3 released.
Index: boehm-gc/configure
===
--- boehm-gc/configure (revision 184807)
+++ boehm-gc/configure (working copy)
@@ -15246,6 +15246,17 @@ _ACEOF
fi
done
+for ac_func in pthread_get_stackaddr_np
+do :
+ ac_fn_c_check_func "$LINENO" "pthread_get_stackaddr_np"
"ac_cv_func_pthread_get_stackaddr_np"
+if test "x$ac_cv_func_pthread_get_stackaddr_np" = x""yes; then :
+ cat >>confdefs.h <<_ACEOF
+#define HAVE_PTHREAD_GET_STACKADDR_NP 1
+_ACEOF
+
+fi
+done
+
LIBS="$oldLIBS"
# Configuration of machine-dependent code
Index: libjava/configure.ac
===
--- libjava/configure.ac(revision 184807)
+++ libjava/configure.ac(working copy)
@@ -886,14 +886,9 @@ case "${host}" in
SYSTEMSPEC="-lunicows $SYSTEMSPEC"
fi
;;
-*-*-darwin9*)
+*-*-darwin[[912]]*)
SYSTEMSPEC="%{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}"
;;
-*-*-darwin[[12]]*)
- # Something is incompatible with pie, would be nice to fix it and
- # remove -no_pie. PR49461
- SYSTEMSPEC="-no_pie %{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}"
-;;
*)
SYSTEMSPEC=
;;
Index: libjava/ChangeLog
===
--- libjava/ChangeLog (revision 184807)
+++ libjava/ChangeLog (working copy)
@@ -1,3 +1,13 @@
+2012-03-02 Jack Howarth
+
+ Backport from mainline
+ 2012-02-23 Patrick Marlier
+ Jack Howarth
+
+ PR target/49461
+ * configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11.
+ * configure: Regenerate.
+
2012-03-01 Release Manager
* GCC 4.6.3 released.
Index: libjava/configure
===
--- libjava/configure (revision 184807)
+++ libjava/configure (working copy)
@@ -19775,
[4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1
On 02/28/2012 07:16 AM, Oleg Endo wrote:
> Wouldn't it make sense to use the value behind
> TARGET_ATOMIC_TEST_AND_SET_TRUEVAL in optabs.c
> (expand_atomic_test_and_set) instead of const1_rtx when emitting
> generated atomic_exchange / atomic_compare_and_swap_exchange_loop?
> Maybe something like the attached patch?
>
> Background:
> I'm working on a patch to add a new option -menable-tas (independent of
> the existing -msoft-atomic option) which would allow the compiler to
> generate SH's tas.b insn. This would allow using the tas.b insn without
> the other atomic sequences, or in combination with them. The reason
> behind this is that the tas.b insn might not always be appropriate to
> use, depending on the particular system hardware/software setup (e.g.
> dual-core SH4A).
> On SH the TARGET_ATOMIC_TEST_AND_SET_TRUEVAL has to be defined as 0x80.
> Having the generated atomic_compare_and_swap / atomic_exchange sequences
> using 0x01 as the 'set' value might lead to inconsistencies when mixing
> code that uses the tas.b insn and code that doesn't use it, which should
> actually be OK to do.
That's a good idea.
For proper binary compatibility, we should probably introduce that asap.
You forgot two things in your patch, gen_int_mode and the fact that we
still have to return a boolean (0/1) value.
Also in order for the binary compatibility to work right, you'd want to
have the SH test-and-set-trueval set appropriately asap. Kaz, I assume
you'd agree that 0x80 is a good value for the "tas.b" insn? We don't
necessarily need to support tas.b right away, but getting trueval set
right is imperative.
I'm in the process of sanity testing this on x86_64 with trueval set to 0x80.
Jakub, ok for 4.7 branch if it passes?
r~
* optabs.c (expand_atomic_test_and_set): Honor
atomic_test_and_set_trueval even when atomic_test_and_set
optab is not in use.
diff --git a/gcc/optabs.c b/gcc/optabs.c
index b0ecdf0..fd353d7 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -7384,34 +7384,57 @@ rtx
expand_atomic_test_and_set (rtx target, rtx mem, enum memmodel model)
{
enum machine_mode mode = GET_MODE (mem);
- rtx ret;
+ rtx ret, trueval, subtarget;
ret = maybe_emit_atomic_test_and_set (target, mem, model);
if (ret)
return ret;
- if (target == NULL_RTX)
-target = gen_reg_rtx (mode);
+ /* Be binary compatible with non-default settings of trueval, and different
+ cpu revisions. E.g. one revision may have atomic-test-and-set, but
+ another only has atomic-exchange. */
+ if (targetm.atomic_test_and_set_trueval == 1)
+{
+ trueval = const1_rtx;
+ subtarget = target ? target : gen_reg_rtx (mode);
+}
+ else
+{
+ trueval = gen_int_mode (targetm.atomic_test_and_set_trueval, mode);
+ subtarget = gen_reg_rtx (mode);
+}
- /* If there is no test and set, try exchange, then a compare_and_swap loop,
- then __sync_test_and_set. */
- ret = maybe_emit_atomic_exchange (target, mem, const1_rtx, model);
- if (ret)
-return ret;
+ /* Try the atomic-exchange optab... */
+ ret = maybe_emit_atomic_exchange (subtarget, mem, trueval, model);
- ret = maybe_emit_compare_and_swap_exchange_loop (target, mem, const1_rtx);
- if (ret)
-return ret;
+ /* ... then an atomic-compare-and-swap loop ... */
+ if (!ret)
+ret = maybe_emit_compare_and_swap_exchange_loop (subtarget, mem, trueval);
- ret = maybe_emit_sync_lock_test_and_set (target, mem, const1_rtx, model);
- if (ret)
-return ret;
+ /* ... before trying the vaguely defined legacy lock_test_and_set. */
+ if (!ret)
+ret = maybe_emit_sync_lock_test_and_set (subtarget, mem, trueval, model);
- /* Failing all else, assume a single threaded environment and simply perform
- the operation. */
- emit_move_insn (target, mem);
- emit_move_insn (mem, const1_rtx);
- return target;
+ /* Recall that the legacy lock_test_and_set optab was allowed to do magic
+ things with the value 1. Thus we try again without trueval. */
+ if (!ret && targetm.atomic_test_and_set_trueval != 1)
+ret = maybe_emit_sync_lock_test_and_set (subtarget, mem, const1_rtx,
model);
+
+ /* Failing all else, assume a single threaded environment and simply
+ perform the operation. */
+ if (!ret)
+{
+ emit_move_insn (subtarget, mem);
+ emit_move_insn (mem, trueval);
+ ret = subtarget;
+}
+
+ /* Recall that have to return a boolean value; rectify if trueval
+ is not exactly one. */
+ if (targetm.atomic_test_and_set_trueval != 1)
+ret = emit_store_flag_force (target, NE, ret, const0_rtx, mode, 0, 1);
+
+ return ret;
}
/* This function expands the atomic exchange operation:
Re: libitm: Update texinfo docs.
On Fri, Mar 02, 2012 at 09:35:18AM -0800, Richard Henderson wrote: > On 03/02/2012 09:10 AM, Torvald Riegel wrote: > > libitm: Update texinfo docs. > > > > libitm/ > > * libitm.texi: Link to specification and add a usage example. > > I would think this should still be ok for 4.7... Yes, it is. Jakub
PATCH: Add --with-abi= support to x86_64-*-*
Hi,
This patch adds --with-abi= support to x86_64-*-* to configure GCC with
--with-abi=x32
--with-abi=mx32
--with-multilib-list=mx32
to set the default ABI to x32. In i386 backend, ISA_64BIT is used to
generate i386 code or x86-64 code. This patch adds a new bit,
ISA_X86_64 to generate 32bit x86-64 code or 64bit x86-64 code. Now it
has
OPTION_MASK_ISA_64BIT 32bit x86-64 code or 64bit x86-64 code
OPTION_MASK_ISA_X86_64 64bit x86-64 code
OPTION_MASK_ISA_X32 32bit x86-64 code
It also extends TARGET_BI_ARCH to support
TARGET_BI_ARCH == 1, by default, OPTION_MASK_ISA_X86_64
TARGET_BI_ARCH == 2, by default, OPTION_MASK_ISA_X32
I also added check --with-multilib-list for x86-64 Linux targets only if
multilib is enabled.
Tested on Linux/x32. OK for trunk?
Thanks.
H.J.
---
2012-03-02 H.J. Lu
* config.gcc: Use i386/biarchx32.h instead of i386/biarch64.h
for --with-abi={x32|mx32} or --with-multilib-list=mx32.
(supported_defaults): Add abi for i[34567]86-*-* and x86_64-*-*.
Check --with-multilib-list for x86-64 Linux targets only if
multilib is enabled.
* config/i386/biarch64.h (TARGET_64BIT_DEFAULT): Add
OPTION_MASK_ISA_X86_64.
* config/i386/biarchx32.h: New.
* config/i386/gnu-user64.h (SPEC_64): Support TARGET_BI_ARCH == 2.
(SPEC_X32): Likewise.
(MULTILIB_DEFAULTS): Likewise.
* config/i386/i386.c (ix86_option_override_internal): Properly
set OPTION_MASK_ISA_64BIT and OPTION_MASK_ISA_X32 as well as
handle -m32, -m64 and -mx32.
* config/i386/i386.h (TARGET_X86_64): New.
(TARGET_LP64): Changed to TARGET_X86_64.
* config/i386/i386.opt (m64): Replace ISA_64BIT with ISA_X86_64.
(mx86-64): New.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 99f0b47..5010739 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -486,6 +486,10 @@ fi
case ${target} in
i[34567]86-*-*)
+ if test "x$with_abi" != x; then
+ echo "This target does not support --with-abi."
+ exit 1
+ fi
if test "x$enable_cld" = xyes; then
tm_defines="${tm_defines} USE_IX86_CLD=1"
fi
@@ -495,7 +499,24 @@ i[34567]86-*-*)
tm_file="vxworks-dummy.h ${tm_file}"
;;
x86_64-*-*)
- tm_file="i386/biarch64.h ${tm_file}"
+ case ${with_abi} in
+ "")
+ if test "x$with_multilib_list" = xmx32; then
+ tm_file="i386/biarchx32.h ${tm_file}"
+ else
+ tm_file="i386/biarch64.h ${tm_file}"
+ fi
+ ;;
+ 64 | m64)
+ tm_file="i386/biarch64.h ${tm_file}"
+ ;;
+ x32 | mx32)
+ tm_file="i386/biarchx32.h ${tm_file}"
+ ;;
+ *)
+ echo "Unknown ABI used in --with-abi=$with_abi"
+ exit 1
+ esac
if test "x$enable_cld" = xyes; then
tm_defines="${tm_defines} USE_IX86_CLD=1"
fi
@@ -1304,22 +1325,24 @@ x86_64-*-linux* | x86_64-*-kfreebsd*-gnu |
x86_64-*-knetbsd*-gnu)
;;
esac
tmake_file="${tmake_file} i386/t-linux64"
- x86_multilibs="${with_multilib_list}"
- if test "$x86_multilibs" = "default"; then
- x86_multilibs="m64,m32"
+ if test "x$enable_multilib" = "xyes"; then
+ x86_multilibs="${with_multilib_list}"
+ if test "$x86_multilibs" = "default"; then
+ x86_multilibs="m64,m32"
+ fi
+ x86_multilibs=`echo $x86_multilibs | sed -e 's/,/ /g'`
+ for x86_multilib in ${x86_multilibs}; do
+ case ${x86_multilib} in
+ m32 | m64 | mx32)
+
TM_MULTILIB_CONFIG="${TM_MULTILIB_CONFIG},${x86_multilib}"
+ ;;
+ *)
+ echo "--with-multilib-list=${x86_with_multilib}
not supported."
+ exit 1
+ esac
+ done
+ TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG | sed 's/^,//'`
fi
- x86_multilibs=`echo $x86_multilibs | sed -e 's/,/ /g'`
- for x86_multilib in ${x86_multilibs}; do
- case ${x86_multilib} in
- m32 | m64 | mx32)
-
TM_MULTILIB_CONFIG="${TM_MULTILIB_CONFIG},${x86_multilib}"
- ;;
- *)
- echo "--with-multilib-list=${x86_with_multilib} not
supported."
- exit 1
- esac
- done
- TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG | sed 's/^,//'`
;;
i[34567]86-pc-msdosdjgpp*)
xm_file=i386/xm-djgpp.h
@@ -3189,7 +3212,7 @@ case "${target}" in
;;
i[34567]86-*-* | x86_64-*-*)
- support
Re: Fix POINTER_PLUS_EXPR oversight
On Mar 2, 2012, at 1:33 AM, Richard Guenther wrote: >> Interestingly, the C++ frontend also has a pointer_diff function, but >> doesn't seem to attempt to optimize. Is there a reason for this? > > Frontends should not optimize when they are not required to. Actually, the frontends should optimize as long as it produces a faster compilation (and they are permitted to). You're thinking of the rule that proceeded this one, we switch away from many many years back.
Re: [v3] Update Solaris baselines for GCC 4.7, take 2
Benjamin De Kosnik writes: >> I was surprised to see GLIBCXX_3.4.15 symbols added, but then realized >> you added the complete set so this seems fine. > > I meant to say: surprised to see GLIBCXX_3.4.16 symbols added, but then > you the complete set so this seems fine. So the only added symbols are > the complete set of GLIBCXX_3.4.16 and then the usual GLIBCXX_3.4.17 > ones. Looks good. Right: as I mentioned in PR libstdc++/52456, when I ran a mainline bootstrap before I'd checked in the new baselines, I got abi_check FAILs for the GLIBCXX_3.4.16 symbols which of course were not in the Solaris baselines from GCC 4.6.0. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libitm: Update texinfo docs.
On 03/02/2012 09:10 AM, Torvald Riegel wrote: > libitm: Update texinfo docs. > > libitm/ > * libitm.texi: Link to specification and add a usage example. I would think this should still be ok for 4.7... r~
Re: [PATCH, rs6000][trunk,4.7,4.6,4.5] Fix PR52457, wrong code for -O1 -m32 -mcpu=power7
On Fri, Mar 02, 2012 at 11:19:15AM -0500, David Edelsohn wrote: > On Fri, Mar 2, 2012 at 10:57 AM, Peter Bergner wrote: > > The patch below fixes a typo in the vsx_set_ pattern that causes > > wrong code to be generated when using -mcpu=power7. This passed bootstrap > > and regression testing on trunk using powerpc64-linux. Ok for trunk? > > > > This is also broken on the 4.7, 4.6 and 4.5 branches, is this ok for > > those release branches once the branches are open for fixes and my > > bootstrapping/regtesting are complete? > > > > Peter > > > > * gcc/config/rs6000/vsx.md (vsx_set_): Reorder operands. > > * gcc/testsuite/gcc.target/powerpc/pr52457.c: New test. > > Okay everywhere, but please make sure that Richi and Jakub are okay > with the patch for GCC 4.7. This is ok for 4.7.0. Jakub
libitm: Update texinfo docs.
Just fixed a missing subsection in libitm's texinfo docs.
OK for trunk? If so, I'd also think it would be good if this could
still get added to 4.7 (sorry for missing the deadline).
commit e50b0c9e610fdefce5063de0b88cee6c842694e5
Author: Torvald Riegel
Date: Fri Mar 2 18:07:16 2012 +0100
libitm: Update texinfo docs.
libitm/
* libitm.texi: Link to specification and add a usage example.
diff --git a/libitm/libitm.texi b/libitm/libitm.texi
index b31657f..6cfcaf9 100644
--- a/libitm/libitm.texi
+++ b/libitm/libitm.texi
@@ -82,8 +82,8 @@ several threads.
To activate support for TM in C/C++, the compile-time flag @option{-fgnu-tm}
must be specified. This enables TM language-level constructs such as
-transaction statements (@code{__transaction}, @pxref{C/C++ Language
-Constructs for TM} for details).
+transaction statements (e.g., @code{__transaction_atomic}, @pxref{C/C++
+Language Constructs for TM} for details).
@c -
@c C/C++ Language Constructs for TM
@@ -92,7 +92,35 @@ Constructs for TM} for details).
@node C/C++ Language Constructs for TM
@chapter C/C++ Language Constructs for TM
-TODO: link to the C++ TM spec. a few examples. how gcc's support differs.
+Transactions are supported in C++ and C in the form of transaction statements,
+transaction expressions, and function transactions. In the following example,
+both @code{a} and @code{b} will be read and the difference will be written to
+@code{c}, all atomically and isolated from other transactions:
+
+@example
+__transaction_atomic @{ c = a - b; @}
+@end example
+
+Therefore, another thread can use the following code to concurrently update
+@code{b} without ever causing @code{c} to hold a negative value (and without
+having to use other synchronization constructs such as locks or C++11
+atomics):
+
+@example
+__transaction_atomic @{ if (a > b) b++; @}
+@end example
+
+GCC follows the @uref{https://sites.google.com/site/tmforcplusplus/, Draft
+Specification of Transactional Language Constructs for C++ (v1.1)} in its
+implementation of transactions.
+
+The precise semantics of transactions are defined in terms of the C++11/C11
+memory model (see the specification). Roughly, transactions provide
+synchronization guarantees that are similar to what would be guaranteed when
+using a single global lock as a guard for all transactions. Note that like
+other synchronization constructs in C/C++, transactions rely on a
+data-race-free program (e.g., a nontransactional write that is concurrent
+with a transactional read to the same memory location is a data race).
@c -
@c The libitm ABI
Re: [PATCH, i386]: Fix PR 46716, [4.4/4.5/4.6/4.7/4.8 Regression] wrong code generated with -mno-sse2 -m64
On Fri, Mar 2, 2012 at 5:40 PM, Uros Bizjak wrote:
>>> Patch was tested on x86_64-pc-linux-gnu {,-m32}. Patch was committed
>>> to mainline, is it OK to commit to 4.7 after it opens?
>>
>> Have you done any compat testing against compiler without that change
>> (using ALT_CC_UNDER_TEST=/whatever/gcc ALT_CXX_UNDER_TEST=/whatever/g++ )?
>> Just to double check it doesn't introduce ABI compatibility issues?
>
> No, but will do so before commit.
No surprises on Fedora 16 with:
ALT_CC_UNDER_TEST="/usr/bin/gcc"
ALT_CXX_UNDER_TEST="/usr/bin/g++"
Uros.
Re: [v3] libstdc++/51785
... removes extra "extern." -benjamin2012-03-02 Benjamin Kosnik * include/c_global/cstdio: Remove extraneous extern. * include/c_std/cstdio: Same. diff --git a/libstdc++-v3/include/c_global/cstdio b/libstdc++-v3/include/c_global/cstdio index d11743a..e648475 100644 --- a/libstdc++-v3/include/c_global/cstdio +++ b/libstdc++-v3/include/c_global/cstdio @@ -47,7 +47,7 @@ #define _GLIBCXX_CSTDIO 1 #ifndef _GLIBCXX_HAVE_GETS -extern "C" extern char* gets (char* __s) __attribute__((deprecated)); +extern "C" char* gets (char* __s) __attribute__((deprecated)); #endif // Get rid of those macros defined in in lieu of real functions. diff --git a/libstdc++-v3/include/c_std/cstdio b/libstdc++-v3/include/c_std/cstdio index 1588fc9..d4f4732 100644 --- a/libstdc++-v3/include/c_std/cstdio +++ b/libstdc++-v3/include/c_std/cstdio @@ -46,7 +46,7 @@ #include #ifndef _GLIBCXX_HAVE_GETS -extern "C" extern char* gets (char* __s) __attribute__((deprecated)); +extern "C" char* gets (char* __s) __attribute__((deprecated)); #endif // Get rid of those macros defined in in lieu of real functions.
Re: [PATCH, i386]: Fix PR 46716, [4.4/4.5/4.6/4.7/4.8 Regression] wrong code generated with -mno-sse2 -m64
On Fri, Mar 2, 2012 at 5:36 PM, Jakub Jelinek wrote:
> On Fri, Mar 02, 2012 at 05:32:18PM +0100, Uros Bizjak wrote:
>> Patch was tested on x86_64-pc-linux-gnu {,-m32}. Patch was committed
>> to mainline, is it OK to commit to 4.7 after it opens?
>
> Have you done any compat testing against compiler without that change
> (using ALT_CC_UNDER_TEST=/whatever/gcc ALT_CXX_UNDER_TEST=/whatever/g++ )?
> Just to double check it doesn't introduce ABI compatibility issues?
No, but will do so before commit.
Thanks,
Uros.
libgo patch committed: Update to weekly.2012-02-14 release
I have committed a patch to libgo to update to the weekly.2012-02-14
release. As usual, in this e-mail message I only include the patches to
files specific to the gccgo version of libgo. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 86886691a02c go/unsafe.cc
--- a/go/unsafe.cc Thu Mar 01 10:18:09 2012 -0800
+++ b/go/unsafe.cc Thu Mar 01 22:36:35 2012 -0800
@@ -88,60 +88,6 @@
if (add_to_globals)
this->add_named_object(no);
- // Typeof.
- Type* empty_interface = Type::make_empty_interface_type(bloc);
- Typed_identifier_list* parameters = new Typed_identifier_list;
- parameters->push_back(Typed_identifier("i", empty_interface, bloc));
- results = new Typed_identifier_list;
- results->push_back(Typed_identifier("", empty_interface, bloc));
- fntype = Type::make_function_type(NULL, parameters, results, bloc);
- no = bindings->add_function_declaration("Typeof", package, fntype, bloc);
- if (add_to_globals)
-this->add_named_object(no);
-
- // Reflect.
- parameters = new Typed_identifier_list;
- parameters->push_back(Typed_identifier("it", empty_interface, bloc));
- results = new Typed_identifier_list;
- results->push_back(Typed_identifier("", empty_interface, bloc));
- results->push_back(Typed_identifier("", pointer_type, bloc));
- fntype = Type::make_function_type(NULL, parameters, results, bloc);
- no = bindings->add_function_declaration("Reflect", package, fntype, bloc);
- if (add_to_globals)
-this->add_named_object(no);
-
- // Unreflect.
- parameters = new Typed_identifier_list;
- parameters->push_back(Typed_identifier("typ", empty_interface, bloc));
- parameters->push_back(Typed_identifier("addr", pointer_type, bloc));
- results = new Typed_identifier_list;
- results->push_back(Typed_identifier("", empty_interface, bloc));
- fntype = Type::make_function_type(NULL, parameters, results, bloc);
- no = bindings->add_function_declaration("Unreflect", package, fntype, bloc);
- if (add_to_globals)
-this->add_named_object(no);
-
- // New.
- parameters = new Typed_identifier_list;
- parameters->push_back(Typed_identifier("typ", empty_interface, bloc));
- results = new Typed_identifier_list;
- results->push_back(Typed_identifier("", pointer_type, bloc));
- fntype = Type::make_function_type(NULL, parameters, results, bloc);
- no = bindings->add_function_declaration("New", package, fntype, bloc);
- if (add_to_globals)
-this->add_named_object(no);
-
- // NewArray.
- parameters = new Typed_identifier_list;
- parameters->push_back(Typed_identifier("typ", empty_interface, bloc));
- parameters->push_back(Typed_identifier("n", int_type, bloc));
- results = new Typed_identifier_list;
- results->push_back(Typed_identifier("", pointer_type, bloc));
- fntype = Type::make_function_type(NULL, parameters, results, bloc);
- no = bindings->add_function_declaration("NewArray", package, fntype, bloc);
- if (add_to_globals)
-this->add_named_object(no);
-
if (!this->imported_unsafe_)
{
go_imported_unsafe();
diff -r 86886691a02c libgo/MERGE
--- a/libgo/MERGE Thu Mar 01 10:18:09 2012 -0800
+++ b/libgo/MERGE Thu Mar 01 22:36:35 2012 -0800
@@ -1,4 +1,4 @@
-52ba9506bd99
+43cf9b39b647
The first line of this file holds the Mercurial revision number of the
last merge done from the master library sources.
diff -r 86886691a02c libgo/Makefile.am
--- a/libgo/Makefile.am Thu Mar 01 10:18:09 2012 -0800
+++ b/libgo/Makefile.am Thu Mar 01 22:36:35 2012 -0800
@@ -225,7 +225,6 @@
$(exp_inotify_gox) \
exp/norm.gox \
exp/proxy.gox \
- exp/signal.gox \
exp/terminal.gox \
exp/types.gox \
exp/utf8string.gox
@@ -325,6 +324,7 @@
toolexeclibgoos_DATA = \
os/exec.gox \
+ os/signal.gox \
os/user.gox
toolexeclibgopathdir = $(toolexeclibgodir)/path
@@ -352,8 +352,7 @@
toolexeclibgotesting_DATA = \
testing/iotest.gox \
- testing/quick.gox \
- testing/script.gox
+ testing/quick.gox
toolexeclibgotextdir = $(toolexeclibgodir)/text
@@ -398,6 +397,7 @@
runtime/go-byte-array-to-string.c \
runtime/go-breakpoint.c \
runtime/go-caller.c \
+ runtime/go-callers.c \
runtime/go-can-convert-interface.c \
runtime/go-cgo.c \
runtime/go-check-interface.c \
@@ -428,7 +428,6 @@
runtime/go-panic.c \
runtime/go-print.c \
runtime/go-recover.c \
- runtime/go-reflect.c \
runtime/go-reflect-call.c \
runtime/go-reflect-map.c \
runtime/go-rune.c \
@@ -450,7 +449,6 @@
runtime/go-type-string.c \
runtime/go-typedesc-equal.c \
runtime/go-typestring.c \
- runtime/go-unreflect.c \
runtime/go-unsafe-new.c \
runtime/go-unsafe-newarray.c \
runtime/go-unsafe-pointer.c \
@@ -468,6 +466,7 @@
runtime/msize.c \
runtime/proc.c \
runtime/runtime.c \
+ runtime/signal_unix.c \
runtime/thread.c \
runtime/yield.c \
$(rtems_task_variable_add_file) \
@@ -509,7 +508,7 @@
mv -f $@.tmp $@
sigqueue.c: $(srcdir)/runtime/sigqueue.goc goc2c
- ./goc2c --gcc --go-prefix libgo_runtime $< > $@.tmp
Re: [PATCH, i386]: Fix PR 46716, [4.4/4.5/4.6/4.7/4.8 Regression] wrong code generated with -mno-sse2 -m64
On Fri, Mar 02, 2012 at 05:32:18PM +0100, Uros Bizjak wrote:
> Patch was tested on x86_64-pc-linux-gnu {,-m32}. Patch was committed
> to mainline, is it OK to commit to 4.7 after it opens?
Have you done any compat testing against compiler without that change
(using ALT_CC_UNDER_TEST=/whatever/gcc ALT_CXX_UNDER_TEST=/whatever/g++ )?
Just to double check it doesn't introduce ABI compatibility issues?
Jakub
[PATCH, i386]: Fix PR 46716, [4.4/4.5/4.6/4.7/4.8 Regression] wrong code generated with -mno-sse2 -m64
Hello!
i386 maintains stable ABI by passing "unsupported" SSE modes in hard
SSE registers, even if original mode does not fit there. This works
quite well for 32bit targets (-msse2 vs -msse), but 64bit targets
assume SSE2 by default, so various paths aren't well tested for
-mno-sse2.
Attached patch fixes one particular problem with -mno-sse2 on 64bit
targets. If the "natural" mode doesn't agree with the mode, choosen by
compiler type system, then compiler decomposes "natural" mode in some
supported mode, breaking various assumptions on how arguments in
"natural" mode are passed around. The patch adopts the same approach
as 32bit targets - it wraps argument in a parallel RTX in a couple of
missed places, tricking the compiler to pass the argument in "natural"
mode. (Please see the comment before gen_reg_or_parallel for further
details).
2012-03-02 Uros Bizjak
PR target/46716
* config/i386/i386.c (construct_container): Use gen_reg_or_parallel
to pass the argument in the register of "natural" mode.
testsuite/ChangeLog:
2012-03-02 Uros Bizjak
PR target/46716
* gcc.target/i386/pr46176.c: New test.
Patch was tested on x86_64-pc-linux-gnu {,-m32}. Patch was committed
to mainline, is it OK to commit to 4.7 after it opens?
I will backport the patch to other release branches in a couple of days.
Uros.
Index: ChangeLog
===
--- ChangeLog (revision 184786)
+++ ChangeLog (working copy)
@@ -231,8 +231,7 @@
(neon_vcgeu): New insn.
(neon_vcgtu): Likewise.
* config/arm/neon.ml (s_8_32, u_8_32): New lists.
- (ops): Unsigned comparison intrinsics call a different
- builtin.
+ (ops): Unsigned comparison intrinsics call a different builtin.
2012-02-28 Richard Guenther
@@ -261,7 +260,7 @@
* config/avr/avr-devices.c (avr_mcu_type): Adjust NULL part
of initializer to changes from r184614.
-
+
2012-02-28 Richard Guenther
PR tree-optimization/52395
@@ -330,8 +329,7 @@
2012-02-27 H.J. Lu
PR target/52352
- * config/i386/i386.md (*movabs_1): Enable only for
- TARGET_LP64.
+ * config/i386/i386.md (*movabs_1): Enable only for TARGET_LP64.
(*movabs_2): Likewise.
2012-02-27 Jakub Jelinek
Index: testsuite/gcc.target/i386/pr46716.c
===
--- testsuite/gcc.target/i386/pr46716.c (revision 0)
+++ testsuite/gcc.target/i386/pr46716.c (revision 0)
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -msse -mno-sse2" } */
+/* { dg-require-effective-target sse } */
+
+#include "sse-check.h"
+
+typedef double V __attribute__ ((__vector_size__ (16), __may_alias__));
+typedef union
+{
+ V x;
+ double a[2];
+} u;
+
+#define EMM_FLT8(a) ((double *)&(a))
+
+void __attribute__ ((noinline))
+test (V s1, V s2)
+{
+ if (EMM_FLT8(s1)[0] != EMM_FLT8(s2)[0]
+ || EMM_FLT8(s1)[1] != EMM_FLT8(s2)[1])
+abort ();
+}
+
+static void
+sse_test (void)
+{
+ u s1;
+
+ s1.a[0] = 1.0;
+ s1.a[1] = 2.0;
+
+ test (s1.x, s1.x);
+}
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 184786)
+++ testsuite/ChangeLog (working copy)
@@ -115,18 +115,15 @@
2012-02-28 Kai Tietz
- * gcc.target/i386/pr46939.c (long): Fix LP64 vs LLP64
- issue.
+ * gcc.target/i386/pr46939.c (long): Fix LP64 vs LLP64 issue.
* gcc.target/i386/pr45352-2.c: Likewise.
- * gcc.target/i386/bitfield3.c: Add -mno-ms-bitfields for
- mingw targets.
- * gcc.target/i386/xop-vshift-1.c(random): Use on mingw
+ * gcc.target/i386/bitfield3.c: Add -mno-ms-bitfields for mingw targets.
+ * gcc.target/i386/xop-vshift-1.c (random): Use on mingw
targets instead rand.
* gcc.target/i386/sse4_1-blendps-2.c: Likewise.
* gcc.target/i386/sse2-mul-1.c: Likewise.
* gcc.target/i386/sse4_1-blendps.c: Likewise.
- * gcc.target/i386/pad-6b.c: Adjust test for x64 mingw
- target.
+ * gcc.target/i386/pad-6b.c: Adjust test for x64 mingw target.
* gcc.target/i386/pad-1.c: Likewise.
* gcc.target/i386/pad-9.c: Likewise.
* gcc.target/i386/pad-2.c: Likewise.
@@ -212,8 +209,7 @@
2012-02-23 Kai Tietz
- * gcc.dg/pack-test-5.c: Add -mno-ms-bitfields option
- for mingw-targets.
+ * gcc.dg/pack-test-5.c: Add -mno-ms-bitfields option for mingw-targets.
* gcc.dg/Wpadded.c: Likewise.
* gcc.dg/bf-ms-layout-2.c: Adjust offsets to fit ms-bitfield
structure-layout.
@@ -223,8 +219,7 @@
targets.
* gcc.dg/stack-usage-1.c (SIZE): Provide proper SIZE for x64 mingw
target.
- * gcc.dg/tls/thr-cse-1.c: Provide proper pattern for x64 mingw
- target.
+ * gcc.dg/tls/thr-cse-1.c: Provide proper pattern for x64 mingw target.
* g
Re: [RFC, patch] powerpc64 FreeBSD support
On Fri, Mar 2, 2012 at 11:04 AM, Andreas Tobler wrote: >> the attached patch adds support for powerpc64-*-freebsd*. >> Results are/were sent to the test results list. >> >> A few words about the patch. >> I have chosen the way to add separate freebsd* files because FreeBSD >> supports not as much as linux does in regard of the PowerPC CPU's. For >> example we only have FreeBSD running on 970 CPU's. POWER support on the >> kernel side is wip, but it grows very slow. >> >> Also, powerpc FreeBSD has 64-bit long doubles while linux-ppc has 128-bit. >> >> The architecture itself is a 64-bit one which can execute 32-bit >> binaries. But it its primary bit width is 64-bit. It is not wanted that >> we have a 32-bit compiler which can build 64-bit objects. >> >> To have a clearer picture and not to influence linux-ppc I thought >> having its own set of files would be easier. >> >> I'd appreciate feedback on the patch. >> >> There are some issues with the tests, I'm cleaning and trying to make >> them work. In certain areas I need to fix the kernel or the libc first >> and this takes some time. >> >> One thing is the libstdc++ test I had to skip. Here the test tries to >> allocate int_max mem. And this blows my machine :) >> >> Here the CL's. >> >> Thank you! >> Andreas >> >> gcc: >> >> >> 2011-12-22 Andreas Tobler >> >> * configure.ac (HAVE_LD_NO_DOT_SYMBOLS): Add powerpc64-*-freebsd*. >> Introduce emul_name to select the right linker emulation for >> powerpc64-*-freebsd*. >> * configure: Regenerate. >> * config.gcc: Add bits to support powerpc64-*-freebsd*. >> * config/rs6000/freebsd.h (POWERPC_FREEBSD): Define. >> * config/rs6000/freebsd64.h: New file. >> * config/rs6000/rs6000.c (rs6000_option_override_internal): Use >> POWERPC_FREEBSD. >> (rs6000_savres_strategy): Likewise. >> (rs6000_savres_routine_name): Likewise. >> (rs6000_elf_file_end): Likewise. >> * config/rs6000/t-freebsd64: New file. >> * config/rs6000/sysv4.h (SUBTARGET_OVERRIDE_OPTIONS): Set the >> rs6000_current_abi for 64-bit FreeBSD to ABI_AIX. >> >> libgcc: >> --- >> >> 2011-12-22 Andreas Tobler >> >> * config.host: Add bits to support powerpc64-*-freebsd*. >> * config/rs6000/freebsd-unwind.h: New file. >> * config/rs6000/t-freebsd64: New file. >> >> libstdc++: >> -- >> 2011-12-22 Andreas Tobler >> >> * testsuite/23_containers/vector/bool/modifiers/insert/31370.cc: >> Skip >> this test on powerpc64-*-freebsd*. This patch is okay for trunk now that it has opened for 4.8 release. I thought that Loren might comment. Thanks, David
Re: [PATCH, rs6000][trunk,4.7,4.6,4.5] Fix PR52457, wrong code for -O1 -m32 -mcpu=power7
On Fri, Mar 2, 2012 at 10:57 AM, Peter Bergner wrote: > The patch below fixes a typo in the vsx_set_ pattern that causes > wrong code to be generated when using -mcpu=power7. This passed bootstrap > and regression testing on trunk using powerpc64-linux. Ok for trunk? > > This is also broken on the 4.7, 4.6 and 4.5 branches, is this ok for > those release branches once the branches are open for fixes and my > bootstrapping/regtesting are complete? > > Peter > > * gcc/config/rs6000/vsx.md (vsx_set_): Reorder operands. > * gcc/testsuite/gcc.target/powerpc/pr52457.c: New test. Okay everywhere, but please make sure that Richi and Jakub are okay with the patch for GCC 4.7. Thanks, David
Re: [RFC, patch] powerpc64 FreeBSD support
Ping! Any comments on the patch? Thanks, Andreas On 22.12.11 21:44, Andreas Tobler wrote: Hi all, the attached patch adds support for powerpc64-*-freebsd*. Results are/were sent to the test results list. A few words about the patch. I have chosen the way to add separate freebsd* files because FreeBSD supports not as much as linux does in regard of the PowerPC CPU's. For example we only have FreeBSD running on 970 CPU's. POWER support on the kernel side is wip, but it grows very slow. Also, powerpc FreeBSD has 64-bit long doubles while linux-ppc has 128-bit. The architecture itself is a 64-bit one which can execute 32-bit binaries. But it its primary bit width is 64-bit. It is not wanted that we have a 32-bit compiler which can build 64-bit objects. To have a clearer picture and not to influence linux-ppc I thought having its own set of files would be easier. I'd appreciate feedback on the patch. There are some issues with the tests, I'm cleaning and trying to make them work. In certain areas I need to fix the kernel or the libc first and this takes some time. One thing is the libstdc++ test I had to skip. Here the test tries to allocate int_max mem. And this blows my machine :) Here the CL's. Thank you! Andreas gcc: 2011-12-22 Andreas Tobler * configure.ac (HAVE_LD_NO_DOT_SYMBOLS): Add powerpc64-*-freebsd*. Introduce emul_name to select the right linker emulation for powerpc64-*-freebsd*. * configure: Regenerate. * config.gcc: Add bits to support powerpc64-*-freebsd*. * config/rs6000/freebsd.h (POWERPC_FREEBSD): Define. * config/rs6000/freebsd64.h: New file. * config/rs6000/rs6000.c (rs6000_option_override_internal): Use POWERPC_FREEBSD. (rs6000_savres_strategy): Likewise. (rs6000_savres_routine_name): Likewise. (rs6000_elf_file_end): Likewise. * config/rs6000/t-freebsd64: New file. * config/rs6000/sysv4.h (SUBTARGET_OVERRIDE_OPTIONS): Set the rs6000_current_abi for 64-bit FreeBSD to ABI_AIX. libgcc: --- 2011-12-22 Andreas Tobler * config.host: Add bits to support powerpc64-*-freebsd*. * config/rs6000/freebsd-unwind.h: New file. * config/rs6000/t-freebsd64: New file. libstdc++: -- 2011-12-22 Andreas Tobler * testsuite/23_containers/vector/bool/modifiers/insert/31370.cc: Skip this test on powerpc64-*-freebsd*.
[PATCH, rs6000][trunk,4.7,4.6,4.5] Fix PR52457, wrong code for -O1 -m32 -mcpu=power7
The patch below fixes a typo in the vsx_set_ pattern that causes
wrong code to be generated when using -mcpu=power7. This passed bootstrap
and regression testing on trunk using powerpc64-linux. Ok for trunk?
This is also broken on the 4.7, 4.6 and 4.5 branches, is this ok for
those release branches once the branches are open for fixes and my
bootstrapping/regtesting are complete?
Peter
* gcc/config/rs6000/vsx.md (vsx_set_): Reorder operands.
* gcc/testsuite/gcc.target/powerpc/pr52457.c: New test.
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 184791)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -1119,9 +1119,9 @@ (define_insn "vsx_set_"
"VECTOR_MEM_VSX_P (mode)"
{
if (INTVAL (operands[3]) == 0)
-return \"xxpermdi %x0,%x1,%x2,1\";
+return \"xxpermdi %x0,%x2,%x1,1\";
else if (INTVAL (operands[3]) == 1)
-return \"xxpermdi %x0,%x2,%x1,0\";
+return \"xxpermdi %x0,%x1,%x2,0\";
else
gcc_unreachable ();
}
Index: gcc/testsuite/gcc.target/powerpc/pr52457.c
===
--- gcc/testsuite/gcc.target/powerpc/pr52457.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr52457.c (revision 0)
@@ -0,0 +1,34 @@
+/* { dg-do run { target { powerpc*-*-linux* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-skip-if "" { powerpc*-*-*spe* } { "*" } { "" } } */
+/* { dg-require-effective-target vsx_hw } */
+/* { dg-options "-O1 -mcpu=power7" } */
+
+extern void abort (void);
+
+typedef long long T;
+typedef T vl_t __attribute__((vector_size(2 * sizeof (T;
+
+vl_t
+buggy_func (T x)
+{
+ vl_t w;
+ T *p = (T *)&w;
+ p[0] = p[1] = x;
+ return w;
+}
+
+int
+main(void)
+{
+ vl_t rval;
+ T *pl;
+
+ pl = (T *) &rval;
+ rval = buggy_func (2);
+
+ if (pl[0] != 2 || pl[1] != 2)
+abort ();
+
+ return 0;
+}
Re: ifcvt cond_exec support rewrite
Ping^3. Better support for nested if-then-else structures: > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01935.html Bernd
Re: [PATCH] Fix PR52406
On Thu, 1 Mar 2012, Richard Guenther wrote:
> On Wed, 29 Feb 2012, Richard Guenther wrote:
>
> > On Wed, 29 Feb 2012, Michael Matz wrote:
> >
> > > Hi,
> > >
> > > On Wed, 29 Feb 2012, Richard Guenther wrote:
> > >
> > > > the whole base object - instead I mark the base MEM_REF of such
> > > > accesses
> > > > with TREE_NO_WARNING (ugh) and special-case for them in dr_may_alias_p.
> > > >
> > >
> > > At least use a flag that isn't currently used for MEM_REF. E.g.
> > > addressable_flag, and make a new macro that checks for the tree being a
> > > MEMREF to access it.
> >
> > Ok, I'll use TREE_VISITED. The alternative is to increase the size of
> > struct indices (and thus all data-refs) and have a separate flag.
>
> As follows (also removes an unused entry in all data-refs and updates
> the docs).
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1 /
> 4.7.1.
And after more complaints I have just added a new flag to the dataref
instead.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-03-02 Richard Guenther
PR tree-optimization/52406
* tree-data-ref.h: Update documentation about DR_BASE_OBJECT.
(struct indices): Add unconstrained_base member.
(struct dr_alias): Remove unused vops member.
(DR_UNCONSTRAINED_BASE): New define.
* tree-data-ref.c (dr_analyze_indices): For COMPONENT_REFs
add indices to allow their disambiguation. Make DR_BASE_OBJECT
be an artificial access that covers the whole indexed object,
or mark it with DR_UNCONSTRAINED_BASE if we cannot do so. Canonicalize
plain decl base-objects to their MEM_REF variant.
(dr_may_alias_p): When the base-object of either data reference
has unknown size use only points-to information.
(compute_affine_dependence): Make dumps easier to read and
more verbose.
* tree-vect-data-ref.c (vector_alignment_reachable_p): Use
DR_REF when looking for packed references.
(vect_supportable_dr_alignment): Likewise.
* gcc.dg/torture/pr52406.c: New testcase.
Index: gcc/tree-data-ref.h
===
*** gcc/tree-data-ref.h (revision 184782)
--- gcc/tree-data-ref.h (working copy)
*** struct innermost_loop_behavior
*** 60,75
};
/* Describes the evolutions of indices of the memory reference. The indices
!are indices of the ARRAY_REFs and the operands of INDIRECT_REFs.
!For ARRAY_REFs, BASE_OBJECT is the reference with zeroed indices
!(note that this reference does not have to be valid, if zero does not
!belong to the range of the array; hence it is not recommended to use
!BASE_OBJECT in any code generation). For INDIRECT_REFs, the address is
!set to the loop-invariant part of the address of the object, except for
!the constant offset. For the examples above,
!base_object:a[0].b[0][0] *(p + x + 4B * j_0)
indices:{j_0, +, 1}_2 {16, +, 4}_2
{i_0, +, 1}_1
{j_0, +, 1}_2
*/
--- 60,76
};
/* Describes the evolutions of indices of the memory reference. The indices
!are indices of the ARRAY_REFs, indexes in artificial dimensions
!added for member selection of records and the operands of MEM_REFs.
!BASE_OBJECT is the part of the reference that is loop-invariant
!(note that this reference does not have to cover the whole object
!being accessed, in which case UNCONSTRAINED_BASE is set; hence it is
!not recommended to use BASE_OBJECT in any code generation).
!For the examples above,
!base_object:a *(p + x + 4B * j_0)
indices:{j_0, +, 1}_2 {16, +, 4}_2
+ 4
{i_0, +, 1}_1
{j_0, +, 1}_2
*/
*** struct indices
*** 81,98
/* A list of chrecs. Access functions of the indices. */
VEC(tree,heap) *access_fns;
};
struct dr_alias
{
/* The alias information that should be used for new pointers to this
! location. SYMBOL_TAG is either a DECL or a SYMBOL_MEMORY_TAG. */
struct ptr_info_def *ptr_info;
-
- /* The set of virtual operands corresponding to this memory reference,
- serving as a description of the alias information for the memory
- reference. This could be eliminated if we had alias oracle. */
- bitmap vops;
};
/* An integer vector. A vector formally consists of an element of a vector
--- 82,98
/* A list of chrecs. Access functions of the indices. */
VEC(tree,heap) *access_fns;
+
+ /* Whether BASE_OBJECT is an access representing the whole object
+ or whether the access could not be constrained. */
+ bool unconstrained_base;
};
struct dr_alias
{
/* T
Re: [wwwdocs] releasing.html: Git - mirror new branch
On Fri, Mar 2, 2012 at 3:10 PM, Tobias Burnus wrote: > On 03/02/2012 03:02 PM, Jakub Jelinek wrote: >> >> releasing.html is wrong for this, it has nothing to do with releasing, but >> with branching, so something like that should go into branching.html >> instead. From this isn't clear where this command needs to be run, btw, on >> gcc.gnu.org directly, somewhere else? > > > Thanks for the comments - I unfortunately saw them only just after Richard's > OK. How about the following? Better. Ok, thanks, Richard. > Tobias
Re: [PATCH, PR16464] testsuite: account for fortran loop-constructs
On Fri, Mar 2, 2012 at 3:25 PM, Bernhard Reutner-Fischer wrote: > On Mar 2, 2012 3:09 PM, "Richard Guenther" > wrote: >> >> On Fri, Mar 2, 2012 at 3:05 PM, Jakub Jelinek wrote: >> > On Fri, Mar 02, 2012 at 03:01:31PM +0100, Bernhard Reutner-Fischer >> > wrote: >> >> PR testsuite/16464 notes that some g77/*.f that contain loops were not >> >> compiled with loop flags. >> >> Compiling only testcases with loop optimization that contain >> >> "endfor/enddo" will lead to ~25% fewer tests (some 3 instead of >> >> previously 4). >> >> >> >> Testing in progess, ok if this completes successfully? >> > >> > There are tons of other loop constructs in Fortran, so I don't think >> > this is >> > a good idea. >> >> Indeed. The focus on -O2 testing seems odd to me though, as well as >> doing -g only at -O3. But well ... > > OK, so what should we do about the PR? > Should we just close it, compile the 2 tests mentioned with loop unrolling > or perhaps use just -O for "dg-do preprocess" instead of "compile" so we > compile more testcases with the full option_list? We can't possibly accomodate all (or even all sensible) compiler options for testcases. So I'd close the bug as wontfix. Btw, -funroll-loops is not exactly triggering very many loop optimizations. Richard. >> Richard.
Re: [wwwdocs] releasing.html: Git - mirror new branch
On 03/02/2012 03:02 PM, Jakub Jelinek wrote: releasing.html is wrong for this, it has nothing to do with releasing, but with branching, so something like that should go into branching.html instead. From this isn't clear where this command needs to be run, btw, on gcc.gnu.org directly, somewhere else? Thanks for the comments - I unfortunately saw them only just after Richard's OK. How about the following? Tobias Index: releasing.html === RCS file: /cvs/gcc/wwwdocs/htdocs/releasing.html,v retrieving revision 1.37 diff -u -r1.37 releasing.html --- releasing.html 2 Mar 2012 14:04:38 - 1.37 +++ releasing.html 2 Mar 2012 14:08:28 - @@ -55,12 +55,6 @@ Reenable the generation of snapshots off the respective release branch in the crontab of gccadmin on gcc.gnu.org. - -For a new major release, add the release to GIT mirror; example: - -$ cd /git/gcc.git/.git -$ git symbolic-ref refs/heads/gcc-4_7-branch refs/remotes/gcc-4_7-branch - Web Site Updates Index: branching.html === RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v retrieving revision 1.30 diff -u -r1.30 branching.html --- branching.html 20 Nov 2010 15:15:51 - 1.30 +++ branching.html 2 Mar 2012 14:08:28 - @@ -23,6 +23,17 @@ Update the file gcc/BASE-VER on the mainline, to use the next major release number (e.g., 3.2 instead of 3.1). +Update the GIT mirror by running on gcc.gnu.org the +following command, substituting appropriate version +numbers: + + +$ cd /git/gcc.git/.git +$ git symbolic-ref refs/heads/gcc-4_7-branch refs/remotes/gcc-4_7-branch + + + + Create a new htdocs/gcc-VERSION directory for the next major release in the wwwdocs repository and populate it with initial copies of changes.html and
Re: [wwwdocs] releasing.html: Git - mirror new branch
On Fri, Mar 2, 2012 at 3:02 PM, Jakub Jelinek wrote: > On Fri, Mar 02, 2012 at 03:00:12PM +0100, Tobias Burnus wrote: >> As mentioned on #gcc, the git mirror should also include new major releases. >> >> Diego also documented it on the wiki: >> http://gcc.gnu.org/wiki/GitMirror#Adding_a_branch_to_origin.2BAC8.2A >> (Wiki page rev. 94 -> 96) >> >> OK for committal? > > releasing.html is wrong for this, it has nothing to do with releasing, > but with branching, so something like that should go into branching.html > instead. From this isn't clear where this command needs to be run, btw, > on gcc.gnu.org directly, somewhere else? Oops, yes. Indeed it belongs in branching.html. >> Index: releasing.html >> === >> RCS file: /cvs/gcc/wwwdocs/htdocs/releasing.html,v >> retrieving revision 1.36 >> diff -u -r1.36 releasing.html >> --- releasing.html 1 Mar 2012 13:16:51 - 1.36 >> +++ releasing.html 2 Mar 2012 13:55:52 - >> @@ -55,6 +55,12 @@ >> >> Reenable the generation of snapshots off the respective release >> branch in the crontab of gccadmin on gcc.gnu.org. >> + >> +For a new major release, add the release to GIT mirror; example: >> + >> +$ cd /git/gcc.git/.git >> +$ git symbolic-ref refs/heads/gcc-4_7-branch refs/remotes/gcc-4_7-branch >> + >> >> >> Web Site Updates > > > Jakub
Re: [PATCH, PR16464] testsuite: account for fortran loop-constructs
On Fri, Mar 2, 2012 at 3:05 PM, Jakub Jelinek wrote: > On Fri, Mar 02, 2012 at 03:01:31PM +0100, Bernhard Reutner-Fischer wrote: >> PR testsuite/16464 notes that some g77/*.f that contain loops were not >> compiled with loop flags. >> Compiling only testcases with loop optimization that contain >> "endfor/enddo" will lead to ~25% fewer tests (some 3 instead of >> previously 4). >> >> Testing in progess, ok if this completes successfully? > > There are tons of other loop constructs in Fortran, so I don't think this is > a good idea. Indeed. The focus on -O2 testing seems odd to me though, as well as doing -g only at -O3. But well ... Richard.
Re: [PATCH, PR16464] testsuite: account for fortran loop-constructs
On Fri, Mar 02, 2012 at 03:01:31PM +0100, Bernhard Reutner-Fischer wrote: > PR testsuite/16464 notes that some g77/*.f that contain loops were not > compiled with loop flags. > Compiling only testcases with loop optimization that contain > "endfor/enddo" will lead to ~25% fewer tests (some 3 instead of > previously 4). > > Testing in progess, ok if this completes successfully? There are tons of other loop constructs in Fortran, so I don't think this is a good idea. > 2012-03-02 Bernhard Reutner-Fischer > > PR testsuite/16464 > * lib/gfortran-dg.exp (gfortran-dg-runtest): Depend options > on weather the testcase is just preprocessed/compiled or > contains loop statements. Jakub
Re: [wwwdocs] releasing.html: Git - mirror new branch
On Fri, Mar 2, 2012 at 3:00 PM, Tobias Burnus wrote: > As mentioned on #gcc, the git mirror should also include new major releases. > > Diego also documented it on the wiki: > http://gcc.gnu.org/wiki/GitMirror#Adding_a_branch_to_origin.2BAC8.2A (Wiki > page rev. 94 -> 96) > > OK for committal? Ok. Richard. > Tobias
Re: [wwwdocs] releasing.html: Git - mirror new branch
On Fri, Mar 02, 2012 at 03:00:12PM +0100, Tobias Burnus wrote: > As mentioned on #gcc, the git mirror should also include new major releases. > > Diego also documented it on the wiki: > http://gcc.gnu.org/wiki/GitMirror#Adding_a_branch_to_origin.2BAC8.2A > (Wiki page rev. 94 -> 96) > > OK for committal? releasing.html is wrong for this, it has nothing to do with releasing, but with branching, so something like that should go into branching.html instead. From this isn't clear where this command needs to be run, btw, on gcc.gnu.org directly, somewhere else? > Index: releasing.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/releasing.html,v > retrieving revision 1.36 > diff -u -r1.36 releasing.html > --- releasing.html1 Mar 2012 13:16:51 - 1.36 > +++ releasing.html2 Mar 2012 13:55:52 - > @@ -55,6 +55,12 @@ > > Reenable the generation of snapshots off the respective release > branch in the crontab of gccadmin on gcc.gnu.org. > + > +For a new major release, add the release to GIT mirror; example: > + > +$ cd /git/gcc.git/.git > +$ git symbolic-ref refs/heads/gcc-4_7-branch refs/remotes/gcc-4_7-branch > + > > > Web Site Updates Jakub
[PATCH, PR16464] testsuite: account for fortran loop-constructs
Hi,
PR testsuite/16464 notes that some g77/*.f that contain loops were not
compiled with loop flags.
Compiling only testcases with loop optimization that contain
"endfor/enddo" will lead to ~25% fewer tests (some 3 instead of
previously 4).
Testing in progess, ok if this completes successfully?
gcc/testsuite/ChangeLog:
2012-03-02 Bernhard Reutner-Fischer
PR testsuite/16464
* lib/gfortran-dg.exp (gfortran-dg-runtest): Depend options
on weather the testcase is just preprocessed/compiled or
contains loop statements.
Signed-off-by: Bernhard Reutner-Fischer
---
gcc/testsuite/lib/gfortran-dg.exp | 28 +---
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/gcc/testsuite/lib/gfortran-dg.exp
b/gcc/testsuite/lib/gfortran-dg.exp
index 50753df..56ecc69 100644
--- a/gcc/testsuite/lib/gfortran-dg.exp
+++ b/gcc/testsuite/lib/gfortran-dg.exp
@@ -90,7 +90,7 @@ proc gfortran-dg-prune { system text } {
# as c-torture does.
proc gfortran-dg-runtest { testcases default-extra-flags } {
global runtests
-global DG_TORTURE_OPTIONS torture_with_loops
+global DG_TORTURE_OPTIONS torture_with_loops torture_without_loops
torture-init
set-torture-options $DG_TORTURE_OPTIONS
@@ -102,12 +102,26 @@ proc gfortran-dg-runtest { testcases default-extra-flags
} {
continue
}
- # look if this is dg-do-run test, in which case
- # we cycle through the option list, otherwise we don't
- if [expr [search_for $test "dg-do run"]] {
- set option_list $torture_with_loops
- } else {
- set option_list [list { -O } ]
+ # look if this is a dg-do-preprocess or dg-to-compile test,
+ # in which case we do not need to cycle through all options.
+ set option_list $torture_without_loops
+ set tmp [grep $test "(dg-do\[ \t\]+(preprocess|compile)|^(?:\[^!\]*\[
\t\]*)\[eE\]\[nN\]\[dD\]\[ \t\]*(\[fF\]\[oO\]\[rR\]|\[dD\]\[oO\]))" line]
+ foreach i $tmp {
+ regexp "(\[0-9\]+)\[ \t\]+(?:dg-do\[ \t\]+)(preprocess|compile)" $i
i lineno what
+ if {[info exists what]} {
+ set option_list [list { -O } ]
+ verbose "Line $lineno: dg-do $what, trimming option_list" 3
+ break
+ } else {
+ regexp "(\[0-9\]+)(?:.*)(\[eE\]\[nN\]\[dD\]\[
\t\]*(\[fF\]\[oO\]\[rR\]|\[dD\]\[oO\]))" $i i lineno loop
+ if {[info exists loop]} {
+ set option_list $torture_with_loops
+ verbose "Line $lineno: extending option_list: loop
detected: `$loop'" 3
+ break
+ # } else {
+ #set option_list $torture_without_loops
+ }
+ }
}
set nshort [file tail [file dirname $test]]/[file tail $test]
--
1.7.9
[wwwdocs] releasing.html: Git - mirror new branch
As mentioned on #gcc, the git mirror should also include new major releases. Diego also documented it on the wiki: http://gcc.gnu.org/wiki/GitMirror#Adding_a_branch_to_origin.2BAC8.2A (Wiki page rev. 94 -> 96) OK for committal? Tobias Index: releasing.html === RCS file: /cvs/gcc/wwwdocs/htdocs/releasing.html,v retrieving revision 1.36 diff -u -r1.36 releasing.html --- releasing.html 1 Mar 2012 13:16:51 - 1.36 +++ releasing.html 2 Mar 2012 13:55:52 - @@ -55,6 +55,12 @@ Reenable the generation of snapshots off the respective release branch in the crontab of gccadmin on gcc.gnu.org. + +For a new major release, add the release to GIT mirror; example: + +$ cd /git/gcc.git/.git +$ git symbolic-ref refs/heads/gcc-4_7-branch refs/remotes/gcc-4_7-branch + Web Site Updates
Re: Ping: [PATCH, 4.6] Backport fixes for PR50031, PR50969
On Thu, Feb 16, 2012 at 2:17 PM, William J. Schmidt
wrote:
> Greetings,
>
> Given the recent discussion on getting 4.6 cleaned up, I thought I'd
> check back on this one. Thanks!
Ok.
Thanks,
Richard.
> Bill
>
> On Fri, 2012-02-10 at 14:58 -0600, William J. Schmidt wrote:
>> This patch backports the two recent trunk fixes for powerpc64
>> vectorization degradations. The fixes are largely identical to their
>> 4.7 counterparts except that (a) the logic for
>> STMT_VINFO_PATTERN_DEF_SEQ does not apply in 4.6, and (b) the changes to
>> vectorizable_conversion in 4.7 correspond to changes in
>> vectorizable_type_demotion and vectorizable_type_promotion in 4.6.
>>
>> Bootstrapped and tested for regressions and performance for
>> powerpc64-linux. OK to commit after the trunk patch has a few days of
>> burn-in?
>>
>> Thanks,
>> Bill
>>
>>
>> 2012-02-10 Bill Schmidt
>> Ira Rosen
>>
>> PR tree-optimization/50031
>> PR tree-optimization/50969
>> * targhooks.c (default_builtin_vectorization_cost): Handle
>> vec_promote_demote.
>> * target.h (enum vect_cost_for_stmt): Add vec_promote_demote.
>> * tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Handle
>> all types of reduction and pattern statements.
>> (vect_estimate_min_profitable_iters): Likewise.
>> * tree-vect-stmts.c (vect_model_promotion_demotion_cost): New function.
>> (vect_model_store_cost): Use vec_perm rather than vector_stmt for
>> statement cost.
>> (vect_model_load_cost): Likewise.
>> (vect_get_load_cost): Likewise; add dump logic for explicit realigns.
>> (vectorizable_type_demotion): Call vect_model_promotion_demotion_cost.
>> (vectorizable_type_promotion): Likewise.
>> * config/spu/spu.c (spu_builtin_vectorization_cost): Handle
>> vec_promote_demote.
>> * config/i386/i386.c (ix86_builtin_vectorization_cost): Likewise.
>> * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Update
>> vec_perm for VSX and handle vec_promote_demote.
>>
>>
>> Index: gcc/targhooks.c
>> ===
>> --- gcc/targhooks.c (revision 184047)
>> +++ gcc/targhooks.c (working copy)
>> @@ -529,6 +529,7 @@ default_builtin_vectorization_cost (enum vect_cost
>> case scalar_to_vec:
>> case cond_branch_not_taken:
>> case vec_perm:
>> + case vec_promote_demote:
>> return 1;
>>
>> case unaligned_load:
>> Index: gcc/target.h
>> ===
>> --- gcc/target.h (revision 184047)
>> +++ gcc/target.h (working copy)
>> @@ -128,7 +128,8 @@ enum vect_cost_for_stmt
>> scalar_to_vec,
>> cond_branch_not_taken,
>> cond_branch_taken,
>> - vec_perm
>> + vec_perm,
>> + vec_promote_demote
>> };
>>
>> /* Sets of optimization levels at which an option may be enabled by
>> Index: gcc/tree-vect-loop.c
>> ===
>> --- gcc/tree-vect-loop.c (revision 184047)
>> +++ gcc/tree-vect-loop.c (working copy)
>> @@ -2104,7 +2104,8 @@ vect_get_single_scalar_iteraion_cost (loop_vec_inf
>> if (stmt_info
>> && !STMT_VINFO_RELEVANT_P (stmt_info)
>> && (!STMT_VINFO_LIVE_P (stmt_info)
>> - || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
>> + || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE
>> (stmt_info)))
>> + && !STMT_VINFO_IN_PATTERN_P (stmt_info))
>> continue;
>>
>> if (STMT_VINFO_DATA_REF (vinfo_for_stmt (stmt)))
>> @@ -2251,11 +2252,19 @@ vect_estimate_min_profitable_iters (loop_vec_info
>> {
>> gimple stmt = gsi_stmt (si);
>> stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
>> +
>> + if (STMT_VINFO_IN_PATTERN_P (stmt_info))
>> + {
>> + stmt = STMT_VINFO_RELATED_STMT (stmt_info);
>> + stmt_info = vinfo_for_stmt (stmt);
>> + }
>> +
>> /* Skip stmts that are not vectorized inside the loop. */
>> if (!STMT_VINFO_RELEVANT_P (stmt_info)
>> && (!STMT_VINFO_LIVE_P (stmt_info)
>> - || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
>> + || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE
>> (stmt_info
>> continue;
>> +
>> vec_inside_cost += STMT_VINFO_INSIDE_OF_LOOP_COST (stmt_info) *
>> factor;
>> /* FIXME: for stmts in the inner-loop in outer-loop vectorization,
>> some of the "outside" costs are generated inside the outer-loop.
>> */
>> Index: gcc/tree-vect-stmts.c
>> ===
>> --- gcc/tree-vect-stmts.c (revision 184047)
>> +++ gcc/tree-vect-stmts.c (working copy)
>> @@ -623,6 +623,46 @@ vect_model_simple_cost (stmt_vec_info stmt_info, i
>> }
>>
>>
>> +/* Model cost fo
Re: [google/4.6] Backport r184357 from trunk to fix validate_failures.py (issue5720047)
On 01/03/12 21:57 , Doug Kwan wrote: Hi Diego, This is a backport from trunk to fix a problem in validate_failures.py when testing a cross compiler. -Doug 2012-03-01 Doug Kwan Backport r184357 from trunk 2012-02-17 Doug Kwan * contrib/testsuite-management/validate_failures.py (GetMakefileValue): Check for cross compilers. OK, thanks. I'll ping you once the merge is committed. Diego.
[PATCH, wwwdocs] Detail more ARM-specific changes
This patch documents some more of the changes that have occurred on ARM this year. I've also re-worded a couple of the existing changes recorded there to try and improve the clarity to users. OK? Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.94 diff -u -p -r1.94 changes.html --- changes.html2 Mar 2012 09:53:07 - 1.94 +++ changes.html2 Mar 2012 12:16:39 - @@ -618,15 +618,32 @@ well. ARM -GCC now supports the Cortex-A7 processor implementing the - v7-a version of the architecture using the option +GCC now supports the Cortex-A7 processor, implementing the + ARMv7-A version of the architecture, using the option -mcpu=cortex-a7. -The default vector size in auto-vectorization for NEON is now 128 bits. - If vectorization fails thusly, the vectorizer tries again with - 64-bit vectors. + GCC now supports the Cortex-R5 processor, implementing the + ARMv7-R version of the architecture, using the option + -mcpu=cortex-r5. +GCC can now automatically detect the host + processor during native compilation. The options + -mcpu=, -mtune= and + -march= now all accept native in place of + the architecture or processor name. +The default vector size in auto-vectorization for NEON is now + 128 bits. If vectorization with 128-bit vectors fails, the vectorizer + will try again with 64-bit vectors. A new option -mvectorize-with-neon-double was added to - allow users to change the vector size to 64 bits. - + restrict auto-vectorization to using 64-bit vectors. +A number of improvements have been made around code generation for + the strided loads and stores for the Neon Advanced SIMD extension. + The auto-vectorizer and the backend now fully support the strided load + and store instructions (for example vld3 and vld4). +Code generation for the Cortex-A15 processor has been improved. + 64-bit sync primitives are now supported on ARM. + Note that code generated for cores implementing architectures prior + to ARMv7 will normally need support from kernel helper functions; + on Linux, kernel versions 3.1 and later provide the required + support. AVR
[4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113
TYPE(*) is Fortran's equivalent to C's "void *buffer". It may only be
used for dummy arguments and essentially might only either be passed on,
or appear in PRESENT, LBOUND/UBOUND/SHAPE/SIZE/IS_CONTIGUOUS - and most
useful: in C_LOC.
Note: For scalar TYPE(*) and for assumed-size dummies, only the address
is passed on. But for dimension(:) and TS29113's new (but unimplemented)
dimension(..) an array descriptor is passed. In that case, one might
recover the type from the array descriptor - at least for intrinsic types.
TYPE(*) is useful for, e.g., MPI (and used in the MPI v3 draft spec):
There, one simply takes an argument of any type and transfers some bytes
from it - without needing to know the type. TYPE(*) avoids to create
hundreds of useless explicit interfaces for all kind of data types (and
missing derived types that way) - or TS29113 avoids the alternative: Not
using explicit interfaces (causing argument checking issues and prevents
the use of BIND(C).)
See PR (or first test case) for a usage example. For a pure Fortran use,
one could imagine:
subroutine send(buf, size)
use iso_c_binding, only: c_signed_char, c_size_t
type(*) :: buf(*)
integer(c_size_t) :: size
integer(c_signed_char) :: ibuf(size)
call c_f_pointer (c_loc(buf), ibuf, shape=[size])
! ... use ibuf ...
end
[This example currently fails as "c_loc(buf)" is rejected. Several
BIND(C) restrictions were removed in F2008 and especially in TS29113,
but gfortran has not yet removed them.]
For more details, see:
* TS 29113 draft: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1904.pdf
(Status: Went as PDTR through one round of voting by the ISO members,
was updated at the last J3 meeting and is now the subject of a one-month
WG5 ballot that ends on 19 March 2012. The schedule is that it will then
be forwarded to SC22, which initiates a DTS ballot such that the final
version will be published in September by ISO.)
* MPIv3 draft (of 2011-12-15):
https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-report-F2008-2011-12-15-changeonlyplustickets_majorpages.pdf
Build and regtested on x86-64-linux.
OK for the 4.8 trunk?
Tobias
2012-03-02 Tobias Burnus
PR fortran/48820
* decl.c (gfc_match_decl_type_spec): Support type(*).
(gfc_verify_c_interop): Allow type(*).
* dump-parse-tree.c (show_typespec): Handle type(*).
* expr.c (gfc_copy_expr): Ditto.
* interface.c (compare_type_rank, compare_parameter,
compare_actual_formal, gfc_procedure_use): Ditto.
* libgfortran.h (bt): Add BT_ASSUMED.
* misc.c (gfc_basic_typename, gfc_typename): Handle type(*).
* module.c (bt_types): Ditto.
* resolve.c (assumed_type_expr_allowed): New static variable.
(resolve_actual_arglist, resolve_variable, resolve_symbol):
Handle type(*).
* trans-expr.c (gfc_conv_procedure_call): Ditto.
* trans-types.c (gfc_typenode_for_spec, gfc_get_dtype): Ditto.
2012-03-02 Tobias Burnus
PR fortran/48820
* gfortran.dg/assumed_type_1.f90: New.
* gfortran.dg/assumed_type_2.f90: New.
* gfortran.dg/assumed_type_3.f90: New.
* gfortran.dg/assumed_type_4.f90: New.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 43c558a..bdb8c39 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2600,9 +2600,31 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int implicit_flag)
}
- m = gfc_match (" type ( %n", name);
+ m = gfc_match (" type (");
matched_type = (m == MATCH_YES);
-
+ if (matched_type)
+{
+ gfc_gobble_whitespace ();
+ if (gfc_peek_ascii_char () == '*')
+ {
+ if ((m = gfc_match ("*)")) != MATCH_YES)
+ return m;
+ if (gfc_current_state () == COMP_DERIVED)
+ {
+ gfc_error ("Assumed type at %C is not allowed for components");
+ return MATCH_ERROR;
+ }
+ if (gfc_notify_std (GFC_STD_F2008_TS, "TS 29113: Assumed type "
+ "at %C") == FAILURE)
+ return MATCH_ERROR;
+ ts->type = BT_ASSUMED;
+ return MATCH_YES;
+ }
+
+ m = gfc_match ("%n", name);
+ matched_type = (m == MATCH_YES);
+}
+
if ((matched_type && strcmp ("integer", name) == 0)
|| (!matched_type && gfc_match (" integer") == MATCH_YES))
{
@@ -3854,9 +3876,9 @@ gfc_verify_c_interop (gfc_typespec *ts)
? SUCCESS : FAILURE;
else if (ts->type == BT_CLASS)
return FAILURE;
- else if (ts->is_c_interop != 1)
+ else if (ts->is_c_interop != 1 && ts->type != BT_ASSUMED)
return FAILURE;
-
+
return SUCCESS;
}
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index c715b30..7f1d28f 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -94,6 +94,12 @@ show_indent (void)
static void
show_typespec (gfc_typespec *ts)
{
+ if (ts->type == BT_ASSUMED)
+{
+ fputs ("(TYPE(*))", dumpfile);
+ return;
+}
+
fprintf (dumpfile, "(%s ", gfc_basic_typename (ts->type));
switch (ts->type)
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 129ece3..1521318 100644
--- a/gcc
GCC 4.8.0 Status Report (2012-03-02), Stage 1 starts now
Status == The trunk has branched for the GCC 4.7 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 4.7 so it is possible to test important fixes for 4.7.0 on it. Quality Data Priority # Change from Last Report --- --- P10 - 2 P2 69 - 1 P31 - 1 --- --- Total70 - 4 Previous Report === http://gcc.gnu.org/ml/gcc/2012-02/msg00441.html The next report will be sent by Jakub.
Re: GCC 4.7.0 Status Report (2012-03-02)
On 03/02/2012 12:15 PM, Richard Guenther wrote: The GCC 4.7 branch has been created and a first release candidate is being prepared right now. The branch is closed for now. Just be clear (I think the information could be useful in general): mainline can be already considered open for Stage 1 commits? Thanks, Paolo.
GCC 4.7.0 Status Report (2012-03-02)
The GCC 4.7 branch has been created and a first release candidate is being prepared right now. The branch is closed for now. Previous Report === http://gcc.gnu.org/ml/gcc/2012-02/msg00441.html The next report will announce the release candidate.
Re: [Patch, Fortran] PR52452 [4.5-4.7 Regr.] Intrinsic wrongly rejected
On Fri, Mar 2, 2012 at 11:12 AM, Paul Richard Thomas wrote: > OK for trunk with RM agreement. Obviously, 4.5 & 4.6 are OK too. Ok for trunk. Richard. > Thanks > > Paul > > On Fri, Mar 2, 2012 at 10:35 AM, Tobias Burnus wrote: >> There is a 4.5 to 4.7 regression for those (vendor) intrinsic procedures, >> which can exists as both subroutine and as function. Example: >> >> INTRINSIC :: etime >> CALL etime(tarray, result) >> >> Here, the "etime" gets marked as attr.subroutine, but later in >> resolve_intrinsics, it is mapped to the intrinsic function "etime". But then >> the compiler complains: >> >> Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'etime' at >> (1) >> >> >> Solution: Don't search for the function, if we have a subroutine. (For some >> reasons, it works without "INTRINSIC :: etime".) >> >> Build and regtested on x86-64-linux. >> OK for the trunk - and the 4.5 to 4.6 branches? >> >> Tobias >> >> PS: I will ask for RM approval if this patch gets approved after (today's?) >> RC1 release. > > > > -- > The knack of flying is learning how to throw yourself at the ground and miss. > --Hitchhikers Guide to the Galaxy
Re: [Patch, Fortran] PR52452 [4.5-4.7 Regr.] Intrinsic wrongly rejected
OK for trunk with RM agreement. Obviously, 4.5 & 4.6 are OK too. Thanks Paul On Fri, Mar 2, 2012 at 10:35 AM, Tobias Burnus wrote: > There is a 4.5 to 4.7 regression for those (vendor) intrinsic procedures, > which can exists as both subroutine and as function. Example: > > INTRINSIC :: etime > CALL etime(tarray, result) > > Here, the "etime" gets marked as attr.subroutine, but later in > resolve_intrinsics, it is mapped to the intrinsic function "etime". But then > the compiler complains: > > Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'etime' at > (1) > > > Solution: Don't search for the function, if we have a subroutine. (For some > reasons, it works without "INTRINSIC :: etime".) > > Build and regtested on x86-64-linux. > OK for the trunk - and the 4.5 to 4.6 branches? > > Tobias > > PS: I will ask for RM approval if this patch gets approved after (today's?) > RC1 release. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: libgo patch committed: Fill out syscall package for GNU/Linux
Ian Lance Taylor 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: /usr/include/sys/ustat.h:31:2: error: #error "Cannot use ustat in the large files compilation environment" make[4]: *** No rule to make target `s-sysinfo', needed by `sysinfo.go'. Stop. make[4]: *** Waiting for unfinished jobs has #if !defined(_LP64) && _FILE_OFFSET_BITS == 64 #error "Cannot use ustat in the large files compilation environment" #endif I've used the hack below to restore bootstrap, but suppose a cleaner solution would be to run the configure tests with the same flags as used for the actual compilations (i.e. OSCFLAGS). Alternatively, one could restrict the use of to Linux since it's only used in go/syscall/libcall_linux.go anyway. Rainer # HG changeset patch # Parent d7ca4c137cbff062787505281b123c22dfc72019 Don't use on 32-bit Solaris diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh --- a/libgo/mksysinfo.sh +++ b/libgo/mksysinfo.sh @@ -110,8 +110,12 @@ cat > sysinfo.c < #endif #if defined(HAVE_USTAT_H) +#if defined(__sun__) && defined(__svr4__) && !defined(_LP64) && _FILE_OFFSET_BITS == 64 +/* Solaris is incompatible with largefiles. */ +#else #include #endif +#endif #if defined(HAVE_UTIME_H) #include #endif -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH wwwdocs] Sort target-specific changes alphabetically
This patch organizes the target-specific changes section alphabetically (which it nearly was). Committed as obvious. R.Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.93 diff -u -p -r1.93 changes.html --- changes.html2 Mar 2012 09:40:55 - 1.93 +++ changes.html2 Mar 2012 09:50:31 - @@ -616,6 +616,19 @@ well. New Targets and Target Specific Improvements +ARM + +GCC now supports the Cortex-A7 processor implementing the + v7-a version of the architecture using the option + -mcpu=cortex-a7. +The default vector size in auto-vectorization for NEON is now 128 bits. + If vectorization fails thusly, the vectorizer tries again with + 64-bit vectors. +A new option -mvectorize-with-neon-double was added to + allow users to change the vector size to 64 bits. + + + AVR GCC now supports XMEGA architecture. @@ -665,19 +678,6 @@ int add_values (const __flash int *p, in -ARM - -GCC now supports the Cortex-A7 processor implementing the - v7-a version of the architecture using the option - -mcpu=cortex-a7. -The default vector size in auto-vectorization for NEON is now 128 bits. - If vectorization fails thusly, the vectorizer tries again with - 64-bit vectors. -A new option -mvectorize-with-neon-double was added to - allow users to change the vector size to 64 bits. - - - C6X Support has been added for the Texas Instruments C6X family of
Re: [PATCH, PR50335] Disable graphite loop flattening
On Fri, Mar 2, 2012 at 6:09 AM, Maxim Kuvyrkov wrote: > On 1/03/2012, at 11:42 PM, Richard Guenther wrote: >> On Thu, Mar 1, 2012 at 6:28 AM, Maxim Kuvyrkov >> wrote: >>> This patch disables graphite loop flattening optimization due to it being >>> effectively unmaintained. To avoid users trying to use unsupported >>> optimization and reporting bugs, Sebastian Pop suggested to disable the >>> optimization. >>> >>> Testing on x86_64 is underway. OK to apply provided no regressions? >> >> That cannot be enough, you need to adjust the testsuite as well. And >> if it is broken, >> why not remove it. Leaving unmaintained broken code in the repository is >> just >> a maintainance burden for no gain. >> >> So, please provide a complete removal patch (docs, making the option a >> dummy one, testcases, etc.) > > OK. The attached patch removes loop flattening optimization and updates > documentation and testsuite. > > Regtested on x86_64-linux-gnu with no regressions. Ok for trunk with the invoke.texi change changed to simply remove all references to floop-fatten and common.opt to use floop-flatten Common Ignore Does nothing. Preserved for backward compatibility. Thanks, Richard. > -- > Maxim Kuvyrkov > CodeSourcery / Mentor Graphics >
[Patch, Fortran] PR52452 [4.5-4.7 Regr.] Intrinsic wrongly rejected
There is a 4.5 to 4.7 regression for those (vendor) intrinsic
procedures, which can exists as both subroutine and as function. Example:
INTRINSIC :: etime
CALL etime(tarray, result)
Here, the "etime" gets marked as attr.subroutine, but later in
resolve_intrinsics, it is mapped to the intrinsic function "etime". But
then the compiler complains:
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'etime' at
(1)
Solution: Don't search for the function, if we have a subroutine. (For
some reasons, it works without "INTRINSIC :: etime".)
Build and regtested on x86-64-linux.
OK for the trunk - and the 4.5 to 4.6 branches?
Tobias
PS: I will ask for RM approval if this patch gets approved after
(today's?) RC1 release.
2012-03-02 Tobias Burnus
PR fortran/52452
* resolve.c (resolve_intrinsic): Don't search for a
function if we know that it is a subroutine.
2012-03-02 Tobias Burnus
PR fortran/52452
* gfortran.dg/intrinsic_8.f90: New.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 4dcf9b1..049a926 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1496,7 +1498,7 @@ resolve_intrinsic (gfc_symbol *sym, locus *loc)
if (sym->intmod_sym_id)
isym = gfc_intrinsic_function_by_id ((gfc_isym_id) sym->intmod_sym_id);
- else
+ else if (!sym->attr.subroutine)
isym = gfc_find_function (sym->name);
if (isym)
--- /dev/null 2012-03-02 07:37:33.883806634 +0100
+++ gcc/gcc/testsuite/gfortran.dg/intrinsic_8.f90 2012-03-02 08:59:51.0 +0100
@@ -0,0 +1,23 @@
+! { dg-do compile }
+!
+! PR fortran/52452
+!
+! Contributed by Roger Ferrer Ibanez
+!
+PROGRAM test_etime
+IMPLICIT NONE
+INTRINSIC :: etime
+REAL(4) :: tarray(1:2)
+REAL(4) :: result
+
+CALL etime(tarray, result)
+END PROGRAM test_etime
+
+subroutine test_etime2
+IMPLICIT NONE
+INTRINSIC :: etime
+REAL(4) :: tarray(1:2)
+REAL(4) :: result
+
+result = etime(tarray)
+END subroutine test_etime2
Re: Fix POINTER_PLUS_EXPR oversight
On Thu, Mar 1, 2012 at 9:23 PM, Bernd Schmidt wrote: > In pointer_diff we still expect pointer addition to use PLUS_EXPR. I > discovered this while working on a new port with somewhat unusual > pointer types. > > Interestingly, the C++ frontend also has a pointer_diff function, but > doesn't seem to attempt to optimize. Is there a reason for this? Frontends should not optimize when they are not required to. > Bootstrapped and tested on i686-linux. Ok for now or stage1? > > > Bernd
