[wwwdocs] Re: C++ Concepts available in trunk?
On 12 August 2015 at 23:54, Dijk, J. van wrote:
Thanks for the clarification. I hope the attached patch against current
wwwdocs will be of use (only the name of the feature test macro is missing
in the new file cxx1z.html; did not manage to find that.)
Thanks, I've committed the attached change to the wwwdocs repo.
I'll add the other new C++17 features to it later today.
Index: htdocs/gcc-6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.19
diff -u -r1.19 changes.html
--- htdocs/gcc-6/changes.html 31 Jul 2015 12:06:47 - 1.19
+++ htdocs/gcc-6/changes.html 13 Aug 2015 08:35:44 -
@@ -68,8 +68,33 @@
h3 id=cxxC++/h3
ul
liThe default mode has been changed to code-std=gnu++14/code./li
+liC++ Concepts are now supported when compiling with
+code-std=gnu++1z/code or code-std=c++1z/code./li
/ul
+h4 id=libstdcxxRuntime Library (libstdc++)/h4
+ ul
+li Experimental support for C++17, including the following
+ new features:
+ ul
+licodestd::uncaught_exceptions/code function (this is also
+available for tt-std=gnu++NN/tt modes); /li
+linew member functions codetry_emplace/code and
+codeinsert_or_assign/code for unique_key maps;/li
+linon-member functions codestd::size/code,
+codestd::empty/code, and codestd::data/code for
+accessing containers and arrays;
+licodestd::shared_mutex/code;/li
+licodestd::void_t/code and codestd::bool_constant/code
+utilities. /li
+ /ul
+/li
+liAn experimental implementation of the File System TS./li
+liExperimental support for most features of the second version of the
+Library Fundamentals TS./li
+ /ul
+
+
h3 id=fortranFortran/h3
ul
liThe codeMATMUL/code intrinsic is now inlined for straightforward
Index: htdocs/projects/cxx1y.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx1y.html,v
retrieving revision 1.23
diff -u -r1.23 cxx1y.html
--- htdocs/projects/cxx1y.html 19 Apr 2015 18:21:43 - 1.23
+++ htdocs/projects/cxx1y.html 13 Aug 2015 08:35:44 -
@@ -167,23 +167,9 @@
h2C++14 Library Features/h2
pThe status of the library implementation can be tracked in this
- a
href=https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2014;table/a
+ a
href=https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2014;table/a.
/p
- h2Development Branches/h2
-
- a name=concepts/ah3C++1z Concepts Branch/h3
-
-pConcepts was a major feature planned for the C++11 standard, but it was
-eventually dropped due to concerns about both the description and
-implementability. Since the publication of C++11, people have been working
-on scaled-down versions of the concepts feature. One approach to concepts,
-known as a href=http://concepts.axiomatics.org/~ans/;Concepts Lite/a,
-has been prototyped in GCC and seems likely to be published as a Technical
-Specification in 2015. The initial implementation is available from the
-link above, and it is in the process of being cleaned up and moved into
-the codec++-concepts/code branch./p
-
/body
/html
Index: htdocs/projects/cxx1z.html
===
RCS file: htdocs/projects/cxx1z.html
diff -N htdocs/projects/cxx1z.html
--- /dev/null 1 Jan 1970 00:00:00 -
+++ htdocs/projects/cxx1z.html 13 Aug 2015 08:35:44 -
@@ -0,0 +1,66 @@
+html
+head
+ titleC++1z Support in GCC/title
+style type=text/css
+ /* ![CDATA[*/
+tr.separator { background: #cc}
+.supported { color: green }
+.unsupported { color: red }
+ /* ]] */
+/style
+/head
+
+body
+ h1C++1z Support in GCC/h1
+
+ pGCC has experimental support for the next revision of the C++
+ standard, which is expected to be published in 2017./p
+
+ pC++1z features are available as part of the mainline GCC
+compiler in the trunk of
+a href=../svn.htmlGCC's Subversion
+ repository/a and in GCC 4.9 and later. To enable C++1z
+ support, add the command-line parameter code-std=c++1z/code
+ to your codeg++/code command line. Or, to enable GNU
+ extensions in addition to C++1z extensions,
+ add code-std=gnu++1z/code to your codeg++/code command
+ line./p
+
+ pstrongImportant/strong: Because the final ISO C++1z standard is
+ still evolving, GCC's support is strongexperimental/strong. No attempt
+ will be made to maintain backward compatibility with implementations of
+ C++1y features that do not reflect the final standard./p
+
+h2C++1z Language Features/h2
+
+ pThe following table lists new language features that have been
+ accepted into the C++1z working draft or an ISO TS. The Proposal column
+ provides a link to the ISO C++ committee proposal that
RE: [Patch, MIPS] MIPS specific optimization for o32 ABI
Hi Steve,
Overall, I don't think these optimizations are ready to include. In principle
the idea looks good but it is done at the wrong point in the compiler in my
opinion.
The biggest concern I have is that the analysis should be possible at (or
prior to) the point where the prologue/epilogue are expanded. I don't think
it is safe enough to post-process the code and delete the stack allocation.
There is at least one other optimization idea that competes with this one
which is to allow LRA to use the argument save area for arbitrary spills when
it is not used for spilling arguments or to prepare varargs. I think we need
to at least consider how the frame header removal will interact with such
an optimization.
I'd also like to see this kind of optimization be on by default and the
fact it is off by default in this patch suggests you/whoever originally
wrote it is not confident enough about its safety.
I've been through the code in detail anyway as there are a couple of things
that should be addressed if you use this in its current form elsewhere.
Thanks,
Matthew
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index c3cd52d..7cdef89 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -77,6 +77,7 @@ along with GCC; see the file COPYING3. If not see
#include cgraph.h
#include builtins.h
#include rtl-iter.h
+#include dumpfile.h
/* This file should be included last. */
#include target-def.h
@@ -380,6 +381,9 @@ struct GTY(()) mips_frame_info {
/* The offset of hard_frame_pointer_rtx from the bottom of the frame. */
HOST_WIDE_INT hard_frame_pointer_offset;
+
+ /* Skip stack frame allocation if possible. */
+ bool skip_stack_frame_allocation_p;
};
/* Enumeration for masked vectored (VI) and non-masked (EIC) interrupts. */
@@ -472,6 +476,15 @@ struct GTY(()) machine_function {
/* True if this is an interrupt handler that should use DERET
instead of ERET. */
bool use_debug_exception_return_p;
+
+ /* True if some of the callees uses its frame header. */
Is this supposed to say 'use their frame header'?
+ bool callees_use_frame_header_p;
+
+ /* True if current function uses its frame header. */
+ bool uses_frame_header_p;
+
+ /* Frame size before updated by optimizations. */
+ HOST_WIDE_INT initial_total_size;
};
/* Information about a single argument. */
@@ -574,6 +587,8 @@ struct mips_rtx_cost_data
/* Global variables for machine-dependent things. */
+static hash_maptree, bool *mips_frame_header_usage;
+
/* The -G setting, or the configuration's default small-data limit if
no -G option is given. */
static unsigned int mips_small_data_threshold;
@@ -1296,6 +1311,7 @@ static const struct mips_rtx_cost_data
}
};
+static void mips_rest_of_frame_header_opt (void);
static rtx mips_find_pic_call_symbol (rtx_insn *, rtx, bool);
static int mips_register_move_cost (machine_mode, reg_class_t,
reg_class_t);
@@ -10358,6 +10374,114 @@ mips_save_reg_p (unsigned int regno)
return false;
}
+/* Try to find if function may use its incoming frame header. */
+
+static bool
+mips_find_if_frame_header_is_used (tree fndecl)
mips_frame_header_used_p
+{
+ bool *frame_header_unused;
What is the pointer doing? This should just be a bool.
+
+ if (mips_frame_header_usage)
+frame_header_unused = mips_frame_header_usage-get (fndecl);
+ else
+frame_header_unused = false;
+
+ return !frame_header_unused;
Is this just supposed to be (or maybe inverted, the logic looks weird):
return !(mips_frame_header_usage
mips_frame_header_usage-get (fndecl));
This should be inlined in the function below it only has one caller.
+}
+
+/* Return true if the instruction is a call and the called function may use
its
+ incoming frame header. */
+
+static bool
+mips_callee_use_frame_header (rtx_insn *insn)
+{
+ rtx call_insn;
+ tree fndecl;
+
+ if (insn == NULL_RTX || !USEFUL_INSN_P (insn))
+return false;
+
+ /* Handle sequence of instructions. */
+ if (GET_CODE (PATTERN (insn)) == SEQUENCE)
+{
+ rtx_insn *subinsn;
+ FOR_EACH_SUBINSN (subinsn, insn)
+ if (INSN_P (subinsn) mips_callee_use_frame_header (subinsn))
+return true;
+}
+
+ if (GET_CODE (insn) != CALL_INSN)
+return false;
+
+ if (GET_CODE (PATTERN (insn)) != PARALLEL
+ || GET_CODE (XVECEXP (PATTERN (insn), 0, 0)) != SET)
+return true;
I don't understand this. It says there is a callee frame header usage if the
instruction does not have this pattern
(parallel [(set...)...])
Why? (I'm probably just being dumb here)
+
+ call_insn = SET_SRC (XVECEXP (PATTERN (insn), 0, 0));
+
+ if (GET_CODE (call_insn) != CALL
+ || GET_CODE (XEXP (call_insn, 0)) != MEM
+ || GET_CODE (XEXP (XEXP (call_insn, 0), 0)) != SYMBOL_REF)
+return true;
MEM_P, SYMBOL_REF_P etc.
Weak symbols? We must assume the worst for preemptable symbols.
+
+ fndecl = SYMBOL_REF_DECL
Re: [PATCH][2/2] Make SCCVN use conditional equivalences
On Thu, 13 Aug 2015, Andreas Schwab wrote: On m68k: FAIL: gcc.dg/tree-ssa/vrp33.c scan-tree-dump vrp1 Folding predicate.*== 1 to 0 $ gcc/xgcc -B gcc/ ../gcc/testsuite/gcc.dg/tree-ssa/vrp33.c -O2 -fdump-tree-vrp1 -S $ grep -c Folding *.vrp1 0 I suppose for logical-op-non-short-circuit you need -fno-tree-fre for that testcase now (which shouldn't harm for other targets). Patch to add that pre-approved if it works. Richard.
[PATCH] More gimple accessor refactoring
This handles calls and conds.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-08-13 Richard Biener rguent...@suse.de
* gimple.h (gcall::code_): New constant static member.
(gcond::code_): Likewise.
* gimple.c (gcall::code_): Define.
(gcond::code_): Likewise.
(is_a_helper const gcond *): Add.
(gimple_call_lhs): Use GIMPLE_CHECK2 in the gimple overload
and forward to a new gcall overload with less checking and a
cheaper way to access the operand.
(gimple_call_lhs_ptr): Likewise.
(gimple_call_set_lhs): Likewise.
(gimple_call_internal_p): Likewise.
(gimple_call_with_bounds_p): Likewise.
(gimple_call_set_with_bounds): Likewise.
(gimple_call_internal_fn): Likewise.
(gimple_call_set_ctrl_altering): Likewise.
(gimple_call_ctrl_altering_p): Likewise.
(gimple_call_fntype): Likewise.
(gimple_call_fn): Likewise.
(gimple_call_fn_ptr): Likewise.
(gimple_call_set_fndecl): Likewise.
(gimple_call_fndecl): Likewise.
(gimple_call_chain): Likewise.
(gimple_call_num_args): Likewise.
(gimple_call_arg): Likewise.
(gimple_call_arg_ptr): Likewise.
(gimple_call_set_arg): Likewise.
(gimple_call_noreturn_p): Likewise.
(gimple_cond_code): Likewise.
(gimple_cond_lhs): Likewise.
(gimple_cond_rhs): Likewise.
(gimple_has_lhs): Reduce checking.
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 226802)
+++ gcc/gimple.c(working copy)
@@ -91,6 +91,8 @@ static const char * const gimple_alloc_k
/* Static gimple tuple members. */
const enum gimple_code gassign::code_;
+const enum gimple_code gcall::code_;
+const enum gimple_code gcond::code_;
/* Gimple tuple constructors.
Index: gcc/gimple.h
===
--- gcc/gimple.h(revision 226802)
+++ gcc/gimple.h(working copy)
@@ -351,6 +351,8 @@ struct GTY((tag(GSS_CALL)))
of this structure. In particular, this means that this
structure cannot be embedded inside another one. */
tree GTY((length (%h.num_ops))) op[1];
+
+ static const enum gimple_code code_ = GIMPLE_CALL;
};
@@ -837,6 +839,7 @@ struct GTY((tag(GSS_WITH_OPS)))
gcond : public gimple_statement_with_ops
{
/* no additional fields; this uses the layout for GSS_WITH_OPS. */
+ static const enum gimple_code code_ = GIMPLE_COND;
};
/* A statement with the invariant that
@@ -959,6 +962,14 @@ is_a_helper gcond *::test (gimple gs)
template
template
inline bool
+is_a_helper const gcond *::test (const_gimple gs)
+{
+ return gs-code == GIMPLE_COND;
+}
+
+template
+template
+inline bool
is_a_helper gdebug *::test (gimple gs)
{
return gs-code == GIMPLE_DEBUG;
@@ -2746,113 +2757,174 @@ is_gimple_call (const_gimple gs)
/* Return the LHS of call statement GS. */
static inline tree
+gimple_call_lhs (const gcall *gs)
+{
+ return gs-op[0];
+}
+
+static inline tree
gimple_call_lhs (const_gimple gs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
- return gimple_op (gs, 0);
+ const gcall *gc = GIMPLE_CHECK2const gcall * (gs);
+ return gimple_call_lhs (gc);
}
/* Return a pointer to the LHS of call statement GS. */
static inline tree *
+gimple_call_lhs_ptr (const gcall *gs)
+{
+ return const_casttree * (gs-op[0]);
+}
+
+static inline tree *
gimple_call_lhs_ptr (const_gimple gs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
- return gimple_op_ptr (gs, 0);
+ const gcall *gc = GIMPLE_CHECK2const gcall * (gs);
+ return gimple_call_lhs_ptr (gc);
}
/* Set LHS to be the LHS operand of call statement GS. */
static inline void
-gimple_call_set_lhs (gimple gs, tree lhs)
+gimple_call_set_lhs (gcall *gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
- gimple_set_op (gs, 0, lhs);
+ gs-op[0] = lhs;
if (lhs TREE_CODE (lhs) == SSA_NAME)
SSA_NAME_DEF_STMT (lhs) = gs;
}
+static inline void
+gimple_call_set_lhs (gimple gs, tree lhs)
+{
+ gcall *gc = GIMPLE_CHECK2gcall * (gs);
+ gimple_call_set_lhs (gc, lhs);
+}
+
/* Return true if call GS calls an internal-only function, as enumerated
by internal_fn. */
static inline bool
-gimple_call_internal_p (const_gimple gs)
+gimple_call_internal_p (const gcall *gs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
return (gs-subcode GF_CALL_INTERNAL) != 0;
}
+static inline bool
+gimple_call_internal_p (const_gimple gs)
+{
+ const gcall *gc = GIMPLE_CHECK2const gcall * (gs);
+ return gimple_call_internal_p (gc);
+}
+
/* Return true if call GS is marked as instrumented by
Pointer Bounds Checker. */
static inline bool
-gimple_call_with_bounds_p (const_gimple gs)
+gimple_call_with_bounds_p (const gcall *gs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
return (gs-subcode GF_CALL_WITH_BOUNDS) != 0;
}
+static
[PATCH] Fix PRs 66502 and 67167
Given there is now PR67167 I am going forward with the earlier posted
patch to switch SCCVN to PHI elimination in favor of another PHI
(to remove IVs) rather than in favor of its only executable edge value.
I still see no way to capture both cases without detecting the choice
and re-numbering the SCC twice, eventually choosing the better outcome.
And then the situation where both cases happen in the same SCC is not
handled either.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-08-13 Richard Biener rguent...@suse.de
PR tree-optimization/66502
PR tree-optimization/67167
* tree-ssa-sccvn.c (vn_phi_compute_hash): Do not include
backedge arguments.
(vn_phi_lookup): Adjust.
(vn_phi_insert): Likewise.
(visit_phi): Prefer to value-number to another PHI node
over value-numbering to a PHI argument.
(init_scc_vn): Mark DFS back edges.
* gcc.dg/tree-ssa/ssa-fre-46.c: New testcase.
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 226807)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -2655,17 +2655,24 @@ static inline hashval_t
vn_phi_compute_hash (vn_phi_t vp1)
{
inchash::hash hstate (vp1-block-index);
- int i;
tree phi1op;
tree type;
+ edge e;
+ edge_iterator ei;
/* If all PHI arguments are constants we need to distinguish
the PHI node via its type. */
type = vp1-type;
hstate.merge_hash (vn_hash_type (type));
- FOR_EACH_VEC_ELT (vp1-phiargs, i, phi1op)
+ FOR_EACH_EDGE (e, ei, vp1-block-preds)
{
+ /* Don't hash backedge values they need to be handled as VN_TOP
+ for optimistic value-numbering. */
+ if (e-flags EDGE_DFS_BACK)
+ continue;
+
+ phi1op = vp1-phiargs[e-dest_idx];
if (phi1op == VN_TOP)
continue;
inchash::add_expr (phi1op, hstate);
@@ -2718,16 +2725,18 @@ vn_phi_lookup (gimple phi)
{
vn_phi_s **slot;
struct vn_phi_s vp1;
- unsigned i;
+ edge e;
+ edge_iterator ei;
shared_lookup_phiargs.truncate (0);
+ shared_lookup_phiargs.safe_grow (gimple_phi_num_args (phi));
/* Canonicalize the SSA_NAME's to their value number. */
- for (i = 0; i gimple_phi_num_args (phi); i++)
+ FOR_EACH_EDGE (e, ei, gimple_bb (phi)-preds)
{
- tree def = PHI_ARG_DEF (phi, i);
+ tree def = PHI_ARG_DEF_FROM_EDGE (phi, e);
def = TREE_CODE (def) == SSA_NAME ? SSA_VAL (def) : def;
- shared_lookup_phiargs.safe_push (def);
+ shared_lookup_phiargs[e-dest_idx] = def;
}
vp1.type = TREE_TYPE (gimple_phi_result (phi));
vp1.phiargs = shared_lookup_phiargs;
@@ -2751,15 +2760,18 @@ vn_phi_insert (gimple phi, tree result)
{
vn_phi_s **slot;
vn_phi_t vp1 = current_info-phis_pool-allocate ();
- unsigned i;
vectree args = vNULL;
+ edge e;
+ edge_iterator ei;
+
+ args.safe_grow (gimple_phi_num_args (phi));
/* Canonicalize the SSA_NAME's to their value number. */
- for (i = 0; i gimple_phi_num_args (phi); i++)
+ FOR_EACH_EDGE (e, ei, gimple_bb (phi)-preds)
{
- tree def = PHI_ARG_DEF (phi, i);
+ tree def = PHI_ARG_DEF_FROM_EDGE (phi, e);
def = TREE_CODE (def) == SSA_NAME ? SSA_VAL (def) : def;
- args.safe_push (def);
+ args[e-dest_idx] = def;
}
vp1-value_id = VN_INFO (result)-value_id;
vp1-type = TREE_TYPE (gimple_phi_result (phi));
@@ -3244,28 +3256,23 @@ visit_phi (gimple phi)
if (def == VN_TOP)
continue;
if (sameval == VN_TOP)
+ sameval = def;
+ else if (!expressions_equal_p (def, sameval))
{
- sameval = def;
- }
- else
- {
- if (!expressions_equal_p (def, sameval))
- {
- allsame = false;
- break;
- }
+ allsame = false;
+ break;
}
}
- /* If all value numbered to the same value, the phi node has that
- value. */
- if (allsame)
-return set_ssa_val_to (PHI_RESULT (phi), sameval);
-
- /* Otherwise, see if it is equivalent to a phi node in this block. */
+ /* First see if it is equivalent to a phi node in this block. We prefer
+ this as it allows IV elimination - see PRs 66502 and 67167. */
result = vn_phi_lookup (phi);
if (result)
changed = set_ssa_val_to (PHI_RESULT (phi), result);
+ /* Otherwise all value numbered to the same value, the phi node has that
+ value. */
+ else if (allsame)
+changed = set_ssa_val_to (PHI_RESULT (phi), sameval);
else
{
vn_phi_insert (phi, PHI_RESULT (phi));
@@ -4155,6 +4162,8 @@ init_scc_vn (void)
int *rpo_numbers_temp;
calculate_dominance_info (CDI_DOMINATORS);
+ mark_dfs_back_edges ();
+
sccstack.create (0);
constant_to_value_id = new hash_tablevn_constant_hasher (23);
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-46.c
RE: [PATCH, MIPS] Enable load/store bonding for I6400
Ping. -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Robert Suchanek Sent: 05 August 2015 09:31 To: catherine_mo...@mentor.com; Matthew Fortune; gcc-patches@gcc.gnu.org Subject: [PATCH, MIPS] Enable load/store bonding for I6400 Hi, Following up https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01730.html The patch below enables the load-load/store-store bonding for MIPS32/MIPS64 R6. Ok to apply? Regards, Robert gcc/ * config/mips/mips.h (ENABLE_LD_ST_PAIRS): Enable load/store pairs for I6400. --- gcc/config/mips/mips.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index d17a833..6e262d6 100644 --- a/gcc/config/mips/mips.h +++ b/gcc/config/mips/mips.h @@ -3177,5 +3177,5 @@ extern GTY(()) struct target_globals *micromips_globals; performance can be degraded for those targets. Hence, do not bond for micromips or fix_24k. */ #define ENABLE_LD_ST_PAIRS \ - (TARGET_LOAD_STORE_PAIRS TUNE_P5600 \ + (TARGET_LOAD_STORE_PAIRS (TUNE_P5600 || TUNE_I6400) \ !TARGET_MICROMIPS !TARGET_FIX_24K) -- 2.4.5
RE: [PATCH, MIPS] Remove W32 and W64 pseudo-processors
Hi, gcc/ * config/mips/mips.c (mips_rtx_cost_data): Remove costs for W32 and W64 pseudo-processors. * config/mips/mips.md (processor): Remove w32 and w64. OK, thanks. Matthew Committed as r226851. Regards, Robert
Re: [PATCH][2/2] Make SCCVN use conditional equivalences
On m68k: FAIL: gcc.dg/tree-ssa/vrp33.c scan-tree-dump vrp1 Folding predicate.*== 1 to 0 $ gcc/xgcc -B gcc/ ../gcc/testsuite/gcc.dg/tree-ssa/vrp33.c -O2 -fdump-tree-vrp1 -S $ grep -c Folding *.vrp1 0 Andreas. -- 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: [gomp4] dimension API
Hi Nathan! On Wed, 12 Aug 2015 09:30:10 -0400, Nathan Sidwell nat...@acm.org wrote: I've committed this patch to gomp4. [...] Also put in the change I mentioned earlier this morning about the default validate dims hook setting the dimensions to 1 on accelerators to. I'll revert Thomas's patch shortly. Confirmed, that works, thanks! Grüße, Thomas pgphIkidFb9cy.pgp Description: PGP signature
Re: [PATCH GCC]Improve bound information in loop niter analysis
Ping. Thanks, bin On Tue, Jul 28, 2015 at 5:36 PM, Bin Cheng bin.ch...@arm.com wrote: Hi, Loop niter computes inaccurate bound information for different loops. This patch is to improve it by using loop initial condition in determine_value_range. Generally, loop niter is computed by subtracting start var from end var in loop exit condition. Moreover, loop bound is computed using value range information of both start and end variables. Basic idea of this patch is to check if loop initial condition implies more range information for both start/end variables. If yes, we refine range information and use that to compute loop bound. With this improvement, more accurate loop bound information is computed for test cases added by this patch. Is it OK? Thanks, bin 2015-07-28 Bin Cheng bin.ch...@arm.com * tree-ssa-loop-niter.c (refine_value_range_using_guard): New. (determine_value_range): Call refine_value_range_using_guard for each loop initial condition to improve value range. gcc/testsuite/ChangeLog 2015-07-28 Bin Cheng bin.ch...@arm.com * gcc.dg/tree-ssa/loop-bound-1.c: New test. * gcc.dg/tree-ssa/loop-bound-3.c: New test. * gcc.dg/tree-ssa/loop-bound-5.c: New test.
Re: [PATCH GCC]Improve loop bound info by simplifying conversions in iv base
Ping. Thanks, bin On Tue, Jul 28, 2015 at 5:38 PM, Bin Cheng bin.ch...@arm.com wrote: Hi, For now, SCEV may compute iv base in the form of (signed T)((unsigned T)base + step)). This complicates other optimizations/analysis depending on SCEV because it's hard to dive into type conversions. For many cases, such type conversions can be simplified with additional range information implied by loop initial conditions. This patch does such simplification. With simplified iv base, loop niter analysis can compute more accurate bound information since sensible value range can be derived for base+step. For example, accurate loop boundmay_be_zero information is computed for cases added by this patch. The code is actually borrowed from loop_exits_before_overflow. Moreover, with simplified iv base, the second case handled in that function now becomes the first case. I didn't remove that part of code because it may(?) still be visited in scev analysis itself and simple_iv isn't an interface for that. Is it OK? Thanks, bin 2015-07-28 Bin Cheng bin.ch...@arm.com * tree-ssa-loop-niter.c (tree_simplify_using_condition): Export the interface. * tree-ssa-loop-niter.h (tree_simplify_using_condition): Declare. * tree-scalar-evolution.c (simple_iv): Simplify type conversions in iv base using loop initial conditions. gcc/testsuite/ChangeLog 2015-07-28 Bin Cheng bin.ch...@arm.com * gcc.dg/tree-ssa/loop-bound-2.c: New test. * gcc.dg/tree-ssa/loop-bound-4.c: New test. * gcc.dg/tree-ssa/loop-bound-6.c: New test.
Re: [PATCH][2/2] Make SCCVN use conditional equivalences
On ia64 and arm64: FAIL: g++.dg/tree-ssa/pr61034.C -std=gnu++11 scan-tree-dump-times fre2 free 10 $ gcc/xg++ -Bgcc/ ../gcc/testsuite/g++.dg/tree-ssa/pr61034.C -nostdinc++ -Iia64-suse-linux/libstdc++-v3/include/ia64-suse-linux -Iia64-suse-linux/libstdc++-v3/include -I../libstdc++-v3/libsupc++ -I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util -std=gnu++11 -O3 -fdump-tree-fre2 -S -o pr61034.s $ grep -c free *.fre2 14 Andreas. -- 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.
[PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax*
Hi, Sorry to bother people again. Is this OK to go now? Thanks! David. On Mon, 29 Jun 2015, David Sherwood wrote: Hi, I have added new STRICT_MAX_EXPR and STRICT_MIN_EXPR expressions to support the IEEE versions of fmin and fmax. This is done by recognising the math library fmax and fmin builtin functions in a similar way to how this is done for -ffast-math. This also allows us to vectorise the IEEE max/min functions for targets that support it, for example aarch64/aarch32. This patch is missing documentation. You need to document the new insn patterns in md.texi and the new tree codes in generic.texi. Hi, I've uploaded a new patch with the documentation. Hope this is ok. In various places where you refer to one operand being NaN, I think you mean one operand being a *quiet* NaN (if one is a signaling NaN - only supported by GCC if -fsignaling-nans - the IEEE minNum and maxNum operations raise invalid and return a quiet NaN). Hi, I have a new patch that hopefully addresses the documentation issues. Thanks, David. ChangeLog: 2015-07-15 David Sherwood david.sherw...@arm.com gcc/ * builtins.c (integer_valued_real_p): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR. (fold_builtin_fmin_fmax): For strict math, convert builting fmin and fmax to STRICT_MIN_EXPR and STRICT_MIN_EXPR, respectively. * expr.c (expand_expr_real_2): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR. * fold-const.c (const_binop): Likewise. (fold_binary_loc, tree_binary_nonnegative_warnv_p): Likewise. (tree_binary_nonzero_warnv_p): Likewise. * optabs.h (strict_minmax_support): Declare. * optabs.def: Add new optabs strict_max_optab/strict_min_optab. * optabs.c (optab_for_tree_code): Return new optabs for STRICT_MIN_EXPR and STRICT_MAX_EXPR. (strict_minmax_support): New function. * real.c (real_arithmetic): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR. * tree.def: Likewise. * tree.c (associative_tree_code, commutative_tree_code): Likewise. * tree-cfg.c (verify_expr): Likewise. (verify_gimple_assign_binary): Likewise. * tree-inline.c (estimate_operator_cost): Likewise. * tree-pretty-print.c (dump_generic_node, op_code_prio): Likewise. (op_symbol_code): Likewise. gcc/config: * aarch64/aarch64.md: New pattern. * aarch64/aarch64-simd.md: Likewise. * aarch64/iterators.md: New unspecs, iterators. * arm/iterators.md: New iterators. * arm/unspecs.md: New unspecs. * arm/neon.md: New pattern. * arm/vfp.md: Likewise. gcc/doc: * generic.texi: Add STRICT_MAX_EXPR and STRICT_MIN_EXPR. * md.texi: Add strict_min and strict_max patterns. gcc/testsuite * gcc.target/aarch64/maxmin_strict.c: New test. * gcc.target/arm/maxmin_strict.c: New test. strict_max.patch Description: Binary data
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
Le 13/08/2015 12:56, Mikael Morin a écrit : Still, implementation-defined behavior is a progress over undefined behaviour. Even if it's not set in stone, the good thing about implementation-defined behaviour is that it's known to be non-random. So it can be checked, either with autoconf, or with a macro. Would it be acceptable to have both variants of the code and decide among them with such a check? It feels a bit overkill for such a little function, but it is the only way that I see to achieve both need for speed and for well-defined-ness. I guess it won't kill the bootstrap-ubsan errors though. Sorry Richi, I didn't see your answer before posting. I will prepare something tomorrow. Mikael
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
On Thu, Aug 13, 2015 at 1:08 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2015.08.13 at 12:56 +0200, Mikael Morin wrote: Le 12/08/2015 22:07, Richard Sandiford a écrit : Jeff Law l...@redhat.com writes: On 08/12/2015 12:32 PM, Richard Biener wrote: On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law l...@redhat.com wrote: On 08/12/2015 11:12 AM, Richard Biener wrote: Prec is almost never a constant and is heavily used from wide-int. We are not exploiting this undefined ness in C so I object to making this so much slower. Can we instead do what we do for abs_hwi and add a checking assert so we can move the tests to the callers that misbehave instead? Given that ISO C++ is moving away from making shifting 1 into the sign bit undefined behaviour, maybe we should make UBSan less strict in its warning. That may eliminate the need for Mikael's patch. We can also use an logical left shift followed by an arithmetic right shift. Or is the latter invoking undefined behaviour as well in some cases we hit? Hmm, why aren't we using logicals for the left shift to begin with? That's the problem area. I don't think the right shifts are an issue at all. Well, they're implementation-defined, at least in C. The C11 wording for E1 E2 is If E1 has a signed type and a negative value, the resulting value is implementation-defined. Is C++ different? (I don't have the standard handy.) So... It's strange that when I was researching this, consistently I saw folks suggesting the LEFT-SHIFT followed by RIGHT-SHIFT, then it'd get shot down as UB, then folks went to either Mikael's approach or another that is very similar. Nobody suggested twidding the types to get a left-logical-shift, then doing a right-arithmetic-shift. ...unless C++ is different, there's not a standard-level concept of arithmetic shift. Still, implementation-defined behavior is a progress over undefined behaviour. Even if it's not set in stone, the good thing about implementation-defined behaviour is that it's known to be non-random. So it can be checked, either with autoconf, or with a macro. Would it be acceptable to have both variants of the code and decide among them with such a check? It feels a bit overkill for such a little function, but it is the only way that I see to achieve both need for speed and for well-defined-ness. I guess it won't kill the bootstrap-ubsan errors though. For such cases you can use the ATTRIBUTE_NO_SANITIZE_UNDEFINED macro, that is defined in include/ansidecl.h. Rather ubsan should not complain about implementation defined behavior (or should separate those cases out with a different switch compared to undefined behavior). Richard. -- Markus
Re: [PATCH] Simple optimization for MASK_STORE.
Hi Richard, Did you have a chance to look at updated patch? Thanks. Yuri. 2015-08-06 14:07 GMT+03:00 Yuri Rumyantsev ysrum...@gmail.com: HI All, Here is updated patch which implements Richard proposal to use vector comparison with boolean result instead of target hook. Support for it was added to ix86_expand_branch. Any comments will be appreciated. Bootstrap and regression testing did not show any new failures. ChangeLog: 2015-08-06 Yuri Rumyantsev ysrum...@gmail.com * config/i386/i386.c (ix86_expand_branch): Implement vector comparison with boolean result. * config/i386/sse.md (define_expand cbranchmode4): Add define for vector comparion. * fold-const.c (fold_relational_const): Add handling of vector comparison with boolean result. * params.def (PARAM_ZERO_TEST_FOR_STORE_MASK): New DEFPARAM. * params.h (ENABLE_ZERO_TEST_FOR_STORE_MASK): new macros. * tree-cfg.c (verify_gimple_comparison): Add test for vector comparion with boolean result. * tree-ssa-forwprop.c (forward_propagate_into_comparison_1): Do not propagate vector comparion with boolean result. * tree-vect-stmts.c (vectorizable_mask_load_store): Initialize has_mask_store field of vect_info. * tree-vectorizer.c: Include files ssa.h, cfghooks.h and params.h. (is_valid_sink): New function. (optimize_mask_stores): New function. (vectorize_loops): Invoke optimaze_mask_stores for loops having masked stores. * tree-vectorizer.h (loop_vec_info): Add new has_mask_store field and correspondent macros. gcc/testsuite/ChangeLog: * gcc.target/i386/avx2-vect-mask-store-move1.c: New test. 2015-07-27 11:48 GMT+03:00 Richard Biener richard.guent...@gmail.com: On Fri, Jul 24, 2015 at 9:11 PM, Jeff Law l...@redhat.com wrote: On 07/24/2015 03:16 AM, Richard Biener wrote: Is there any rationale given anywhere for the transformation into conditional expressions? ie, is there any reason why we can't have a GIMPLE_COND where the expression is a vector condition? No rationale for equality compare which would have the semantic of having all elements equal or not equal. But you can't define a sensible ordering (that HW implements) for other compare operators and you obviously need a single boolean result, not a vector of element comparison results. Right. EQ/NE only as others just don't have any real meaning. I've already replied that I'm fine allowing ==/!= whole-vector compares. But one needs to check whether expansion does anything sensible with them (either expand to integer subreg compares or add optabs for the compares). Agreed, EQ/NE for whole vector compares only would be fine for me too under the same conditions. Btw, you can already do this on GIMPLE by doing TImode vec_as_int = VIEW_CONVERT_EXPR TImode (vec_2); if (vec_as_int == 0) ... which is what the RTL will look like in the end. So not sure if making this higher-level in GIMPLE is good or required. Richard. jeff
RE: [PATCH, MIPS] Enable load/store bonding for I6400
Hi, gcc/ * config/mips/mips.h (ENABLE_LD_ST_PAIRS): Enable load/store pairs for I6400. Sorry, I missed this one. OK to commit. Thanks, Matthew Committed as r226860. Regards, Robert
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
On 2015.08.13 at 12:56 +0200, Mikael Morin wrote: Le 12/08/2015 22:07, Richard Sandiford a écrit : Jeff Law l...@redhat.com writes: On 08/12/2015 12:32 PM, Richard Biener wrote: On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law l...@redhat.com wrote: On 08/12/2015 11:12 AM, Richard Biener wrote: Prec is almost never a constant and is heavily used from wide-int. We are not exploiting this undefined ness in C so I object to making this so much slower. Can we instead do what we do for abs_hwi and add a checking assert so we can move the tests to the callers that misbehave instead? Given that ISO C++ is moving away from making shifting 1 into the sign bit undefined behaviour, maybe we should make UBSan less strict in its warning. That may eliminate the need for Mikael's patch. We can also use an logical left shift followed by an arithmetic right shift. Or is the latter invoking undefined behaviour as well in some cases we hit? Hmm, why aren't we using logicals for the left shift to begin with? That's the problem area. I don't think the right shifts are an issue at all. Well, they're implementation-defined, at least in C. The C11 wording for E1 E2 is If E1 has a signed type and a negative value, the resulting value is implementation-defined. Is C++ different? (I don't have the standard handy.) So... It's strange that when I was researching this, consistently I saw folks suggesting the LEFT-SHIFT followed by RIGHT-SHIFT, then it'd get shot down as UB, then folks went to either Mikael's approach or another that is very similar. Nobody suggested twidding the types to get a left-logical-shift, then doing a right-arithmetic-shift. ...unless C++ is different, there's not a standard-level concept of arithmetic shift. Still, implementation-defined behavior is a progress over undefined behaviour. Even if it's not set in stone, the good thing about implementation-defined behaviour is that it's known to be non-random. So it can be checked, either with autoconf, or with a macro. Would it be acceptable to have both variants of the code and decide among them with such a check? It feels a bit overkill for such a little function, but it is the only way that I see to achieve both need for speed and for well-defined-ness. I guess it won't kill the bootstrap-ubsan errors though. For such cases you can use the ATTRIBUTE_NO_SANITIZE_UNDEFINED macro, that is defined in include/ansidecl.h. -- Markus
[PATCH] Missing Skylake -march=/-mtune= option
Hi All, Here is patch for adding march/mtune options for Skylake. Bootstrap and regression testing did not show any new failures. Is it OK for trunk? ChangeLog: 2015-08-13 Yuri Rumyantsev ysrum...@gmail.com * config/i386/driver-i386.c (host_detect_local_cpu): Add support for skylake. * config/i386/i386.c (PTA_SKYLAKE): New macros. (processor_alias_table): Add skylake description. (enum processor_model): Add skylake processor. (arch_names_table): Add skylake record. * doc/invoke.texi: Add skylake item. gcc/testsuite/ChangeLog: * gcc.target/i386/builtin_target.c: Add skylake check. libgcc/ChangeLog: * config/i386/cpuinfo.c (enum processor_subtypes): Add skylake. (get_intel_cpu): Likewise. skl.patch.1 Description: Binary data
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law l...@redhat.com wrote: On 08/12/2015 10:24 AM, Ian Lance Taylor wrote: On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey t...@tromey.com wrote: Jeff In the past this has stalled on issues like how will asynch-exceptions Jeff be tested and the like. It seems to me that either there is some other language which needs this -- in which case that language ought to have testing for the feature -- or the feature is only used by gcj, in which case it doesn't matter. Of course is!=ought; but relying on gcj and libjava to provide this small amount of testing seems like a bad cost/benefit tradeoff. Go does use asynchronous exceptions, and has test cases that rely on them working. If you're comfortable with Go at this point and we have mechanisms in place to ensure Go only gets built on platforms that support Go, then I think we should go forward with replacing GCJ with Go. I think replacing it with Ada makes more sense (still have some systems where a ton of Go tests fail presumably because of too old glibc/kernel). Or just replace it with nothing as effectively neither Go nor Ada are going to be enabled for all primary host platforms (as for Ada you need an Ada host compiler for example). Well. My original idea was to strip down Java testing by basically removing classpath from the picture (to the extent of actually pruning it from the repository apart from maybe java.lang classes). Richard. Jeff
Re: [PATCH 2/2] replace several uses of the anon namespace with GCC_FINAL
On Wed, Aug 12, 2015 at 4:30 PM, Trevor Saunders tbsau...@tbsaunde.org wrote: On Wed, Aug 12, 2015 at 03:31:35PM -0400, David Edelsohn wrote: This patch has caused a bootstrap failure on AIX. reverted, though my bet is this is some sort of generic devirt bug on aix. There have been a lot of issues with GCC's generation of weak / one-only symbols on AIX, so this definitely could be related. I will try a bootstrap with GCC 5 and sources prior to your reversion. Thanks, David
RE: [PATCH, MIPS] Enable load/store bonding for I6400
gcc/ * config/mips/mips.h (ENABLE_LD_ST_PAIRS): Enable load/store pairs for I6400. Sorry, I missed this one. OK to commit. Thanks, Matthew
Re: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax*
On Thu, Aug 13, 2015 at 12:11 PM, David Sherwood david.sherw...@arm.com wrote: Hi, Sorry to bother people again. Is this OK to go now? Hmm, why don't you go the vectorized function call path for this, implementing the builtin_vectorized_function target hook? Richard. Thanks! David. On Mon, 29 Jun 2015, David Sherwood wrote: Hi, I have added new STRICT_MAX_EXPR and STRICT_MIN_EXPR expressions to support the IEEE versions of fmin and fmax. This is done by recognising the math library fmax and fmin builtin functions in a similar way to how this is done for -ffast-math. This also allows us to vectorise the IEEE max/min functions for targets that support it, for example aarch64/aarch32. This patch is missing documentation. You need to document the new insn patterns in md.texi and the new tree codes in generic.texi. Hi, I've uploaded a new patch with the documentation. Hope this is ok. In various places where you refer to one operand being NaN, I think you mean one operand being a *quiet* NaN (if one is a signaling NaN - only supported by GCC if -fsignaling-nans - the IEEE minNum and maxNum operations raise invalid and return a quiet NaN). Hi, I have a new patch that hopefully addresses the documentation issues. Thanks, David. ChangeLog: 2015-07-15 David Sherwood david.sherw...@arm.com gcc/ * builtins.c (integer_valued_real_p): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR. (fold_builtin_fmin_fmax): For strict math, convert builting fmin and fmax to STRICT_MIN_EXPR and STRICT_MIN_EXPR, respectively. * expr.c (expand_expr_real_2): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR. * fold-const.c (const_binop): Likewise. (fold_binary_loc, tree_binary_nonnegative_warnv_p): Likewise. (tree_binary_nonzero_warnv_p): Likewise. * optabs.h (strict_minmax_support): Declare. * optabs.def: Add new optabs strict_max_optab/strict_min_optab. * optabs.c (optab_for_tree_code): Return new optabs for STRICT_MIN_EXPR and STRICT_MAX_EXPR. (strict_minmax_support): New function. * real.c (real_arithmetic): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR. * tree.def: Likewise. * tree.c (associative_tree_code, commutative_tree_code): Likewise. * tree-cfg.c (verify_expr): Likewise. (verify_gimple_assign_binary): Likewise. * tree-inline.c (estimate_operator_cost): Likewise. * tree-pretty-print.c (dump_generic_node, op_code_prio): Likewise. (op_symbol_code): Likewise. gcc/config: * aarch64/aarch64.md: New pattern. * aarch64/aarch64-simd.md: Likewise. * aarch64/iterators.md: New unspecs, iterators. * arm/iterators.md: New iterators. * arm/unspecs.md: New unspecs. * arm/neon.md: New pattern. * arm/vfp.md: Likewise. gcc/doc: * generic.texi: Add STRICT_MAX_EXPR and STRICT_MIN_EXPR. * md.texi: Add strict_min and strict_max patterns. gcc/testsuite * gcc.target/aarch64/maxmin_strict.c: New test. * gcc.target/arm/maxmin_strict.c: New test.
Re: [wwwdocs] Re: C++ Concepts available in trunk?
Here's the patch for the rest of the C++17 support. On 13 August 2015 at 09:58, Jonathan Wakely jwakely@gmail.com wrote: On 12 August 2015 at 23:54, Dijk, J. van wrote: Thanks for the clarification. I hope the attached patch against current wwwdocs will be of use (only the name of the feature test macro is missing in the new file cxx1z.html; did not manage to find that.) Thanks, I've committed the attached change to the wwwdocs repo. I'll add the other new C++17 features to it later today. Index: htdocs/projects/cxx1z.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx1z.html,v retrieving revision 1.1 diff -u -r1.1 cxx1z.html --- htdocs/projects/cxx1z.html 13 Aug 2015 08:36:07 - 1.1 +++ htdocs/projects/cxx1z.html 13 Aug 2015 09:24:13 - @@ -19,7 +19,7 @@ pC++1z features are available as part of the mainline GCC compiler in the trunk of a href=../svn.htmlGCC's Subversion - repository/a and in GCC 4.9 and later. To enable C++1z + repository/a and in GCC 5 and later. To enable C++1z support, add the command-line parameter code-std=c++1z/code to your codeg++/code command line. Or, to enable GNU extensions in addition to C++1z extensions, @@ -48,9 +48,58 @@ thSD-6 Feature Test/th /tr tr + td Removing trigraphs /td + tda href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4086.html;N4086/a /td + td class=supported align=center5.1/td + td /td +/tr +tr + tdcodeu8/code character literals /td + tda href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html;N4267/a /td + td class=supported align=center 6 /td + td __cpp_unicode_characters gt;= 201411 /td +/tr +tr + td Folding expressions/td + tda href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4295.html;N4295/a /td + td class=supported align=center 6 /td + td __cpp_fold_expressions gt;= 201411/td +/tr +tr + td Attributes for namespaces and enumerators /td + tda href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4266.html;N4266/a /td + td class=supported align=center +4.9 (namespaces) br / 6 (enumerators) + /td + td +__cpp_namespace_attributes gt;= 201411 br / +__cpp_enumerator_attributes gt;= 201411 + /td +/tr +tr + td Nested namespace definitions/td + tda href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4230.html;N4230/a /td + td class=unsupported align=centerNo/td + td __cpp_nested_namespace_definitions gt;= 201411/td +/tr +tr + td Allow constant evaluation for all non-type template arguments/td + tda href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4268.html;N4268/a /td + td class=unsupported align=centerNo/td + td__cpp_nontype_template_args gt;= 201411 /td +/tr +!-- +tr + td /td + td /td + td class=unsupported align=centerNo/td + td /td +/tr +-- +tr tdC++ concepts/td tda href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf;N4377/a/td - td class=supported align=centera href=../gcc-6/changes.html#cxx6/a/td + td class=supported align=center 6 /td td __cpp_concepts gt;= 201507 /td /tr /table
[PATCH] Fix PR67191
Just remove the assert which I now know how it can trigger without
causing harm.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-08-13 Richard Biener rguent...@suse.de
PR tree-optimization/67191
* tree-ssa-sccvn.c (sccvn_dom_walker::before_dom_children): Remove
assert we value-numbered last stmts operand because it can validly
trigger for unreachable code.
* gcc.dg/torture/pr67191.c: New testcase.
* g++.dg/torture/pr67191.C: Likewise.
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 226851)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -4429,6 +4429,9 @@ sccvn_dom_walker::before_dom_children (b
return;
}
+ if (dump_file (dump_flags TDF_DETAILS))
+fprintf (dump_file, Visiting BB %d\n, bb-index);
+
/* If we have a single predecessor record the equivalence from a
possible condition on the predecessor edge. */
if (single_pred_p (bb))
@@ -4502,17 +4505,10 @@ sccvn_dom_walker::before_dom_children (b
if (dump_file (dump_flags TDF_DETAILS))
{
- fprintf (dump_file, Visiting stmt ending BB %d: , bb-index);
+ fprintf (dump_file, Visiting control stmt ending BB %d: , bb-index);
print_gimple_stmt (dump_file, stmt, 0, 0);
}
- /* Value-number the last stmts SSA uses. */
- ssa_op_iter i;
- tree op;
- FOR_EACH_SSA_TREE_OPERAND (op, stmt, i, SSA_OP_USE)
-gcc_assert (VN_INFO (op)-visited
- || SSA_NAME_IS_DEFAULT_DEF (op));
-
/* ??? We can even handle stmts with outgoing EH or ABNORMAL edges
if value-numbering can prove they are not reachable. Handling
computed gotos is also possible. */
Index: gcc/testsuite/gcc.dg/torture/pr67191.c
===
--- gcc/testsuite/gcc.dg/torture/pr67191.c (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr67191.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+int a;
+void f(void)
+{
+ int b;
+ for(a=1; a;);
+ for(; b; b++)
+lbl:
+ b || a;
+ if(a)
+goto lbl;
+}
Index: gcc/testsuite/g++.dg/torture/pr67191.C
===
--- gcc/testsuite/g++.dg/torture/pr67191.C (revision 0)
+++ gcc/testsuite/g++.dg/torture/pr67191.C (revision 0)
@@ -0,0 +1,117 @@
+// { dg-do compile }
+
+template typename class A;
+template typename _Tp using __allocator_base = _Tp;
+template class T, class = T, class = int, class = __allocator_baseint
+class B;
+template class T, class H, class P, class A
+bool operator==(BT, H, P, A const , BT, H, P, A const );
+template class T, class H, class P, class A
+bool operator!=(BT, H, P, A const , BT, H, P, A const );
+typedef Bint int_multiset;
+int a;
+template typename struct C {
+C(int) {}
+};
+template typename struct D;
+template typename struct K;
+struct L : CADint, CAKint {
+template typename First, typename Second
+ L(First, Second)
+ : CADint(0), CAKint(0) {}
+};
+template typename Node struct F {
+typedef typename Node::node_pointer node_pointer;
+node_pointer node_;
+F();
+F(typename Node::link_pointer p1) : node_(static_castnode_pointer(p1)) {}
+void operator++() { node_ = 0; }
+int operator!=(F p1) { return node_ != p1.node_; }
+};
+struct G {
+typedef G *link_pointer;
+};
+struct H {
+static int new_bucket_count(int) {
+ int b;
+ int *c = 0;
+ if (a)
+ b = *c;
+ return b;
+}
+};
+class functions {
+public:
+functions(int, int) {}
+~functions();
+};
+template typename Types struct table : functions {
+typedef typename Types::policy policy;
+typedef Types node_allocator;
+typedef Ftypename Types::node iterator;
+L allocators_;
+int bucket_count_;
+int size_;
+typename Types::link_pointer get_previous_start() const;
+iterator begin() const { return size_ ? get_previous_start() : 0; }
+table(int, typename Types::hasher, typename Types::key_equal,
node_allocator)
+ : functions(0, 0), allocators_(0, 0),
+ bucket_count_(policy::new_bucket_count(0)), size_() {}
+};
+template typename struct K : G { typedef K *node_pointer; };
+struct I {
+typedef G *link_pointer;
+};
+struct J {
+typedef I::link_pointer link_pointer;
+};
+template typename struct D {
+typedef int hasher;
+typedef int key_equal;
+typedef Kint node;
+typedef J::link_pointer link_pointer;
+typedef H policy;
+};
+struct M : tableDint {
+node_allocator grouped_table_impl_a;
+M(int, int) : table(0, 0, 0, grouped_table_impl_a) {}
+void equals(M const ) const {
+ for (iterator d = begin(); d.node_;) {
+ iterator e;
+ group_equals(e);
+ }
+}
+static int group_equals(iterator p1) {
+ int f;
+ iterator g;
+ for (; g != p1; ++g)
+ if
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
On Wed, Aug 12, 2015 at 10:52 PM, Mike Stump mikest...@comcast.net wrote: On Aug 12, 2015, at 1:07 PM, Richard Sandiford rdsandif...@googlemail.com wrote: I don't think the right shifts are an issue at all. Well, they're implementation-defined, at least in C. The C11 wording for E1 E2 is If E1 has a signed type and a negative value, the resulting value is implementation-defined”. Is C++ different? No, it is the same: 3 The value of E1 E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 divided by the quantity 2 raised to the power E2. If E1 has a signed type and a negative value, the resulting value is implementation- defined. Ok, then guard the with __GCC__ and do the expensive bit stuff otherwise. Just to cater for other host compilers doing sth unsensibly implementation defined. This thing _is_ performance critical. Richard. (I don't have the standard handy.) Google is your friend.
Re: [PATCH][2/2] Make SCCVN use conditional equivalences
Richard Biener rguent...@suse.de writes:
On Thu, 13 Aug 2015, Andreas Schwab wrote:
On m68k:
FAIL: gcc.dg/tree-ssa/vrp33.c scan-tree-dump vrp1 Folding predicate.*== 1
to 0
$ gcc/xgcc -B gcc/ ../gcc/testsuite/gcc.dg/tree-ssa/vrp33.c -O2
-fdump-tree-vrp1 -S
$ grep -c Folding *.vrp1
0
I suppose for logical-op-non-short-circuit you need -fno-tree-fre for
that testcase now (which shouldn't harm for other targets).
Yes, that works, and didn't change anything on ia64 or arm64.
Andreas.
* gcc.dg/tree-ssa/vrp33.c: Add -fno-tree-fre.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp33.c
b/gcc/testsuite/gcc.dg/tree-ssa/vrp33.c
index 8c8879b..75fefa4 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/vrp33.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp33.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 -fdump-tree-vrp1 } */
+/* { dg-options -O2 -fdump-tree-vrp1 -fno-tree-fre } */
/* This is from PR14052. */
--
2.5.0
--
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][2/2] Make SCCVN use conditional equivalences
On Thu, 13 Aug 2015, Andreas Schwab wrote: On ia64 and arm64: FAIL: g++.dg/tree-ssa/pr61034.C -std=gnu++11 scan-tree-dump-times fre2 free 10 $ gcc/xg++ -Bgcc/ ../gcc/testsuite/g++.dg/tree-ssa/pr61034.C -nostdinc++ -Iia64-suse-linux/libstdc++-v3/include/ia64-suse-linux -Iia64-suse-linux/libstdc++-v3/include -I../libstdc++-v3/libsupc++ -I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util -std=gnu++11 -O3 -fdump-tree-fre2 -S -o pr61034.s $ grep -c free *.fre2 14 Hmpf. I remember 2015-04-28 Jan Hubicka hubi...@ucw.cz * g++.dg/tree-ssa/pr61034.C: Add temporary; fix template. which managed to fix an inconsistency. I suppose that no longer works :/ Will try to investigate at some point - mind opening a bug for this one? Thanks, Richard.
Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
On Wed, Aug 12, 2015 at 10:41 PM, Tobias Grosser tob...@grosser.es wrote: On 08/12/2015 10:33 PM, Aditya Kumar wrote: Passes bootstrap, no regressions. With this patch gcc bootstraps with graphite. make BOOT_CFLAGS=-g -O2 -fgraphite-identity -floop-interchange -floop-block LGTM, but please use a longer sentence to explain what you do. As the middle-end generally freely exchanges INTEGER_TYPE ENUMERAL_TYPE and BOOLEAN_TYPE you want to use INTEGRAL_TYPE_P here. RIchard. Tobias
[PING][PATCH][3/N] Replace the pattern GET_MODE_BITSIZE (GET_MODE_INNER (m)) with GET_MODE_UNIT_BITSIZE (m)
Hi, This patch follows on from [PATCH][1/N] Change GET_MODE_INNER to always return a non-void mode It is another tidy up, replacing the pattern GET_MODE_BITSIZE (GET_MODE_INNER (m)) with GET_MODE_UNIT_BITSIZE (m). Also replaces any calls to GET_MODE_PRECISION (GET_MODE_INNER (m)) with GET_MODE_UNIT_PRECISION (m). Tested: aarch64 and aarch64_be - no regressions in gcc testsuite x86_64 - bootstrap build, no testsuite regressions arm-none-eabi - no regressions in gcc testsuite Run contrib/config-list.mk - no regressions Good to go? Thanks, David. 2015-08-04 David Sherwood david.sherw...@arm.com gcc/ * config/arm/arm.c (neon_element_bits): Replace call to GET_MODE_BITSIZE (GET_MODE_INNER (m)) with GET_MODE_UNIT_BITSIZE (m). * config/arm/neon.md (neon_vget_lanemode): Likewise. (neon_vget_laneumode, neon_vset_lanemode): Likewise (neon_vdup_lanemode): Likewise. * config/i386/i386.c (ix86_expand_int_vcond): Likewise. (ix86_expand_multi_arg_builtin, ix86_expand_reduc): Likewise. (expand_vec_perm_palignr, ix86_expand_sse2_abs): Likewise. * config/rs6000/rs6000.c (rs6000_do_expand_vec_perm): Likewise. * config/spu/spu.c (arith_immediate_p): Likewise. * expmed.c (store_bit_field_1, extract_bit_field_1): Likewise. * expr.c (expand_expr_real_2): Likewise. * optabs.c (shift_amt_for_vec_perm_mask): Likewise. * simplify-rtx.c (simplify_immed_subreg): Likewise. * tree-cfg.c (verify_gimple_assign_ternary): Likewise. * tree-vect-patterns.c (vect_recog_mixed_size_cond_pattern): Likewise. New variable. * fold-const.c (fold_binary_loc): Replace call to GET_MODE_PRECISION (GET_MODE_INNER (m)) with GET_MODE_UNIT_PRECISION (m). mode_inner3.patch Description: Binary data
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
Le 12/08/2015 22:07, Richard Sandiford a écrit : Jeff Law l...@redhat.com writes: On 08/12/2015 12:32 PM, Richard Biener wrote: On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law l...@redhat.com wrote: On 08/12/2015 11:12 AM, Richard Biener wrote: Prec is almost never a constant and is heavily used from wide-int. We are not exploiting this undefined ness in C so I object to making this so much slower. Can we instead do what we do for abs_hwi and add a checking assert so we can move the tests to the callers that misbehave instead? Given that ISO C++ is moving away from making shifting 1 into the sign bit undefined behaviour, maybe we should make UBSan less strict in its warning. That may eliminate the need for Mikael's patch. We can also use an logical left shift followed by an arithmetic right shift. Or is the latter invoking undefined behaviour as well in some cases we hit? Hmm, why aren't we using logicals for the left shift to begin with? That's the problem area. I don't think the right shifts are an issue at all. Well, they're implementation-defined, at least in C. The C11 wording for E1 E2 is If E1 has a signed type and a negative value, the resulting value is implementation-defined. Is C++ different? (I don't have the standard handy.) So... It's strange that when I was researching this, consistently I saw folks suggesting the LEFT-SHIFT followed by RIGHT-SHIFT, then it'd get shot down as UB, then folks went to either Mikael's approach or another that is very similar. Nobody suggested twidding the types to get a left-logical-shift, then doing a right-arithmetic-shift. ...unless C++ is different, there's not a standard-level concept of arithmetic shift. Still, implementation-defined behavior is a progress over undefined behaviour. Even if it's not set in stone, the good thing about implementation-defined behaviour is that it's known to be non-random. So it can be checked, either with autoconf, or with a macro. Would it be acceptable to have both variants of the code and decide among them with such a check? It feels a bit overkill for such a little function, but it is the only way that I see to achieve both need for speed and for well-defined-ness. I guess it won't kill the bootstrap-ubsan errors though. Mikael
[PATCH][MIPS] Fix register renaming in the interrupt handlers
Hi,
It was discovered that with the attached test case compiled with -O2
-funroll-loops,
the regrename pass renamed one of the registers ($2) to $8 that was not
saved by the prologue.
The attached patch fixes it by defining macro HARD_REGNO_RENAME_OK that returns
zero iff the current function is an interrupt handler and a register was never
live.
Regression is still in progress. Ok to apply if it passes?
Regards,
Robert
gcc/
* config/mips/mips-protos.h (mips_hard_regno_rename_ok): New prototype.
* config/mips/mips.c (mips_hard_regno_rename_ok): New function.
* config/mips/mips.h (HARD_REGNO_RENAME_OK): New.
gcc/testsuite/
* gcc.target/mips/interrupt_handler-bug-1.c: New test.
---
gcc/config/mips/mips-protos.h | 1 +
gcc/config/mips/mips.c | 14 ++
gcc/config/mips/mips.h | 3 +++
gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c | 12
4 files changed, 30 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
diff --git a/gcc/config/mips/mips-protos.h b/gcc/config/mips/mips-protos.h
index 6ce3d70..e43 100644
--- a/gcc/config/mips/mips-protos.h
+++ b/gcc/config/mips/mips-protos.h
@@ -317,6 +317,7 @@ extern unsigned int mips_sync_loop_insns (rtx, rtx *);
extern const char *mips_output_division (const char *, rtx *);
extern const char *mips_msa_output_division (const char *, rtx *);
extern const char *mips_output_probe_stack_range (rtx, rtx);
+extern bool mips_hard_regno_rename_ok (unsigned int, unsigned int);
extern unsigned int mips_hard_regno_nregs (int, machine_mode);
extern bool mips_linked_madd_p (rtx, rtx);
extern bool mips_store_data_bypass_p (rtx, rtx);
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index a9829bd..151f774 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -12959,6 +12959,20 @@ mips_hard_regno_mode_ok_p (unsigned int regno,
machine_mode mode)
return false;
}
+/* Return nonzero if register OLD_REG can be renamed to register NEW_REG. */
+
+bool
+mips_hard_regno_rename_ok (unsigned int old_reg ATTRIBUTE_UNUSED,
+ unsigned int new_reg)
+{
+ /* Interrupt functions can only use registers that have already been
+ saved by the prologue, even if they would normally be call-clobbered. */
+ if (cfun-machine-interrupt_handler_p !df_regs_ever_live_p (new_reg))
+return false;
+
+ return true;
+}
+
/* Implement HARD_REGNO_NREGS. */
unsigned int
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 6578ae5..3fe690a 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1932,6 +1932,9 @@ struct mips_cpu_info {
#define HARD_REGNO_MODE_OK(REGNO, MODE)
\
mips_hard_regno_mode_ok[ (int)(MODE) ][ (REGNO) ]
+#define HARD_REGNO_RENAME_OK(OLD_REG, NEW_REG) \
+ mips_hard_regno_rename_ok (OLD_REG, NEW_REG)
+
/* Select a register mode required for caller save of hard regno REGNO. */
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
mips_hard_regno_caller_save_mode (REGNO, NREGS, MODE)
diff --git a/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
b/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
new file mode 100644
index 000..877d00c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
@@ -0,0 +1,12 @@
+/* { dg-options -funroll-loops } */
+int foo;
+int bar;
+
+void __attribute__ ((interrupt)) isr(void)
+{
+ if (!foo)
+ {
+ while (bar 0xFF30);
+ }
+}
+/* { dg-final { scan-assembler-not \\\$8 } } */
--
2.4.5
RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers
I'd like to give Catherine chance to review this, I notice a couple
of formatting nits in the test case:
Robert Suchanek robert.sucha...@imgtec.com writes:
a/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
b/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
new file mode 100644
index 000..877d00c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
@@ -0,0 +1,12 @@
+/* { dg-options -funroll-loops } */
+int foo;
+int bar;
+
+void __attribute__ ((interrupt)) isr(void) {
Newline for function name and whitespace before args
+ if (!foo)
+ {
Double space indent for brace or remove them entirely as it is
single statement.
+ while (bar 0xFF30);
+ }
+}
+/* { dg-final { scan-assembler-not \\\$8 } } */
Thanks,
Matthew
Re: [PATCH ppc64,aarch64,alpha 00/15] Improve backend constant generation
On Wed, Aug 12, 2015 at 11:10 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: On Wed, Aug 12, 2015 at 03:31:48AM -0500, Segher Boessenkool wrote: * This is the only platform for which I bothered collecting any sort of performance data: As best I can tell, there is a 9% improvement in bootstrap speed for ppc64. That is, 10 minutes off the original 109 minute build. That is, wow. Wow :-) Bootstrap + 4 regtests of a virgin trunk du jour took me 127m; with your patches, 130m. So I'm not seeing that improvement (but no regression either). This is gcc110 fwiw. The patch series is fine with me. As Segher mentioned, the performance impact is in the noise for my tests. Thanks, David
Re: [PATCH] Simple optimization for MASK_STORE.
On Thu, Aug 13, 2015 at 1:32 PM, Yuri Rumyantsev ysrum...@gmail.com wrote: Hi Richard, Did you have a chance to look at updated patch? Having a quick look now. Btw, you didn't try the simpler alternative of tree type = type_for_mode (int_mode_for_mode (TYPE_MODE (vectype))); build2 (EQ_EXPR, boolean_type_node, build1 (VIEW_CONVERT, type, op0), build1 (VIEW_CONVERT, type, op1)); ? That is, use the GIMPLE level equivalent of (cmp (subreg:TI reg:V4SI) (subreg:TI reg:V4SI)) ? That should be supported by the expander already, though again not sure if the target(s) have compares that match this. Btw, the tree-cfg.c hook wasn't what was agreed on - the restriction on EQ/NE_EXPR is missing. Operand type equality is tested anyway. Why do you need to restrict forward_propagate_into_comparison_1? Otherwise this looks better, but can you try with the VIEW_CONVERT as well? Thanks, Richard. Thanks. Yuri. 2015-08-06 14:07 GMT+03:00 Yuri Rumyantsev ysrum...@gmail.com: HI All, Here is updated patch which implements Richard proposal to use vector comparison with boolean result instead of target hook. Support for it was added to ix86_expand_branch. Any comments will be appreciated. Bootstrap and regression testing did not show any new failures. ChangeLog: 2015-08-06 Yuri Rumyantsev ysrum...@gmail.com * config/i386/i386.c (ix86_expand_branch): Implement vector comparison with boolean result. * config/i386/sse.md (define_expand cbranchmode4): Add define for vector comparion. * fold-const.c (fold_relational_const): Add handling of vector comparison with boolean result. * params.def (PARAM_ZERO_TEST_FOR_STORE_MASK): New DEFPARAM. * params.h (ENABLE_ZERO_TEST_FOR_STORE_MASK): new macros. * tree-cfg.c (verify_gimple_comparison): Add test for vector comparion with boolean result. * tree-ssa-forwprop.c (forward_propagate_into_comparison_1): Do not propagate vector comparion with boolean result. * tree-vect-stmts.c (vectorizable_mask_load_store): Initialize has_mask_store field of vect_info. * tree-vectorizer.c: Include files ssa.h, cfghooks.h and params.h. (is_valid_sink): New function. (optimize_mask_stores): New function. (vectorize_loops): Invoke optimaze_mask_stores for loops having masked stores. * tree-vectorizer.h (loop_vec_info): Add new has_mask_store field and correspondent macros. gcc/testsuite/ChangeLog: * gcc.target/i386/avx2-vect-mask-store-move1.c: New test. 2015-07-27 11:48 GMT+03:00 Richard Biener richard.guent...@gmail.com: On Fri, Jul 24, 2015 at 9:11 PM, Jeff Law l...@redhat.com wrote: On 07/24/2015 03:16 AM, Richard Biener wrote: Is there any rationale given anywhere for the transformation into conditional expressions? ie, is there any reason why we can't have a GIMPLE_COND where the expression is a vector condition? No rationale for equality compare which would have the semantic of having all elements equal or not equal. But you can't define a sensible ordering (that HW implements) for other compare operators and you obviously need a single boolean result, not a vector of element comparison results. Right. EQ/NE only as others just don't have any real meaning. I've already replied that I'm fine allowing ==/!= whole-vector compares. But one needs to check whether expansion does anything sensible with them (either expand to integer subreg compares or add optabs for the compares). Agreed, EQ/NE for whole vector compares only would be fine for me too under the same conditions. Btw, you can already do this on GIMPLE by doing TImode vec_as_int = VIEW_CONVERT_EXPR TImode (vec_2); if (vec_as_int == 0) ... which is what the RTL will look like in the end. So not sure if making this higher-level in GIMPLE is good or required. Richard. jeff
Re: [patch][libstdc++] Provide nearly complete locale support for DragonFly
On 7/31/2015 6:06 PM, John Marino wrote:
So far, DragonFly only handles the C/POSIX locale through the generic
locale support files, similar to FreeBSD and Darwin. The following
patchset enables nearly complete support for named locales. The except
is for std:messages which requires gettext support in libc which is not
present in any *BSD. For that category, I have left generic support in
place at Jonathan's recommendation.
The support was made by talking the GNU version and adapting it to work
on DragonFly.
Testing has shown these patches to be working. A before test results:
https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01678.html
PASS: 9883
FAIL: 89
XSUCC: 1
XFAIL: 66
UNSUP: 465
The most recent test:
https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg03024.html
PASS: 10074
FAIL: 32
XFAIL: 68
UNSUP: 401
For full disclosure, a number of improvements were made to the OS in the
area of locales, such as DragonFly being the first BSD to acquire full
collation support.
Most of the remaining failures are due to differences in locale
definitions between linux and DragonFly (DragonFly now uses CLDR POSIX
definitions, v2.0.1 currently)
Attachments:
1. combined diff
2. diff between gnu and dragonfly version (FYI)
3. Suggested Changelog entry
This work should be highly interesting for FreeBSD and perhaps darwin as
well. FreeBSD may be able to switch to it directly without any required
modifications, but of course that must be tested.
There is no risk to approving this patchset because it affects only
DragonFly. Please consider approving this for incorporating into trunk
(also recall that my FSF copyright assignment is filed and in order.)
I'd like to ping the original post
(https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02678.html )
and also provide a 2-line revision of the patch set.
The first line adds #include xlocale.h to bits/c++locale.h which is
needed for the locale_t type definition.
The second change adds #define _GLIBCXX_USE_C99 1 to dragonfly's
os_defines.h. We copied FreeBSD's configuration, but FreeBSD doesn't
yet support C99 so it wasn't set there. It fixes several regressions we
found after using GCC a bit.
How does this attached patchset look?
I had to add one line to the suggested Changelog entry for os_defines.h
Regards,
John
Index: libstdc++-v3/acinclude.m4
===
--- libstdc++-v3/acinclude.m4 (revision 226444)
+++ libstdc++-v3/acinclude.m4 (working copy)
@@ -2087,17 +2087,17 @@
dragonfly)
AC_MSG_RESULT(dragonfly)
- CLOCALE_H=config/locale/generic/c_locale.h
+ CLOCALE_H=config/locale/dragonfly/c_locale.h
CLOCALE_CC=config/locale/dragonfly/c_locale.cc
- CCODECVT_CC=config/locale/generic/codecvt_members.cc
- CCOLLATE_CC=config/locale/generic/collate_members.cc
+ CCODECVT_CC=config/locale/dragonfly/codecvt_members.cc
+ CCOLLATE_CC=config/locale/dragonfly/collate_members.cc
CCTYPE_CC=config/locale/dragonfly/ctype_members.cc
CMESSAGES_H=config/locale/generic/messages_members.h
CMESSAGES_CC=config/locale/generic/messages_members.cc
- CMONEY_CC=config/locale/generic/monetary_members.cc
- CNUMERIC_CC=config/locale/generic/numeric_members.cc
- CTIME_H=config/locale/generic/time_members.h
- CTIME_CC=config/locale/generic/time_members.cc
+ CMONEY_CC=config/locale/dragonfly/monetary_members.cc
+ CNUMERIC_CC=config/locale/dragonfly/numeric_members.cc
+ CTIME_H=config/locale/dragonfly/time_members.h
+ CTIME_CC=config/locale/dragonfly/time_members.cc
CLOCALE_INTERNAL_H=config/locale/generic/c++locale_internal.h
;;
Index: libstdc++-v3/config/locale/dragonfly/c_locale.cc
===
--- libstdc++-v3/config/locale/dragonfly/c_locale.cc(revision 226444)
+++ libstdc++-v3/config/locale/dragonfly/c_locale.cc(working copy)
@@ -1,4 +1,4 @@
-// Wrapper for underlying C-language localization -*- C++ -*-
+// localization implementation details, DragonFly version -*- C++ -*-
// Copyright (C) 2014-2015 Free Software Foundation, Inc.
//
@@ -27,19 +27,15 @@
//
// Written by Benjamin Kosnik b...@redhat.com
+// Modified for DragonFly by John Marino gnu...@marino.st
-#include cerrno // For errno
-#include cmath // For isinf, finite, finitef, fabs
-#include cstdlib // For strof, strtold
-#include cstring
-#include cstdio
+#include cstdlib
#include locale
+#include stdexcept
#include limits
+#include langinfo.h
+#include xlocale.h
-#ifdef _GLIBCXX_HAVE_IEEEFP_H
-#include ieeefp.h
-#endif
-
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -47,41 +43,11 @@
template
void
__convert_to_v(const char* __s, float __v, ios_base::iostate __err,
- const __c_locale) throw()
+
[C++ Patch] PR 63693
Hi,
in this ICE on invalid, during error recovery resolve_typename_type gets
a TYPE which has a DECLTYPE_TYPE as TYPE_CONTEXT and
CLASSTYPE_PRIMARY_TEMPLATE_TYPE ICEs on the latter. Checking
CLASS_TYPE_P and thus returning the TYPE as is avoids the ICE and passes
testing on x86_64-linux.
Thanks,
Paolo.
///
/cp
2015-08-13 Paolo Carlini paolo.carl...@oracle.com
PR c++/63693
* pt.c (resolve_typename_type): Don't use
CLASSTYPE_PRIMARY_TEMPLATE_TYPE on non-CLASS_TYPE_P.
/testsuite
2015-08-13 Paolo Carlini paolo.carl...@oracle.com
PR c++/63693
* g++.dg/cpp0x/decltype63.C: New.
Index: cp/pt.c
===
--- cp/pt.c (revision 226855)
+++ cp/pt.c (working copy)
@@ -22669,7 +22669,8 @@ resolve_typename_type (tree type, bool only_curren
return type;
/* If SCOPE isn't the template itself, it will not have a valid
TYPE_FIELDS list. */
- if (same_type_p (scope, CLASSTYPE_PRIMARY_TEMPLATE_TYPE (scope)))
+ if (CLASS_TYPE_P (scope)
+ same_type_p (scope, CLASSTYPE_PRIMARY_TEMPLATE_TYPE (scope)))
/* scope is either the template itself or a compatible instantiation
like XT, so look up the name in the original template. */
scope = CLASSTYPE_PRIMARY_TEMPLATE_TYPE (scope);
Index: testsuite/g++.dg/cpp0x/decltype63.C
===
--- testsuite/g++.dg/cpp0x/decltype63.C (revision 0)
+++ testsuite/g++.dg/cpp0x/decltype63.C (working copy)
@@ -0,0 +1,7 @@
+// PR c++/63693
+// { dg-do compile { target c++11 } }
+
+templatetypename T
+class C{
+ T t;
+ decltype(t)::a:: // { dg-error expected }
[PATCH] Use non-nullness of parameters in SCCVN
Simply register an != 0 expression for them. This should solve Honzas
request to optimize away != 0 checks for this pointers during early opts.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-08-13 Richard Biener rguent...@suse.de
* tree.c (nonnull_arg_p): Move from ...
* tree-vrp.c (nonnull_arg_p): ... here.
* tree.h (nonnull_arg_p): Declare.
* tree-ssa-sccvn.c (init_scc_vn): Perform all lattice init
here, register ptr != 0 for nonnull_arg_p pointer arguments.
Properly initialize static chain and by-reference result pointer.
(run_scc_vn): Adjust.
Index: gcc/tree.c
===
--- gcc/tree.c (revision 226852)
+++ gcc/tree.c (working copy)
@@ -13571,4 +13571,67 @@ verify_type (const_tree t)
}
}
+
+/* Return true if ARG is marked with the nonnull attribute in the
+ current function signature. */
+
+bool
+nonnull_arg_p (const_tree arg)
+{
+ tree t, attrs, fntype;
+ unsigned HOST_WIDE_INT arg_num;
+
+ gcc_assert (TREE_CODE (arg) == PARM_DECL POINTER_TYPE_P (TREE_TYPE
(arg)));
+
+ /* The static chain decl is always non null. */
+ if (arg == cfun-static_chain_decl)
+return true;
+
+ /* THIS argument of method is always non-NULL. */
+ if (TREE_CODE (TREE_TYPE (cfun-decl)) == METHOD_TYPE
+ arg == DECL_ARGUMENTS (cfun-decl)
+ flag_delete_null_pointer_checks)
+return true;
+
+ /* Values passed by reference are always non-NULL. */
+ if (TREE_CODE (TREE_TYPE (arg)) == REFERENCE_TYPE
+ flag_delete_null_pointer_checks)
+return true;
+
+ fntype = TREE_TYPE (cfun-decl);
+ for (attrs = TYPE_ATTRIBUTES (fntype); attrs; attrs = TREE_CHAIN (attrs))
+{
+ attrs = lookup_attribute (nonnull, attrs);
+
+ /* If nonnull wasn't specified, we know nothing about the argument. */
+ if (attrs == NULL_TREE)
+ return false;
+
+ /* If nonnull applies to all the arguments, then ARG is non-null. */
+ if (TREE_VALUE (attrs) == NULL_TREE)
+ return true;
+
+ /* Get the position number for ARG in the function signature. */
+ for (arg_num = 1, t = DECL_ARGUMENTS (cfun-decl);
+ t;
+ t = DECL_CHAIN (t), arg_num++)
+ {
+ if (t == arg)
+ break;
+ }
+
+ gcc_assert (t == arg);
+
+ /* Now see if ARG_NUM is mentioned in the nonnull list. */
+ for (t = TREE_VALUE (attrs); t; t = TREE_CHAIN (t))
+ {
+ if (compare_tree_int (TREE_VALUE (t), arg_num) == 0)
+ return true;
+ }
+}
+
+ return false;
+}
+
+
#include gt-tree.h
Index: gcc/tree.h
===
--- gcc/tree.h (revision 226852)
+++ gcc/tree.h (working copy)
@@ -5133,4 +5133,6 @@ extern void gt_ggc_mx (tree );
extern void gt_pch_nx (tree );
extern void gt_pch_nx (tree , gt_pointer_operator, void *);
+extern bool nonnull_arg_p (const_tree);
+
#endif /* GCC_TREE_H */
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 226852)
+++ gcc/tree-vrp.c (working copy)
@@ -355,68 +355,6 @@ avoid_overflow_infinity (tree val)
}
-/* Return true if ARG is marked with the nonnull attribute in the
- current function signature. */
-
-static bool
-nonnull_arg_p (const_tree arg)
-{
- tree t, attrs, fntype;
- unsigned HOST_WIDE_INT arg_num;
-
- gcc_assert (TREE_CODE (arg) == PARM_DECL POINTER_TYPE_P (TREE_TYPE
(arg)));
-
- /* The static chain decl is always non null. */
- if (arg == cfun-static_chain_decl)
-return true;
-
- /* THIS argument of method is always non-NULL. */
- if (TREE_CODE (TREE_TYPE (current_function_decl)) == METHOD_TYPE
- arg == DECL_ARGUMENTS (current_function_decl)
- flag_delete_null_pointer_checks)
-return true;
-
- /* Values passed by reference are always non-NULL. */
- if (TREE_CODE (TREE_TYPE (arg)) == REFERENCE_TYPE
- flag_delete_null_pointer_checks)
-return true;
-
- fntype = TREE_TYPE (current_function_decl);
- for (attrs = TYPE_ATTRIBUTES (fntype); attrs; attrs = TREE_CHAIN (attrs))
-{
- attrs = lookup_attribute (nonnull, attrs);
-
- /* If nonnull wasn't specified, we know nothing about the argument. */
- if (attrs == NULL_TREE)
- return false;
-
- /* If nonnull applies to all the arguments, then ARG is non-null. */
- if (TREE_VALUE (attrs) == NULL_TREE)
- return true;
-
- /* Get the position number for ARG in the function signature. */
- for (arg_num = 1, t = DECL_ARGUMENTS (current_function_decl);
- t;
- t = DECL_CHAIN (t), arg_num++)
- {
- if (t == arg)
- break;
- }
-
- gcc_assert (t == arg);
-
- /* Now see if ARG_NUM is mentioned in the nonnull list. */
- for (t = TREE_VALUE (attrs); t; t = TREE_CHAIN (t))
- {
- if
Re: [PATCH][AArch64][1/3] Expand signed mod by power of 2 using CSNEG
On 03/08/15 14:01, James Greenhalgh wrote:
On Fri, Jul 24, 2015 at 11:55:33AM +0100, Kyrill Tkachov wrote:
Hi all,
This patch implements an aarch64-specific expansion of the signed modulo by a
power of 2.
The proposed sequence makes use of the conditional negate instruction CSNEG.
For a power of N, x % N can be calculated with:
negs x1, x0
andx0, x0, #(N - 1)
andx1, x1, #(N - 1)
csneg x0, x0, x1, mi
So, for N == 256 this would be:
negs x1, x0
andx0, x0, #255
andx1, x1, #255
csneg x0, x0, x1, mi
For comparison, the existing sequence emitted by expand_smod_pow2 in expmed.c
is:
asr x1, x0, 63
lsr x1, x1, 56
add x0, x0, x1
and x0, x0, 255
sub x0, x0, x1
Note that the CSNEG sequence is one instruction shorter and that the two and
operations
are independent, compared to the existing sequence where all instructions are
dependent
on the preceeding instructions.
For the special case of N == 2 we can do even better:
cmp x0, xzr
and x0, x0, 1
csneg x0, x0, x0, ge
I first tried implementing this in the generic code in expmed.c but that didn't
work
out for a few reasons:
* This relies on having a conditional-negate instruction. We could gate it on
HAVE_conditional_move and the combiner is capable of merging the final negate
into
the conditional move if a conditional negate is available (like on aarch64) but
on
targets without a conditional negate this would end up emitting a separate
negate.
* The first negs has to be a negs for the sequence to be a win i.e. having a
separate
negate and compare makes the sequence slower than the existing one (at least in
my
microbenchmarking) and I couldn't get subsequent passes to combine the negate
and combine
into the negs (presumably due to the use of the negated result in one of the
ands).
Doing it in the aarch64 backend where I could just call the exact gen_*
functions that
I need worked much more cleanly.
The costing logic is updated to reflect this sequence during the intialisation
of
expmed.c where it calculates the smod_pow2_cheap metric.
The tests will come in patch 3 of the series which are partly shared with the
equivalent
arm implementation.
Bootstrapped and tested on aarch64.
Ok for trunk?
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 9d88a60..7bb4a55 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6639,8 +6639,26 @@ cost_plus:
if (VECTOR_MODE_P (mode))
*cost += extra_cost-vect.alu;
else if (GET_MODE_CLASS (mode) == MODE_INT)
- *cost += (extra_cost-mult[mode == DImode].add
- + extra_cost-mult[mode == DImode].idiv);
+ {
+ /* We can expand signed mod by power of 2 using a
+NEGS, two parallel ANDs and a CSNEG. Assume here
+that CSNEG is COSTS_N_INSNS (1). This case should
+only ever be reached through the set_smod_pow2_cheap check
+in expmed.c. */
+ if (code == MOD
+ CONST_INT_P (XEXP (x, 1))
+ exact_log2 (INTVAL (XEXP (x, 1))) 0
+ (mode == SImode || mode == DImode))
+ {
+ *cost += COSTS_N_INSNS (3)
+ + 2 * extra_cost-alu.logical
+ + extra_cost-alu.arith;
+ return true;
+ }
+
+ *cost += (extra_cost-mult[mode == DImode].add
+ + extra_cost-mult[mode == DImode].idiv);
+ }
else if (mode == DFmode)
*cost += (extra_cost-fp[1].mult
+ extra_cost-fp[1].div);
This looks like it calculates the wrong cost for !speed. I think we will
still expand through modmode3 when compiling for size, so we probably
still want to cost the multiple instructions.
Have I misunderstood?
You're right, the logic needs a bit of wiggling to do the right
thing. I've moved this case into a separate MOD case and added
a gate on speed for the extra costs addition.
Ok?
Thanks,
Kyrill
2015-08-13 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/aarch64/aarch64.md (modmode3): New define_expand.
(*negmode2_compare0): Rename to...
(negmode2_compare0): ... This.
* config/aarch64/aarch64.c (aarch64_rtx_costs, MOD case):
Move check for speed inside the if-then-elses. Reflect
CSNEG sequence in MOD by power of 2 case.
Thanks,
James
commit de67e5fba716ce835f595c4167f57ec4faf61607
Author: Kyrylo Tkachov kyrylo.tkac...@arm.com
Date: Wed Jul 15 17:01:13 2015 +0100
[AArch64][1/3] Expand signed mod by power of 2 using CSNEG
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 1394ed7..c8bd8d2 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6652,6 +6652,25 @@ cost_plus:
return true;
case MOD:
+/* We can expand signed mod by power of 2 using a
+ NEGS,
[PATCH] [Ada] Make the stack non-executable in GNAT tools
Due to PR67205, the deeply nested instantiations require trampolines, which in turn requires an executable stack for the GNAT tools on architectures such as x86_64. Bootstrapped on x86_64-redhat-linux-gnu, and make check-ada reports no unexpected failures. Okay for trunk? -- Florian Weimer / Red Hat Product Security 2015-08-13 Florian Weimer fwei...@redhat.com * prj.adb (For_Every_Project_Imported_Context.Recursive_Check_Context): Move Name_Id_Set instantiation to the Prj package, to avoid trampolines. * prj-proc.adb (Process.Process_Expression_Variable_Decl): Move Name_Ids instantiation to the Prj.Proc package, to avoid trampolines. diff --git a/gcc/ada/prj-proc.adb b/gcc/ada/prj-proc.adb index 57b88c6..3a014f1 100644 --- a/gcc/ada/prj-proc.adb +++ b/gcc/ada/prj-proc.adb @@ -72,6 +72,8 @@ package body Prj.Proc is Equal = =); -- Stores the default values of 'Runtime names for the various languages + package Name_Ids is new Ada.Containers.Vectors (Positive, Name_Id); + procedure Add (To_Exp : in out Name_Id; Str : Name_Id); -- Concatenate two strings and returns another string if both -- arguments are not null string. @@ -2193,8 +2195,6 @@ package body Prj.Proc is if Is_Attribute and then Name = Snames.Name_Project_Path then if In_Tree.Is_Root_Tree then declare - package Name_Ids is -new Ada.Containers.Vectors (Positive, Name_Id); Val : String_List_Id := New_Value.Values; List : Name_Ids.Vector; begin diff --git a/gcc/ada/prj.adb b/gcc/ada/prj.adb index 9da0f44..0deb39b 100644 --- a/gcc/ada/prj.adb +++ b/gcc/ada/prj.adb @@ -76,6 +76,9 @@ package body Prj is All_Upper_Case = All_Upper_Case_Image'Access, Mixed_Case = Mixed_Case_Image'Access); + package Name_Id_Set is + new Ada.Containers.Ordered_Sets (Element_Type = Name_Id); + procedure Free (Project : in out Project_Id); -- Free memory allocated for Project @@ -589,9 +592,6 @@ package body Prj is In_Aggregate_Lib : Boolean; From_Encapsulated_Lib : Boolean) is - package Name_Id_Set is - new Ada.Containers.Ordered_Sets (Element_Type = Name_Id); - Seen_Name : Name_Id_Set.Set; -- This set is needed to ensure that we do not handle the same -- project twice in the context of aggregate libraries.
[patch] Add SD-6 features test macros for recent libstdc++ changes
Subject says it all.
Tested ppc64le-linux, committing to trunk.
commit d7f997a59a1383b7f08618fbf1d7855edb5fa012
Author: Jonathan Wakely jwak...@redhat.com
Date: Thu Aug 13 10:27:59 2015 +0100
* include/bits/alloc_traits.h: Add feature-test macro.
* include/bits/allocator.h: Likewise.
* include/bits/range_access.h: Likewise.
* include/bits/stl_map.h: Likewise.
* include/bits/unordered_map.h: Likewise.
diff --git a/libstdc++-v3/include/bits/alloc_traits.h b/libstdc++-v3/include/bits/alloc_traits.h
index e5ed92b..565b89b 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -36,6 +36,8 @@
#include bits/ptr_traits.h
#include ext/numeric_traits.h
+#define __cpp_lib_allocator_traits_is_always_equal 201411
+
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
diff --git a/libstdc++-v3/include/bits/allocator.h b/libstdc++-v3/include/bits/allocator.h
index c7a2503..6fd3214 100644
--- a/libstdc++-v3/include/bits/allocator.h
+++ b/libstdc++-v3/include/bits/allocator.h
@@ -78,6 +78,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// 2103. std::allocator propagate_on_container_move_assignment
typedef true_type propagate_on_container_move_assignment;
+#define __cpp_lib_allocator_is_always_equal 201411
typedef true_type is_always_equal;
#endif
};
diff --git a/libstdc++-v3/include/bits/range_access.h b/libstdc++-v3/include/bits/range_access.h
index 586d162..aa78afb 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -223,6 +223,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#endif // C++14
#if __cplusplus 201402L
+#define __cpp_lib_nonmember_container_access 201411
/**
* @brief Return the size of a container.
diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index 68ab6da..dff9f9c 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -591,7 +591,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
std::forward_Args(__args)...);
}
#endif
+
#if __cplusplus 201402L
+#define __cpp_lib_map_try_emplace 201411
/**
* @brief Attempts to build and insert a std::pair into the %map.
*
@@ -708,6 +710,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
return __i;
}
#endif
+
/**
* @brief Attempts to insert a std::pair into the %map.
@@ -805,6 +808,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{ _M_t._M_insert_unique(__first, __last); }
#if __cplusplus 201402L
+#define __cpp_lib_map_insertion 201411
/**
* @brief Attempts to insert or assign a std::pair into the %map.
* @param __kKey to use for finding a possibly existing pair in
diff --git a/libstdc++-v3/include/bits/unordered_map.h b/libstdc++-v3/include/bits/unordered_map.h
index 15d4b8b..1b90459 100644
--- a/libstdc++-v3/include/bits/unordered_map.h
+++ b/libstdc++-v3/include/bits/unordered_map.h
@@ -412,6 +412,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
#if __cplusplus 201402L
+#define __cpp_lib_unordered_map_try_emplace 201411
/**
* @brief Attempts to build and insert a std::pair into the
* %unordered_map.
@@ -617,6 +618,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
#if __cplusplus 201402L
+#define __cpp_lib_unordered_map_insertion 201411
/**
* @brief Attempts to insert a std::pair into the %unordered_map.
* @param __kKey to use for finding a possibly existing pair in
[v3 PATCH] Add C++11 cuchar
Greetings,
Now that most systems have uchar.h for conversion between char16_t* and
char32_t* to multibyte (analogue of wchar.h and cwchar) i think we
should check off this last little crumb of C++11.
I submitted this a while back but Jonathan suggested improvements and it
took me a hot minute to wade through autohell.
Built and tested clean on x86_64-linux.
OK?
2015-08-13 Edward Smith-Rowland 3dw...@verizon.net
Add C++11 header cuchar.
* acinclude.m4: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for uchar.h.
* include/Makefile.am: Check for uchar.h.
* include/Makefile.in: Regenerate.
* include/c/cuchar: New.
* include/c_compatibility/uchar.h: New.
* include/c_global/cuchar: New.
* include/c_std/cuchar: New.
* include/precompiled/stdc++.h: Include cuchar.
* testsuite/17_intro/headers/c++200x/stdc++.cc: Include uchar.h.
* testsuite/17_intro/headers/c++200x/stdc++_multiple_inclusion.cc:
Include uchar.h.
Index: acinclude.m4
===
--- acinclude.m4(revision 226808)
+++ acinclude.m4(working copy)
@@ -1926,6 +1926,51 @@
])
dnl
+dnl Check for uchar.h and usability.
+dnl
+AC_DEFUN([GLIBCXX_ENABLE_CUCHAR], [
+
+ # Test uchar.h.
+ AC_MSG_CHECKING([for ISO C11 support for uchar.h for C++11 cuchar])
+ AC_CHECK_HEADERS(uchar.h, ac_has_uchar_h=yes, ac_has_uchar_h=no)
+ AC_MSG_RESULT($ac_has_uchar_h)
+
+ AC_LANG_SAVE
+ AC_LANG_CPLUSPLUS
+
+ if test x$ac_has_uchar_h = xyes; then
+AC_TRY_COMPILE([#include uchar.h
+ #ifdef __STDC_UTF_16__
+ long i = __STDC_UTF_16__;
+ #endif
+ #ifdef __STDC_UTF_32__
+ long j = __STDC_UTF_32__;
+ #endif
+ namespace test
+ {
+ using ::c16rtomb;
+ using ::c32rtomb;
+ using ::mbrtoc16;
+ using ::mbrtoc32;
+ }
+ ],
+ [], [ac_c11_uchar_cxx11=yes], [ac_c11_uchar_cxx11=no])
+ else
+ac_c11_uchar_cxx11=no
+ fi
+ AC_MSG_RESULT($ac_c11_uchar_cxx11)
+ if test x$ac_c11_uchar_cxx11 = xyes; then
+AC_DEFINE(_GLIBCXX_USE_C11_UCHAR_CXX11, 1,
+ [Define if C11 functions in uchar.h should be imported in
+ cuchar in namespace std.])
+ fi
+
+ AC_LANG_RESTORE
+ AC_MSG_RESULT($enable_libstdcxx_cuchar)
+ GLIBCXX_CONDITIONAL(ENABLE_CUCHAR, test $enable_libstdcxx_cuchar = yes)
+])
+
+dnl
dnl Check for what type of C headers to use.
dnl
dnl --enable-cheaders= [does stuff].
Index: config.h.in
===
--- config.h.in (revision 226808)
+++ config.h.in (working copy)
@@ -454,6 +454,9 @@
/* Define to 1 if the target supports thread-local storage. */
#undef HAVE_TLS
+/* Define to 1 if you have the uchar.h header file. */
+#undef HAVE_UCHAR_H
+
/* Define to 1 if you have the unistd.h header file. */
#undef HAVE_UNISTD_H
@@ -780,6 +783,10 @@
/* Define to use Sun versioning in the shared library. */
#undef _GLIBCXX_SYMVER_SUN
+/* Define if C11 functions in uchar.h should be imported in cuchar in
+ namespace std. */
+#undef _GLIBCXX_USE_C11_UCHAR_CXX11
+
/* Define if C99 functions or macros from wchar.h, math.h, complex.h,
stdio.h, and stdlib.h can be used or exposed. */
#undef _GLIBCXX_USE_C99
Index: configure
===
--- configure (revision 226808)
+++ configure (working copy)
@@ -671,6 +671,8 @@
OPT_LDFLAGS
SECTION_LDFLAGS
GLIBCXX_LIBS
+ENABLE_CUCHAR_FALSE
+ENABLE_CUCHAR_TRUE
ENABLE_VTABLE_VERIFY_FALSE
ENABLE_VTABLE_VERIFY_TRUE
VTV_CYGMIN_FALSE
@@ -11594,7 +11596,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat conftest.$ac_ext _LT_EOF
-#line 11597 configure
+#line 11599 configure
#include confdefs.h
#if HAVE_DLFCN_H
@@ -11700,7 +11702,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat conftest.$ac_ext _LT_EOF
-#line 11703 configure
+#line 11705 configure
#include confdefs.h
#if HAVE_DLFCN_H
@@ -15386,7 +15388,7 @@
# Fake what AC_TRY_COMPILE does.
cat conftest.$ac_ext EOF
-#line 15389 configure
+#line 15391 configure
int main()
{
typedef bool atomic_type;
@@ -15421,7 +15423,7 @@
rm -f conftest*
cat conftest.$ac_ext EOF
-#line 15424 configure
+#line 15426 configure
int main()
{
typedef short atomic_type;
@@ -15456,7 +15458,7 @@
rm -f conftest*
cat conftest.$ac_ext EOF
-#line 15459 configure
+#line 15461 configure
int main()
{
// NB: _Atomic_word not necessarily int.
@@ -15492,7 +15494,7 @@
rm -f conftest*
cat conftest.$ac_ext EOF
-#line
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
On 2015.08.13 at 15:40 +0200, Marek Polacek wrote: On Thu, Aug 13, 2015 at 01:11:53PM +0200, Richard Biener wrote: Rather ubsan should not complain about implementation defined behavior (or should separate those cases out with a different switch compared to undefined behavior). I think ubsan doesn't complain about implementation-defined behavior. It seems to me that in this thread it only (rightfully) complained about left-shifting of negative value. There are two issues in the same location: 1) gcc/hwint.h:250:19: runtime error: left shift of 8589934588 by 32 places cannot be represented in type 'long int' 2) left-shifting of negative values -- Markus
[PATCH] Forward to correct function in std::shared_mutex::unlock().
This commits the patch from
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00663.html and adds
tests for all the mutex types.
Eelis, thanks for the patch. Please CC the libstdc++ list for all
libstdc++ patches, I don't subscribe to gcc-patches and only saw your
mail because Ville brought it to my attention.
Tested ppc64le-linux, committed to trunk.
commit 88dda918ab3602d1fb9ba7fe6454211d02160f92
Author: Jonathan Wakely jwak...@redhat.com
Date: Thu Aug 13 14:44:11 2015 +0100
* testsuite/30_threads/mutex/unlock/2.cc: New.
* testsuite/30_threads/recursive_mutex/unlock/2.cc: New.
* testsuite/30_threads/recursive_timed_mutex/unlock/2.cc: New.
* testsuite/30_threads/shared_mutex/unlock/1.cc: New.
* testsuite/30_threads/shared_timed_mutex/unlock/1.cc: New.
* testsuite/30_threads/timed_mutex/unlock/2.cc: New.
diff --git a/libstdc++-v3/testsuite/30_threads/mutex/unlock/2.cc b/libstdc++-v3/testsuite/30_threads/mutex/unlock/2.cc
new file mode 100644
index 000..02464cd
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/mutex/unlock/2.cc
@@ -0,0 +1,43 @@
+// { dg-do run { target *-*-freebsd* *-*-dragonfly* *-*-netbsd* *-*-linux* *-*-gnu* *-*-solaris* *-*-cygwin *-*-darwin* powerpc-ibm-aix* } }
+// { dg-options -std=gnu++11 -pthread { target *-*-freebsd* *-*-dragonfly* *-*-netbsd* *-*-linux* *-*-gnu* powerpc-ibm-aix* } }
+// { dg-options -std=gnu++11 -pthreads { target *-*-solaris* } }
+// { dg-options -std=gnu++11 { target *-*-cygwin *-*-darwin* } }
+// { dg-require-cstdint }
+// { dg-require-gthreads }
+
+// Copyright (C) 2015 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
+// http://www.gnu.org/licenses/.
+
+#include mutex
+#include thread
+
+using mutex_type = std::mutex;
+
+mutex_type m;
+
+void f()
+{
+ std::lock_guardmutex_type l(m);
+}
+
+int main()
+{
+ std::thread t1(f);
+ std::thread t2(f);
+ t1.join();
+ t2.join();
+}
diff --git a/libstdc++-v3/testsuite/30_threads/recursive_mutex/unlock/2.cc b/libstdc++-v3/testsuite/30_threads/recursive_mutex/unlock/2.cc
new file mode 100644
index 000..68bd5d0
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/recursive_mutex/unlock/2.cc
@@ -0,0 +1,43 @@
+// { dg-do run { target *-*-freebsd* *-*-dragonfly* *-*-netbsd* *-*-linux* *-*-gnu* *-*-solaris* *-*-cygwin *-*-darwin* powerpc-ibm-aix* } }
+// { dg-options -std=gnu++11 -pthread { target *-*-freebsd* *-*-dragonfly* *-*-netbsd* *-*-linux* *-*-gnu* powerpc-ibm-aix* } }
+// { dg-options -std=gnu++11 -pthreads { target *-*-solaris* } }
+// { dg-options -std=gnu++11 { target *-*-cygwin *-*-darwin* } }
+// { dg-require-cstdint }
+// { dg-require-gthreads }
+
+// Copyright (C) 2015 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
+// http://www.gnu.org/licenses/.
+
+#include mutex
+#include thread
+
+using mutex_type = std::recursive_mutex;
+
+mutex_type m;
+
+void f()
+{
+ std::lock_guardmutex_type l(m);
+}
+
+int main()
+{
+ std::thread t1(f);
+ std::thread t2(f);
+ t1.join();
+ t2.join();
+}
diff --git a/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc b/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc
new file mode 100644
index 000..ac51f43
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc
@@ -0,0 +1,43 @@
+// { dg-do run { target *-*-freebsd* *-*-dragonfly* *-*-netbsd* *-*-linux* *-*-gnu* *-*-solaris* *-*-cygwin *-*-darwin* powerpc-ibm-aix* } }
+// { dg-options -std=gnu++11 -pthread { target *-*-freebsd* *-*-dragonfly* *-*-netbsd* *-*-linux* *-*-gnu* powerpc-ibm-aix* } }
+// { dg-options -std=gnu++11 -pthreads { target *-*-solaris* } }
+// { dg-options
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
On Thu, Aug 13, 2015 at 01:11:53PM +0200, Richard Biener wrote: Rather ubsan should not complain about implementation defined behavior (or should separate those cases out with a different switch compared to undefined behavior). I think ubsan doesn't complain about implementation-defined behavior. It seems to me that in this thread it only (rightfully) complained about left-shifting of negative value. Using __GCC__ conditional in a case where we rely on what gcc does when right-shifting a negative value, i.e. that it sign-extends, seems fine (ubsan certainly doesn't error on that). Marek
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
On Thu, Aug 13, 2015 at 03:52:00PM +0200, Markus Trippelsdorf wrote: On 2015.08.13 at 15:40 +0200, Marek Polacek wrote: On Thu, Aug 13, 2015 at 01:11:53PM +0200, Richard Biener wrote: Rather ubsan should not complain about implementation defined behavior (or should separate those cases out with a different switch compared to undefined behavior). I think ubsan doesn't complain about implementation-defined behavior. It seems to me that in this thread it only (rightfully) complained about left-shifting of negative value. There are two issues in the same location: 1) gcc/hwint.h:250:19: runtime error: left shift of 8589934588 by 32 places cannot be represented in type 'long int' 2) left-shifting of negative values I see, both are UB. Marek
Re: [wwwdocs] Re: C++ Concepts available in trunk?
And a small correction. On 13 August 2015 at 10:24, Jonathan Wakely jwakely@gmail.com wrote: Here's the patch for the rest of the C++17 support. On 13 August 2015 at 09:58, Jonathan Wakely jwakely@gmail.com wrote: On 12 August 2015 at 23:54, Dijk, J. van wrote: Thanks for the clarification. I hope the attached patch against current wwwdocs will be of use (only the name of the feature test macro is missing in the new file cxx1z.html; did not manage to find that.) Thanks, I've committed the attached change to the wwwdocs repo. I'll add the other new C++17 features to it later today. Index: htdocs/projects/cxx1z.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx1z.html,v retrieving revision 1.2 diff -u -r1.2 cxx1z.html --- htdocs/projects/cxx1z.html 13 Aug 2015 09:24:30 - 1.2 +++ htdocs/projects/cxx1z.html 13 Aug 2015 14:31:40 - @@ -62,7 +62,7 @@ tr td Folding expressions/td tda href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4295.html;N4295/a /td - td class=supported align=center 6 /td + td class=unsupported align=center No /td td __cpp_fold_expressions gt;= 201411/td /tr tr
Re: [PATCH 2/2] replace several uses of the anon namespace with GCC_FINAL
On Wed, Aug 12, 2015 at 4:30 PM, Trevor Saunders tbsau...@tbsaunde.org wrote: On Wed, Aug 12, 2015 at 03:31:35PM -0400, David Edelsohn wrote: This patch has caused a bootstrap failure on AIX. reverted, though my bet is this is some sort of generic devirt bug on aix. bootstrap with GCC 5 does not help. - David
Re: [Aarch64][target/PR 67143] Use correct constraints on operands for atomic operations.
On 12/08/15 22:26, Joseph Myers wrote:
On Tue, 11 Aug 2015, Matthew Wahab wrote:
PR target/67143
* gcc.target/aarch64/pr67143.c: New
What's architecture-specific about this test? That is, why doesn't it
just go in gcc.c-torture/compile (no dg- directives needed, automatically
looped over optimization options)?
Attached is an updated patch which puts the pr67143.c test case in
gcc.c-torture/compile and drops the dg- directives.
Tested for aarch64-none-eabi with cross-compiled check-gcc. Also ran
check-gcc for x86_64-none-linux-gnu, to check the new test case.
Ok?
Matthew
gcc/
2015-08-13 Matthew Wahab matthew.wa...@arm.com
PR target/67143
* config/aarch64/atomics.md (atomic_optabmode): Replace
'lconst_atomic' with 'const_atomic'.
(atomic_fetch_optabmode): Likewise.
(atomic_optab_fetchmode): Likewise.
* config/aarch64/iterators.md (lconst-atomic): Move below
'const_atomic'.
(const_atomic): New.
gcc/testsuite/
2015-08-13 Matthew Wahab matthew.wa...@arm.com
Matthias Klose d...@debian.org
PR target/67143
* gcc.c-torture/compile/pr67143.c: New
* gcc.target/aarch64/atomic-op-imm.c
(atomic_fetch_add_negative_RELAXED): New.
(atomic_fetch_sub_negative_ACQUIRE): New.
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
index 1a38ac0..6e6be99 100644
--- a/gcc/config/aarch64/atomics.md
+++ b/gcc/config/aarch64/atomics.md
@@ -119,7 +119,7 @@
[(set (match_operand:ALLI 0 aarch64_sync_memory_operand +Q)
(unspec_volatile:ALLI
[(atomic_op:ALLI (match_dup 0)
- (match_operand:ALLI 1 atomic_op_operand rlconst_atomic))
+ (match_operand:ALLI 1 atomic_op_operand rconst_atomic))
(match_operand:SI 2 const_int_operand)] ;; model
UNSPECV_ATOMIC_OP))
(clobber (reg:CC CC_REGNUM))
@@ -164,7 +164,7 @@
(set (match_dup 1)
(unspec_volatile:ALLI
[(atomic_op:ALLI (match_dup 1)
- (match_operand:ALLI 2 atomic_op_operand rlconst_atomic))
+ (match_operand:ALLI 2 atomic_op_operand rconst_atomic))
(match_operand:SI 3 const_int_operand)] ;; model
UNSPECV_ATOMIC_OP))
(clobber (reg:CC CC_REGNUM))
@@ -209,7 +209,7 @@
[(set (match_operand:ALLI 0 register_operand =r)
(atomic_op:ALLI
(match_operand:ALLI 1 aarch64_sync_memory_operand +Q)
- (match_operand:ALLI 2 atomic_op_operand rlconst_atomic)))
+ (match_operand:ALLI 2 atomic_op_operand rconst_atomic)))
(set (match_dup 1)
(unspec_volatile:ALLI
[(match_dup 1) (match_dup 2)
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 5d7966d..b8a45d1 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -345,9 +345,6 @@
;; Attribute to describe constants acceptable in logical operations
(define_mode_attr lconst [(SI K) (DI L)])
-;; Attribute to describe constants acceptable in atomic logical operations
-(define_mode_attr lconst_atomic [(QI K) (HI K) (SI K) (DI L)])
-
;; Map a mode to a specific constraint character.
(define_mode_attr cmode [(QI q) (HI h) (SI s) (DI d)])
@@ -843,6 +840,16 @@
(plus aarch64_plus_operand)
(minus aarch64_plus_operand)])
+;; Constants acceptable for atomic operations.
+;; This definition must appear in this file before the iterators it refers to.
+(define_code_attr const_atomic
+ [(plus IJ) (minus IJ)
+ (xor lconst_atomic) (ior lconst_atomic)
+ (and lconst_atomic)])
+
+;; Attribute to describe constants acceptable in atomic logical operations
+(define_mode_attr lconst_atomic [(QI K) (HI K) (SI K) (DI L)])
+
;; ---
;; Int Iterators.
;; ---
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr67143.c b/gcc/testsuite/gcc.c-torture/compile/pr67143.c
new file mode 100644
index 000..62c4186
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr67143.c
@@ -0,0 +1,21 @@
+long a, c;
+int b;
+int d;
+void ut_dbg_assertion_failed() __attribute__((noreturn));
+long dict_index_is_spatial(int *);
+void btr_block_get_func(char *);
+long btr_page_get_level_low(unsigned char *);
+void btr_validate_level(long p1) {
+ unsigned char *e;
+ while (p1 != btr_page_get_level_low(e)) {
+if (__builtin_expect(b, 0))
+ ut_dbg_assertion_failed();
+if (dict_index_is_spatial(d))
+ while (c != 5535) {
+__sync_add_and_fetch(a, 536870912);
+btr_block_get_func();
+ }
+ }
+ for (long i; i; ++i)
+btr_validate_level(-i);
+}
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-imm.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-imm.c
index 6c6f7e1..47d7a96 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-imm.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-imm.c
@@ -16,6 +16,18 @@ atomic_fetch_sub_ACQUIRE ()
}
int
+atomic_fetch_add_negative_RELAXED ()
+{
+ return
Re: [v3 PATCH] Add C++11 cuchar
On 13/08/15 10:37 -0400, Ed Smith-Rowland wrote:
Greetings,
Now that most systems have uchar.h for conversion between char16_t*
and char32_t* to multibyte (analogue of wchar.h and cwchar) i think we
should check off this last little crumb of C++11.
Ooh, I forgot about this, thanks!
Add C++11 header cuchar.
* acinclude.m4: Regenerate.
This file isn't auto-generated, so the changelog is wrong. Maybe
something like:
acinclude.m4 (GLIBCXX_ENABLE_CUCHAR): Define.
Index: include/Makefile.am
===
--- include/Makefile.am (revision 226808)
+++ include/Makefile.am (working copy)
@@ -709,6 +709,7 @@
${c_base_srcdir}/cstring \
${c_base_srcdir}/ctgmath \
${c_base_srcdir}/ctime \
+ ${c_base_srcdir}/cuchar \
${c_base_srcdir}/cwchar \
${c_base_srcdir}/cwctype
@@ -751,10 +752,19 @@
${c_compatibility_srcdir}/string.h \
${c_compatibility_srcdir}/tgmath.h \
${c_compatibility_srcdir}/time.h \
+ ${c_compatibility_srcdir}/uchar.h \
${c_compatibility_srcdir}/wchar.h \
${c_compatibility_srcdir}/wctype.h
endif
+if ENABLE_CUCHAR
+cuchar_headers = \
+ ${c_base_srcdir}/cuchar \
+ ${c_compatibility_srcdir}/uchar.h
+else
+cuchar_headers =
+endif
This cuchar_headers variable doesn't seem to be used anywhere, am I
missing something?
It looks like the headers are installed unconditionally, and this
ENABLE_CUCHAR block isn't needed (and so the GLIBCXX_CONDITIONAL that
creates it in acinclude.m4 isn't needed either).
+// Copyright (C) 2013 Free Software Foundation, Inc.
A few of the new files have 2013 as the copyright date, not 2015
(I'm always forgetting to update the dates when I return to old
patches that have been uncommitted for a while!)
[PATCH, FIXINCLUDES] AIX stdio C++ inline fix
AIX stdio.h header includes code specific for C++ that looks like:
extern C {
#ifdef __cplusplus
#ifdef ferror
#undef ferror
inline int ferror(FILE * _p)
{
return ((_p)-_flag _IOERR);
}
#endif /*ferror*/
which generates code that makes the AIX linker and loader rather upset
because the inline function is not mangled and conflicts with the C
library.
This fixincludes patch protects this code with an addition test for
IBMCPP (not that IBMCPP will use GCC include-fixed headers, but ).
Okay?
Thanks, David
* inclhack.def (aix_stdio_inline): New fix.
* fixincl.x: Regenerated.
* test/base/stdio.h [AIX_STDIO_INLINE]: New test.
Index: inclhack.def
===
--- inclhack.def(revision 226860)
+++ inclhack.def(working copy)
@@ -892,10 +892,32 @@
};
/*
+ * stdio.h on AIX defines ferror, clearerr and feof as C++ inline, which
+ produces wrong code with G++.
+ */
+fix = {
+hackname = aix_stdio_inline;
+mach = *-*-aix*;
+files = stdio.h;
+select= #ifdef __cplusplus\\\n
+}\\\n\\\n
+#ifdef ferror\\\n;
+c_fix = format;
+c_fix_arg = #ifdef __cplusplus\n
+}\n
+#endif\n\n
+#if (defined(__cplusplus) defined(__IBMCPP__))\n
+#ifdef ferror\n;
+test_text = #ifdef __cplusplus\n}\n\n#ifdef ferror;
+};
+
+
+/*
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
On Aug 13, 2015, at 3:05 AM, Richard Biener richard.guent...@gmail.com wrote: Ok, then guard the with __GCC__ and do the expensive bit stuff otherwise. Just to cater for other host compilers doing sth unsensibly implementation defined. Ick. The guard should be specific to the implementation defined semantic or undefined semantic, and then when compiling with gcc, we turn it on. My take is that when we do this, we should add the 5 or 10 other most popular compilers to the list of how they behave so that they all do the cheap path code as well. If the language standard were serious in this area, it would specify a header file that can define the implementation defined and undefined semantics that are interesting for portable code. It isn’t. If it were, we would then just use the standard defined guards. The language standard should be improved to directly state the possible implementation choices and to require the implementation to communicate to the program which choice it made.
RE: [PATCH] [graphite] Constrain only on INTEGER_TYPE
Date: Thu, 13 Aug 2015 12:02:43 +0200 Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE From: richard.guent...@gmail.com To: tob...@grosser.es CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org; s@samsung.com; seb...@gmail.com On Wed, Aug 12, 2015 at 10:41 PM, Tobias Grosser tob...@grosser.es wrote: On 08/12/2015 10:33 PM, Aditya Kumar wrote: Passes bootstrap, no regressions. With this patch gcc bootstraps with graphite. make BOOT_CFLAGS=-g -O2 -fgraphite-identity -floop-interchange -floop-block LGTM, but please use a longer sentence to explain what you do. As the middle-end generally freely exchanges INTEGER_TYPE ENUMERAL_TYPE and BOOLEAN_TYPE you want to use INTEGRAL_TYPE_P here. Thanks. I tried INTEGRAL_TYPE_P, and that fails bootstrap. After a little bit of debugging I figured out that adding ENUMERAL_TYPE causes the failure (miscompile) in tree-vect-data-refs.c. I can add INTEGER_TYPE and BOOLEAN_TYPE (bootstrap passes with these). But that would be inconsistent with the type-checks at other places in graphite-*.c. Currently, we are only checking for INTEGER_TYPE at other places. -Aditya RIchard. Tobias
Re: [PATCH 2/2] replace several uses of the anon namespace with GCC_FINAL
On 08/12/2015 11:36 PM, Trevor Saunders wrote:
In many places gcc puts classes in the anon namespace so the compiler can tell
they do not get inheritted from to enable better devirtualization.
C++ does not allow class members to have static linkage, so there is no way to
tell the compiler that a member function will not be called from another
translation unit except for placing it into an anonymous namespace. AFAIK this
affects inliner decisions rather significantly (i.e. devirtualization is not
the only reason).
are they actually all that common? I think gcc is the only C++ with
which I'm familiar that uses them much.
LLVM is an example of another large project, which uses anonymous namespaces
extensively: http://llvm.org/docs/CodingStandards.html#anonymous-namespaces
BTW, I noticed that LLVM developers put small inline functions into anon.
namespaces (instead of just declaring them static). I wonder, whether it is
just a
matter of style or there is some other, more important reason...
The problem is you can't get to stuff in the anonymous namespace easily in
the debugger. There was talk of fixing that, but I don't think it ever went
forward on the gdb side.
I think, a possible solution is to define a macro which expands to namespace {
during normal build and expands to nothing in some sort of debug build (for
example, when ENABLE_CHECKING is defined).
--
Regards,
Mikhail Maltsev
RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers
-Original Message-
From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
Sent: Thursday, August 13, 2015 7:20 AM
To: Robert Suchanek; Moore, Catherine
Cc: gcc-patches@gcc.gnu.org
Subject: RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers
I'd like to give Catherine chance to review this, I notice a couple of
formatting
nits in the test case:
Yes, this patch is OK with Matthew's suggested changes.
Thanks,
Catherine
Robert Suchanek robert.sucha...@imgtec.com writes:
a/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
b/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
new file mode 100644
index 000..877d00c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
@@ -0,0 +1,12 @@
+/* { dg-options -funroll-loops } */ int foo; int bar;
+
+void __attribute__ ((interrupt)) isr(void) {
Newline for function name and whitespace before args
+ if (!foo)
+ {
Double space indent for brace or remove them entirely as it is single
statement.
+ while (bar 0xFF30);
+ }
+}
+/* { dg-final { scan-assembler-not \\\$8 } } */
Thanks,
Matthew
[patch] Include recog.h from ira-int.h
There was a recent change which causes ira-int.h to depend on recog.h.. but doesnt include it. Every file which needs it included it before I think, it just required some shuffling of order. By including recog.h in ira-int.h ordering issues are fixed, and we can simply remove recog.h form every file that includes ira-int.h Bootstraps on x86_64-pc-linux-gnu with no new regressions. OK for trunk? Andrew * ira-int.h: Include recog.h. * ira-build.c: Don't include recog.h. * ira-color.c: Likewise. * ira-conflicts.c: Likewise. * ira-costs.c: Likewise. * ira-emit.c: Likewise. * ira-lives.c: Likewise. * ira.c: Likewise. * sched-deps.c: Likewise. * sel-sched.c: Likewise. * target-globals.c: Likewise. Index: ira-int.h === *** ira-int.h (revision 226807) --- ira-int.h (working copy) *** along with GCC; see the file COPYING3. *** 21,26 --- 21,28 #ifndef GCC_IRA_INT_H #define GCC_IRA_INT_H + #include recog.h + /* To provide consistency in naming, all IRA external variables, functions, common typedefs start with prefix ira_. */ Index: ira-build.c === *** ira-build.c (revision 226807) --- ira-build.c (working copy) *** along with GCC; see the file COPYING3. *** 30,36 #include regs.h #include flags.h #include insn-config.h - #include recog.h #include diagnostic-core.h #include params.h #include reload.h --- 30,35 Index: ira-color.c === *** ira-color.c (revision 226807) --- ira-color.c (working copy) *** along with GCC; see the file COPYING3. *** 46,52 #include cfgloop.h #include ira.h #include alloc-pool.h - #include recog.h #include ira-int.h typedef struct allocno_hard_regs *allocno_hard_regs_t; --- 46,51 Index: ira-conflicts.c === *** ira-conflicts.c (revision 226807) --- ira-conflicts.c (working copy) *** along with GCC; see the file COPYING3. *** 30,36 #include target.h #include flags.h #include insn-config.h - #include recog.h #include diagnostic-core.h #include params.h #include sparseset.h --- 30,35 Index: ira-costs.c === *** ira-costs.c (revision 226807) --- ira-costs.c (working copy) *** along with GCC; see the file COPYING3. *** 39,45 #include tm_p.h #include regs.h #include addresses.h - #include recog.h #include reload.h #include diagnostic-core.h #include target.h --- 39,44 Index: ira-emit.c === *** ira-emit.c (revision 226807) --- ira-emit.c (working copy) *** along with GCC; see the file COPYING3. *** 89,95 #include varasm.h #include stmt.h #include expr.h - #include recog.h #include params.h #include reload.h #include cfgloop.h --- 89,94 Index: ira-lives.c === *** ira-lives.c (revision 226807) --- ira-lives.c (working copy) *** along with GCC; see the file COPYING3. *** 31,37 #include flags.h #include except.h #include insn-config.h - #include recog.h #include diagnostic-core.h #include params.h #include sparseset.h --- 31,36 Index: ira.c === *** ira.c (revision 226807) --- ira.c (working copy) *** along with GCC; see the file COPYING3. *** 387,393 #include varasm.h #include stmt.h #include expr.h - #include recog.h #include params.h #include tree-pass.h #include output.h --- 387,392 Index: sched-deps.c === *** sched-deps.c (revision 226807) --- sched-deps.c (working copy) *** along with GCC; see the file COPYING3. *** 35,41 #include insn-config.h #include insn-attr.h #include except.h - #include recog.h #include emit-rtl.h #include cfgbuild.h #include sched-int.h --- 35,40 Index: sel-sched.c === *** sel-sched.c (revision 226807) --- sel-sched.c (working copy) *** along with GCC; see the file COPYING3. *** 32,38 #include insn-config.h #include insn-attr.h #include except.h - #include recog.h #include params.h #include target.h #include output.h --- 32,37 Index: target-globals.c === *** target-globals.c (revision 226807) --- target-globals.c (working copy) *** along with GCC; see the file COPYING3. *** 44,56 #include cfgloop.h #include ira.h #include alloc-pool.h - #include recog.h #include ira-int.h #include builtins.h
Re: [PATCH][MIPS] Fix register renaming in the interrupt handlers
On Aug 13, 2015, at 12:54 PM, Richard Sandiford rdsandif...@googlemail.com wrote: It was discovered that with the attached test case compiled with -O2 -funroll-loops, the regrename pass renamed one of the registers ($2) to $8 that was not saved by the prologue. The attached patch fixes it by defining macro HARD_REGNO_RENAME_OK that returns zero iff the current function is an interrupt handler and a register was never live. You also need to do the same thing for TARGET_HARD_REGNO_SCRATCH_OK, to stop peephole2 from using unsaved registers as scratch registers. I should dig out my patches to clean up this interface. It's just too brittle to have two macros that say what registers can be used after reload. Gosh, I don’t like the interface of them at all. I have interrupt functions and I want all the goodness out of gcc and I want gcc to just know that it can’t use registers it doesn’t want to save for any reason that the port marked as saved by the calling api of the function. :-( Very few ports (3) define TARGET_HARD_REGNO_SCRATCH_OK and many port (19 or so) don’t define this but do seem to have interrupt functions. The existing documentation seems not give be enough information to let me decide if I need to define it or not. I read through all the ports that do define it, and none of them shed any light on to allow me to decide if my port needs to or not. So, first question is, are the 16 other ports that have interrupt functions and don’t define this just buggy (or non-optimal)? How can I tell if I need to or not? A single example of that does cause a port to see it and a single example of why a port would not need to define it would be instructive. Along the lines of TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS, I’d be willing to explain the required abi of each function, and then I just want gcc to just work. All functions are normal, except for interrupt functions, all allocatable register need to be saved. I think this is a universally true thing, and it just happens to be true on my port as well. Anyway, I’d love to see gcc improved in this area. This one is a pet peeve of mine as I’ve seen what happens to software when a single register that should have been saved, wasn’t. It was slightly annoying to track down and find. Fixing was trivial.
Re: Using libbacktrace in libgfortran: some questions
On Thu, Aug 13, 2015 at 8:50 AM, FX fxcoud...@gmail.com wrote:
And yet, that patch has absolutely nothing to do with libbacktrace.
Hmmm. Let's try this one.
Works perfectly with the patch:
Patch tested and committed with this ChangeLog entry.
2015-08-13 Ian Lance Taylor i...@google.com
* dwarf.c (read_function_entry): Add vec_inlined parameter.
Change all callers.
Index: dwarf.c
===
--- dwarf.c (revision 226846)
+++ dwarf.c (working copy)
@@ -2250,7 +2250,8 @@ read_function_entry (struct backtrace_st
struct unit *u, uint64_t base, struct dwarf_buf *unit_buf,
const struct line_header *lhdr,
backtrace_error_callback error_callback, void *data,
-struct function_vector *vec)
+struct function_vector *vec_function,
+struct function_vector *vec_inlined)
{
while (unit_buf-left 0)
{
@@ -2258,6 +2259,7 @@ read_function_entry (struct backtrace_st
const struct abbrev *abbrev;
int is_function;
struct function *function;
+ struct function_vector *vec;
size_t i;
uint64_t lowpc;
int have_lowpc;
@@ -2279,6 +2281,11 @@ read_function_entry (struct backtrace_st
|| abbrev-tag == DW_TAG_entry_point
|| abbrev-tag == DW_TAG_inlined_subroutine);
+ if (abbrev-tag == DW_TAG_inlined_subroutine)
+ vec = vec_inlined;
+ else
+ vec = vec_function;
+
function = NULL;
if (is_function)
{
@@ -2458,7 +2465,8 @@ read_function_entry (struct backtrace_st
if (!is_function)
{
if (!read_function_entry (state, ddata, u, base, unit_buf, lhdr,
- error_callback, data, vec))
+ error_callback, data, vec_function,
+ vec_inlined))
return 0;
}
else
@@ -2471,7 +2479,8 @@ read_function_entry (struct backtrace_st
memset (fvec, 0, sizeof fvec);
if (!read_function_entry (state, ddata, u, base, unit_buf, lhdr,
- error_callback, data, fvec))
+ error_callback, data, vec_function,
+ fvec))
return 0;
if (fvec.count 0)
@@ -2535,7 +2544,7 @@ read_function_info (struct backtrace_sta
while (unit_buf.left 0)
{
if (!read_function_entry (state, ddata, u, 0, unit_buf, lhdr,
- error_callback, data, pfvec))
+ error_callback, data, pfvec, pfvec))
return;
}
Re: [PATCH 06/15] rs6000: Use rldiwi in constant construction
On Aug 12, 2015, at 7:43 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: Yes. And there are much worse problems, like many things not working right if your HOST_WIDE_INT would happen to be more than 64 bits; we cannot really shake those out because there is no actual system to test that on -- but it also doesn't actually matter, because there is no system to run it on :-) Lots of systems support 128 bit types just fine, and one could use TImode for HOST_WIDE_INT, if one really, really wanted to. x86_64 I think is one of those systems.
Re: [PATCH] Add extensions to dwarf2.def
I'm currently working on migrating debugging information for Ada from GNAT encodings to standard DWARF. At the moment, I have worked on two topics that I believe are not (completely) supported in standard DWARF: - fixed point types with arbitrary scale factors; - scalar types with biased representations. My goal is to submit an issue on dwarfstd.org in an attempt to introduce these extensions to the next DWARF standard. Before that, though, I would like to make sure that these extensions actually fit the need by having them supported both in GCC and GDB. The two attached patches make these extensions public so that no other vendor-specific tags/attributes conflict with them in the future. I cannot submit the patches that actually use these right now because I need first to port them from the 4.9 branch onto mainline (I hope I will be able to do this on early July). May I commit them? I also attached two documents that describe how to use these extensions. I guess this should go to the wiki just like for DW_AT_GNAT_descriptive_type (https://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type). I will do this if the patches are integrated. Thank you in advance! include/ * dwarf2.def (DW_TAG_GNU_rational_constant): New tag. (DW_AT_GNU_numerator, DW_AT_GNU_denominator): New attributes. I don't think you really need a new TAG here -- DW_TAG_constant could just as easily take DW_AT_GNU_numerator and DW_AT_GNU_denominator as an alternative to DW_AT_const_value. I'm not really sure why DW_AT_small was defined to refer to a DW_TAG_constant DIE rather than just providing the constant as the attribute value. It would seem more efficient, space-wise, to have a DW_AT_scale attribute that would provide a multiplicative scale factor, and an optional DW_AT_scale_divisor to provide the denominator if necessary. Another, perhaps far-fetched, alternative would be to introduce a new form that would represent a rational constant as two unsigned LEB128 values, and allow that form for DW_AT_const_value and/or for DW_AT_small. For now, I'd suggest going with your proposal, except use the existing DW_TAG_constant instead of a new TAG. (I.e., just add the two new DW_AT_numerator and DW_AT_denominator attributes.) include/ * dwarf2.def (DW_AT_GNU_bias): New attribute. This is OK. Looks like a good idea to me. -cary
Re: [PATCH] Missing Skylake -march=/-mtune= option
On Thu, Aug 13, 2015 at 11:31 AM, Yuri Rumyantsev ysrum...@gmail.com wrote: Hi All, Here is patch for adding march/mtune options for Skylake. Bootstrap and regression testing did not show any new failures. Is it OK for trunk? OK. Thanks, Uros. ChangeLog: 2015-08-13 Yuri Rumyantsev ysrum...@gmail.com * config/i386/driver-i386.c (host_detect_local_cpu): Add support for skylake. * config/i386/i386.c (PTA_SKYLAKE): New macros. (processor_alias_table): Add skylake description. (enum processor_model): Add skylake processor. (arch_names_table): Add skylake record. * doc/invoke.texi: Add skylake item. gcc/testsuite/ChangeLog: * gcc.target/i386/builtin_target.c: Add skylake check. libgcc/ChangeLog: * config/i386/cpuinfo.c (enum processor_subtypes): Add skylake. (get_intel_cpu): Likewise.
[PATCH 1/2] C++-ify dominance.c
Hi all.
These two patches are refactoring of dominator-related code.
The comment in dominance.c says: We work in a poor-mans object oriented
fashion, and carry an instance of this structure through all our 'methods'. So,
the first patch converts the mentioned structure (dom_info) into a class with
proper encapsulation. It also adds a new member - m_fn (the function currently
being compiled) to this structure and replaces some uses of cfun with m_fn. It
also contains some fixes, related to current coding standards: move variable
declarations to place of first use, replace elaborated type specifiers (i.e.
struct/enum foo) by simple ones (i.e., just foo) in function prototypes.
Bootstrapped and regtested on x86_64-linux. Tested build of config-list.mk.
gcc/ChangeLog:
2015-08-14 Mikhail Maltsev malts...@gmail.com
* (ENABLE_CHECKING): Define as 0 by default.
dominance.c (new_zero_array): Define.
(dom_info): Define as class instead of struct.
(dom_info::dom_info, ~dom_info): Define. Use new/delete for memory
allocations/deallocations. Pass function as parameter (instead of
using cfun).
(dom_info::get_idom): Define accessor method.
(dom_info::calc_dfs_tree_nonrec, calc_dfs_tree, compress, eval,
link_roots, calc_idoms): Redefine as class members. Use m_fn instead
of cfun.
(init_dom_info, free_dom_info): Remove (use dom_info ctor/dtor).
(dom_convert_dir_to_idx): Fix prototype.
(assign_dfs_numbers): Move variable declarations to their first uses.
(calculate_dominance_info): Remove conditional compilation, move
variables.
(free_dominance_info, get_immediate_dominator, set_immediate_dominator,
get_dominated_b, get_dominated_by_region, get_dominated_to_depth,
redirect_immediate_dominators, nearest_common_dominator_for_set,
dominated_by_p, bb_dom_dfs_in, bb_dom_dfs_out, verify_dominators,
determine_dominators_for_sons, iterate_fix_dominators, first_dom_son,
next_dom_son, debug_dominance_info, debug_dominance_tree_1): Adjust to
use class dom_info. Move variable declarations to the place of first
use. Fix prototypes (remove struct/enum).
* dominance.h: Fix prototypes (remove struct/enum).
--
Regards,
Mikhail Maltsev
diff --git a/gcc/dominance.c b/gcc/dominance.c
index d8d87ca..3c4f228 100644
--- a/gcc/dominance.c
+++ b/gcc/dominance.c
@@ -44,6 +44,10 @@
#include timevar.h
#include graphds.h
+#ifndef ENABLE_CHECKING
+# define ENABLE_CHECKING 0
+#endif
+
/* We name our nodes with integers, beginning with 1. Zero is reserved for
'undefined' or 'end of list'. The name of each node is given by the dfs
number of the corresponding basic block. Please note, that we include the
@@ -53,139 +57,154 @@
/* Type of Basic Block aka. TBB */
typedef unsigned int TBB;
-/* We work in a poor-mans object oriented fashion, and carry an instance of
- this structure through all our 'methods'. It holds various arrays
- reflecting the (sub)structure of the flowgraph. Most of them are of type
- TBB and are also indexed by TBB. */
+namespace {
+
+/* This class holds various arrays reflecting the (sub)structure of the
+ flowgraph. Most of them are of type TBB and are also indexed by TBB. */
-struct dom_info
+class dom_info
{
+public:
+ dom_info (function *, cdi_direction);
+ ~dom_info ();
+ void calc_dfs_tree (bool);
+ void calc_idoms (bool);
+
+ inline basic_block get_idom (basic_block);
+private:
+ void calc_dfs_tree_nonrec (basic_block, bool);
+ void compress (TBB);
+ TBB eval (TBB);
+ void link_roots (TBB, TBB);
+
/* The parent of a node in the DFS tree. */
- TBB *dfs_parent;
- /* For a node x key[x] is roughly the node nearest to the root from which
+ TBB *m_dfs_parent;
+ /* For a node x m_key[x] is roughly the node nearest to the root from which
exists a way to x only over nodes behind x. Such a node is also called
semidominator. */
- TBB *key;
- /* The value in path_min[x] is the node y on the path from x to the root of
- the tree x is in with the smallest key[y]. */
- TBB *path_min;
- /* bucket[x] points to the first node of the set of nodes having x as key. */
- TBB *bucket;
- /* And next_bucket[x] points to the next node. */
- TBB *next_bucket;
- /* After the algorithm is done, dom[x] contains the immediate dominator
+ TBB *m_key;
+ /* The value in m_path_min[x] is the node y on the path from x to the root of
+ the tree x is in with the smallest m_key[y]. */
+ TBB *m_path_min;
+ /* m_bucket[x] points to the first node of the set of nodes having x as
+ key. */
+ TBB *m_bucket;
+ /* And m_next_bucket[x] points to the next node. */
+ TBB *m_next_bucket;
+ /* After the algorithm is done, m_dom[x] contains the immediate dominator
of x. */
- TBB *dom;
+ TBB *m_dom;
/* The following few fields implement the structures needed for
Re: [PATCH GCC]Improve loop bound info by simplifying conversions in iv base
On 07/28/2015 03:38 AM, Bin Cheng wrote: Hi, For now, SCEV may compute iv base in the form of (signed T)((unsigned T)base + step)). This complicates other optimizations/analysis depending on SCEV because it's hard to dive into type conversions. For many cases, such type conversions can be simplified with additional range information implied by loop initial conditions. This patch does such simplification. With simplified iv base, loop niter analysis can compute more accurate bound information since sensible value range can be derived for base+step. For example, accurate loop boundmay_be_zero information is computed for cases added by this patch. The code is actually borrowed from loop_exits_before_overflow. Moreover, with simplified iv base, the second case handled in that function now becomes the first case. I didn't remove that part of code because it may(?) still be visited in scev analysis itself and simple_iv isn't an interface for that. Is it OK? Thanks, bin 2015-07-28 Bin Cheng bin.ch...@arm.com * tree-ssa-loop-niter.c (tree_simplify_using_condition): Export the interface. * tree-ssa-loop-niter.h (tree_simplify_using_condition): Declare. * tree-scalar-evolution.c (simple_iv): Simplify type conversions in iv base using loop initial conditions. gcc/testsuite/ChangeLog 2015-07-28 Bin Cheng bin.ch...@arm.com * gcc.dg/tree-ssa/loop-bound-2.c: New test. * gcc.dg/tree-ssa/loop-bound-4.c: New test. * gcc.dg/tree-ssa/loop-bound-6.c: New test. I have the same concerns about these tests... Which makes me really think I must be mis-understanding something in the debugging output. jeff
Re: r226516 - in /trunk/gcc: ChangeLog testsuite/Ch...
On 08/05/2015 01:44 AM, Andreas Schwab wrote:
FAIL: gcc.dg/pr66314.c (test for excess errors)
Excess errors:
/usr/local/gcc/gcc-20150805/gcc/testsuite/gcc.dg/pr66314.c:1:0: warning:
-fsanitize=address and -fsanitize=kernel-address are not supported for this
target
Fixing this is ever-so-slightly more complicated than just moving the
test. We need to clear all the sanitizers via -fno-sanitize=all before
-fsanitize=kernel-address as -fsanitize=address conflicts with
-fsanitize=kernel-address.
Committed to the trunk.
Sorry for the noise.
Jeff
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 4561032..2929fe4 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2015-08-13 Jeff Law l...@redhat.com
+
+ * gcc.dg/pr66314.c: Moved from here to ..
+ * gcc.dg/asan/pr66314.c: Here. Use -fno-sanitize=all
+ to clear all sanitizers before -fsanitize=kernel-address.
+
2015-08-13 Kyrylo Tkachov kyrylo.tkac...@arm.com
* gcc.target/aarch64/cinc_common_1.c: New test.
diff --git a/gcc/testsuite/gcc.dg/asan/pr66314.c
b/gcc/testsuite/gcc.dg/asan/pr66314.c
new file mode 100644
index 000..3f6b12c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr66314.c
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options -std=gnu89 -Os -fprofile-arcs -fno-sanitize=all
-fsanitize=kernel-address } */
+
+char *a;
+int d;
+
+static int
+fn1 (int b, int c)
+{
+ while (a)
+if (*a)
+ return -126;
+ if (b)
+return -12;
+ if (c == -12)
+return c;
+}
+
+void
+fn2 (int b, int c)
+{
+ for (;;)
+{
+ d = fn1 (b, c);
+ switch (d)
+{
+case -126:
+ continue;
+default:
+ return;
+}
+}
+}
diff --git a/gcc/testsuite/gcc.dg/pr66314.c b/gcc/testsuite/gcc.dg/pr66314.c
deleted file mode 100644
index f74ab5b..000
--- a/gcc/testsuite/gcc.dg/pr66314.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options -std=gnu89 -Os -fprofile-arcs -fsanitize=kernel-address } */
-
-char *a;
-int d;
-
-static int
-fn1 (int b, int c)
-{
- while (a)
-if (*a)
- return -126;
- if (b)
-return -12;
- if (c == -12)
-return c;
-}
-
-void
-fn2 (int b, int c)
-{
- for (;;)
-{
- d = fn1 (b, c);
- switch (d)
-{
-case -126:
- continue;
-default:
- return;
-}
-}
-}
[gomp4.1] coerce libgomp to build with C++
Ughh... what was supposed to be a short hack turned out to be 2 days of
pure torture.
So...I'm implementing task priorities as per the 4.1 standard, and
decided to use a priority queue. Since we already have splay trees in
libgomp, I figured these priority queues could be built on top of them.
However, our libgomp splay tree adaptation is not exactly generic
enough, so I started rewriting it to use C++ templates.
I quickly found out that libgomp is built with C, so I said to myself...
Self, how bad can it be to convert libgomp to C++?. Very.
I've pretty much renounced the splay tree in C++ idea, but only because
I don't want to iron out the remaining automake/configury magic, not to
mention possible ABI issues I've yet to uncover. However, throwing 2
days' worth of work away would be silly, so how about we pass
-Wc++-compat and avoid further C/C++ divergence?
I have tested this patch as is, as well as with:
AM_CFLAGS = $(XCFLAGS) -x c++
Using the C++ compiler compiles, but does not link:
/usr/bin/ld: .libs/loop.o: relocation R_X86_64_PC32 against undefined
symbol `gomp_ialias_GOMP_parallel_end' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
I really must get back to task priorities, so I'm not going to pursue
C++ linking any further. However, the attached patch should get us 95%
of the way there, and we can keep it going forward.
I could provide a trunk version of this, but considering gomp4.1 will
get merged (*crosses fingers*), no sense in doing the work twice.
Most everything is obvious. The things that are not, or I'm unsure
about, I have documented throughout.
OK for gomp4.1 branch?
commit 69a9fc925ecf856057883e49842186e2b412cad2
Author: Aldy Hernandez al...@redhat.com
Date: Thu Aug 13 13:02:48 2015 -0700
* Makefile.am (AM_CFLAGS): Pass -Wc++-compat.
* Makefile.in: Regenerate.
* config/linux/affinity.c (gomp_affinity_alloc): Fix *alloc cast.
(gomp_affinity_init_level): Same.
(gomp_affinity_print_place): Fix *signed comparison.
(omp_get_place_num_procs): Same.
(omp_get_place_proc_ids): Same.
* critical.c (GOMP_critical_name_start): Cast pointer assignment.
* env.c (gomp_global_icv): Rearrange field initialization.
(parse_schedule): Fix *signed comparison.
(parse_unsigned_long_list): Cast pointer assignment.
(parse_bind_var): Same.
(handle_omp_display_env): Fix *signed comparison.
Insert space after string concatenation.
(omp_set_schedule): Cast enum.
(omp_get_schedule): Cast pointer assignment.
(omp_proc_bind_t): Cast enum.
* fortran.c (gomp_init_nest_lock__30): Add unused attribute.
(gomp_destroy_nest_lock__30): Same.
(gomp_set_nest_lock__30): Same.
(gomp_unset_nest_lock__30): Same.
(gomp_test_nest_lock__30): Same.
(omp_set_schedule_): Cast pointer.
(omp_set_schedule_8_): Cast enum.
* iter.c (gomp_iter_static_next): Fix signness issues.
* iter_ull.c (gomp_iter_ull_static_next): Same.
* libgomp.h: Wrap gomp_*_{25,30} functions in extern C.
* libgomp_g.h: Wrap GOMP_* functions in extern C.
* loop_ull.c: Same.
* loop.c (gomp_loop_init): Same.
Fix sign issues.
* oacc-async.c: Add __GOACC_CXX_NOEXCEPT to all acc_* functions.
* oacc-cuda.c: Same.
* oacc-init.c (goacc_register): Same.
(resolve_device): Fix enum issues.
(goacc_new_thread): Fix typo in malloc size.
(goacc_destroy_thread): Fix pointer cast.
(acc_*): Add __GOACC_CXX_NOEXCEPT.
* oacc-host.c (host_dispatch): Rearrange field initialization.
* oacc-mem.c (lookup_host): Fix sign problems
(acc_*): Add __GOACC_CXX_NOEXCEPT. Fix sign problems.
* oacc-parallel.c (find_pset): Same.
(GOACC_parallel): Insert space in between string concat.
Add pointer casts.
* oacc-plugin.c (GOMP_PLUGIN_async_unmap_vars): Add pointer cast.
* omp.h.in (__GOMP_NOTHROW): Remove throw() from C++ definition.
* openacc.h (__GOACC_CXX_NOEXCEPT): New.
(__GOACC_NOTHROW): Use it.
* ordered.c (GOMP_ordered_start): Provide C++ mangling.
* parallel.c (omp_get_ancestor_thread_num): Sign sign issues.
(omp_get_team_size): Same.
* plugin/plugin-host.c (GOMP_OFFLOAD_openacc_parallel): Cast
pointer.
(GOMP_OFFLOAD_openacc_create_thread_data): Same.
* sections.c (gomp_sections_init): Fix sign issues.
* target.c (gomp_map_vars): Add pointer casts.
Insert space in between string concat.
(gomp_offload_image_to_device): Add pointer casts.
(GOMP_offload_register): Same.
(GOMP_target_41): Same.
(gomp_exit_data): Protect variable declaration from goto.
(omp_target_associate_ptr): Add pointer casts.
Re: [PATCH GCC]Improve bound information in loop niter analysis
On 07/28/2015 03:36 AM, Bin Cheng wrote:
Hi,
Loop niter computes inaccurate bound information for different loops. This
patch is to improve it by using loop initial condition in
determine_value_range. Generally, loop niter is computed by subtracting
start var from end var in loop exit condition. Moreover, loop bound is
computed using value range information of both start and end variables.
Basic idea of this patch is to check if loop initial condition implies more
range information for both start/end variables. If yes, we refine range
information and use that to compute loop bound.
With this improvement, more accurate loop bound information is computed for
test cases added by this patch.
Is it OK?
Thanks,
bin
2015-07-28 Bin Chengbin.ch...@arm.com
* tree-ssa-loop-niter.c (refine_value_range_using_guard): New.
(determine_value_range): Call refine_value_range_using_guard for
each loop initial condition to improve value range.
gcc/testsuite/ChangeLog
2015-07-28 Bin Chengbin.ch...@arm.com
* gcc.dg/tree-ssa/loop-bound-1.c: New test.
* gcc.dg/tree-ssa/loop-bound-3.c: New test.
* gcc.dg/tree-ssa/loop-bound-5.c: New test.
improve-loop-bound-analysis-20150728.txt
Index: gcc/testsuite/gcc.dg/tree-ssa/loop-bound-3.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/loop-bound-3.c(revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/loop-bound-3.c(revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-ivopts-details } */
+
+int *a;
+
+int
+foo (unsigned char s, unsigned char l)
+{
+ unsigned char i;
+ int sum = 0;
+
+ for (i = s; i l; i -= 1)
So is this really bounded by 254 iterations? ISTM it's bounded by 255
iterations when called with s = 255, l = 0. What am I missing here?
Am I mis-interpreting the dump output in some way?
Similarly for the other tests.
Jeff
Re: Fix reload1.c warning for some targets
Jeff Law l...@redhat.com writes: On 08/05/2015 08:18 AM, Richard Sandiford wrote: Building some targets results in a warning about orig_dup[i] potentially being used uninitialised. I think the warning is fair, since it isn't obvious that the reog_data-based loop bound remains unchanged between: for (i = 0; i recog_data.n_dups; i++) orig_dup[i] = *recog_data.dup_loc[i]; and: for (i = 0; i recog_data.n_dups; i++) *recog_data.dup_loc[i] = orig_dup[i]; Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * reload1.c (elimination_costs_in_insn): Make it obvious to the compiler that the n_dups and n_operands loop bounds are invariant. So thinking more about this, I think the best way forward is to: 1. Create a new BZ with the false positive extracted from c#4. 2. Install your patch and close 55035. I'll take care of #1, you can handle #2. Thanks, I've now done #2. Richard
Re: [PING][PATCH][3/N] Replace the pattern GET_MODE_BITSIZE (GET_MODE_INNER (m)) with GET_MODE_UNIT_BITSIZE (m)
On 08/13/2015 04:12 AM, David Sherwood wrote: Hi, This patch follows on from [PATCH][1/N] Change GET_MODE_INNER to always return a non-void mode It is another tidy up, replacing the pattern GET_MODE_BITSIZE (GET_MODE_INNER (m)) with GET_MODE_UNIT_BITSIZE (m). Also replaces any calls to GET_MODE_PRECISION (GET_MODE_INNER (m)) with GET_MODE_UNIT_PRECISION (m). Tested: aarch64 and aarch64_be - no regressions in gcc testsuite x86_64 - bootstrap build, no testsuite regressions arm-none-eabi - no regressions in gcc testsuite Run contrib/config-list.mk - no regressions Good to go? Thanks, David. 2015-08-04 David Sherwood david.sherw...@arm.com gcc/ * config/arm/arm.c (neon_element_bits): Replace call to GET_MODE_BITSIZE (GET_MODE_INNER (m)) with GET_MODE_UNIT_BITSIZE (m). * config/arm/neon.md (neon_vget_lanemode): Likewise. (neon_vget_laneumode, neon_vset_lanemode): Likewise (neon_vdup_lanemode): Likewise. * config/i386/i386.c (ix86_expand_int_vcond): Likewise. (ix86_expand_multi_arg_builtin, ix86_expand_reduc): Likewise. (expand_vec_perm_palignr, ix86_expand_sse2_abs): Likewise. * config/rs6000/rs6000.c (rs6000_do_expand_vec_perm): Likewise. * config/spu/spu.c (arith_immediate_p): Likewise. * expmed.c (store_bit_field_1, extract_bit_field_1): Likewise. * expr.c (expand_expr_real_2): Likewise. * optabs.c (shift_amt_for_vec_perm_mask): Likewise. * simplify-rtx.c (simplify_immed_subreg): Likewise. * tree-cfg.c (verify_gimple_assign_ternary): Likewise. * tree-vect-patterns.c (vect_recog_mixed_size_cond_pattern): Likewise. New variable. * fold-const.c (fold_binary_loc): Replace call to GET_MODE_PRECISION (GET_MODE_INNER (m)) with GET_MODE_UNIT_PRECISION (m). OK. jeff
Re: [PATCH 06/15] rs6000: Use rldiwi in constant construction
On Thu, 13 Aug 2015, Mike Stump wrote: On Aug 12, 2015, at 7:43 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: Yes. And there are much worse problems, like many things not working right if your HOST_WIDE_INT would happen to be more than 64 bits; we cannot really shake those out because there is no actual system to test that on -- but it also doesn't actually matter, because there is no system to run it on :-) Lots of systems support 128 bit types just fine, and one could use TImode for HOST_WIDE_INT, if one really, really wanted to. x86_64 I think is one of those systems. There's no printf support (or other standard library support); you'd run into practical problems there. -- Joseph S. Myers jos...@codesourcery.com
Re: [patch] Include recog.h from ira-int.h
On 08/13/2015 12:09 PM, Andrew MacLeod wrote: There was a recent change which causes ira-int.h to depend on recog.h.. but doesnt include it. Every file which needs it included it before I think, it just required some shuffling of order. By including recog.h in ira-int.h ordering issues are fixed, and we can simply remove recog.h form every file that includes ira-int.h Bootstraps on x86_64-pc-linux-gnu with no new regressions. OK for trunk? OK. jeff
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On 08/13/2015 04:00 AM, Richard Biener wrote: On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law l...@redhat.com wrote: On 08/12/2015 10:24 AM, Ian Lance Taylor wrote: On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey t...@tromey.com wrote: Jeff In the past this has stalled on issues like how will asynch-exceptions Jeff be tested and the like. It seems to me that either there is some other language which needs this -- in which case that language ought to have testing for the feature -- or the feature is only used by gcj, in which case it doesn't matter. Of course is!=ought; but relying on gcj and libjava to provide this small amount of testing seems like a bad cost/benefit tradeoff. Go does use asynchronous exceptions, and has test cases that rely on them working. If you're comfortable with Go at this point and we have mechanisms in place to ensure Go only gets built on platforms that support Go, then I think we should go forward with replacing GCJ with Go. I think replacing it with Ada makes more sense (still have some systems where a ton of Go tests fail presumably because of too old glibc/kernel). Or just replace it with nothing as effectively neither Go nor Ada are going to be enabled for all primary host platforms (as for Ada you need an Ada host compiler for example). Neither Ada nor Go are perfect. However, Ada should be at a point where, if you have a suitable host compiler, it should build and regression test. For Go, if there's platforms where the tests are unreliable, then it needs to be disabled on that platform until the tests are reliable. That's the key thing in my mind -- building and regression testing. Thus I'd support either or both between Ada and Go. In fact the more I think about it, the more I think both ought to be enabled and GCJ disabled for the default build. jeff
Re: [PATCH, FIXINCLUDES] AIX stdio C++ inline fix
Looks good to me...
On Thu, Aug 13, 2015 at 10:33 AM, David Edelsohn dje@gmail.com wrote:
AIX stdio.h header includes code specific for C++ that looks like:
extern C {
#ifdef __cplusplus
#ifdef ferror
#undef ferror
inline int ferror(FILE * _p)
{
return ((_p)-_flag _IOERR);
}
#endif /*ferror*/
which generates code that makes the AIX linker and loader rather upset
because the inline function is not mangled and conflicts with the C
library.
This fixincludes patch protects this code with an addition test for
IBMCPP (not that IBMCPP will use GCC include-fixed headers, but ).
Okay?
Thanks, David
* inclhack.def (aix_stdio_inline): New fix.
* fixincl.x: Regenerated.
* test/base/stdio.h [AIX_STDIO_INLINE]: New test.
Index: inclhack.def
===
--- inclhack.def(revision 226860)
+++ inclhack.def(working copy)
@@ -892,10 +892,32 @@
};
/*
+ * stdio.h on AIX defines ferror, clearerr and feof as C++ inline, which
+ produces wrong code with G++.
+ */
+fix = {
+hackname = aix_stdio_inline;
+mach = *-*-aix*;
+files = stdio.h;
+select= #ifdef __cplusplus\\\n
+}\\\n\\\n
+#ifdef ferror\\\n;
+c_fix = format;
+c_fix_arg = #ifdef __cplusplus\n
+}\n
+#endif\n\n
+#if (defined(__cplusplus) defined(__IBMCPP__))\n
+#ifdef ferror\n;
+test_text = #ifdef __cplusplus\n}\n\n#ifdef ferror;
+};
+
+
+/*
Re: Fix reload1.c warning for some targets
On 08/13/2015 02:29 PM, Richard Sandiford wrote: Jeff Law l...@redhat.com writes: On 08/05/2015 08:18 AM, Richard Sandiford wrote: Building some targets results in a warning about orig_dup[i] potentially being used uninitialised. I think the warning is fair, since it isn't obvious that the reog_data-based loop bound remains unchanged between: for (i = 0; i recog_data.n_dups; i++) orig_dup[i] = *recog_data.dup_loc[i]; and: for (i = 0; i recog_data.n_dups; i++) *recog_data.dup_loc[i] = orig_dup[i]; Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * reload1.c (elimination_costs_in_insn): Make it obvious to the compiler that the n_dups and n_operands loop bounds are invariant. So thinking more about this, I think the best way forward is to: 1. Create a new BZ with the false positive extracted from c#4. 2. Install your patch and close 55035. I'll take care of #1, you can handle #2. Thanks, I've now done #2. THanks. I've got the new BZ in place. So we both pop one item off our stacks. jeff
Re: [PATCH 2/2] replace several uses of the anon namespace with GCC_FINAL
Trevor Saunders tbsau...@tbsaunde.org writes: On Wed, Aug 12, 2015 at 01:03:36PM -0600, Jeff Law wrote: On 08/12/2015 12:57 PM, Richard Sandiford wrote: Jeff Law l...@redhat.com writes: On 08/10/2015 06:05 AM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders tbsaunde+...@tbsaunde.org Hi, In many places gcc puts classes in the anon namespace so the compiler can tell they do not get inheritted from to enable better devirtualization. However debugging code in the anon namespace can be a pain, and the same thing can be accomplished more directly by marking the classes as final. When bootstrapping stage 3 should always be built in C++14 mode now, and of course will always be newer than gcc 4.7, so these classes will always be marked as final there. AIUI cross compilers are supposed to be built with recent gcc, which I would tend to think implies newer than 4.7, so they should also be built with these classes marked as final. I believe that means in all important cases this works just as well as the anon namespace. bootstrapped + regtested on x86_64-linux-gnu, ok? Trev gcc/ChangeLog: 2015-08-10 Trevor Saunders tbsau...@tbsaunde.org * compare-elim.c, dce.c, dse.c, gimple-ssa-isolate-paths.c, gimple-ssa-strength-reduction.c, graphite.c, init-regs.c, ipa-pure-const.c, ipa-visibility.c, ipa.c, mode-switching.c, omp-low.c, reorg.c, sanopt.c, trans-mem.c, tree-eh.c, tree-if-conv.c, tree-ssa-copyrename.c, tree-ssa-dce.c, tree-ssa-dom.c, tree-ssa-dse.c, tree-ssa-forwprop.c, tree-ssa-sink.c, tree-ssanames.c, tree-stdarg.c, tree-tailcall.c, tree-vect-generic.c, tree.c, ubsan.c, var-tracking.c, vtable-verify.c, web.c: Use GCC_FINAL instead of the anonymous namespace. OK. I was hoping someone else was going to speak up since I seem to have been posting a few negative messages recently, but I think this is really a step in the wrong direction. I think the code was using anonymous namespaces in exactly the way they were are they actually all that common? I think gcc is the only C++ with which I'm familiar that uses them much. Yeah, fair question. I suppose working on a codebase with anonymous namespaces day-in day-out doesn't make them more common than working on the codebase for one day :-) Even if it felt that way at the time... But an internal codebase at a previous job used them. LLVM also used them quite a bit when I was looking after the SystemZ port (I assume still does). Thanks, Richard
Re: [PATCH GCC]Improve loop bound info by simplifying conversions in iv base
On Fri, Aug 14, 2015 at 6:10 AM, Jeff Law l...@redhat.com wrote: On 07/28/2015 03:38 AM, Bin Cheng wrote: Hi, For now, SCEV may compute iv base in the form of (signed T)((unsigned T)base + step)). This complicates other optimizations/analysis depending on SCEV because it's hard to dive into type conversions. For many cases, such type conversions can be simplified with additional range information implied by loop initial conditions. This patch does such simplification. With simplified iv base, loop niter analysis can compute more accurate bound information since sensible value range can be derived for base+step. For example, accurate loop boundmay_be_zero information is computed for cases added by this patch. The code is actually borrowed from loop_exits_before_overflow. Moreover, with simplified iv base, the second case handled in that function now becomes the first case. I didn't remove that part of code because it may(?) still be visited in scev analysis itself and simple_iv isn't an interface for that. Is it OK? Thanks, bin 2015-07-28 Bin Cheng bin.ch...@arm.com * tree-ssa-loop-niter.c (tree_simplify_using_condition): Export the interface. * tree-ssa-loop-niter.h (tree_simplify_using_condition): Declare. * tree-scalar-evolution.c (simple_iv): Simplify type conversions in iv base using loop initial conditions. gcc/testsuite/ChangeLog 2015-07-28 Bin Cheng bin.ch...@arm.com * gcc.dg/tree-ssa/loop-bound-2.c: New test. * gcc.dg/tree-ssa/loop-bound-4.c: New test. * gcc.dg/tree-ssa/loop-bound-6.c: New test. I have the same concerns about these tests... Which makes me really think I must be mis-understanding something in the debugging output. This patch tries to simplify SCEV base with the help of loop's initial conditions. The previous patch can only handle simplified SCEV base when analyzing loop's bound information. It's independent to the previous one. Actually it can be viewed as an irrelevant patch even the previous one is proven wrong. Of course, I need to change test case in that way. Thanks, bin jeff
Re: [PATCH GCC]Improve bound information in loop niter analysis
On Fri, Aug 14, 2015 at 6:08 AM, Jeff Law l...@redhat.com wrote:
On 07/28/2015 03:36 AM, Bin Cheng wrote:
Hi,
Loop niter computes inaccurate bound information for different loops.
This
patch is to improve it by using loop initial condition in
determine_value_range. Generally, loop niter is computed by subtracting
start var from end var in loop exit condition. Moreover, loop bound is
computed using value range information of both start and end variables.
Basic idea of this patch is to check if loop initial condition implies
more
range information for both start/end variables. If yes, we refine range
information and use that to compute loop bound.
With this improvement, more accurate loop bound information is computed
for
test cases added by this patch.
Is it OK?
Thanks,
bin
2015-07-28 Bin Chengbin.ch...@arm.com
* tree-ssa-loop-niter.c (refine_value_range_using_guard): New.
(determine_value_range): Call refine_value_range_using_guard for
each loop initial condition to improve value range.
gcc/testsuite/ChangeLog
2015-07-28 Bin Chengbin.ch...@arm.com
* gcc.dg/tree-ssa/loop-bound-1.c: New test.
* gcc.dg/tree-ssa/loop-bound-3.c: New test.
* gcc.dg/tree-ssa/loop-bound-5.c: New test.
improve-loop-bound-analysis-20150728.txt
Index: gcc/testsuite/gcc.dg/tree-ssa/loop-bound-3.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/loop-bound-3.c(revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/loop-bound-3.c(revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-ivopts-details } */
+
+int *a;
+
+int
+foo (unsigned char s, unsigned char l)
+{
+ unsigned char i;
+ int sum = 0;
+
+ for (i = s; i l; i -= 1)
So is this really bounded by 254 iterations? ISTM it's bounded by 255
iterations when called with s = 255, l = 0. What am I missing here? Am I
mis-interpreting the dump output in some way?
Thanks for the comment.
IIUC, the niter information in struct tree_niter_desc means the number
of executions of the latch of the loop, so it's 254, rather than 255.
And same the bound information. Of course, statements in the loop
body could execute bound+1 times depending on its position in loop.
For example, struct nb_iter_bound is to describe number of iterations
of statements(exit conditions).
Moreover, if we modify the test as in below:
+int *a;
+
+int
+foo (void)
+{
+ unsigned char i;
+ int sum = 0;
+
+ for (i = 255; i 0; i -= 1)
GCC now successfully analyzes the loop's bound as 254.
I might be wrong about the code, so please correct me.
Thanks,
bin
Similarly for the other tests.
Jeff
[PATCH, committed] jit: on OS X, add -Wl,-undefined,dynamic_lookup to driver invocation
Reported as fixing the library on OS X Yosemite: https://gcc.gnu.org/ml/jit/2015-q3/msg00147.html Committed to trunk as r226882. Committed to gcc-5-branch as r226883. gcc/jit/ChangeLog: * jit-playback.c (invoke_driver): On OS X, add -Wl,-undefined,dynamic_lookup to the driver arguments. --- gcc/jit/jit-playback.c | 9 + 1 file changed, 9 insertions(+) diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c index 925fa86..01cfd4b 100644 --- a/gcc/jit/jit-playback.c +++ b/gcc/jit/jit-playback.c @@ -2416,6 +2416,15 @@ invoke_driver (const char *ctxt_progname, time. */ ADD_ARG (-fno-use-linker-plugin); +#if defined (DARWIN_X86) || defined (DARWIN_PPC) + /* OS X's linker defaults to treating undefined symbols as errors. + If the context has any imported functions or globals they will be + undefined until the .so is dynamically-linked into the process. + Ensure that the driver passes in -undefined dynamic_lookup to the + linker. */ + ADD_ARG (-Wl,-undefined,dynamic_lookup); +#endif + /* pex argv arrays are NULL-terminated. */ argvec.safe_push (NULL); -- 1.8.5.3
Re: [PATCH][MIPS] Fix register renaming in the interrupt handlers
Robert Suchanek robert.sucha...@imgtec.com writes: Hi, It was discovered that with the attached test case compiled with -O2 -funroll-loops, the regrename pass renamed one of the registers ($2) to $8 that was not saved by the prologue. The attached patch fixes it by defining macro HARD_REGNO_RENAME_OK that returns zero iff the current function is an interrupt handler and a register was never live. Regression is still in progress. Ok to apply if it passes? Regards, Robert gcc/ * config/mips/mips-protos.h (mips_hard_regno_rename_ok): New prototype. * config/mips/mips.c (mips_hard_regno_rename_ok): New function. * config/mips/mips.h (HARD_REGNO_RENAME_OK): New. gcc/testsuite/ * gcc.target/mips/interrupt_handler-bug-1.c: New test. You also need to do the same thing for TARGET_HARD_REGNO_SCRATCH_OK, to stop peephole2 from using unsaved registers as scratch registers. I should dig out my patches to clean up this interface. It's just too brittle to have two macros that say what registers can be used after reload. Thanks, Richard
Re: [PATCH] Move A - (A B) - ~B A
On Fri, 17 Jul 2015, Marek Polacek wrote:
On Fri, Jul 17, 2015 at 02:23:50PM +0200, Richard Biener wrote:
+/* Fold A - (A B) into ~B A. */
+(simplify
+ (minus (convert? @0) (convert? (bit_and:c @0 @1)))
I think you want :s on the bit_and and its convert?
Ok, I keep forgetting about this :(.
Are you sure you don't need to check for a nop conversion here?
I thought I didn't need it here, and couldn't find a testcase which
would break without tree_nop_conversion_p checks, but that doesn't mean
much. So for extra safety I put the checks there.
I believe you were right that we don't need the checks, it should also be
valid for narrowing / extending conversions.
Note that the equivalent (X Y) ^ Y as ~X Y does not have the
optional converts.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-07-17 Marek Polacek pola...@redhat.com
* fold-const.c (fold_binary_loc): Move A - (A B) into ~B A ...
* match.pd: ... here.
* gcc.dg/fold-minus-7.c: New test.
diff --git gcc/fold-const.c gcc/fold-const.c
index 93dd29d..fa321f4 100644
--- gcc/fold-const.c
+++ gcc/fold-const.c
@@ -9777,30 +9777,6 @@ fold_binary_loc (location_t loc,
if (! FLOAT_TYPE_P (type))
{
- /* Fold A - (A B) into ~B A. */
- if (!TREE_SIDE_EFFECTS (arg0)
- TREE_CODE (arg1) == BIT_AND_EXPR)
- {
- if (operand_equal_p (arg0, TREE_OPERAND (arg1, 1), 0))
- {
- tree arg10 = fold_convert_loc (loc, type,
-TREE_OPERAND (arg1, 0));
- return fold_build2_loc (loc, BIT_AND_EXPR, type,
- fold_build1_loc (loc, BIT_NOT_EXPR,
- type, arg10),
- fold_convert_loc (loc, type, arg0));
- }
- if (operand_equal_p (arg0, TREE_OPERAND (arg1, 0), 0))
- {
- tree arg11 = fold_convert_loc (loc,
-type, TREE_OPERAND (arg1, 1));
- return fold_build2_loc (loc, BIT_AND_EXPR, type,
- fold_build1_loc (loc, BIT_NOT_EXPR,
- type, arg11),
- fold_convert_loc (loc, type, arg0));
- }
- }
-
/* Fold (A ~B) - (A B) into (A ^ B) - B, where B is
any power of 2 minus 1. */
if (TREE_CODE (arg0) == BIT_AND_EXPR
diff --git gcc/match.pd gcc/match.pd
index c335ada..700a692 100644
--- gcc/match.pd
+++ gcc/match.pd
@@ -662,6 +662,12 @@ along with GCC; see the file COPYING3. If not see
(bit_ior:c (bit_and:cs @0 (bit_not @2)) (bit_and:cs @1 @2))
(bit_xor (bit_and (bit_xor @0 @1) @2) @0))
+/* Fold A - (A B) into ~B A. */
+(simplify
+ (minus (convert? @0) (convert?:s (bit_and:cs @0 @1)))
+ (if (tree_nop_conversion_p (type, TREE_TYPE (@0))
+ tree_nop_conversion_p (type, TREE_TYPE (@1)))
+ (convert (bit_and (bit_not @1) @0
/* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */
(simplify
diff --git gcc/testsuite/gcc.dg/fold-minus-7.c
gcc/testsuite/gcc.dg/fold-minus-7.c
index e69de29..7a49faa 100644
--- gcc/testsuite/gcc.dg/fold-minus-7.c
+++ gcc/testsuite/gcc.dg/fold-minus-7.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-options -O -fdump-tree-cddce1 } */
+
+int
+f1 (int a, int b)
+{
+ int tem = a b;
+ return a - tem;
+}
+
+int
+f2 (int a, int b)
+{
+ int tem = b a;
+ return a - tem;
+}
+
+int
+f3 (unsigned int a, int b)
+{
+ return a - (a b);
+}
+
+int
+f4 (int a, unsigned int b)
+{
+ return a - (a b);
+}
+
+int
+f5 (int a, int b)
+{
+ return a - (unsigned) (b a);
+}
+
+/* { dg-final { scan-tree-dump-not - cddce1 } } */
Marek
--
Marc Glisse
