Re: [PATCH] -mcmodel=large -fpic TLS GD and LD support gcc + binutils (PR target/58067)
On Tue, Aug 13, 2013 at 9:42 PM, Jakub Jelinek wrote: > We right now ICE with -mcmodel=large -fpic on x86_64 on TLS GD and LD > sequences, because obviously we can't call __tls_get_addr@plt there from code > potentially more than 2GB away from the PLT slot. > > The attached patches add support for that in gcc and also teaches linker > about those, because otherwise the linker will fail if you try to link such > -mcmodel=large -fpic code into binaries or PIEs. > > To make transitions possible, we emit always > leaq foo@tlsgd(%rip), %rdi > movabsq $__tls_get_addr@pltoff, %rax > addq $rbx, %rax > call *%rax > resp. > leaq foo@tlsld(%rip), %rdi > movabsq $__tls_get_addr@pltoff, %rax > addq $rbx, %rax > call *%rax > sequences (22 bytes, 6 bytes longer than what we do for TLSGD for normal > libraries). > > Bootstrapped/regtested on x86_64-linux and i686-linux, attached is also the > sources I've used to test all the 3 different transitions. > > Ok for trunk and 4.8 branch (and binutils trunk)? The implementation for x86 is technically OK, but I wonder if these sequences should be documented in some authoritative document about TLS relocations. The "ELF Handling For Thread-Local Storage" document [1] doesn't mention various code models fo x86_64, so I was not able to cross-check the implementaton vs. documentation. [1] http://www.akkadia.org/drepper/tls.pdf Thanks, Uros.
Re: [PATCH] x86_64 -mcmodel={medium,large} -fpic address delegitimization
On Tue, Aug 13, 2013 at 9:47 PM, Jakub Jelinek wrote: > On x86_64 with -mcmodel=large -fpic -g -O2 we get tons of > notes about non-delegitimized unspecs like UNSPEC_GOTOFF, UNSPEC_PLTOFF > or UNSPEC_GOT. Seems we already handle most of those properly for -m32 > code, so the issue is just that we wouldn't fall back into the -m32 handling > code which takes care of dealing with addends, missing pic pointer etc. > The following patch inverts the last condition for TARGET_64BIT code > and falls through for CM_MEDIUM_PIC and CM_LARGE_PIC cmodels. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2013-08-13 Jakub Jelinek > Alexandre Oliva > > PR target/58067 > * config/i386/i386.c (ix86_delegitimize_address): For CM_MEDIUM_PIC > and CM_LARGE_PIC ix86_cmodel fall thru into the -m32 code, handle > there also UNSPEC_PLTOFF. OK, also for backport to other release branches. Thanks, Uros.
Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL
Hi Richard,
Here is an attempt to address your earlier review comments. Bootstrapped
and there is no new regression for X86_64 and arm. Thank you very much
for your time.
Thanks,
Kugan
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,25 @@
+2013-08-14 Kugan Vivekanandarajah
+
+ * tree-flow.h (mark_range_info_unknown): New function definition.
+ * tree-ssa-alias.c (dump_alias_info) : Check pointer type.
+ * tree-ssa-copy.c (fini_copy_prop) : Check pointer type and copy
+ range info.
+ * tree-ssanames.c (make_ssa_name_fn) : Check pointer type in
+ initialize.
+ * (mark_range_info_unknown) : New function.
+ * (duplicate_ssa_name_range_info) : Likewise.
+ * (duplicate_ssa_name_fn) : Check pointer type and call correct
+ duplicate function.
+ * tree-vrp.c (extract_exp_value_range): New function.
+ * (simplify_stmt_using_ranges): Call extract_exp_value_range and
+ tree_ssa_set_value_range.
+ * tree-ssaname.c (ssa_range_info): New function.
+ * tree.h (SSA_NAME_PTR_INFO) : changed to access via union
+ * tree.h (SSA_NAME_RANGE_INFO) : New macro
+ * gimple-pretty-print.c (print_double_int) : New function.
+ * gimple-pretty-print.c (dump_gimple_phi) : Dump range info.
+ * (pp_gimple_stmt_1) : Likewise.
+
2013-08-09 Jan Hubicka
* cgraph.c (cgraph_create_edge_1): Clear speculative flag.
On 03/07/13 21:55, Kugan wrote:
On 17/06/13 18:33, Richard Biener wrote:
On Mon, 17 Jun 2013, Kugan wrote:
+/* Extract the value range of assigned exprassion for GIMPLE_ASSIGN
stmt.
+ If the extracted value range is valid, return true else return
+ false. */
+static bool
+extract_exp_value_range (gimple stmt, value_range_t *vr)
+{
+ gcc_assert (is_gimple_assign (stmt));
+ tree rhs1 = gimple_assign_rhs1 (stmt);
+ tree lhs = gimple_assign_lhs (stmt);
+ enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
...
@@ -8960,6 +9016,23 @@ simplify_stmt_using_ranges (gimple_stmt_iterator
*gsi)
{
enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
tree rhs1 = gimple_assign_rhs1 (stmt);
+ tree lhs = gimple_assign_lhs (stmt);
+
+ /* Set value range information for ssa. */
+ if (!POINTER_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt)))
+ && (TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME)
+ && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt)))
+ && !SSA_NAME_RANGE_INFO (lhs))
+{
+ value_range_t vr = VR_INITIALIZER;
...
+ if (extract_exp_value_range (stmt, &vr))
+tree_ssa_set_value_range (lhs,
+ tree_to_double_int (vr.min),
+ tree_to_double_int (vr.max),
+ vr.type == VR_RANGE);
+}
This looks overly complicated to me. In vrp_finalize you can simply do
for (i = 0; i < num_vr_values; i++)
if (vr_value[i])
{
tree name = ssa_name (i);
if (POINTER_TYPE_P (name))
continue;
if (vr_value[i].type == VR_RANGE
|| vr_value[i].type == VR_ANTI_RANGE)
tree_ssa_set_value_range (name, tree_to_double_int
(vr_value[i].min), tree_to_double_int (vr_value[i].max), vr_value[i].type
== VR_RANGE);
}
Thanks Richard for taking time to review it.
I was doing something like what you are suggesting earlier but noticed
some problems and that’s the reason why I changed.
For example, for the following testcase from the test suite,
unsigned long l = (unsigned long)-2;
unsigned short s;
int main () {
long t = l + 1;
s = l;
if (s != (unsigned short) -2)
abort ();
exit (0);
}
with the following gimple stmts
main ()
{
short unsigned int s.1;
long unsigned int l.0;
;; basic block 2, loop depth 0
;;pred: ENTRY
l.0_2 = l;
s.1_3 = (short unsigned int) l.0_2;
s = s.1_3;
if (s.1_3 != 65534)
goto ;
else
goto ;
;;succ: 3
;;4
;; basic block 3, loop depth 0
;;pred: 2
abort ();
;;succ:
;; basic block 4, loop depth 0
;;pred: 2
exit (0);
;;succ:
}
has the following value range.
l.0_2: VARYING
s.1_3: [0, +INF]
From zero/sign extension point of view, the variable s.1_3 is expected
to have a value that will overflow (or varying) as this is what is
assigned to a smaller variable. extract_range_from_assignment initially
calculates the value range as VARYING but later changed to [0, +INF] by
extract_range_basic. What I need here is the value that will be assigned
from the rhs expression and not the value that we will have with proper
assignment.
I understand that the above code of mine needs to be changed but not
convinced about the best way to do that.
I can possibly re-factor extract_range_from_assignment to give me this
information with an additional argument. Could you kindly let me know
your pre
Re: [PATCH i386 2/8] [AVX512] Add mask registers.
Hello,
Patch was rebased on top of trunk.
It is applicable on top of [1/8] (which was rebased on new trunk today).
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000 & 2006 build show no regressions both with and without -mavx512f
option.
4. Spec 2000 & 2006 run shows no regressions without -m512d option.
Thanks, K
---
gcc/config/i386/constraints.md | 8 +-
gcc/config/i386/i386.c | 32 +--
gcc/config/i386/i386.h | 40 ++--
gcc/config/i386/i386.md| 204 +
4 files changed, 247 insertions(+), 37 deletions(-)
diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index 28e626f..92e0c05 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -19,7 +19,7 @@
;;; Unused letters:
;;; B H T
-;;; h jk
+;;; h j
;; Integer register constraints.
;; It is not necessary to define 'r' here.
@@ -78,6 +78,12 @@
"TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387 ? FP_SECOND_REG : NO_REGS"
"Second from top of 80387 floating-point stack (@code{%st(1)}).")
+(define_register_constraint "k" "TARGET_AVX512F ? MASK_EVEX_REGS : NO_REGS"
+"@internal Any mask register that can be used as predicate, i.e. k1-k7.")
+
+(define_register_constraint "Yk" "TARGET_AVX512F ? MASK_REGS : NO_REGS"
+"@internal Any mask register.")
+
;; Vector registers (also used for plain floating point nowadays).
(define_register_constraint "y" "TARGET_MMX ? MMX_REGS : NO_REGS"
"Any MMX register.")
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index dd97e6b..7412745 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2303,6 +2303,9 @@ enum reg_class const regclass_map[FIRST_PSEUDO_REGISTER] =
EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS,
EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS,
EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS,
+ /* Mask registers. */
+ MASK_REGS, MASK_EVEX_REGS, MASK_EVEX_REGS, MASK_EVEX_REGS,
+ MASK_EVEX_REGS, MASK_EVEX_REGS, MASK_EVEX_REGS, MASK_EVEX_REGS,
};
/* The "default" register map used in 32bit mode. */
@@ -2318,6 +2321,7 @@ int const dbx_register_map[FIRST_PSEUDO_REGISTER] =
-1, -1, -1, -1, -1, -1, -1, -1, /* extended SSE registers */
-1, -1, -1, -1, -1, -1, -1, -1, /* new SSE registers 16-23*/
-1, -1, -1, -1, -1, -1, -1, -1, /* new SSE registers 24-31*/
+ 93, 94, 95, 96, 97, 98, 99, 100, /* Mask registers */
};
/* The "default" register map used in 64bit mode. */
@@ -2333,6 +2337,7 @@ int const dbx64_register_map[FIRST_PSEUDO_REGISTER] =
25, 26, 27, 28, 29, 30, 31, 32, /* extended SSE registers */
67, 68, 69, 70, 71, 72, 73, 74, /* new SSE registers 16-23 */
75, 76, 77, 78, 79, 80, 81, 82, /* new SSE registers 24-31 */
+ 118, 119, 120, 121, 122, 123, 124, 125, /* Mask registers */
};
/* Define the register numbers to be used in Dwarf debugging information.
@@ -2400,6 +2405,7 @@ int const svr4_dbx_register_map[FIRST_PSEUDO_REGISTER] =
-1, -1, -1, -1, -1, -1, -1, -1, /* extended SSE registers */
-1, -1, -1, -1, -1, -1, -1, -1, /* new SSE registers 16-23*/
-1, -1, -1, -1, -1, -1, -1, -1, /* new SSE registers 24-31*/
+ 93, 94, 95, 96, 97, 98, 99, 100, /* Mask registers */
};
/* Define parameter passing and return registers. */
@@ -4457,7 +4463,8 @@ ix86_conditional_register_usage (void)
/* If AVX512F is disabled, squash the registers. */
if (! TARGET_AVX512F)
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
- if (TEST_HARD_REG_BIT (reg_class_contents[(int)EVEX_SSE_REGS], i))
+ if (TEST_HARD_REG_BIT (reg_class_contents[(int)MASK_REGS], i)
+ || TEST_HARD_REG_BIT (reg_class_contents[(int)EVEX_SSE_REGS], i))
fixed_regs[i] = call_used_regs[i] = 1, reg_names[i] = "";
}
@@ -34114,10 +34121,12 @@ ix86_preferred_reload_class (rtx x, reg_class_t
regclass)
return regclass;
/* Force constants into memory if we are loading a (nonzero) constant into
- an MMX or SSE register. This is because there are no MMX/SSE instructions
- to load from a constant. */
+ an MMX, SSE or MASK register. This is because there are no MMX/SSE/MASK
+ instructions to load from a constant. */
if (CONSTANT_P (x)
- && (MAYBE_MMX_CLASS_P (regclass) || MAYBE_SSE_CLASS_P (regclass)))
+ && (MAYBE_MMX_CLASS_P (regclass)
+ || MAYBE_SSE_CLASS_P (regclass)
+ || MAYBE_MASK_CLASS_P (regclass)))
return NO_REGS;
/* Prefer SSE regs only, if we can use them for math. */
@@ -34221,10 +34230,11 @@ ix86_secondary_reload (bool in_p, rtx x, reg_class_t
rclass,
/* QImode spills from non-QI registers require
intermediate register on 32bit targets. */
- if (!TARGET_64BIT
- && !in_p && mode == QImode
- && INTEGER_CLASS_P (rclass)
- &&
Re: [PATCH][2 of 2] RTL expansion for zero sign extension elimination with VRP
Hi Eric,
Thanks for reviewing the patch.
On 01/07/13 18:51, Eric Botcazou wrote:
[Sorry for the delay]
For example, when an expression is evaluated and it's value is assigned
to variable of type short, the generated RTL would look something like
the following.
(set (reg:SI 110)
(zero_extend:SI (subreg:HI (reg:SI 117) 0)))
However, if during value range propagation, if we can say for certain
that the value of the expression which is present in register 117 is
within the limits of short and there is no sign conversion, we do not
need to perform the subreg and zero_extend; instead we can generate the
following RTl.
(set (reg:SI 110)
(reg:SI 117)))
Same could be done for other assign statements.
The idea looks interesting. Some remarks:
+2013-06-03 Kugan Vivekanandarajah
+
+ * gcc/dojump.c (do_compare_and_jump): generates rtl without
+ zero/sign extension if redundant.
+ * gcc/cfgexpand.c (expand_gimple_stmt_1): Likewise.
+ * gcc/gimple.c (gimple_assign_is_zero_sign_ext_redundant) : New
+ function.
+ * gcc/gimple.h (gimple_assign_is_zero_sign_ext_redundant) : New
+ function definition.
No gcc/ prefix in entries for gcc/ChangeLog. "Generate RTL without..."
I have now changed it to.
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2013-08-14 Kugan Vivekanandarajah
+
+ * dojump.c (do_compare_and_jump): Generate rtl without
+ zero/sign extension if redundant.
+ * cfgexpand.c (expand_gimple_stmt_1): Likewise.
+ * gimple.c (gimple_assign_is_zero_sign_ext_redundant) : New
+ function.
+ * gimple.h (gimple_assign_is_zero_sign_ext_redundant) : New
+ function definition.
+
2013-08-09 Jan Hubicka
* cgraph.c (cgraph_create_edge_1): Clear speculative flag.
+/* If the value in SUBREG of temp fits that SUBREG (does not
+ overflow) and is assigned to target SUBREG of the same mode
+ without sign convertion, we can skip the SUBREG
+ and extension. */
+else if (promoted
+ && gimple_assign_is_zero_sign_ext_redundant (stmt)
+ && (GET_CODE (temp) == SUBREG)
+ && (GET_MODE (target) == GET_MODE (temp))
+ && (GET_MODE (SUBREG_REG (target))
+ == GET_MODE (SUBREG_REG (temp
+ emit_move_insn (SUBREG_REG (target), SUBREG_REG (temp));
else if (promoted)
{
int unsignedp = SUBREG_PROMOTED_UNSIGNED_P (target);
Can we relax the strict mode equality here? This change augments the same
transformation applied to the RHS when it is also a SUBREG_PROMOTED_VAR_P at
the beginning of convert_move, but the condition on the mode is less strict in
the latter case, so maybe it can serve as a model here.
I have now changed it based on convert_move to
+else if (promoted
+ && gimple_assign_is_zero_sign_ext_redundant (stmt)
+ && (GET_CODE (temp) == SUBREG)
+ && (GET_MODE_PRECISION (GET_MODE (SUBREG_REG (temp)))
+>= GET_MODE_PRECISION (GET_MODE (target)))
+ && (GET_MODE (SUBREG_REG (target))
+ == GET_MODE (SUBREG_REG (temp
+ {
Is this what you wanted me to do.
+ /* Is zero/sign extension redundant as per VRP. */
+ bool op0_ext_redundant = false;
+ bool op1_ext_redundant = false;
+
+ /* If promoted and the value in SUBREG of op0 fits (does not overflow),
+ it is a candidate for extension elimination. */
+ if (GET_CODE (op0) == SUBREG && SUBREG_PROMOTED_VAR_P (op0))
+op0_ext_redundant =
+ gimple_assign_is_zero_sign_ext_redundant (SSA_NAME_DEF_STMT (treeop0));
+
+ /* If promoted and the value in SUBREG of op1 fits (does not overflow),
+ it is a candidate for extension elimination. */
+ if (GET_CODE (op1) == SUBREG && SUBREG_PROMOTED_VAR_P (op1))
+op1_ext_redundant =
+ gimple_assign_is_zero_sign_ext_redundant (SSA_NAME_DEF_STMT (treeop1));
Are the gimple_assign_is_zero_sign_ext_redundant checks necessary here?
When set on a SUBREG, SUBREG_PROMOTED_VAR_P guarantees that SUBREG_REG is
always properly extended (otherwise it's a bug) so don't you just need to
compare SUBREG_PROMOTED_UNSIGNED_SET? See do_jump for an existing case.
I am sorry I don’t think I understood you here. How would I know that
extension is redundant without calling
gimple_assign_is_zero_sign_ext_redundant ? Could you please elaborate.
+ /* If zero/sign extension is redundant, generate RTL
+ for operands without zero/sign extension. */
+ if ((op0_ext_redundant || TREE_CODE (treeop0) == INTEGER_CST)
+ && (op1_ext_redundant || TREE_CODE (treeop1) == INTEGER_CST))
Don't you need to be careful with the INTEGER_CSTs here? The CONST_INTs are
always sign-extended in RTL so 0x80 is always re
RE: [PATCH][tree-optimization] Fix PR58088
Ping. Thanks, Kyrill 2013-08-14 Kyrylo Tkachov PR tree-optimization/58088 * fold-const.c (mask_with_trailing_zeros): New function. (fold_binary_loc): Make sure we don't recurse infinitely when the X in (X & C1) | C2 is a tree of the form (Y * K1) & K2. Use mask_with_trailing_zeros where appropriate. 2013-08-14 Kyrylo Tkachov PR tree-optimization/58088 * gcc.c-torture/compile/pr58088.c: New test. > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov > Sent: 07 August 2013 14:22 > To: gcc-patches > Cc: 'Richard Biener'; pola...@redhat.com > Subject: [PATCH][tree-optimization] Fix PR58088 > > Hi all, > > In PR58088 the constant folder goes into an infinite recursion and runs > out of > stack space because of two conflicting optimisations: > (X * C1) & C2 plays dirty when nested inside an IOR expression like so: > ((X * > C1) & C2) | C4. One can undo the other leading to an infinite recursion. > > Thanks to Marek for finding the IOR case. > > This patch fixes that by checking in the IOR case that the change to C2 > will > not conflict with the AND case transformation. Example testcases in the > PR on > bugzilla. > > This issue is present in 4.8.1 as well as trunk. However, I think 4.8 > uses a > different API for double_int, so this patch will need to be reworked for > 4.8. > > In the meantime, > Ok for trunk? > > Bootstrapped on x86_64-linux-gnu and tested arm-none-eabi on qemu. > > > Thanks, > Kyrill > > 2013-08-07 Kyrylo Tkachov > > * gcc/fold-const.c (mask_with_trailing_zeros): New function. > (fold_binary_loc): Make sure we don't recurse infinitely > when the X in (X & C1) | C2 is a tree of the form (Y * K1) & K2. > Use mask_with_trailing_zeros where appropriate. > > > 2013-08-07 Kyrylo Tkachov > > * gcc.c-torture/compile/pr58088.c: New test.
Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc
On Wed, Aug 07, 2013 at 11:47:55PM +0200, Paolo Carlini wrote: > Hi, > > On 08/07/2013 10:48 PM, Uros Bizjak wrote: > >2013-08-07 Uros Bizjak > > > > * src/c++98/compatibility.cc (_ZTIe): Use const_cast to avoid warning. > > (_ZTIPe): Ditto. > > (ZTIPKe): Ditto. > > > >The patch was bootstrapped on alpha-linux-gnu, regression test is still > >running. > > > >OK for mainline if regtest shows no problems? Also for 4.8? > I think you want in any case Jakub to have a look. Changing all those (void *) casts into (const void *) in the _ZTIe, _ZTIPe and _ZTIPKe initializers seems to also work. I'm not really a C++ guy, so I'll leave whether (const void *) or const_cast should be used to libstdc++ maintainers. I'm just surprised you haven't changed all the spots, just some of them, and (void *) &_ZTVN10__cxxabiv123__fundamental_type_infoE[2] and similar and (void *) 1L etc. were left untouched. Jakub
Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc
On Wed, Aug 14, 2013 at 10:29 AM, Jakub Jelinek wrote: >> >2013-08-07 Uros Bizjak >> > >> > * src/c++98/compatibility.cc (_ZTIe): Use const_cast to avoid warning. >> > (_ZTIPe): Ditto. >> > (ZTIPKe): Ditto. >> > >> >The patch was bootstrapped on alpha-linux-gnu, regression test is still >> >running. >> > >> >OK for mainline if regtest shows no problems? Also for 4.8? >> I think you want in any case Jakub to have a look. > > Changing all those (void *) casts into (const void *) in the _ZTIe, > _ZTIPe and _ZTIPKe initializers seems to also work. I'm not really a C++ > guy, so I'll leave whether (const void *) or const_cast should be used > to libstdc++ maintainers. I'm just surprised you haven't changed > all the spots, just some of them, and > (void *) &_ZTVN10__cxxabiv123__fundamental_type_infoE[2] and similar > and (void *) 1L etc. were left untouched. These didn't emit warnings for my target (alpha), so also not being a C++ person, I left them as they were. Uros.
Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc
On 08/14/2013 10:41 AM, Uros Bizjak wrote: These didn't emit warnings for my target (alpha), so also not being a C++ person, I left them as they were. Ok then, for now let's simply go ahead with your original patch. Please also add a one line comment before the first cast. Thanks! Paolo.
[PATCH] Properly install dummy libgcc_bc library
The rules to install the dummy libgcc_bc library have never worked as intented, probably due to the fact that the fedora gcc package installs it by hand, ignoring all damage that has been done. The target that creates libgcj_bc.la for the testsuite is mucking around with internal details that will confuse libtool when it tries to install it, the effect of which can't be undone by install-exec-hook. We need to create a clean second copy that is actually installed. Andreas. * Makefile.am (toolexeclib_LTLIBRARIES) [USE_LIBGCJ_BC]: Use install/libgcj_bc.la instead of libgcj_bc.la. (noinst_LTLIBRARIES) [USE_LIBGCJ_BC]: Define. (install_libgcj_bc_la_SOURCES): Define. (install/libgcj_bc.la): New rule. * Makefile.in: Regenerate. diff --git a/libjava/Makefile.am b/libjava/Makefile.am index dce1bb0..5af58fa 100644 --- a/libjava/Makefile.am +++ b/libjava/Makefile.am @@ -212,7 +212,8 @@ LIBJAVA_CORE_EXTRA = endif if USE_LIBGCJ_BC -toolexeclib_LTLIBRARIES += libgcj_bc.la +toolexeclib_LTLIBRARIES += install/libgcj_bc.la +noinst_LTLIBRARIES = libgcj_bc.la endif if XLIB_AWT @@ -606,6 +607,7 @@ lib_gnu_awt_xlib_la_LINK = $(LIBLINK) $(lib_gnu_awt_xlib_la_LDFLAGS) \ ## This lets us have one soname in BC objects and another in C++ ABI objects. ## This library is not linked against libgcj. libgcj_bc_la_SOURCES = libgcj_bc.c +install_libgcj_bc_la_SOURCES = $(libgcj_bc_la_SOURCES) libgcj_bc_la_LDFLAGS = -rpath $(toolexeclibdir) -no-static -version-info 1:0:0 \ $(LIBGCJ_LD_SYMBOLIC_FUNCTIONS) $(LIBJAVA_LDFLAGS_NOUNDEF) libgcj_bc_la_DEPENDENCIES = libgcj.la $(libgcj_bc_la_version_dep) @@ -628,6 +630,11 @@ libgcj_bc.la: $(libgcj_bc_la_OBJECTS) $(libgcj_bc_la_DEPENDENCIES) rm .libs/libgcj_bc.so.1; \ $(LN_S) libgcj_bc.so.1.0.0 .libs/libgcj_bc.so.1 +## This rule creates the libgcj_bc library that is actually installed. +install/libgcj_bc.la: $(libgcj_bc_la_OBJECTS) $(libgcj_bc_la_DEPENDENCIES) install/$(am__dirstamp) + $(libgcj_bc_la_LINK) $(am_libgcj_bc_la_rpath) $(libgcj_bc_la_LDFLAGS) \ + $(libgcj_bc_la_OBJECTS) $(libgcj_bc_la_LIBADD) $(LIBS) + ## Note that property_files is defined in sources.am. propertyo_files = $(patsubst classpath/resource/%,%,$(addsuffix .lo,$(property_files))) -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
RE: [PATCH,i386] PR58105 wrong code generation with multi-versioned functions
On Wed, 14 Aug 2013 12:36:00, Richard Biener wrote: > ChangeLog without gcc/ prefix - it's for the gcc/ChangeLog file. Ok > with that > change. > > Thanks, > Richard. > Thanks for your quick response. But as I do not have check-in access I might need some help. Thanks Bernd.
Re: [PATCH] S/390: Hardware transactional memory support
On Tue, 2013-08-13 at 12:09 -0700, Richard Henderson wrote:
> On 08/13/2013 11:26 AM, Jakub Jelinek wrote:
> > On Fri, Aug 02, 2013 at 11:05:33AM -1000, Richard Henderson wrote:
> >> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
> >>> ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
> >>
> >> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
> >> floating point registers; similarly for the write accessors.
> >
> > So, would it be enough to compile just beginend.cc with -msoft-float
> > and the rest normally?
>
> No.
>
> >From what I understand of the s390 restriction, we can't touch the
> floating point registers after starting a transaction, at least until
> we're committed to restoring them all.
>
> Which means that we have to have everything along the path from
> htm_begin_success == false until a longjmp restores them. This path
> includes a call to std::operator new, so that makes it a non-starter.
>
> Better, I think, to pass the gtm_jmpbuf to htm_begin. Then we can do
>
> uint32_t ret = __builtin_tbegin_nofloat (NULL);
> if (!htm_begin_success(ret))
> // restore fpu state from jb
> return ret;
>
> at which point we're back to normal and we can do whatever we want
> within the normal abi wrt the fpu.
Can we instead move the successful path of the HTM fastpath to the
_ITM_beginTransaction asm function, and just do the fallback and retry
code in beginend.cc? So, add a tbegin (or xbegin) and the check of
serial_lock to the asm function as in Andi's patch
(http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00640.html), but keep the
restart policy code (ie, the serial lock read/write locking for the
wait, etc.) in beginend.cc? The latter could return a new code that
tells the asm function to try the HTM fastpath again; we might also want
to use a separate bit in the arguments to gtm_thread::begin_transaction
to tell it whether the HTM fastpath failed before.
This way, we get lower overhead when the HTM fastpath succeeds right
away because we can do the minimally necessary thing in asm; we still
can change the retry policies easily; and we can restore the floating
point registers to a sane state for any libitm C/C++ code that we might
call without having to do any restore inside of the C/C++ code.
Thoughts? I'll put working on a draft of this for x86 on my list.
Re: [PATCH][4.8 backport] S/390: Transactional Execution support
On Thu, Aug 01, 2013 at 10:55:15AM +0200, Andreas Krebbel wrote: > I would like to apply backports of the TX support patches to 4.8 > branch. We released 4.8 with EC12 support already but the support is > somewhat incomplete without having TX. With these patches we will > have full EC12 support in 4.8. In your backport you've forgot to include the libitm/config/s390 directory, so I guess it is broken on 4.8 branch even more than it is on the trunk (the pending -msoft-float issue). Jakub
[PATCH] Fix SRA with volatile loads/stores (PR tree-optimization/58145)
Hi!
On the following testcases we miscompile the code (on -1.c just drop
= {v} from the statements, on -2.c lim moves the volatile stores after the
loop), because SRA drops the volatileness from the MEM_REF.
SRA generally ignores volatile vars and fields etc., but if we have a
structure assignment to volatile from non-volatile or vice versa,
if SRA decides to scalarize rhs resp. lhs, new MEM_REFs are created even
for the volatile access with different type.
The following patch fixes that by propagating TREE_THIS_VOLATILE and
TREE_SIDE_EFFECTS from the prev_base to the newly created MEM_REF.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.8?
On IRC with Martin we've also discussed slsr in this regard, but that seems
to be fine, it uses the original volatile type if it was volatile and
propagates TREE_THIS_VOLATILE/TREE_SIDE_EFFECTS flags to the newly created
MEM_REF.
2013-08-14 Jakub Jelinek
PR tree-optimization/58145
* tree-sra.c (build_ref_for_offset): If base is TREE_THIS_VOLATILE,
propagate it to exp_type and MEM_REF.
* gcc.dg/pr58145-1.c: New test.
* gcc.dg/pr58145-2.c: New test.
--- gcc/tree-sra.c.jj 2013-08-14 11:02:55.290711106 +0200
+++ gcc/tree-sra.c 2013-08-14 12:38:47.405230042 +0200
@@ -1466,6 +1466,7 @@ build_ref_for_offset (location_t loc, tr
{
tree prev_base = base;
tree off;
+ tree mem_ref;
HOST_WIDE_INT base_offset;
unsigned HOST_WIDE_INT misalign;
unsigned int align;
@@ -1515,8 +1516,17 @@ build_ref_for_offset (location_t loc, tr
align = (misalign & -misalign);
if (align < TYPE_ALIGN (exp_type))
exp_type = build_aligned_type (exp_type, align);
-
- return fold_build2_loc (loc, MEM_REF, exp_type, base, off);
+ if (TREE_THIS_VOLATILE (TREE_TYPE (prev_base))
+ && !TREE_THIS_VOLATILE (exp_type))
+exp_type = build_qualified_type (exp_type, TYPE_QUALS (exp_type)
+ | TYPE_QUAL_VOLATILE);
+
+ mem_ref = fold_build2_loc (loc, MEM_REF, exp_type, base, off);
+ if (TREE_THIS_VOLATILE (exp_type) || TREE_THIS_VOLATILE (prev_base))
+TREE_THIS_VOLATILE (mem_ref) = 1;
+ if (TREE_SIDE_EFFECTS (prev_base))
+TREE_SIDE_EFFECTS (mem_ref) = 1;
+ return mem_ref;
}
/* Construct a memory reference to a part of an aggregate BASE at the given
--- gcc/testsuite/gcc.dg/pr58145-1.c.jj 2013-08-14 12:02:07.077086488 +0200
+++ gcc/testsuite/gcc.dg/pr58145-1.c2013-08-14 12:03:15.895198976 +0200
@@ -0,0 +1,37 @@
+/* PR tree-optimization/58145 */
+/* { dg-do compile { target { int32plus } } } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+struct S { unsigned int data : 32; };
+struct T { unsigned int data; };
+volatile struct S s2;
+
+void
+f1 (int val)
+{
+ struct S s = { .data = val };
+ *(volatile struct S *) 0x88UL = s;
+}
+
+void
+f2 (int val)
+{
+ struct T t = { .data = val };
+ *(volatile struct T *) 0x88UL = t;
+}
+
+void
+f3 (int val)
+{
+ *(volatile unsigned int *) 0x88UL = val;
+}
+
+void
+f4 (int val)
+{
+ struct S s = { .data = val };
+ s2 = s;
+}
+
+/* { dg-final { scan-tree-dump-times " ={v} " 4 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
--- gcc/testsuite/gcc.dg/pr58145-2.c.jj 2013-08-14 12:02:28.409663559 +0200
+++ gcc/testsuite/gcc.dg/pr58145-2.c2013-08-14 12:04:19.471612107 +0200
@@ -0,0 +1,51 @@
+/* PR tree-optimization/58145 */
+/* { dg-do compile { target { int32plus } } } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+struct S { unsigned int data : 32; };
+struct T { unsigned int data; };
+volatile struct S s2;
+
+static inline void
+f1 (int val)
+{
+ struct S s = { .data = val };
+ *(volatile struct S *) 0x88UL = s;
+}
+
+static inline void
+f2 (int val)
+{
+ struct T t = { .data = val };
+ *(volatile struct T *) 0x88UL = t;
+}
+
+static inline void
+f3 (int val)
+{
+ *(volatile unsigned int *) 0x88UL = val;
+}
+
+static inline void
+f4 (int val)
+{
+ struct S s = { .data = val };
+ s2 = s;
+}
+
+void
+f5 (void)
+{
+ int i;
+ for (i = 0; i < 100; i++)
+f1 (0);
+ for (i = 0; i < 100; i++)
+f2 (0);
+ for (i = 0; i < 100; i++)
+f3 (0);
+ for (i = 0; i < 100; i++)
+f4 (0);
+}
+
+/* { dg-final { scan-tree-dump-times " ={v} " 4 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Jakub
[PATCH] Fix PR 57662
Hello,
As noted in Bugzilla, the problem is this PR is the rare case of removing
the unconditional jump that is used for traversing CFG when simplifying
control flow. We rescan the remaining successors when we know the flow
below the current point has changed, and when we have removed the jump we
are currently on, we segfault. The fix is just to break out of successor
iterator loop as in the unconditional jump case we have already visited the
only successor.
Bootstrapped and tested on x86-64, ok for trunk? If yes, Alexander, could
you please commit this for me?
Andrey
2013-08-14 Andrey Belevantsev
PR rtl-optimization/57662
gcc/
* sel-sched.c (code_motion_process_successors): When the current insn
is removed after the recursive traversal, break from the loop.
Add comments and debug printouts.
testsuite/
* gcc.dg/pr57662.c: New test.
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index fb9386f..a7b8897 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -6424,10 +6424,23 @@ code_motion_process_successors (insn_t insn, av_set_t orig_ops,
res = b;
/* We have simplified the control flow below this point. In this case,
- the iterator becomes invalid. We need to try again. */
+ the iterator becomes invalid. We need to try again.
+ If we have removed the insn itself, it could be only an
+ unconditional jump. Thus, do not rescan but break immediately --
+ we have already visited the only successor block. */
+ if (!BLOCK_FOR_INSN (insn))
+ {
+ if (sched_verbose >= 6)
+ sel_print ("Not doing rescan: already visited the only successor"
+ " of block %d\n", old_index);
+ break;
+ }
if (BLOCK_FOR_INSN (insn)->index != old_index
|| EDGE_COUNT (bb->succs) != old_succs)
{
+ if (sched_verbose >= 6)
+ sel_print ("Rescan: control flow simplified below insn %d, block %d\n",
+ INSN_UID (insn), BLOCK_FOR_INSN (insn)->index);
insn = sel_bb_end (BLOCK_FOR_INSN (insn));
goto rescan;
}
diff --git a/gcc/testsuite/gcc.dg/pr57662.c b/gcc/testsuite/gcc.dg/pr57662.c
new file mode 100644
index 000..7af8455
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr57662.c
@@ -0,0 +1,47 @@
+/* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
+/* { dg-options " -O -fno-guess-branch-probability -fpeel-loops -freorder-blocks-and-partition -fschedule-insns2 -fsel-sched-pipelining -fselective-scheduling2 -ftree-pre" } */
+
+struct intC
+{
+ short x;
+ short y;
+};
+
+void Get(void);
+
+int size_x;
+
+struct
+{
+ int *depot_table;
+ struct intC *ti;
+ int size;
+} dummy;
+
+static inline int
+GetRotatedTileFromOffset (int *a, struct intC tidc)
+{
+ if (!*a)
+Get ();
+ switch (*a)
+{
+case 0:
+ return (tidc.y << size_x) + tidc.x;
+case 1:
+ return tidc.y + (dummy.size - tidc.x) * size_x;
+case 2:
+ return tidc.x + (dummy.size - tidc.y) * size_x;
+case 3:
+ return (dummy.size - tidc.x);
+}
+ return 0;
+}
+
+int
+GetHangarNum (int *a, int i)
+{
+ while (dummy.size)
+if (GetRotatedTileFromOffset (a, dummy.ti[i]))
+ return *dummy.depot_table;
+ return 0;
+}
[ubsan] Add -lpthread to POSTSTAGE1_LDFLAGS
When doing bootstrap with ubsan, some files require libpthread to be linked. This patch adds -lpthread into POSTSTAGE1_LDFLAGS for the bootstrap-ubsan. Applying to the ubsan branch. 2013-08-14 Marek Polacek * bootstrap-ubsan.mk (POSTSTAGE1_LDFLAGS): Add -lpthread. --- gcc/bootstrap-ubsan.mk.mp 2013-08-14 16:01:34.752485016 +0200 +++ gcc/bootstrap-ubsan.mk 2013-08-14 16:01:50.381541011 +0200 @@ -2,6 +2,6 @@ STAGE2_CFLAGS += -fsanitize=undefined STAGE3_CFLAGS += -fsanitize=undefined -POSTSTAGE1_LDFLAGS += -fsanitize=undefined -static-libubsan \ +POSTSTAGE1_LDFLAGS += -fsanitize=undefined -static-libubsan -lpthread \ -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ubsan/ \ -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ubsan/.libs Marek
Re: [PATCH 2/3] Support using 'auto' in a function parameter list to introduce an implicit template parameter.
On 08/12/2013 08:34 PM, Adam Butcher wrote: Currently it is the implicit function template code in pt.c that updates this; specifically add_implicit_template_parms and finish_fully_implicit_template. It is queried by the parser (both in parser.c and lambda.c) to decide whether a new [implicit] template parameter list as been started and to decide how to finish up. I had a look into this; it should be possible to move these out of pt.c and into parser.c (or some new file generic-parms.c, implicit-pt.c or some such) and possibly add a plain global counter for this state, rather than attribute it to each scope. Right, I was thinking it would make sense as a field of cp_parser, since it doesn't affect template instantiation context. Jason
Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc
On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis
wrote:
> I agree 'const void*' is preferable, and all the places you mention should
> be covered too.
I already installed my original patch, so attached incremental patch
implements preferred solution.
2013-08-14 Uros Bizjak
* src/c++98/compatibility.cc (_ZTIe): Use (const cast *)
to avoid -Wcast-qual warnings.
(_ZTIPe): Ditto.
(ZTIPKe): Ditto.
Tested on alphaev68-pc-linux-gnu and installed on mainline SVN.
Is this solution also OK for other release branches?
Uros.
Index: src/c++98/compatibility.cc
===
--- src/c++98/compatibility.cc (revision 201723)
+++ src/c++98/compatibility.cc (working copy)
@@ -516,18 +516,17 @@
extern __attribute__((used, weak)) const char _ZTSe[2] = "e";
extern __attribute__((used, weak)) const char _ZTSPe[3] = "Pe";
extern __attribute__((used, weak)) const char _ZTSPKe[4] = "PKe";
-// const_casts are used to avoid -Wcast-qual warnings
extern __attribute__((used, weak)) const void * const _ZTIe[2]
- = { (void *) &_ZTVN10__cxxabiv123__fundamental_type_infoE[2],
- const_cast(_ZTSe) };
+ = { (const void *) &_ZTVN10__cxxabiv123__fundamental_type_infoE[2],
+ (const void *) _ZTSe };
extern __attribute__((used, weak)) const void * const _ZTIPe[4]
- = { (void *) &_ZTVN10__cxxabiv119__pointer_type_infoE[2],
- const_cast(_ZTSPe), (void *) 0L,
- const_cast(_ZTIe) };
+ = { (const void *) &_ZTVN10__cxxabiv119__pointer_type_infoE[2],
+ (const void *) _ZTSPe, (const void *) 0L,
+ (const void *) _ZTIe };
extern __attribute__((used, weak)) const void * const _ZTIPKe[4]
- = { (void *) &_ZTVN10__cxxabiv119__pointer_type_infoE[2],
- const_cast(_ZTSPKe), (void *) 1L,
- const_cast(_ZTIe) };
+ = { (const void *) &_ZTVN10__cxxabiv119__pointer_type_infoE[2],
+ (const void *) _ZTSPKe, (const void *) 1L,
+ (const void *) _ZTIe };
#endif // _GLIBCXX_LONG_DOUBLE_COMPAT
#ifdef _GLIBCXX_SYMVER_DARWIN
Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc
On Wed, Aug 14, 2013 at 04:22:07PM +0200, Uros Bizjak wrote: > On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis > wrote: > > I agree 'const void*' is preferable, and all the places you mention should > > be covered too. > > I already installed my original patch, so attached incremental patch > implements preferred solution. > > 2013-08-14 Uros Bizjak > > * src/c++98/compatibility.cc (_ZTIe): Use (const cast *) > to avoid -Wcast-qual warnings. > (_ZTIPe): Ditto. > (ZTIPKe): Ditto. > > Tested on alphaev68-pc-linux-gnu and installed on mainline SVN. > > Is this solution also OK for other release branches? If it is ok for trunk, then it is also ok for 4.8/4.7 from RM POV. Jakub
Re: [PATCH 2/3] Support using 'auto' in a function parameter list to introduce an implicit template parameter.
On Wed, Aug 14, 2013 at 9:07 AM, Jason Merrill wrote: > On 08/12/2013 08:34 PM, Adam Butcher wrote: >> >> Currently it is the implicit function template code in pt.c that updates >> this; specifically add_implicit_template_parms and >> finish_fully_implicit_template. >> >> It is queried by the parser (both in parser.c and lambda.c) to decide >> whether a new [implicit] template parameter list as been started and to >> decide how to finish up. >> >> I had a look into this; it should be possible to move these out of pt.c >> and into parser.c (or some new file generic-parms.c, implicit-pt.c or >> some such) and possibly add a plain global counter for this state, >> rather than attribute it to each scope. > > > Right, I was thinking it would make sense as a field of cp_parser, since it > doesn't affect template instantiation context. Agreed. I think we should reduce the number of such object macro states. -- Gaby
Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc
On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote: > > On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis > wrote: > > I agree 'const void*' is preferable, and all the places you mention should > > be covered too. > > I already installed my original patch, so attached incremental patch > implements preferred solution. > > 2013-08-14 Uros Bizjak > > * src/c++98/compatibility.cc (_ZTIe): Use (const cast *) > to avoid -Wcast-qual warnings. > (_ZTIPe): Ditto. > (ZTIPKe): Ditto. > > Tested on alphaev68-pc-linux-gnu and installed on mainline SVN. > > Is this solution also OK for other release branches? > > Uros. Sorry, when I said 'const void*' was OK, I implicitly assumed that you would use C++-style cast reinterpret_cast(_Z….). Same for reinterpret_cast(1); -- Gaby
Re: [PATCH] Fix PR 57662
On Wed, 14 Aug 2013, Andrey Belevantsev wrote: > Hello, > > As noted in Bugzilla, the problem is this PR is the rare case of removing the > unconditional jump that is used for traversing CFG when simplifying control > flow. We rescan the remaining successors when we know the flow below the > current point has changed, and when we have removed the jump we are currently > on, we segfault. The fix is just to break out of successor iterator loop as > in the unconditional jump case we have already visited the only successor. > > Bootstrapped and tested on x86-64, ok for trunk? If yes, Alexander, could you > please commit this for me? This is OK. Committed after adjusting one overlong line. Thanks. Alexander
Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc
On Wed, Aug 14, 2013 at 4:34 PM, Gabriel Dos Reis wrote: > On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote: >> >> On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis >> wrote: >> > I agree 'const void*' is preferable, and all the places you mention should >> > be covered too. >> >> I already installed my original patch, so attached incremental patch >> implements preferred solution. >> >> 2013-08-14 Uros Bizjak >> >> * src/c++98/compatibility.cc (_ZTIe): Use (const cast *) >> to avoid -Wcast-qual warnings. >> (_ZTIPe): Ditto. >> (ZTIPKe): Ditto. >> >> Tested on alphaev68-pc-linux-gnu and installed on mainline SVN. >> >> Is this solution also OK for other release branches? >> >> Uros. > > Sorry, when I said 'const void*' was OK, I implicitly assumed that you would > use C++-style cast reinterpret_cast(_Z….). Same for > reinterpret_cast(1); Ah, OK. I'll add this in a moment. Thanks, Uros.
Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc
On Wed, Aug 14, 2013 at 4:36 PM, Uros Bizjak wrote:
> On Wed, Aug 14, 2013 at 4:34 PM, Gabriel Dos Reis
> wrote:
>> On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote:
>>>
>>> On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis
>>> wrote:
>>> > I agree 'const void*' is preferable, and all the places you mention should
>>> > be covered too.
>>>
>>> I already installed my original patch, so attached incremental patch
>>> implements preferred solution.
>>>
>>> 2013-08-14 Uros Bizjak
>>>
>>> * src/c++98/compatibility.cc (_ZTIe): Use (const cast *)
>>> to avoid -Wcast-qual warnings.
>>> (_ZTIPe): Ditto.
>>> (ZTIPKe): Ditto.
>>>
>>> Tested on alphaev68-pc-linux-gnu and installed on mainline SVN.
>>>
>>> Is this solution also OK for other release branches?
>>>
>>> Uros.
>>
>> Sorry, when I said 'const void*' was OK, I implicitly assumed that you would
>> use C++-style cast reinterpret_cast(_Z….). Same for
>> reinterpret_cast(1);
>
> Ah, OK. I'll add this in a moment.
Like the attached patch?
Again, build tested on alphaev68-pc-linux-gnu.
Uros.
Index: src/c++98/compatibility.cc
===
--- src/c++98/compatibility.cc (revision 201727)
+++ src/c++98/compatibility.cc (working copy)
@@ -517,16 +517,21 @@
extern __attribute__((used, weak)) const char _ZTSPe[3] = "Pe";
extern __attribute__((used, weak)) const char _ZTSPKe[4] = "PKe";
extern __attribute__((used, weak)) const void * const _ZTIe[2]
- = { (const void *) &_ZTVN10__cxxabiv123__fundamental_type_infoE[2],
- (const void *) _ZTSe };
+ = { reinterpret_cast
+ (&_ZTVN10__cxxabiv123__fundamental_type_infoE[2]),
+ reinterpret_cast(_ZTSe) };
extern __attribute__((used, weak)) const void * const _ZTIPe[4]
- = { (const void *) &_ZTVN10__cxxabiv119__pointer_type_infoE[2],
- (const void *) _ZTSPe, (const void *) 0L,
- (const void *) _ZTIe };
+ = { reinterpret_cast
+ (&_ZTVN10__cxxabiv119__pointer_type_infoE[2]),
+ reinterpret_cast(_ZTSPe),
+ reinterpret_cast(0L),
+ reinterpret_cast(_ZTIe) };
extern __attribute__((used, weak)) const void * const _ZTIPKe[4]
- = { (const void *) &_ZTVN10__cxxabiv119__pointer_type_infoE[2],
- (const void *) _ZTSPKe, (const void *) 1L,
- (const void *) _ZTIe };
+ = { reinterpret_cast
+ (&_ZTVN10__cxxabiv119__pointer_type_infoE[2]),
+ reinterpret_cast(_ZTSPKe),
+ reinterpret_cast(1L),
+ reinterpret_cast(_ZTIe) };
#endif // _GLIBCXX_LONG_DOUBLE_COMPAT
#ifdef _GLIBCXX_SYMVER_DARWIN
[ubsan] Fix assert in c-ubsan.c
We ICEd on the following testcase because even though the underlying
types were the same, theirs TREE_TYPEs were not. We can use
TYPE_MAIN_VARIANT to see through the typedefs which confused us.
Tested x86_64-pc-linux-gnu, applying to the ubsan branch.
2013-08-14 Marek Polacek
* c-ubsan.c (ubsan_instrument_division): Use TYPE_MAIN_VARIANT
in the assert.
* c-c++-common/ubsan/typedef-1.c: New test.
--- gcc/c-family/c-ubsan.c.mp 2013-08-14 16:55:56.322784886 +0200
+++ gcc/c-family/c-ubsan.c 2013-08-14 16:56:03.716812775 +0200
@@ -42,8 +42,10 @@ ubsan_instrument_division (location_t lo
tree type = TREE_TYPE (op0);
/* At this point both operands should have the same type,
- because they are already converted to RESULT_TYPE. */
- gcc_assert (type == TREE_TYPE (op1));
+ because they are already converted to RESULT_TYPE.
+ Use TYPE_MAIN_VARIANT since typedefs can confuse us. */
+ gcc_assert (TYPE_MAIN_VARIANT (TREE_TYPE (op0))
+ == TYPE_MAIN_VARIANT (TREE_TYPE (op1)));
/* TODO: REAL_TYPE is not supported yet. */
if (TREE_CODE (type) != INTEGER_TYPE)
--- gcc/testsuite/c-c++-common/ubsan/typedef-1.c.mp 2013-08-14
16:58:05.767181047 +0200
+++ gcc/testsuite/c-c++-common/ubsan/typedef-1.c2013-08-14
16:57:21.086022479 +0200
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=undefined" } */
+
+typedef int V;
+int
+foo (void)
+{
+ V v = 9;
+ int a = 3;
+ v += v % a;
+ return v / 3;
+}
Marek
Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv
On 08/12/2013 07:07 PM, Caroline Tice wrote:
The feature is supposed to be active in production code (like the
stack protector).
Okay, and it makes sense to enable this in programs that run with
different privileges than the invoking user.
If a trust transition occurred during the past execve, libvtv must not
use the current directory to store files, or derive file paths from
environment variables. Using shared directories such as /tmp is also
tricky. (The current libvtv version in trunk has an arbitrary file
creation vulnerability because of the hardcoded path in /tmp.)
Realistically, I think libvtv can only log to standard error (or perhaps
syslog/the journal) if it detects it runs with elevated privileges.
One way to achieve that is to return dup(2) as the file descriptor if
logs_dir is NULL (after changing getenv to secure_getenv), instead of
setting logs_dir to ".". This means that unless the environment
variable is set, nothing would be logged to disk. I'm not sure if this
what you want. But it follows the principle of least surprise, though.
Creating log files in strange places because of a crash is unusual.
If you insist on dumping stuff into the current directory by default,
you'll have to use getauxval(AT_SECURE) (glibc 2.17 and later),
__libc_enable_secure (some glibc systems, but not Fedora and the ELs),
issetugid (Solaris and the BSDs) or an explicit comparison between
getuid()/geteuid() and getgid()/getegid() (all the rest, slightly unsafe
on Linux). I can write down this approach in more detail, it should
probably go into the Fedora security guide anyway.
I also noticed this in log_memory_protection_data:
log_fd = __vtv_open_log ("vtv_memory_protection_data_%d.log");
The "_%d" should probably be dropped because the argument is not a
format string.
--
Florian Weimer / Red Hat Product Security Team
[PATCH, PowerPC] Fix PR57949 (ABI alignment issue)
This fixes a long-standing problem with GCC's implementation of the
PPC64 ELF ABI. If a structure contains a member requiring 128-bit
alignment, and that structure is passed as a parameter, the parameter
currently receives only 64-bit alignment. This is an error, and is
incompatible with correct code generated by the IBM XL compilers.
This situation should be rare, so we feel that it is ok to correct GCC
to generate compliant code. However, it is possible that new code may
need to link with existing libraries that expect the incorrect parameter
passing. For this case, a new option mcompat-align-parm is provided to
cause the noncompliant code to be generated. (David, any better choice
of name for this option?)
Correcting the initial bug exposed another problem with varargs
handling. When receiving a parameter having size zero, the alignment
specified for the parameter must be honored. Several variations in the
compatibility test suite detected that this is not being done. For
example, a parameter of type
struct { struct { } a[4]; } __attribute__((aligned))
must use the default alignment for the target, which for PowerPC is 128
bits. This was not being done. When I corrected the first problem to
generate 128-bit alignment for structs that require it, the un-honored
alignment for zero-size arguments in varargs was exposed. This patch
corrects that also.
In both cases, existing code for MachO/darwin can be used for AIX and
Linux.
I've provided two tests to verify correct parameter offsets for the
first problem, one with the mcompat-align-parm option set, and one
without. I did not add tests for the second problem, as the
compatibility test suite is already sufficient.
Bootstrapped and tested on powerpc64-unknown-linux-gnu with no
regressions. Ok for trunk?
Thanks,
Bill
gcc:
2013-08-14 Bill Schmidt
PR target/57949
* doc/invoke.texi: Add documentation of mcompat-align-parm
option.
* config/rs6000/rs6000.opt: Add mcompat-align-parm option.
* config/rs6000/rs6000.c (rs6000_function_arg_boundary): For AIX
and Linux, correct BLKmode alignment when 128-bit alignment is
required and compatibility flag is not set.
(rs6000_gimplify_va_arg): For AIX and Linux, honor specified
alignment for zero-size arguments when compatibility flag is not
set.
gcc/testsuite:
2013-08-14 Bill Schmidt
PR target/57949
* gcc.target/powerpc/pr57949-1.c: New.
* gcc.target/powerpc/pr57949-2.c: New.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 201492)
+++ gcc/doc/invoke.texi (working copy)
@@ -866,7 +866,8 @@ See RS/6000 and PowerPC Options.
-msave-toc-indirect -mno-save-toc-indirect @gol
-mpower8-fusion -mno-mpower8-fusion -mpower8-vector -mno-power8-vector @gol
-mcrypto -mno-crypto -mdirect-move -mno-direct-move @gol
--mquad-memory -mno-quad-memory}
+-mquad-memory -mno-quad-memory @gol
+-mcompat-align-parm -mno-compat-align-parm}
@emph{RX Options}
@gccoptlist{-m64bit-doubles -m32bit-doubles -fpu -nofpu@gol
@@ -18323,6 +18324,22 @@ stack location in the function prologue if the fun
a pointer on AIX and 64-bit Linux systems. If the TOC value is not
saved in the prologue, it is saved just before the call through the
pointer. The @option{-mno-save-toc-indirect} option is the default.
+
+@item -mcompat-align-parm
+@itemx -mno-compat-align-parm
+@opindex mcompat-align-parm
+Generate (do not generate) code to pass structure parameters with a
+maximum alignment of 64 bits, for compatibility with older versions
+of GCC.
+
+Older versions of GCC (prior to 4.9.0) incorrectly did not align a
+structure parameter on a 128-bit boundary when that structure contained
+a member requiring 128-bit alignment. This is corrected in more
+recent versions of GCC. This option may be used to generate code
+that is compatible with functions compiled with older versions of
+GCC.
+
+The @option{-mno-compat-align-parm} option is the default.
@end table
@node RX Options
Index: gcc/testsuite/gcc.target/powerpc/pr57949-1.c
===
--- gcc/testsuite/gcc.target/powerpc/pr57949-1.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr57949-1.c(revision 0)
@@ -0,0 +1,19 @@
+/* { dg-do compile { target { powerpc64*-*-* && lp64 } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-options "-O2 -mcpu=power7" } */
+
+/* Verify that vs is 16-byte aligned in the absence of -mcompat-align-parm. */
+
+typedef float v4sf __attribute__ ((vector_size (16)));
+struct s { long m; v4sf v; };
+long n;
+v4sf ve;
+
+void pr57949 (long d1, long d2, long d3, long d4, long d5, long d6,
+ long d7, long d8, long d9, struct s vs) {
+ n = vs.m;
+ ve = vs.v;
+}
+
+/* { dg-final { scan-assembler "li \.\*,144" } } */
+/* { dg-final { scan-assembler "
Re: [PATCH] S/390: Hardware transactional memory support
On 08/14/2013 05:44 AM, Torvald Riegel wrote: > Can we instead move the successful path of the HTM fastpath to the > _ITM_beginTransaction asm function, and just do the fallback and retry > code in beginend.cc? Certainly, but this seems like a larger re-design, and I was thinking of a shorter-term solution. r~
Re: -mtune-ctrl=.... support, round-2
Ping? David On Mon, Aug 12, 2013 at 9:54 AM, Xinliang David Li wrote: > Fixed some formatting issues and typos. There are no regressions with > the attached patch. Ok for trunk? > > thanks, > > David > > On Wed, Aug 7, 2013 at 10:12 PM, Xinliang David Li wrote: >> Hi, the attached is a follow up patch. The patch includes the following >> changes: >> >> 1. new option -mno-default -- suggested by H.J. It can be combined >> with -mtune-ctrl= to clear the default settings. >> 2. new option -mdump-tune-features -- this option can be used to dump >> all feature names and their default settings. >> 3. Added documentation to the 3 new options >> >> 4. Move the contents of inital_x86_tune_features into x86-tune.def to >> make sure they are always in sync >> 5. Some refactoring and handle the the tune features properly during >> target option restore. >> >> 2013-08-07 Xinliang David Li >> >> * config/i386/i386.h: Adjust macro definition. >> * config/i386/i386.opt: Define two new options. >> * config/i386/x86-tune.def: Add arch selector field in macros. >> * config/i386/i386.h: include x86-tune.def. >> * config/i386/i386.c (ix86_option_override_internal): >> Refactor the code. >> (parse_mtune_ctrl_str): New function. >> (set_ix86_tune_features): New function. >> (ix86_function_specific_restore): Call the new helper function. >> >> Ok for trunk after testing? >> >> thanks, >> >> David >> >> >> On Wed, Aug 7, 2013 at 5:22 PM, Xinliang David Li wrote: >>> On Wed, Aug 7, 2013 at 4:54 PM, Joseph S. Myers >>> wrote: On Sun, 4 Aug 2013, Andi Kleen wrote: > Richard Biener writes: > > > > The patch fails to add documentation. > > That seems like a feature, it's likely not useful for the general > public. More for specialized tools that automatically search > for the best tuning. If such a tool is not part of GCC itself, then it is a user of GCC and documentation should be provided for those writing such a tool. Options should be undocumented in very limited cases such as multiple variant spellings where only one should be used but others are accepted because they were historically, or whether the user interface to an option is separate from the internal option passed to cc1 (the documentation is of options as passed to the driver, but the .opt file may describe options passed to cc1 as a result of other options being passed to the driver), or the option really is only for use within the build of GCC itself. Otherwise, the strong presumption is that all options should be documented, with appropriate caveats as applicable about the cases where an option is useful. >>> >>> Fair enough. I will add the documentation in a followup patch which >>> also implements H.J's proposal -mno-default and cleans up the initial >>> tuning array to be always in sync with new enums. >>> >>> > > And I am nervous about testing > > coverage - is this considered a development option only or are random > > combinations expected to work in all situations? I expect not, thus > > this looks like a dangerous option? > > When it's undocumented it doesn't need to work in every situation? No input files and command-line arguments whatsoever to the driver should result in ICEs, including undocumented options. >>> >>> True -- if ICEs are found, we should fix them. >>> >>> thanks, >>> >>> David >>> -- Joseph S. Myers jos...@codesourcery.com
Ping: [avr] testsuite patches ({3,5,7,8,9,14}/14)
These patches haven't been reviewed for more that three weeks: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00808.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00811.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00906.html
[linaro/gcc-4_8-branch] Backports from trunk and merge from gcc-4_8-branch
Hi, I have recently backported the following revisions from to linaro/gcc-4_8-branch: 200204 (as 201484) 200419 (as 201485) 200466,200467 (as 201486) 200519 (as 201487) 200521 (as 201488) 200531 (as 201489) 200532,200565 (as 201490) 200637 (as 201491) 200670 (as 201493) 200720 (as 201496) 200922 (as 201497) 198928,198973,199203,201240,201241,201307 (as 201527) 199438,199439,199533,201326 (as 201528) 198684,198735,198831,199959 (as 201529) 200596,201067,201083 (as 201531) 201237 (as 201556) 198489,200167,200199,200510,200513,200515,200576 (as 201590+201594) 199720 (as 201662) I have also merged the gcc-4_8-branch into linaro/gcc-4_8-branch up to revision 201477 as 201722. Thanks, Christophe.
Ping: testsuite patches ({1,2,6,10,12}/14)
These patches have not been reviewed for more than three weeks: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00807.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00812.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00816.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00819.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00895.html
Re: -mtune-ctrl=.... support, round-2
> > 2013-08-07 Xinliang David Li
> >
> > * config/i386/i386.h: Adjust macro definition.
> > * config/i386/i386.opt: Define two new options.
> > * config/i386/x86-tune.def: Add arch selector field in macros.
> > * config/i386/i386.h: include x86-tune.def.
> > * config/i386/i386.c (ix86_option_override_internal):
> > Refactor the code.
> > (parse_mtune_ctrl_str): New function.
> > (set_ix86_tune_features): New function.
> > (ix86_function_specific_restore): Call the new helper function.
OK.
> +/* Helper function to set ix86_tune_features. IX86_TUNE is the
> + processor type. */
> +
> +static void
> +set_ix86_tune_features (enum processor_type ix86_tune, bool dump)
> +{
> + unsigned int ix86_tune_mask = 1u << ix86_tune;
> + int i;
> +
> + for (i = 0; i < X86_TUNE_LAST; ++i)
> +{
> + if (ix86_tune_no_default)
> +ix86_tune_features[i] = 0;
> + else
> +ix86_tune_features[i] = !!(initial_ix86_tune_features[i] &
> ix86_tune_mask);
Perhaps != 0?
> Index: doc/invoke.texi
> ===
> --- doc/invoke.texi (revision 201645)
> +++ doc/invoke.texi (working copy)
> @@ -637,6 +637,7 @@ Objective-C and Objective-C++ Dialects}.
>
> @emph{i386 and x86-64 Options}
> @gccoptlist{-mtune=@var{cpu-type} -march=@var{cpu-type} @gol
> +-mtune-ctrl=@var{feature-list} -mdump-tune-features -mno-default @gol
> -mfpmath=@var{unit} @gol
> -masm=@var{dialect} -mno-fancy-math-387 @gol
> -mno-fp-ret-in-387 -msoft-float @gol
> @@ -14429,6 +14430,24 @@ supported architecture, using the approp
> the file containing the CPU detection code should be compiled without
> these options.
>
> +@item -mdump-tune-features
> +@opindex mdump-tune-features
> +This option instructs GCC to dump the names of the x86 performance
> +tuning features and default settings. The names can be used in
> +@option{-mtune-ctrl=@var{feature-list}}.
> +
> +@item -mtune-ctrl=@var{feature-list}
> +@opindex mtune-ctrl=@var{feature-list}
> +This option is used to do fine grain control of x86 code generation features.
> +@var{feature-list} is a comma separated list of @var{feature} names. See also
> +@option{-mdump-tune-features}. When specified, the @var{feature} will be
> turned
> +on if it is not preceded with @code{^}, otherwise, it will be turned off.
> +
> +@item -mno-default
> +@opindex mno-default
> +This option instructs GCC to turn off all tunable features. See also
> +@option{-mtune-ctrl=@var{feature-list}} and @option{-mdump-tune-features}.
Perhaps we shall at least explicitely document that this is intended for
devleopment
only and may lead to ICEs.
Honza
> +
> @item -mcld
> @opindex mcld
> This option instructs GCC to emit a @code{cld} instruction in the prologue
Re: Ping: testsuite patches ({1,2,6,10,12}/14)
On 08/14/2013 08:55 AM, Joern Rennecke wrote: > These patches have not been reviewed for more than three weeks: > > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00807.html > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00812.html > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00816.html > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00819.html These are OK. > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00895.html I'd prefer to have someone else review this patch, which replaces -gdwarf-2 with -gdwarf. Janis
Re: -mtune-ctrl=.... support, round-2
On Wed, Aug 14, 2013 at 9:01 AM, Jan Hubicka wrote:
>> > 2013-08-07 Xinliang David Li
>> >
>> > * config/i386/i386.h: Adjust macro definition.
>> > * config/i386/i386.opt: Define two new options.
>> > * config/i386/x86-tune.def: Add arch selector field in macros.
>> > * config/i386/i386.h: include x86-tune.def.
>> > * config/i386/i386.c (ix86_option_override_internal):
>> > Refactor the code.
>> > (parse_mtune_ctrl_str): New function.
>> > (set_ix86_tune_features): New function.
>> > (ix86_function_specific_restore): Call the new helper function.
> OK.
>> +/* Helper function to set ix86_tune_features. IX86_TUNE is the
>> + processor type. */
>> +
>> +static void
>> +set_ix86_tune_features (enum processor_type ix86_tune, bool dump)
>> +{
>> + unsigned int ix86_tune_mask = 1u << ix86_tune;
>> + int i;
>> +
>> + for (i = 0; i < X86_TUNE_LAST; ++i)
>> +{
>> + if (ix86_tune_no_default)
>> +ix86_tune_features[i] = 0;
>> + else
>> +ix86_tune_features[i] = !!(initial_ix86_tune_features[i] &
>> ix86_tune_mask);
> Perhaps != 0?
This part is copied from the original version -- so I will leave it
alone here ;)
>> Index: doc/invoke.texi
>> ===
>> --- doc/invoke.texi (revision 201645)
>> +++ doc/invoke.texi (working copy)
>> @@ -637,6 +637,7 @@ Objective-C and Objective-C++ Dialects}.
>>
>> @emph{i386 and x86-64 Options}
>> @gccoptlist{-mtune=@var{cpu-type} -march=@var{cpu-type} @gol
>> +-mtune-ctrl=@var{feature-list} -mdump-tune-features -mno-default @gol
>> -mfpmath=@var{unit} @gol
>> -masm=@var{dialect} -mno-fancy-math-387 @gol
>> -mno-fp-ret-in-387 -msoft-float @gol
>> @@ -14429,6 +14430,24 @@ supported architecture, using the approp
>> the file containing the CPU detection code should be compiled without
>> these options.
>>
>> +@item -mdump-tune-features
>> +@opindex mdump-tune-features
>> +This option instructs GCC to dump the names of the x86 performance
>> +tuning features and default settings. The names can be used in
>> +@option{-mtune-ctrl=@var{feature-list}}.
>> +
>> +@item -mtune-ctrl=@var{feature-list}
>> +@opindex mtune-ctrl=@var{feature-list}
>> +This option is used to do fine grain control of x86 code generation
>> features.
>> +@var{feature-list} is a comma separated list of @var{feature} names. See
>> also
>> +@option{-mdump-tune-features}. When specified, the @var{feature} will be
>> turned
>> +on if it is not preceded with @code{^}, otherwise, it will be turned off.
>> +
>> +@item -mno-default
>> +@opindex mno-default
>> +This option instructs GCC to turn off all tunable features. See also
>> +@option{-mtune-ctrl=@var{feature-list}} and @option{-mdump-tune-features}.
>
> Perhaps we shall at least explicitely document that this is intended for
> devleopment
> only and may lead to ICEs.
Ok will do.
thanks,
David
>
> Honza
>> +
>> @item -mcld
>> @opindex mcld
>> This option instructs GCC to emit a @code{cld} instruction in the prologue
>
Re: Ping: testsuite patches ({1,2,6,10,12}/14)
On 14 Aug 2013, at 17:15, Janis Johnson wrote: >> >> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00895.html > > I'd prefer to have someone else review this patch, which replaces > -gdwarf-2 with -gdwarf. It is quite likely to break on (at least) Darwin9..10 and likely later - I'll give it a spin on my next build cycle. Iain
Re: testsuite patches (12/14): Add predicates to tests that depend on integer size
On Jul 19, 2013, at 11:46 PM, Joern Rennecke
wrote:
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-07-17 Joern Rennecke
>
> * c-c++-common/simulate-thread/bitfields-2.c: Run test only for
> target { ! int16 }.
> * gcc.dg/tree-ssa/pr54245.c: Do slsr scan only for target { ! int16 }.
> * gcc.dg/tree-ssa/slsr-1.c: Adjust multiplicators to scan for for
> target { int16 }. Restrict existing tests to target { int32 }
> where appropriate.
> * gcc.dg/tree-ssa/slsr-2.c, gcc.dg/tree-ssa/slsr-27.c: Likewise.
> * gcc.dg/tree-ssa/slsr-28.c, gcc.dg/tree-ssa/slsr-29.c: Likewise.
> * gcc.dg/tree-ssa/slsr-3.c, gcc.dg/tree-ssa/ssa-ccp-23.c: Likewise.
> * lib/target-supports.exp (check_effective_target_int32): New proc.
Ok.
I'd recommend an Ok? in patches that seek approval or explicit review.
Sometimes people post patches that are trivial and just check them in.
Re: testsuite patches (10/14): Add missing test conditions in c-c++-common/scal-to-vec1.c
Ok.
On Jul 19, 2013, at 11:28 PM, Joern Rennecke
wrote:
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-07-05 Joern Rennecke
>
> * c-c++-common/scal-to-vec1.c: Add !int16 and large_double conditions
> to tests that assume int/double are larger than short/float.
>
> Index: c-c++-common/scal-to-vec1.c
> ===
> --- c-c++-common/scal-to-vec1.c (revision 201032)
> +++ c-c++-common/scal-to-vec1.c (working copy)
> @@ -26,13 +26,13 @@ int main (int argc, char *argv[]) {
> int i = 12;
> double d = 3.;
>
> -v1 = i + v0;/* { dg-error "conversion of scalar \[^\\n\]* to
> vector" } */
> +v1 = i + v0;/* { dg-error "conversion of scalar \[^\\n\]* to
> vector" "scalar to vector" { target { ! int16 } } } */
> v1 = 9 + v0;/* { dg-error "conversion of scalar \[^\\n\]* to
> vector" } */
>
> -f1 = d + f0;/* { dg-error "conversion of scalar \[^\\n\]* to
> vector" } */
> -f1 = 1.3 + f0; /* { dg-error "conversion of scalar \[^\\n\]* to
> vector" } */
> +f1 = d + f0;/* { dg-error "conversion of scalar \[^\\n\]* to
> vector" "scalar to vector" { target { large_double } } } */
> +f1 = 1.3 + f0; /* { dg-error "conversion of scalar \[^\\n\]* to
> vector" "scalar to vector" { target { large_double } } } */
> f1 = sll + f0; /* { dg-error "conversion of scalar \[^\\n\]* to
> vector" } */
> -f1 = ((int)998769576) + f0; /* { dg-error "conversion of scalar
> \[^\\n\]* to vector" } */
> +f1 = ((int)998769576) + f0; /* { dg-error "conversion of scalar
> \[^\\n\]* to vector" "scalar to vector" { target { ! int16 } } } */
>
> /* convert.c should take care of this. */
> i1 = sfl + i0; /* { dg-error "can't convert value to a
> vector|invalid operands" } */
Re: testsuite patches (6/14): Use sizeof (double) to define size of vector of two doubles
OK.
On Jul 19, 2013, at 11:14 PM, Joern Rennecke
wrote:
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-07-05 Joern Rennecke
>
> * gcc.dg/pr44214-1.c (v2df): Define size using sizeof (double).
> * gcc.dg/pr44214-3.c (v2df): Likewise.
>
> Index: gcc.dg/pr44214-1.c
> ===
> --- gcc.dg/pr44214-1.c(revision 201032)
> +++ gcc.dg/pr44214-1.c(working copy)
> @@ -1,7 +1,7 @@
> /* { dg-do compile } */
> /* { dg-options "-O2 -freciprocal-math -fdump-tree-ccp1" } */
>
> -typedef double v2df __attribute__ ((vector_size (16)));
> +typedef double v2df __attribute__ ((vector_size (2 * sizeof (double;
>
> void do_div (v2df *a, v2df *b)
> {
> Index: gcc.dg/pr44214-3.c
> ===
> --- gcc.dg/pr44214-3.c(revision 201032)
> +++ gcc.dg/pr44214-3.c(working copy)
> @@ -1,7 +1,7 @@
> /* { dg-do compile } */
> /* { dg-options "-O2 -fdump-tree-ccp1" } */
>
> -typedef double v2df __attribute__ ((vector_size (16)));
> +typedef double v2df __attribute__ ((vector_size (2 * sizeof (double;
>
> void do_div (v2df *a, v2df *b)
> {
Re: testsuite patches (2/14): Don't run execute/pr56799.c for int16 targets
Ok.
On Jul 19, 2013, at 10:54 PM, Joern Rennecke
wrote:
> With 16 bit integers, (int) 0x0001 is just 0, so execution of that test
> fails.
>
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-05-13 Joern Rennecke
>
> * gcc.c-torture/execute/pr56799.x: New file.
>
> Index: gcc.c-torture/execute/pr56799.x
> ===
> --- gcc.c-torture/execute/pr56799.x (revision 0)
> +++ gcc.c-torture/execute/pr56799.x (working copy)
> @@ -0,0 +1,7 @@
> +load_lib target-supports.exp
> +
> +if { [check_effective_target_int32plus] } {
> + return 0
> +}
> +
> +return 1;
Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc
On Wed, Aug 14, 2013 at 9:49 AM, Uros Bizjak wrote: > On Wed, Aug 14, 2013 at 4:36 PM, Uros Bizjak wrote: >> On Wed, Aug 14, 2013 at 4:34 PM, Gabriel Dos Reis >> wrote: >>> On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote: On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis wrote: > I agree 'const void*' is preferable, and all the places you mention > should > be covered too. I already installed my original patch, so attached incremental patch implements preferred solution. 2013-08-14 Uros Bizjak * src/c++98/compatibility.cc (_ZTIe): Use (const cast *) to avoid -Wcast-qual warnings. (_ZTIPe): Ditto. (ZTIPKe): Ditto. Tested on alphaev68-pc-linux-gnu and installed on mainline SVN. Is this solution also OK for other release branches? Uros. >>> >>> Sorry, when I said 'const void*' was OK, I implicitly assumed that you would >>> use C++-style cast reinterpret_cast(_Z….). Same for >>> reinterpret_cast(1); >> >> Ah, OK. I'll add this in a moment. > > Like the attached patch? > > Again, build tested on alphaev68-pc-linux-gnu. > > Uros. Yes, OK if it passes tests. Thanks! -- Gaby
Re: Ping: testsuite patches ({1,2,6,10,12}/14)
On 14 Aug 2013, at 17:19, Iain Sandoe wrote: > On 14 Aug 2013, at 17:15, Janis Johnson wrote: >>> >>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00895.html >> >> I'd prefer to have someone else review this patch, which replaces >> -gdwarf-2 with -gdwarf. > > It is quite likely to break on (at least) Darwin9..10 and likely later - I'll > give it a spin on my next build cycle. tried on recent builds of i686-darwin9, x86_64-darwin10 and x86_64-darwin12 with no change in test output for check-gcc-c RUNTESTFLAGS=dwarf2.exp. So my concern appears unfounded, Iain
Re: Ping: testsuite patches ({1,2,6,10,12}/14)
On Aug 14, 2013, at 9:51 AM, Iain Sandoe wrote: > On 14 Aug 2013, at 17:19, Iain Sandoe wrote: >> On 14 Aug 2013, at 17:15, Janis Johnson wrote: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00895.html >>> >>> I'd prefer to have someone else review this patch, which replaces >>> -gdwarf-2 with -gdwarf. >> >> It is quite likely to break on (at least) Darwin9..10 and likely later - >> I'll give it a spin on my next build cycle. > > tried on recent builds of i686-darwin9, x86_64-darwin10 and x86_64-darwin12 > with no change in test output for > check-gcc-c RUNTESTFLAGS=dwarf2.exp. > > So my concern appears unfounded, Thanks for testing.
Re: RFA: Use -gdwarf in gcc.dg/debug/dwarf (Was: Re: testsuite patches (1/14): Request dwarf-2 output where needed)
Ok.
On Jul 22, 2013, at 2:40 AM, Joern Rennecke wrote:
> Quoting Jakub Jelinek :
>
>> On Mon, Jul 22, 2013 at 10:31:03AM +0530, Senthil Kumar Selvaraj wrote:
> ..
>>> I ran into this problem a while ago, and after discussion on the
>>> mailing list, added a -gdwarf option to emit DWARF with the default
>>> version (http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00592.html). Might
>>> be better than hardcoding dwarf-2 IMO.
>>
>> Yeah, definitely.
>>
>> Jakub
>
> All right, then we should start by changing the existing -gdwarf-2 options in
> the gcc.dg/debug/dwarf2 directory to -gdwarf.
>
> Tested on i686-pc-linux-gnu .
>
> 2013-07-22 Joern Rennecke
>
> * gcc.dg/debug/dwarf2/dwarf2.exp: Replace -gdwarf-2 with -gdwarf.
> * gcc.dg/debug/dwarf2/dwarf-die7.c: Likewise.
> * gcc.dg/debug/dwarf2/static1.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-dfp.c: Likewise.
> * gcc.dg/debug/dwarf2/fesd-any.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-uninit.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-die1.c: Likewise.
> * gcc.dg/debug/dwarf2/var1.c: Likewise.
> * gcc.dg/debug/dwarf2/pr29609-2.c: Likewise.
> * gcc.dg/debug/dwarf2/aranges-fnsec-1.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-die3.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-merge.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-char1.c: Likewise.
> * gcc.dg/debug/dwarf2/discriminator.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-char2.c: Likewise.
> * gcc.dg/debug/dwarf2/fesd-baseonly.c: Likewise.
> * gcc.dg/debug/dwarf2/pr36690-3.c: Likewise.
> * gcc.dg/debug/dwarf2/const-2.c: Likewise.
> * gcc.dg/debug/dwarf2/ipa-cp1.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-char3.c: Likewise.
> * gcc.dg/debug/dwarf2/var2.c: Likewise.
> * gcc.dg/debug/dwarf2/pr36690-2.c: Likewise.
> * gcc.dg/debug/dwarf2/pr31230.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-float.c: Likewise.
> * gcc.dg/debug/dwarf2/short-circuit.c: Likewise.
> * gcc.dg/debug/dwarf2/pr36690-1.c: Likewise.
> * gcc.dg/debug/dwarf2/fesd-reduced.c: Likewise.
> * gcc.dg/debug/dwarf2/pr37616.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-die2.c: Likewise.
> * gcc.dg/debug/dwarf2/inline1.c: Likewise.
> * gcc.dg/debug/dwarf2/fesd-sys.c: Likewise.
> * gcc.dg/debug/dwarf2/pr29609-1.c: Likewise.
> * gcc.dg/debug/dwarf2/asm-line1.c: Likewise.
> * gcc.dg/debug/dwarf2/c99-typedef1.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf2-macro.c: Likewise.
> * gcc.dg/debug/dwarf2/fesd-none.c: Likewise.
> * gcc.dg/debug/dwarf2/pr51410.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-file1.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-die6.c: Likewise.
> * gcc.dg/debug/dwarf2/const-2b.c: Likewise.
> * gcc.dg/debug/dwarf2/dwarf-die5.c: Likewise.
>
> Index: gcc.dg/debug/dwarf2/dwarf2.exp
> ===
> --- gcc.dg/debug/dwarf2/dwarf2.exp(revision 201032)
> +++ gcc.dg/debug/dwarf2/dwarf2.exp(working copy)
> @@ -22,7 +22,7 @@
> # If a testcase doesn't have special options, use these.
> global DEFAULT_CFLAGS
> if ![info exists DEFAULT_CFLAGS] then {
> -set DEFAULT_CFLAGS " -ansi -pedantic-errors -gdwarf-2"
> +set DEFAULT_CFLAGS " -ansi -pedantic-errors -gdwarf"
> }
>
> # Initialize `dg'.
> @@ -31,7 +31,7 @@
> # Main loop.
> set comp_output [gcc_target_compile \
> "$srcdir/$subdir/../trivial.c" "trivial.S" assembly \
> -"additional_flags=-gdwarf-2"]
> +"additional_flags=-gdwarf"]
> if { ! [string match "*: target system does not support the * debug format*" \
> $comp_output] } {
> remove-build-file "trivial.S"
> Index: gcc.dg/debug/dwarf2/dwarf-die7.c
> ===
> --- gcc.dg/debug/dwarf2/dwarf-die7.c (revision 201032)
> +++ gcc.dg/debug/dwarf2/dwarf-die7.c (working copy)
> @@ -1,6 +1,6 @@
> /* Inlined non-inline function must have abstract DIE */
> /* { dg-do compile } */
> -/* { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } */
> +/* { dg-options "-O2 -gdwarf -dA -fpreprocessed" } */
> /* { dg-final { scan-assembler "1.*DW_AT_inline" } } */
> #1 "test.h"
> void f(void);
> Index: gcc.dg/debug/dwarf2/static1.c
> ===
> --- gcc.dg/debug/dwarf2/static1.c (revision 201032)
> +++ gcc.dg/debug/dwarf2/static1.c (working copy)
> @@ -1,5 +1,5 @@
> /* { dg-do compile } */
> -/* { dg-options "-O2 -gdwarf-2" } */
> +/* { dg-options "-O2 -gdwarf" } */
> void
> main(void)
> {
> Index: gcc.dg/debug/dwarf2/dwarf-dfp.c
> ===
> --- gcc.dg/debug/dwarf2/dwarf-dfp.c (revision 201032)
> +++ gcc.dg/debug/dwarf2/dwarf-dfp.c (working copy)
> @@ -2,7 +2,7 @@
>
> /* { dg-do compile */
> /* { dg-require-effective-target dfp } */
> -/* { dg-options "-O0 -gdwa
Re: Ping: testsuite patches ({1,2,6,10,12}/14)
On Aug 14, 2013, at 8:55 AM, Joern Rennecke wrote: > These patches have not been reviewed for more than three weeks: Ok, all should be reviewed now, let us know if there are any missed.
[testsuite] fix directives in gcc.target/arm/atomic-*.c tests
As the test directives section of the GCC internals manual says:
The order in which test directives appear in a test can be important:
directives local to GCC sometimes override information used by the
DejaGnu directives, which know nothing about the GCC directives, so
the DejaGnu directives must precede GCC directives.
This patch fixes several tests in gcc.target/arm to move dg-do to before
dg-require-effective-target so the test will be skipped as expected.
Tested with several sets of flags with arm-none-eabi, checked in as
obvious.
Janis
2013-08-14 Janis Johnson
* gcc.target/arm/atomic-comp-swap-release-acquire.c: Move dg-do
to be the first test directive.
* gcc.target/arm/atomic-op-acq_rel.c: Likewise.
* gcc.target/arm/atomic-op-acquire.c: Likewise.
* gcc.target/arm/atomic-op-char.c: Likewise.
* gcc.target/arm/atomic-op-consume.c: Likewise.
* gcc.target/arm/atomic-op-int.c: Likewise.
* gcc.target/arm/atomic-op-relaxed.c: Likewise.
* gcc.target/arm/atomic-op-release.c: Likewise.
* gcc.target/arm/atomic-op-seq_cst.c: Likewise.
* gcc.target/arm/atomic-op-short.c: Likewise.
Index: testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
===
--- testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c (revision
201513)
+++ testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
/* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_arch_v8a } */
Index: testsuite/gcc.target/arm/atomic-op-acq_rel.c
===
--- testsuite/gcc.target/arm/atomic-op-acq_rel.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-acq_rel.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
/* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_arch_v8a } */
Index: testsuite/gcc.target/arm/atomic-op-acquire.c
===
--- testsuite/gcc.target/arm/atomic-op-acquire.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-acquire.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
/* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_arch_v8a } */
Index: testsuite/gcc.target/arm/atomic-op-char.c
===
--- testsuite/gcc.target/arm/atomic-op-char.c (revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-char.c (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
/* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_arch_v8a } */
Index: testsuite/gcc.target/arm/atomic-op-consume.c
===
--- testsuite/gcc.target/arm/atomic-op-consume.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-consume.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
/* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_arch_v8a } */
Index: testsuite/gcc.target/arm/atomic-op-int.c
===
--- testsuite/gcc.target/arm/atomic-op-int.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-int.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
/* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_arch_v8a } */
Index: testsuite/gcc.target/arm/atomic-op-relaxed.c
===
--- testsuite/gcc.target/arm/atomic-op-relaxed.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-relaxed.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
/* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_arch_v8a } */
Index: testsuite/gcc.target/arm/atomic-op-release.c
===
--- testsuite/gcc.target/arm/atomic-op-release.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-release.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
/* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_arch_v8a } */
Index: testsuite/gcc.target/arm/atomic-op-seq_cst.c
===
--- testsuite/gcc.target/arm/atomic-op-seq_cst.
[testsuite] skip gcc.target/arm/pr19599.c for -mthumb
This patch skips an arm test if the multilib flags include "-mthumb", which would override the "-marm" used for the test. Tested with several sets of flags for arm-none-eabi and checked in as obvious. Janis 2013-04-24 Janis Johnson * arm-none-linux-eabi.inc (print_eembc_scale_factor): decrease for rexella. Index: release-configs/arm-none-linux-eabi.inc === --- release-configs/arm-none-linux-eabi.inc (revision 409607) +++ release-configs/arm-none-linux-eabi.inc (working copy) @@ -51,6 +51,9 @@ (averil*) echo 2 ;; + (rexella*) + echo 2 + ;; (*) echo 100 ;;
Re: testsuite patches (3/14): gcc.dg/c99-stdint-1.c [avr-*-*]: Update line number for dg-bogus.
Ok.
[ minor updates like this can be checked in under the obvious rule if you wish ]
On Jul 19, 2013, at 10:58 PM, Joern Rennecke
wrote:
> Because we now issue the error message for the place of the macro definition,
> the expected line number has to be updated.
>
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-05-26 Joern Rennecke
>
> * gcc.dg/c99-stdint-1.c [avr-*-*]: Update line number for dg-bogus.
>
> Index: gcc.dg/c99-stdint-1.c
> ===
> --- gcc.dg/c99-stdint-1.c (revision 201032)
> +++ gcc.dg/c99-stdint-1.c (working copy)
> @@ -214,7 +214,7 @@ test_max (void)
> void
> test_misc_limits (void)
> {
> -/* { dg-bogus "size" "ptrdiff is 16bits" { xfail avr-*-* } 218 } */
> +/* { dg-bogus "size" "ptrdiff is 16bits" { xfail avr-*-* } 56 } */
> CHECK_SIGNED_LIMITS_2(__PTRDIFF_TYPE__, PTRDIFF_MIN, PTRDIFF_MAX, -65535L,
> 65535L);
> #ifndef SIGNAL_SUPPRESS
> CHECK_LIMITS_2(sig_atomic_t, SIG_ATOMIC_MIN, SIG_ATOMIC_MAX, -127, 127,
> 255);
Re: [RFC] Bare bones of virtual call tracking
On 08/14/2013 02:14 AM, Jan Hubicka wrote: As a temporary hack I suppose I can rely on assembler name of virtual table to be unique for each templated class? Actually, that seems like a fine solution for devirtualization; just compare the mangled name of the vtable to establish type identity. Jason
Re: testsuite patches (5/14): Skip stackalign/builtin-apply-2.c for avr
Ok.
[ be sure to ask Ok? when you would like a review/approval ]
On Jul 19, 2013, at 11:09 PM, Joern Rennecke
wrote:
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-06-24 Joern Rennecke
>
> * gcc.dg/torture/stackalign/builtin-apply-2.c: Also skip for avr.
>
> Index: gcc.dg/torture/stackalign/builtin-apply-2.c
> ===
> --- gcc.dg/torture/stackalign/builtin-apply-2.c (revision 201032)
> +++ gcc.dg/torture/stackalign/builtin-apply-2.c (working copy)
> @@ -6,7 +6,10 @@
>
> /* { dg-do run } */
>
> -/* { dg-skip-if "Variadic funcs use Base AAPCS. Normal funcs use VFP
> variant." { arm_hf_eabi } } */
> +/* arm_hf_eabi: Variadic funcs use Base AAPCS. Normal funcs use VFP variant.
> + avr: Variadic funcs don't pass arguments in registers, while normal funcs
> +do. */
> +/* { dg-skip-if "Variadic funcs use different argument passing from normal
> funcs" { arm_hf_eabi || { avr-*-* } } "*" "" } */
>
>
> #define INTEGER_ARG 5
Re: testsuite patches (7/14): gcc.dg/pr46647.c: xfail for avr*-*-*
Ok. On Jul 22, 2013, at 3:57 AM, Joern Rennecke wrote: > Quoting Georg-Johann Lay : > >> Joern Rennecke wrote: >>> xfail for avr*-*-* >> >> Hi, >> >> the target machine is avr-*-* because, say, avr32 (a 32-bit MCU not >> officially >> supported) is a quite different architecture than avr. >> >> Similar for your other testsuite patches with avr*-*-* > > I have attached amended versions of the patches 7/8/9/14. > > tested for avr using --target_board=atmega128-sim . > >
Re: Ping: [avr] testsuite patches ({3,5,7,8,9,14}/14)
On Aug 14, 2013, at 8:47 AM, Joern Rennecke wrote: > These patches haven't been reviewed for more that three weeks: > > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00808.html > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00811.html > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00906.html Ok, all these should now be reviewed.
Re: [PATCH][i386]Fix PR 57756
On Wed, Aug 14, 2013 at 3:38 AM, Richard Biener
wrote:
> On Wed, Aug 14, 2013 at 2:02 AM, Sriraman Tallam
> wrote:
>>
>> Hi,
>>
>> I have attached a patch to fix PR57756. Description: The
>> following program,
>>
>> __attribute__((always_inline,target("sse4.2")))
>> __inline int callee ()
>> {
>> return 0;
>> }
>>
>> __attribute__((target("sse")))
>> __inline int caller ()
>> {
>> return callee();
>> }
>>
>> does not generate an error and callee is inlined into caller. This is
>> because callee has a higher target ISA. Interchanging the position of
>> caller and callee will generate the correct error. Also, removing the
>> target attribute from caller will generate the error.
>>
>> The reason for the bug is that when the caller's target options are
>> processed, global_options contain the ISA flags of the callee
>> (previously processed) and doing this in i386-common.c, where opts is
>> global_options:
>>
>> opts->x_ix86_isa_flags |= OPTION_MASK_ISA_SSE_SET;
>>
>> is not changing global options. The fix is to reset global_options to
>> the default each time a new target option needs to be processed.
>
>
> Shouldn't ix86_valid_target_attribute_tree be refactored to work on a
> selected
> opt structure rather than global_options?
Yes, that would be the ideal fix. The code here seems hairy and many
functions set and use global_options directly (in the call chain of
ix86_valid_target_attribute_tree). I will take a stab at it.
Thanks
Sri
>
> Richard.
>
>>
>> Patch ok?
>>
>> Thanks
>> Sri
>
>
Re: [PATCH] Fix SRA with volatile loads/stores (PR tree-optimization/58145)
Jakub Jelinek wrote:
>Hi!
>
>On the following testcases we miscompile the code (on -1.c just drop
>= {v} from the statements, on -2.c lim moves the volatile stores after
>the
>loop), because SRA drops the volatileness from the MEM_REF.
>
>SRA generally ignores volatile vars and fields etc., but if we have a
>structure assignment to volatile from non-volatile or vice versa,
>if SRA decides to scalarize rhs resp. lhs, new MEM_REFs are created
>even
>for the volatile access with different type.
>
>The following patch fixes that by propagating TREE_THIS_VOLATILE and
>TREE_SIDE_EFFECTS from the prev_base to the newly created MEM_REF.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>trunk/4.8?
You do not need the volatile qualified type, and IIRC we're not consistent in
setting tree-sideeffects either.
Thus,
Ok with not doing the volatile qualification.
Thanks,
Richard.
>On IRC with Martin we've also discussed slsr in this regard, but that
>seems
>to be fine, it uses the original volatile type if it was volatile and
>propagates TREE_THIS_VOLATILE/TREE_SIDE_EFFECTS flags to the newly
>created
>MEM_REF.
>
>2013-08-14 Jakub Jelinek
>
> PR tree-optimization/58145
> * tree-sra.c (build_ref_for_offset): If base is TREE_THIS_VOLATILE,
> propagate it to exp_type and MEM_REF.
>
> * gcc.dg/pr58145-1.c: New test.
> * gcc.dg/pr58145-2.c: New test.
>
>--- gcc/tree-sra.c.jj 2013-08-14 11:02:55.290711106 +0200
>+++ gcc/tree-sra.c 2013-08-14 12:38:47.405230042 +0200
>@@ -1466,6 +1466,7 @@ build_ref_for_offset (location_t loc, tr
> {
> tree prev_base = base;
> tree off;
>+ tree mem_ref;
> HOST_WIDE_INT base_offset;
> unsigned HOST_WIDE_INT misalign;
> unsigned int align;
>@@ -1515,8 +1516,17 @@ build_ref_for_offset (location_t loc, tr
> align = (misalign & -misalign);
> if (align < TYPE_ALIGN (exp_type))
> exp_type = build_aligned_type (exp_type, align);
>-
>- return fold_build2_loc (loc, MEM_REF, exp_type, base, off);
>+ if (TREE_THIS_VOLATILE (TREE_TYPE (prev_base))
>+ && !TREE_THIS_VOLATILE (exp_type))
>+exp_type = build_qualified_type (exp_type, TYPE_QUALS (exp_type)
>+ | TYPE_QUAL_VOLATILE);
>+
>+ mem_ref = fold_build2_loc (loc, MEM_REF, exp_type, base, off);
>+ if (TREE_THIS_VOLATILE (exp_type) || TREE_THIS_VOLATILE (prev_base))
>+TREE_THIS_VOLATILE (mem_ref) = 1;
>+ if (TREE_SIDE_EFFECTS (prev_base))
>+TREE_SIDE_EFFECTS (mem_ref) = 1;
>+ return mem_ref;
> }
>
>/* Construct a memory reference to a part of an aggregate BASE at the
>given
>--- gcc/testsuite/gcc.dg/pr58145-1.c.jj2013-08-14 12:02:07.077086488
>+0200
>+++ gcc/testsuite/gcc.dg/pr58145-1.c 2013-08-14 12:03:15.895198976
>+0200
>@@ -0,0 +1,37 @@
>+/* PR tree-optimization/58145 */
>+/* { dg-do compile { target { int32plus } } } */
>+/* { dg-options "-O2 -fdump-tree-optimized" } */
>+
>+struct S { unsigned int data : 32; };
>+struct T { unsigned int data; };
>+volatile struct S s2;
>+
>+void
>+f1 (int val)
>+{
>+ struct S s = { .data = val };
>+ *(volatile struct S *) 0x88UL = s;
>+}
>+
>+void
>+f2 (int val)
>+{
>+ struct T t = { .data = val };
>+ *(volatile struct T *) 0x88UL = t;
>+}
>+
>+void
>+f3 (int val)
>+{
>+ *(volatile unsigned int *) 0x88UL = val;
>+}
>+
>+void
>+f4 (int val)
>+{
>+ struct S s = { .data = val };
>+ s2 = s;
>+}
>+
>+/* { dg-final { scan-tree-dump-times " ={v} " 4 "optimized" } } */
>+/* { dg-final { cleanup-tree-dump "optimized" } } */
>--- gcc/testsuite/gcc.dg/pr58145-2.c.jj2013-08-14 12:02:28.409663559
>+0200
>+++ gcc/testsuite/gcc.dg/pr58145-2.c 2013-08-14 12:04:19.471612107
>+0200
>@@ -0,0 +1,51 @@
>+/* PR tree-optimization/58145 */
>+/* { dg-do compile { target { int32plus } } } */
>+/* { dg-options "-O2 -fdump-tree-optimized" } */
>+
>+struct S { unsigned int data : 32; };
>+struct T { unsigned int data; };
>+volatile struct S s2;
>+
>+static inline void
>+f1 (int val)
>+{
>+ struct S s = { .data = val };
>+ *(volatile struct S *) 0x88UL = s;
>+}
>+
>+static inline void
>+f2 (int val)
>+{
>+ struct T t = { .data = val };
>+ *(volatile struct T *) 0x88UL = t;
>+}
>+
>+static inline void
>+f3 (int val)
>+{
>+ *(volatile unsigned int *) 0x88UL = val;
>+}
>+
>+static inline void
>+f4 (int val)
>+{
>+ struct S s = { .data = val };
>+ s2 = s;
>+}
>+
>+void
>+f5 (void)
>+{
>+ int i;
>+ for (i = 0; i < 100; i++)
>+f1 (0);
>+ for (i = 0; i < 100; i++)
>+f2 (0);
>+ for (i = 0; i < 100; i++)
>+f3 (0);
>+ for (i = 0; i < 100; i++)
>+f4 (0);
>+}
>+
>+/* { dg-final { scan-tree-dump-times " ={v} " 4 "optimized" } } */
>+/* { dg-final { cleanup-tree-dump "optimized" } } */
>
> Jakub
Fix potential uninitialized variable error
I committed the following patch as obvious fix.
Index: ChangeLog
===
Index: config/i386/i386.c
===
davidxl@aples2:../tot/gcc\>> svn diff
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 201732)
+++ config/i386/i386.c (working copy)
@@ -2815,7 +2815,7 @@ ix86_parse_stringop_strategy_string (cha
do
{
- int mins, maxs;
+ int mins = 0, maxs;
stringop_alg alg;
char alg_name[128];
char align[16];
Index: ChangeLog
===
--- ChangeLog (revision 201732)
+++ ChangeLog (working copy)
@@ -1,4 +1,8 @@
2013-08-14 Xinliang David Li
+ * config/i386/i386.c (ix86_option_override_internal):
+ Fix potential unitialized variable error.
+
+2013-08-14 Xinliang David Li
* config/i386/i386.opt: Define two new options.
* config/i386/x86-tune.def: Add arch selector field in macros.
Re: Fix potential uninitialized variable error
On Wed, Aug 14, 2013 at 11:12:27AM -0700, Xinliang David Li wrote: > Index: ChangeLog > === > --- ChangeLog (revision 201732) > +++ ChangeLog (working copy) > @@ -1,4 +1,8 @@ > 2013-08-14 Xinliang David Li > + * config/i386/i386.c (ix86_option_override_internal): > + Fix potential unitialized variable error. The CL entry is missing a blank line. Marek
Re: Fix potential uninitialized variable error
On Wed, Aug 14, 2013 at 08:17:55PM +0200, Marek Polacek wrote: > On Wed, Aug 14, 2013 at 11:12:27AM -0700, Xinliang David Li wrote: > > Index: ChangeLog > > === > > --- ChangeLog (revision 201732) > > +++ ChangeLog (working copy) > > @@ -1,4 +1,8 @@ > > 2013-08-14 Xinliang David Li > > + * config/i386/i386.c (ix86_option_override_internal): > > + Fix potential unitialized variable error. > > The CL entry is missing a blank line. Also, the patch is not obvious. The uninitialization is not potential, it is unconditional for n == 0, but more importantly, nothing ever uses input_ranges[...].min field, so it is clearly a write only field and thus IMHO should be dropped altogether together with the mins variable. Jakub
Re: Fix potential uninitialized variable error
Ok. Will drop it in the next patch. David On Wed, Aug 14, 2013 at 11:23 AM, Jakub Jelinek wrote: > On Wed, Aug 14, 2013 at 08:17:55PM +0200, Marek Polacek wrote: >> On Wed, Aug 14, 2013 at 11:12:27AM -0700, Xinliang David Li wrote: >> > Index: ChangeLog >> > === >> > --- ChangeLog (revision 201732) >> > +++ ChangeLog (working copy) >> > @@ -1,4 +1,8 @@ >> > 2013-08-14 Xinliang David Li >> > + * config/i386/i386.c (ix86_option_override_internal): >> > + Fix potential unitialized variable error. >> >> The CL entry is missing a blank line. > > Also, the patch is not obvious. The uninitialization is not potential, it > is unconditional for n == 0, but more importantly, nothing ever uses > input_ranges[...].min field, so it is clearly a write only field and thus > IMHO should be dropped altogether together with the mins variable. > > Jakub
Re: [PATCH][4.8 backport] S/390: Transactional Execution support
On 14/08/13 15:00, Jakub Jelinek wrote: > On Thu, Aug 01, 2013 at 10:55:15AM +0200, Andreas Krebbel wrote: >> I would like to apply backports of the TX support patches to 4.8 >> branch. We released 4.8 with EC12 support already but the support is >> somewhat incomplete without having TX. With these patches we will >> have full EC12 support in 4.8. > > In your backport you've forgot to include the libitm/config/s390 > directory, so I guess it is broken on 4.8 branch even more than it is on the > trunk (the pending -msoft-float issue). Fixed. -Andreas-
[C++ Patch /RFC] PR 51912
Hi all, Jason,
thus, per the notes I left on the audit trail some time ago, this seems
to me a possible approach to reject this kind of invalid code. What do
you think?
Booted & tested x86_64-linux.
Thanks,
Paolo.
//
Index: cp/call.c
===
--- cp/call.c (revision 201731)
+++ cp/call.c (working copy)
@@ -1314,7 +1314,8 @@ standard_conversion (tree to, tree from, tree expr
/* As an extension, allow conversion to complex type. */
else if (ARITHMETIC_TYPE_P (to))
{
- if (! (INTEGRAL_CODE_P (fcode) || fcode == REAL_TYPE)
+ if (! (INTEGRAL_CODE_P (fcode)
+|| (fcode == REAL_TYPE && !(flags & LOOKUP_NO_NON_INTEGRAL)))
|| SCOPED_ENUM_P (from))
return NULL;
conv = build_conv (ck_std, to, conv);
@@ -1681,7 +1682,7 @@ implicit_conversion (tree to, tree from, tree expr
resolution, or after we've chosen one. */
flags &= (LOOKUP_ONLYCONVERTING|LOOKUP_NO_CONVERSION|LOOKUP_COPY_PARM
|LOOKUP_NO_TEMP_BIND|LOOKUP_NO_RVAL_BIND|LOOKUP_PREFER_RVALUE
- |LOOKUP_NO_NARROWING|LOOKUP_PROTECT);
+ |LOOKUP_NO_NARROWING|LOOKUP_PROTECT|LOOKUP_NO_NON_INTEGRAL);
/* FIXME: actually we don't want warnings either, but we can't just
have 'complain &= ~(tf_warning|tf_error)' because it would cause
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 201731)
+++ cp/cp-tree.h(working copy)
@@ -4510,6 +4510,8 @@ enum overload_flags { NO_SPECIAL = 0, DTOR_FLAG, T
#define LOOKUP_EXPLICIT_TMPL_ARGS (LOOKUP_ALREADY_DIGESTED << 1)
/* Like LOOKUP_NO_TEMP_BIND, but also prevent binding to xvalues. */
#define LOOKUP_NO_RVAL_BIND (LOOKUP_EXPLICIT_TMPL_ARGS << 1)
+/* Used in case_conversion. */
+#define LOOKUP_NO_NON_INTEGRAL (LOOKUP_NO_RVAL_BIND << 1)
#define LOOKUP_NAMESPACES_ONLY(F) \
(((F) & LOOKUP_PREFER_NAMESPACES) && !((F) & LOOKUP_PREFER_TYPES))
Index: cp/decl.c
===
--- cp/decl.c (revision 201731)
+++ cp/decl.c (working copy)
@@ -3103,7 +3103,9 @@ case_conversion (tree type, tree value)
{
if (INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (type))
type = type_promotes_to (type);
- value = perform_implicit_conversion (type, value, tf_warning_or_error);
+ value = (perform_implicit_conversion_flags
+ (type, value, tf_warning_or_error,
+ LOOKUP_IMPLICIT | LOOKUP_NO_NON_INTEGRAL));
}
return cxx_constant_value (value);
}
Index: testsuite/g++.dg/cpp0x/enum15.C
===
--- testsuite/g++.dg/cpp0x/enum15.C (revision 201726)
+++ testsuite/g++.dg/cpp0x/enum15.C (working copy)
@@ -15,6 +15,6 @@ void foo (A a, int i)
{
case A::Val0: break; // { dg-error "" }
case 1: break;
-case 2.0: break;
+case 2.0: break;// { dg-error "" }
}
}
Index: testsuite/g++.dg/cpp0x/enum28.C
===
--- testsuite/g++.dg/cpp0x/enum28.C (revision 0)
+++ testsuite/g++.dg/cpp0x/enum28.C (working copy)
@@ -0,0 +1,17 @@
+// PR c++/51912
+// { dg-do compile { target c++11 } }
+
+constexpr double g() { return 2.0; }
+
+void f(int i)
+{
+ switch (i)
+{
+case 1.0:;// { dg-error "could not convert" }
+}
+
+ switch (i)
+{
+case g():;// { dg-error "could not convert" }
+}
+}
Re: [PATCH, vtv update] Change fixed size array to a vector; fix diagnostic messages.
Ping? On Thu, Aug 8, 2013 at 3:16 PM, Caroline Tice wrote: > This patch replaces the fixed sized array that was holding vtable > pointers for a particular class hierarchy with a vector, allowing for > dynamic resizing. It also fixes issues with the warning diagnostics. > I am in the process of running regression tests with this patch; > assuming they all pass, is this patch OK to commit? > > -- Caroline Tice > cmt...@google.com > > 2013-08-08 Caroline Tice > > * vtable-class-hierarchy.c: Remove unnecessary include statements. > (MAX_SET_SIZE): Remove unnecessary constant. > (register_construction_vtables): Make vtable_ptr_array parameter > into a vector; remove num_args parameter. Change array accesses to > vector accesses. > (register_other_binfo_vtables): Ditto. > (insert_call_to_register_set): Ditto. > (insert_call_to_register_pair): Ditto. > (output_set_info): Ditto. Also change warning calls to warning_at > calls, and fix format of warning messages. > (register_all_pairs): Change vtbl_ptr_array from an array into a > vector. Remove num_vtable_args (replace with calls to vector length). > Change array stores & accesses to vector functions. Change calls to > register_construction_vtables, register_other_binfo_vtables, > insert_call_to_register_set, insert_call_to_register_pair and > output_set_info to match their new signatures. Change warning to > warning_at and fix the format of the warning message.
RFA: Testsuite patch: request dwarf output where needed (Was: Re: testsuite patches (1/14): Request dwarf-2 output where needed)
Quoting Jakub Jelinek :
On Mon, Jul 22, 2013 at 10:31:03AM +0530, Senthil Kumar Selvaraj wrote:
On Sat, Jul 20, 2013 at 01:45:37AM -0400, Joern Rennecke wrote:
> Although the gcc.dg/debug/dwarf2/dwarf2.exp generally requests dwarf-2
> information, so that the test will work with targets that have a different
> default output format, that doesn't happen where the test
specifies specific
> target options. In that case, we have to specify -gdwarf-2 in
the individual
> test case.
I ran into this problem a while ago, and after discussion on the
mailing list, added a -gdwarf option to emit DWARF with the default
version (http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00592.html). Might
be better than hardcoding dwarf-2 IMO.
Yeah, definitely.
Jakub
Here is the patch, amended to use -gdwarf.
Tested on i686-pc-linux-gnu.
Ok to apply?
2013-08-14 Joern Rennecke
* gcc.dg/debug/dwarf2/global-used-types.c: Request dwarf output.
* gcc.dg/debug/dwarf2/inline2.c: Likewise.
* gcc.dg/debug/dwarf2/inline3.c: Likewise.
* gcc.dg/debug/dwarf2/pr37726.c: Likewise.
* gcc.dg/debug/dwarf2/pr41445-1.c: Likewise.
* gcc.dg/debug/dwarf2/pr41445-2.c: Likewise.
* gcc.dg/debug/dwarf2/pr41445-3.c: Likewise.
* gcc.dg/debug/dwarf2/pr41445-4.c: Likewise.
* gcc.dg/debug/dwarf2/pr41445-5.c: Likewise.
* gcc.dg/debug/dwarf2/pr41445-6.c: Likewise.
* gcc.dg/debug/dwarf2/pr41543.c: Likewise.
* gcc.dg/debug/dwarf2/pr41695.c: Likewise.
* gcc.dg/debug/dwarf2/pr43237.c: Likewise.
* gcc.dg/debug/dwarf2/pr47939-1.c: Likewise.
* gcc.dg/debug/dwarf2/pr47939-2.c: Likewise.
* gcc.dg/debug/dwarf2/pr47939-3.c: Likewise.
* gcc.dg/debug/dwarf2/pr47939-4.c: Likewise.
* gcc.dg/debug/dwarf2/pr53948.c: Likewise.
* gcc.dg/debug/dwarf2/struct-loc1.c: Likewise.
Index: gcc.dg/debug/dwarf2/global-used-types.c
===
--- gcc.dg/debug/dwarf2/global-used-types.c (revision 201032)
+++ gcc.dg/debug/dwarf2/global-used-types.c (working copy)
@@ -1,6 +1,6 @@
/*
Contributed by Dodji Seketeli
- { dg-options "-g -dA -fno-merge-debug-strings" }
+ { dg-options "-gdwarf -dA -fno-merge-debug-strings" }
{ dg-do compile }
{ dg-final { scan-assembler-times "DIE \\(0x\[^\n\]*\\)
DW_TAG_enumeration_type" 1 } }
{ dg-final { scan-assembler-times "DIE \\(0x\[^\n\]*\\) DW_TAG_enumerator" 2
} }
Index: gcc.dg/debug/dwarf2/inline2.c
===
--- gcc.dg/debug/dwarf2/inline2.c (revision 201032)
+++ gcc.dg/debug/dwarf2/inline2.c (working copy)
@@ -14,7 +14,7 @@
properly nested DW_TAG_inlined_subroutine DIEs for third, second and first.
*/
-/* { dg-options "-O -g3 -dA" } */
+/* { dg-options "-O -g3 -gdwarf -dA" } */
/* { dg-do compile } */
/* There are 6 inlined subroutines:
Index: gcc.dg/debug/dwarf2/inline3.c
===
--- gcc.dg/debug/dwarf2/inline3.c (revision 201032)
+++ gcc.dg/debug/dwarf2/inline3.c (working copy)
@@ -1,7 +1,7 @@
/* Verify that only one DW_AT_const_value is emitted for baz,
not for baz abstract DIE and again inside of
DW_TAG_inlined_subroutine. */
-/* { dg-options "-O2 -g -dA -fmerge-all-constants" } */
+/* { dg-options "-O2 -gdwarf -dA -fmerge-all-constants" } */
/* { dg-do compile } */
/* { dg-final { scan-assembler-times " DW_AT_const_value" 1 } } */
Index: gcc.dg/debug/dwarf2/pr37726.c
===
--- gcc.dg/debug/dwarf2/pr37726.c (revision 201032)
+++ gcc.dg/debug/dwarf2/pr37726.c (working copy)
@@ -1,6 +1,6 @@
/* PR debug/37726 */
/* { dg-do compile } */
-/* { dg-options "-g -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-gdwarf -O0 -dA -fno-merge-debug-strings" } */
int foo (int parm)
{
Index: gcc.dg/debug/dwarf2/pr41445-1.c
===
--- gcc.dg/debug/dwarf2/pr41445-1.c (revision 201032)
+++ gcc.dg/debug/dwarf2/pr41445-1.c (working copy)
@@ -2,7 +2,7 @@
/* Test that token after multi-line function-like macro use
gets correct locus even when preprocessing separately. */
/* { dg-do compile } */
-/* { dg-options "-save-temps -g -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-save-temps -gdwarf -O0 -dA -fno-merge-debug-strings" } */
#define A(a,b)
int varh;A(1,
Index: gcc.dg/debug/dwarf2/pr41445-2.c
===
--- gcc.dg/debug/dwarf2/pr41445-2.c (revision 201032)
+++ gcc.dg/debug/dwarf2/pr41445-2.c (working copy)
@@ -1,6 +1,6 @@
/* PR preprocessor/41445 */
/* { dg-do compile } */
-/* { dg-options "-g -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-gdwarf -O0 -dA -fno-merge-debug-strings" } */
#include "pr41445-1
Re: [C++ Patch /RFC] PR 51912
On 08/14/2013 03:20 PM, Paolo Carlini wrote: +/* Used in case_conversion. */ Also say what it means. OK with that change. Jason
Re: RFA: Testsuite patch: request dwarf output where needed (Was: Re: testsuite patches (1/14): Request dwarf-2 output where needed)
On Wed, Aug 14, 2013 at 03:29:21PM -0400, Joern Rennecke wrote: > Ok to apply? Yes, thanks. > 2013-08-14 Joern Rennecke > > * gcc.dg/debug/dwarf2/global-used-types.c: Request dwarf output. > * gcc.dg/debug/dwarf2/inline2.c: Likewise. > * gcc.dg/debug/dwarf2/inline3.c: Likewise. > * gcc.dg/debug/dwarf2/pr37726.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-1.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-2.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-3.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-4.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-5.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-6.c: Likewise. > * gcc.dg/debug/dwarf2/pr41543.c: Likewise. > * gcc.dg/debug/dwarf2/pr41695.c: Likewise. > * gcc.dg/debug/dwarf2/pr43237.c: Likewise. > * gcc.dg/debug/dwarf2/pr47939-1.c: Likewise. > * gcc.dg/debug/dwarf2/pr47939-2.c: Likewise. > * gcc.dg/debug/dwarf2/pr47939-3.c: Likewise. > * gcc.dg/debug/dwarf2/pr47939-4.c: Likewise. > * gcc.dg/debug/dwarf2/pr53948.c: Likewise. > * gcc.dg/debug/dwarf2/struct-loc1.c: Likewise. Jakub
Re: RFA: Testsuite patch: request dwarf output where needed (Was: Re: testsuite patches (1/14): Request dwarf-2 output where needed)
On Aug 14, 2013, at 12:29 PM, Joern Rennecke wrote: > Ok to apply? Ok. > 2013-08-14 Joern Rennecke > > * gcc.dg/debug/dwarf2/global-used-types.c: Request dwarf output. > * gcc.dg/debug/dwarf2/inline2.c: Likewise. > * gcc.dg/debug/dwarf2/inline3.c: Likewise. > * gcc.dg/debug/dwarf2/pr37726.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-1.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-2.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-3.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-4.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-5.c: Likewise. > * gcc.dg/debug/dwarf2/pr41445-6.c: Likewise. > * gcc.dg/debug/dwarf2/pr41543.c: Likewise. > * gcc.dg/debug/dwarf2/pr41695.c: Likewise. > * gcc.dg/debug/dwarf2/pr43237.c: Likewise. > * gcc.dg/debug/dwarf2/pr47939-1.c: Likewise. > * gcc.dg/debug/dwarf2/pr47939-2.c: Likewise. > * gcc.dg/debug/dwarf2/pr47939-3.c: Likewise. > * gcc.dg/debug/dwarf2/pr47939-4.c: Likewise. > * gcc.dg/debug/dwarf2/pr53948.c: Likewise. > * gcc.dg/debug/dwarf2/struct-loc1.c: Likewise.
RE: Ping: [avr] testsuite patches ({3,5,7,8,9,14}/14)
> -Original Message-
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Wednesday, August 14, 2013 8:48 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Anatoly Sokolov; Weddington, Eric
> Subject: Ping: [avr] testsuite patches ({3,5,7,8,9,14}/14)
>
> These patches haven't been reviewed for more that three weeks:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00808.html
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00811.html
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00906.html
All approved.
Thanks, Joern.
Eric
[PATCH, gcc-4_8-branch] Fix the issue of incorrectly using #ifdef HAVE_ATTR_enabled
Hi, Jakub,
According to this discussion thread:
http://gcc.gnu.org/ml/gcc/2013-08/msg00142.html
The bug that David mentioned has been fixed on trunk but not on 4.8 branch.
IMHO it would be a good idea to backport it and Vladmir agreed with that.
The patch and a plaintext ChangeLog are as follow.
Bootstraped and regtested on x86_64-unknown-linux-gnu.
Is it OK to backport it into gcc-4_8-branch?
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 201718)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2013-08-14 David Given
+
+ Backport from mainline
+ 2013-04-26 Vladimir Makarov
+
+ * lra-constraints.c (process_alt_operands): Use #if HAVE_ATTR_enable
+ instead of #ifdef.
+
2013-08-13 Jakub Jelinek
PR sanitizer/56417
Index: gcc/lra-constraints.c
===
--- gcc/lra-constraints.c (revision 201718)
+++ gcc/lra-constraints.c (working copy)
@@ -1388,7 +1388,7 @@
for (nalt = 0; nalt < n_alternatives; nalt++)
{
/* Loop over operands for one constraint alternative. */
-#ifdef HAVE_ATTR_enabled
+#if HAVE_ATTR_enabled
if (curr_id->alternative_enabled_p != NULL
&& ! curr_id->alternative_enabled_p[nalt])
continue;
Best regards,
jasonwucj
Re: [PATCH, gcc-4_8-branch] Fix the issue of incorrectly using #ifdef HAVE_ATTR_enabled
On Thu, Aug 15, 2013 at 04:09:18AM +0800, Chung-Ju Wu wrote: > According to this discussion thread: > http://gcc.gnu.org/ml/gcc/2013-08/msg00142.html > > The bug that David mentioned has been fixed on trunk but not on 4.8 branch. > IMHO it would be a good idea to backport it and Vladmir agreed with that. Generally maintainers can ack backports to release branches, RM ack isn't needed, unless the branch is frozen. This is ok. Jakub
Re: [PATCH, PowerPC] Fix PR57949 (ABI alignment issue)
On Wed, Aug 14, 2013 at 11:32 AM, Bill Schmidt wrote: > Bootstrapped and tested on powerpc64-unknown-linux-gnu with no > regressions. Ok for trunk? > > Thanks, > Bill > > > gcc: > > 2013-08-14 Bill Schmidt > > PR target/57949 > * doc/invoke.texi: Add documentation of mcompat-align-parm > option. > * config/rs6000/rs6000.opt: Add mcompat-align-parm option. > * config/rs6000/rs6000.c (rs6000_function_arg_boundary): For AIX > and Linux, correct BLKmode alignment when 128-bit alignment is > required and compatibility flag is not set. > (rs6000_gimplify_va_arg): For AIX and Linux, honor specified > alignment for zero-size arguments when compatibility flag is not > set. > > gcc/testsuite: > > 2013-08-14 Bill Schmidt > > PR target/57949 > * gcc.target/powerpc/pr57949-1.c: New. > * gcc.target/powerpc/pr57949-2.c: New. I don't have any better suggestion on the option name. LGTM. Thanks, David
Re: Fix potential uninitialized variable error
Here is the clean up patch. Ok for trunk?
thanks,
David
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 201735)
+++ config/i386/i386.c (working copy)
@@ -2792,7 +2792,6 @@ static const char *stringop_alg_names[]
struct stringop_size_range
{
- int min;
int max;
stringop_alg alg;
bool noalign;
@@ -2815,7 +2814,7 @@ ix86_parse_stringop_strategy_string (cha
do
{
- int mins = 0, maxs;
+ int maxs;
stringop_alg alg;
char alg_name[128];
char align[16];
@@ -2831,7 +2830,7 @@ ix86_parse_stringop_strategy_string (cha
return;
}
- if (n > 0 && (maxs < (mins = input_ranges[n - 1].max + 1) && maxs != -1))
+ if (n > 0 && (maxs < (input_ranges[n - 1].max + 1) && maxs != -1))
{
error ("size ranges of option %s should be increasing",
is_memset ? "-mmemset_strategy=" : "-mmemcpy_strategy=");
@@ -2855,7 +2854,6 @@ ix86_parse_stringop_strategy_string (cha
return;
}
- input_ranges[n].min = mins;
input_ranges[n].max = maxs;
input_ranges[n].alg = alg;
if (!strcmp (align, "align"))
Index: ChangeLog
===
--- ChangeLog (revision 201735)
+++ ChangeLog (working copy)
@@ -1,6 +1,12 @@
2013-08-14 Xinliang David Li
+
+ * config/i386/i386.c (ix86_option_override_internal):
+ Remove unused variable and field.
+
+2013-08-14 Xinliang David Li
+
* config/i386/i386.c (ix86_option_override_internal):
- Fix potential unitialized variable error.
+ Fix uninitialized variable error.
2013-08-14 Xinliang David Li
On Wed, Aug 14, 2013 at 11:23 AM, Jakub Jelinek wrote:
> On Wed, Aug 14, 2013 at 08:17:55PM +0200, Marek Polacek wrote:
>> On Wed, Aug 14, 2013 at 11:12:27AM -0700, Xinliang David Li wrote:
>> > Index: ChangeLog
>> > ===
>> > --- ChangeLog (revision 201732)
>> > +++ ChangeLog (working copy)
>> > @@ -1,4 +1,8 @@
>> > 2013-08-14 Xinliang David Li
>> > + * config/i386/i386.c (ix86_option_override_internal):
>> > + Fix potential unitialized variable error.
>>
>> The CL entry is missing a blank line.
>
> Also, the patch is not obvious. The uninitialization is not potential, it
> is unconditional for n == 0, but more importantly, nothing ever uses
> input_ranges[...].min field, so it is clearly a write only field and thus
> IMHO should be dropped altogether together with the mins variable.
>
> Jakub
Re: Fix potential uninitialized variable error
On Wed, Aug 14, 2013 at 01:50:31PM -0700, Xinliang David Li wrote:
> Here is the clean up patch. Ok for trunk?
Ok.
> --- config/i386/i386.c (revision 201735)
> +++ config/i386/i386.c (working copy)
> @@ -2792,7 +2792,6 @@ static const char *stringop_alg_names[]
>
> struct stringop_size_range
> {
> - int min;
>int max;
>stringop_alg alg;
>bool noalign;
> @@ -2815,7 +2814,7 @@ ix86_parse_stringop_strategy_string (cha
>
>do
> {
> - int mins = 0, maxs;
> + int maxs;
>stringop_alg alg;
>char alg_name[128];
>char align[16];
> @@ -2831,7 +2830,7 @@ ix86_parse_stringop_strategy_string (cha
>return;
> }
>
> - if (n > 0 && (maxs < (mins = input_ranges[n - 1].max + 1) && maxs !=
> -1))
> + if (n > 0 && (maxs < (input_ranges[n - 1].max + 1) && maxs != -1))
> {
>error ("size ranges of option %s should be increasing",
> is_memset ? "-mmemset_strategy=" : "-mmemcpy_strategy=");
> @@ -2855,7 +2854,6 @@ ix86_parse_stringop_strategy_string (cha
>return;
> }
>
> - input_ranges[n].min = mins;
>input_ranges[n].max = maxs;
>input_ranges[n].alg = alg;
>if (!strcmp (align, "align"))
Jakub
Re: [PATCH] S/390: Hardware transactional memory support
On 02/08/13 23:05, Richard Henderson wrote:
> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
>> ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
>
> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
> floating point registers; similarly for the write accessors.
Right. I've reverted that change on mainline and 4.8 branch.
Bye,
-Andreas-
Re: [PATCH] S/390: Hardware transactional memory support
On 14/08/13 17:33, Richard Henderson wrote: > On 08/14/2013 05:44 AM, Torvald Riegel wrote: >> Can we instead move the successful path of the HTM fastpath to the >> _ITM_beginTransaction asm function, and just do the fallback and retry >> code in beginend.cc? > > Certainly, but this seems like a larger re-design, and I was thinking of > a shorter-term solution. > Before http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00820.html no FPR appears to be used as GPR save slot. So it should be safe for 4.8 branch. Skimming through the EC12 compiled libitm.so disassembly all FPR uses appear to be limited to the ITM_* accessor functions. I think 4.8 should be ok as is and we perhaps could go with the patches from Andi for mainline? Bye, -Andreas-
[patch, Fortran] PR 58146, enable array slice compile-time bounds checking
Hello world,
the attached patch enables more sophisticated bounds-checking on
array slices by using gfc_dep_difference to calculate extents.
The information may also be useful in other places of the
front end, I don't really know.
There is one wrinkle (alluded to in the comments) which makes
this harder. When somebody changes the value of a variable
used in detemining the size of an array, such as
subroutine foo(a,n)
real, dimension(n) :: a
n = n -2
print *,ubound(a(n-1:))
we cannot compare n-1 against n and think that their difference is
one :-(
This is why I restricted myself to expressions where all
indices are specified, e.g. in a(n+1:n+4) or none are specified,
as in a(:).
In order for this to work on 64-bit systems, it was necessary
to look through widening integer conversions, so I added that
functionality to discard_nops. Using this function in
gfc_dep_compare_expr made this function shorter and cleaner.
Regression-tested. OK for trunk?
Thomas
2013-08-14 Thomas Koenig
PR fortran/58146
* array.c (gfc_ref_dimen_size): If possible, use
gfc_dep_difference to calculate array refrence
sizes. Fall back to integer code otherwise.
* dependency.c (discard_nops). Move up.
Also discarde widening integer conversions.
(gfc_dep_compare_expr): Use discard_nops.
2013-08-14 Thomas Koenig
PR fortran/58146
* gfortran.dg/bounds_check_18.f90: New test.
Index: array.c
===
--- array.c (Revision 201648)
+++ array.c (Arbeitskopie)
@@ -2112,6 +2112,7 @@ bool
gfc_ref_dimen_size (gfc_array_ref *ar, int dimen, mpz_t *result, mpz_t *end)
{
mpz_t upper, lower, stride;
+ mpz_t diff;
bool t;
if (dimen < 0 || ar == NULL || dimen > ar->dimen - 1)
@@ -2130,9 +2131,63 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen,
break;
case DIMEN_RANGE:
+
+ mpz_init (stride);
+
+ if (ar->stride[dimen] == NULL)
+ mpz_set_ui (stride, 1);
+ else
+ {
+ if (ar->stride[dimen]->expr_type != EXPR_CONSTANT)
+ {
+ mpz_clear (stride);
+ return false;
+ }
+ mpz_set (stride, ar->stride[dimen]->value.integer);
+ }
+
+ /* Calculate the number of elements via gfc_dep_differce, but only if
+ start and end are both supplied in the reference or the array spec.
+ This is to guard against strange but valid code like
+
+ subroutine foo(a,n)
+ real a(1:n)
+ n = 3
+ print *,size(a(n-1:))
+
+ where the user changes the value of a variable. If we have to
+ determine end as well, we cannot do this using gfc_dep_difference.
+ Fall back to the constants-only code then. */
+
+ if (end == NULL)
+ {
+ bool use_dep;
+
+ use_dep = gfc_dep_difference (ar->end[dimen], ar->start[dimen],
+ &diff);
+ if (!use_dep && ar->end[dimen] == NULL && ar->start[dimen] == NULL)
+ use_dep = gfc_dep_difference (ar->as->upper[dimen],
+ ar->as->lower[dimen], &diff);
+
+ if (use_dep)
+ {
+ mpz_init (*result);
+ mpz_add (*result, diff, stride);
+ mpz_div (*result, *result, stride);
+ if (mpz_cmp_ui (*result, 0) < 0)
+ mpz_set_ui (*result, 0);
+
+ mpz_clear (stride);
+ mpz_clear (diff);
+ return true;
+ }
+
+ }
+
+ /* Constant-only code here, which covers more cases
+ like a(:4) etc. */
mpz_init (upper);
mpz_init (lower);
- mpz_init (stride);
t = false;
if (ar->start[dimen] == NULL)
@@ -2163,15 +2218,6 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen,
mpz_set (upper, ar->end[dimen]->value.integer);
}
- if (ar->stride[dimen] == NULL)
- mpz_set_ui (stride, 1);
- else
- {
- if (ar->stride[dimen]->expr_type != EXPR_CONSTANT)
- goto cleanup;
- mpz_set (stride, ar->stride[dimen]->value.integer);
- }
-
mpz_init (*result);
mpz_sub (*result, upper, lower);
mpz_add (*result, *result, stride);
Index: dependency.c
===
--- dependency.c (Revision 201648)
+++ dependency.c (Arbeitskopie)
@@ -240,6 +240,46 @@ gfc_dep_compare_functions (gfc_expr *e1, gfc_expr
return -2;
}
+/* Helper function to look through parens, unary plus and widening
+ integer conversions. */
+
+static gfc_expr*
+discard_nops (gfc_expr *e)
+{
+ gfc_actual_arglist *arglist;
+
+ if (e == NULL)
+return NULL;
+
+ while (true)
+{
+ if (e->expr_type == EXPR_OP
+ && (e->value.op.op == INTRINSIC_UPLUS
+ || e->value.op.op == INTRINSIC_PARENTHESES))
+ {
+ e = e->value.op.op1;
+ continue;
+ }
+
+ if (e->expr_type == EXPR_FUNCTION && e->value.function.isym
+ && e->value.function.isym->id == GFC_ISYM_CONVERSION
+ && e->ts.type == BT_INTEGER)
+ {
+ arglist = e->value.function.actual;
+ if (arglist->expr->ts.type == BT_INTEGER
+ && e->ts.kind > arglist->expr->ts.kind)
+ {
+ e = arglist->expr;
+ c
[PATCH, powerpc] PR 58160 -- fix power8 gpr load fusion to be safer
In running the spec 2006 testsuite with several options, we discovered that
-mtune=power8 (which turns on the -mpower8-fusion option) has a segmentation
fault in two benchmarks:
403.gcc when built with -O2 -mcpu=power7 -mtune=power8 -m32
435.gromacs when built with -O3 -funroll-loops -mcpu=power7 -mtune=power8 -m32
In the gcc case, I tracked it down to the fusion op in the function
strength_reduce in the file loop.c. It was wanting to use the result of the
addis instruction after the loop.
It wanted to optimize:
lis 10,loop_dump_stream@ha
lwz 6,loop_dump_stream@l(6)
stw 10,24(1)
to:
lis 6,loop_dump_stream@ha
lwz 6,loop_dump_stream@l(6)
stw 10,24(1)
The problem is fusion was implemented using define_peephole, and the register
live notes are not correct when peepholes are done.
I have written the following patch, and bootstrapped the compiler using
BOOT_CFLAGS='-g -O2 -mcpu=power7 -mtune=power8' to stress the code. There were
no regressions in make check. Are these patches ok to install in the tree?
I have the code for the function that causes the problem narrowed down to the
function that generates the bad code. However, I'm worried that this test will
be very fragile, and it will need to be updated as the compiler changes.
The compiler should be fixed so that it won't be tempted to spill the ELF_HIGH
for the addis on the stack, so that in the future, it could safely fusion the
addis and load operation.
[gcc]
2013-08-14 Michael Meissner
PR target/58160
* config/rs6000/predicates.md (fusion_gpr_mem_load): Allow the
memory rtx to contain ZERO_EXTEND and SIGN_EXTEND.
* config/rs6000/rs6000-protos.h (fusion_gpr_load_p): Pass operands
array instead of each individual operand as a separate argument.
(emit_fusion_gpr_load): Likewise.
(expand_fusion_gpr_load): Add new function declaration.
* config/rs6000/rs6000.c (fusion_gpr_load_p): Change the calling
signature to have the operands passed as an array, instead of as
separate arguments. Allow ZERO_EXTEND to be in the memory
address, and also SIGN_EXTEND if -mpower8-fusion-sign. Do not
depend on the register live/dead flags when peepholes are run.
(expand_fusion_gpr_load): New function to be called from the
peephole2 pass, to change the register that addis sets to be the
target register.
(emit_fusion_gpr_load): Change the calling signature to have the
operands passed as an array, instead of as separate arguments.
Allow ZERO_EXTEND to be in the memory address, and also
SIGN_EXTEND if -mpower8-fusion-sign.
* config/rs6000/rs6000.md (UNSPEC_FUSION_GPR): Delete unused
unspec enumeration.
(power8 fusion peephole/peephole2): Rework the fusion peepholes to
adjust the register addis loads up in the peephole2 pass. Do not
depend on the register live/dead state when the peephole pass is
done.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 201670)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -1740,10 +1740,18 @@ (define_predicate "fusion_gpr_addis"
;; Match the second insn (lbz, lhz, lwz, ld) in fusing the combination of addis
;; and loads to GPR registers on power8.
(define_predicate "fusion_gpr_mem_load"
- (match_code "mem")
+ (match_code "mem,sign_extend,zero_extend")
{
rtx addr;
+ /* Handle sign/zero extend. */
+ if (GET_CODE (op) == ZERO_EXTEND
+ || (TARGET_P8_FUSION_SIGN && GET_CODE (op) == SIGN_EXTEND))
+{
+ op = XEXP (op, 0);
+ mode = GET_MODE (op);
+}
+
if (!MEM_P (op))
return 0;
Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h (revision 201670)
+++ gcc/config/rs6000/rs6000-protos.h (working copy)
@@ -73,8 +73,9 @@ extern int mems_ok_for_quad_peep (rtx, r
extern bool gpr_or_gpr_p (rtx, rtx);
extern bool direct_move_p (rtx, rtx);
extern bool quad_load_store_p (rtx, rtx);
-extern bool fusion_gpr_load_p (rtx, rtx, rtx, rtx, rtx);
-extern const char *emit_fusion_gpr_load (rtx, rtx, rtx, rtx);
+extern bool fusion_gpr_load_p (rtx *, bool);
+extern void expand_fusion_gpr_load (rtx *);
+extern const char *emit_fusion_gpr_load (rtx *);
extern enum reg_class (*rs6000_preferred_reload_class_ptr) (rtx,
enum reg_class);
extern enum reg_class (*rs6000_secondary_reload_class_ptr) (enum reg_class,
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 20167
Re: [PATCH, powerpc] PR 58160 -- fix power8 gpr load fusion to be safer
On Wed, Aug 14, 2013 at 06:55:26PM -0400, Michael Meissner wrote: > In running the spec 2006 testsuite with several options, we discovered that > -mtune=power8 (which turns on the -mpower8-fusion option) has a segmentation > fault in two benchmarks: > > 403.gcc when built with -O2 -mcpu=power7 -mtune=power8 -m32 > 435.gromacs when built with -O3 -funroll-loops -mcpu=power7 -mtune=power8 -m32 > > In the gcc case, I tracked it down to the fusion op in the function > strength_reduce in the file loop.c. It was wanting to use the result of the > addis instruction after the loop. Reminds me of PR57281/PR57300 on i?86/s390, where it was trying to check for dead registers in splitters instead of peephole, but otherwise was similar. Peephole2 is the pass which guarantees the note problem is computed and you can use peep2_reg_dead_p etc. safely, you can't use that in peephole or splitter patterns, and as computing it is expensive, it can't be easily available in too many passes. Jakub
Re: [PATCH, powerpc] PR 58160 -- fix power8 gpr load fusion to be safer
On Thu, Aug 15, 2013 at 01:18:00AM +0200, Jakub Jelinek wrote: > On Wed, Aug 14, 2013 at 06:55:26PM -0400, Michael Meissner wrote: > > In running the spec 2006 testsuite with several options, we discovered that > > -mtune=power8 (which turns on the -mpower8-fusion option) has a segmentation > > fault in two benchmarks: > > > > 403.gcc when built with -O2 -mcpu=power7 -mtune=power8 -m32 > > 435.gromacs when built with -O3 -funroll-loops -mcpu=power7 -mtune=power8 > > -m32 > > > > In the gcc case, I tracked it down to the fusion op in the function > > strength_reduce in the file loop.c. It was wanting to use the result of the > > addis instruction after the loop. > > Reminds me of PR57281/PR57300 on i?86/s390, where it was trying to check for > dead registers in splitters instead of peephole, but otherwise was similar. > Peephole2 is the pass which guarantees the note problem is computed and you > can use peep2_reg_dead_p etc. safely, you can't use that in peephole or > splitter patterns, and as computing it is expensive, it can't be easily > available in too many passes. Yep, as I was looking at the register dumps, I remembed having problems in the past with peepholes and live/dead information was not up to date. The real solution is to widen what valid addresses are and fix them up in secondary reload, which I'm attempting to do, but that will take longer to get done. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
[v3] libstdc++/58163
Hi,
tested x86_64-linux, make check/check-debug, committing to mainline.
Thanks,
Paolo.
/
2013-08-14 Paolo Carlini
PR libstdc++/58163
* include/bits/basic_string.h (basic_string<>::operator[]): Fix
_GLIBCXX_DEBUG_PEDASSERT check vs C++11.
* include/ext/vstring.h: Likewise.
* testsuite/21_strings/basic_string/element_access/char/58163.cc:
New.
* testsuite/21_strings/basic_string/element_access/wchar_t/58163.cc:
Likewise.
* testsuite/ext/vstring/element_access/char/58163.cc: Likewise.
* testsuite/ext/vstring/element_access/wchar_t/58163.cc: Likewise.
Index: include/bits/basic_string.h
===
--- include/bits/basic_string.h (revision 201753)
+++ include/bits/basic_string.h (working copy)
@@ -842,10 +842,11 @@
reference
operator[](size_type __pos)
{
-// allow pos == size() as v3 extension:
+// Allow pos == size() both in C++98 mode, as v3 extension,
+ // and in C++11 mode.
_GLIBCXX_DEBUG_ASSERT(__pos <= size());
-// but be strict in pedantic mode:
- _GLIBCXX_DEBUG_PEDASSERT(__pos < size());
+// In pedantic mode be strict in C++98 mode.
+ _GLIBCXX_DEBUG_PEDASSERT(__cplusplus >= 201103L || __pos < size());
_M_leak();
return _M_data()[__pos];
}
Index: include/ext/vstring.h
===
--- include/ext/vstring.h (revision 201753)
+++ include/ext/vstring.h (working copy)
@@ -557,10 +557,12 @@
reference
operator[](size_type __pos)
{
-// allow pos == size() as v3 extension:
+// Allow pos == size() both in C++98 mode, as v3 extension,
+ // and in C++11 mode.
_GLIBCXX_DEBUG_ASSERT(__pos <= this->size());
-// but be strict in pedantic mode:
- _GLIBCXX_DEBUG_PEDASSERT(__pos < this->size());
+// In pedantic mode be strict in C++98 mode.
+ _GLIBCXX_DEBUG_PEDASSERT(__cplusplus >= 201103L
+|| __pos < this->size());
this->_M_leak();
return this->_M_data()[__pos];
}
Index: testsuite/21_strings/basic_string/element_access/char/58163.cc
===
--- testsuite/21_strings/basic_string/element_access/char/58163.cc
(revision 0)
+++ testsuite/21_strings/basic_string/element_access/char/58163.cc
(working copy)
@@ -0,0 +1,39 @@
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
[patch google/gcc-4_8] Applied r201755 to google/gcc-4_8 branch
Greetings, I've committed r201755 on google/gcc-4_8 branch as r201761.
