Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
On May 14, 2015 12:46:06 AM GMT+02:00, Joseph Myers
wrote:
>On Wed, 13 May 2015, Marek Polacek wrote:
>
>> > Rather, how about having an extra argument to c_fully_fold_internal
>(e.g.
>> > for_int_const) indicating that the folding is of an expression with
>
>> > integer constant operands (so this argument would be true in the
>new case
>> > of folding the contents of a C_MAYBE_CONST_EXPR with
>> > C_MAYBE_CONST_EXPR_INT_OPERANDS set)? In that special case,
>> > c_fully_fold_internal would only fold the expression itself if all
>> > evaluated operands folded to INTEGER_CSTs (so if something that
>doesn't
>> > get folded, such as division by 0, is encountered, then all
>evaluated
>> > expressions containing it also don't get folded).
>>
>> Did you mean something like the following? It is on top of the
>previous
>> c_fully_fold_internal patch; if it makes any sense, I'll squash these
>> into one.
>
>Yes. The two patches are OK together, though I think it would be
>better
>to add for_int_const checks also in the cases of unary operations, &&,
>||
>and ?: (the last three being cases where it's only the evaluated
>operands
>that need to fold to INTEGER_CSTs, not any unevaluated operands). It
>may
>well be the case that no folding at present can fold any of those cases
>to
>an INTEGER_CST when it shouldn't be one, but I don't think we should
>rely
>on that.
>
>> This still doesn't reject enum { A = 0 * (unsigned) (1 / 0) };, but
>note
>> that we don't reject such an enum at present.
>
>It's rejected with -pedantic-errors, but it should indeed be rejected
>unconditionally like the other cases.
>
>Casts can do some optimization prematurely, but I don't know if that
>has
>anything to do with the non-rejection here.
Do the patches allow us to remove the restrictions from the folding patterns?
Richard.
Re: [gomp4] libgomp: Cope with DejaGnu having no mechanism to transfer environment variables to remote boards
On Thu, May 14, 2015 at 12:10:50AM +0200, Thomas Schwinge wrote: > No doubt, looking forward to the day, when this can be reverted. > > libgomp/ > * env.c (initialize_env): Remove static attribute. > * libgomp.map (INTERNAL): Export initialize_env. Ugh. While you achieve what you want for the remote board cases, doesn't this completely break all OpenMP and OpenACC programs not built as part of the testsuite, because initialize_env won't be called in that case? Jakub
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
On Thu, May 14, 2015 at 09:59:49AM +0200, Richard Biener wrote: > Do the patches allow us to remove the restrictions from the folding patterns? With the c_fully_fold_internal patches there's no need to tweak any match.pd patterns. So PR66127 + PR66066 are to be solved solely in the C FE. Is that what you're asking about? Marek
Re: [gomp4] nvptx libgcc atomic routines
On Wed, May 13, 2015 at 10:19:31PM +0200, Thomas Schwinge wrote:
> +/* Kernel helper for compare-and-exchange. */
> +static int
> +nvidia_cas (int oldval, int newval, int *ptr)
> +{
> + int ret;
> +
> + asm volatile ("atom.cas.b32 %0, [%1], %2, %3;" : "=r"(ret) : "r"(ptr),
> + "r"(oldval), "r"(newval));
> +
> + return ret;
> +}
Why? Can't you just use __sync_*_compare_and_swap or __atomic_* ?
> +#define OP_AND_FETCH_WORD(OP, PFX_OP, INF_OP)
> \
> + int HIDDEN \
> + __sync_##OP##_and_fetch_4 (int *ptr, int val)
> \
> + { \
> +int tmp, failure;
> \
> + \
> +do { \
> + tmp = *ptr;\
> + failure = __kernel_cmpxchg (tmp, PFX_OP (tmp INF_OP val), ptr);
> \
> +} while (failure != 0); \
> + \
> +return PFX_OP (tmp INF_OP val); \
> + }
Again, why? I thought 32-bit and 64-bit atomics are supported inline.
> +int HIDDEN
> +__sync_val_compare_and_swap_4 (int *ptr, int oldval, int newval)
> +{
> + int actual_oldval, fail;
> +
> + while (1)
> +{
> + actual_oldval = *ptr;
> +
> + if (oldval != actual_oldval)
> + return actual_oldval;
> +
> + fail = __kernel_cmpxchg (actual_oldval, newval, ptr);
> +
> + if (!fail)
> + return oldval;
> +}
> +}
Likewise.
> +typedef unsigned char bool;
> +
> +bool HIDDEN
> +__sync_bool_compare_and_swap_4 (int *ptr, int oldval, int newval)
> +{
> + int failure = __kernel_cmpxchg (oldval, newval, ptr);
> + return (failure == 0);
> +}
Likewise. Why the unsigned char bool? Just use _Bool instead?
> +int HIDDEN
> +__sync_lock_test_and_set_4 (int *ptr, int val)
> +{
> + int failure, oldval;
> +
> + do {
> +oldval = *ptr;
> +failure = __kernel_cmpxchg (oldval, val, ptr);
> + } while (failure != 0);
> +
> + return oldval;
> +}
Ditto.
> +SYNC_LOCK_RELEASE (int, 4)
Ditto.
Jakub
Re: [gomp4] Assorted OpenACC changes (was: Next set of OpenACC changes)
On Wed, May 13, 2015 at 10:52:08PM +0200, Thomas Schwinge wrote: > In a similar vein, I have now committed the following to gomp-4_0-branch > in r223178. This is not meant to be integrated into trunk as-is: there > are incompatible libgomp ABI changes, for example. We'd still appreciate ABI incompatible libgomp changes are absolute no-no. You need to provide backwards compatibility... Jakub
Re: RFA: RL78: Place zero-initialised data into the .bss section
Hi DJ, Ok but.. +case SECCAT_TBSS: + return default_select_section (decl, reloc, align); + +default: + gcc_unreachable (); Would it be better to just "default:" everything to default_select_section, instead of enumerating everything we know about today? Yes it would. :-} I have committed the patch with that change applied. Cheers Nick
Re: C/C++ PATCH to allow deprecating enum values (PR c/47043)
Ping.
Joseph, do you have any further comments on the patch?
Jason, can you review the C++ parts?
Thanks,
On Thu, May 07, 2015 at 06:22:40PM +0200, Marek Polacek wrote:
> This (third) version of the patch entails the change in tsubst_enum Ed
> suggested + new testcase.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2015-05-07 Marek Polacek
> Edward Smith-Rowland <3dw...@verizon.net>
>
> PR c/47043
> * c-common.c (handle_deprecated_attribute): Allow CONST_DECL.
>
> * c-parser.c (c_parser_enum_specifier): Parse and apply enumerator
> attributes.
>
> * cp-tree.h (build_enumerator): Update declaration.
> * decl.c (build_enumerator): Add attributes parameter. Call
> cplus_decl_attributes.
> * init.c (constant_value_1): Pass 0 to mark_used.
> * parser.c (cp_parser_enumerator_definition): Parse attributes and
> pass them down to build_enumerator.
> * pt.c (tsubst_enum): Pass decl attributes to build_enumerator.
> * semantics.c (finish_id_expression): Don't warn_deprecated_use here.
>
> * doc/extend.texi (Enumerator Attributes): New section.
> Document syntax of enumerator attributes.
>
> * c-c++-common/attributes-enum-1.c: New test.
> * c-c++-common/attributes-enum-2.c: New test.
> * g++.dg/cpp0x/attributes-enum-1.C: New test.
> * g++.dg/cpp1y/attributes-enum-1.C: New test.
>
> diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
> index ada8e8a..36968e5 100644
> --- gcc/c-family/c-common.c
> +++ gcc/c-family/c-common.c
> @@ -8810,6 +8810,7 @@ handle_deprecated_attribute (tree *node, tree name,
> || TREE_CODE (decl) == VAR_DECL
> || TREE_CODE (decl) == FUNCTION_DECL
> || TREE_CODE (decl) == FIELD_DECL
> + || TREE_CODE (decl) == CONST_DECL
> || objc_method_decl (TREE_CODE (decl)))
> TREE_DEPRECATED (decl) = 1;
>else
> diff --git gcc/c/c-parser.c gcc/c/c-parser.c
> index bf0e4c57..889e6d7 100644
> --- gcc/c/c-parser.c
> +++ gcc/c/c-parser.c
> @@ -2516,6 +2516,13 @@ c_parser_declspecs (c_parser *parser, struct
> c_declspecs *specs,
> enumerator:
> enumeration-constant
> enumeration-constant = constant-expression
> +
> + GNU Extensions:
> +
> + enumerator:
> + enumeration-constant attributes[opt]
> + enumeration-constant attributes[opt] = constant-expression
> +
> */
>
> static struct c_typespec
> @@ -2575,6 +2582,8 @@ c_parser_enum_specifier (c_parser *parser)
> c_parser_set_source_position_from_token (token);
> decl_loc = value_loc = token->location;
> c_parser_consume_token (parser);
> + /* Parse any specified attributes. */
> + tree enum_attrs = c_parser_attributes (parser);
> if (c_parser_next_token_is (parser, CPP_EQ))
> {
> c_parser_consume_token (parser);
> @@ -2584,7 +2593,9 @@ c_parser_enum_specifier (c_parser *parser)
> else
> enum_value = NULL_TREE;
> enum_decl = build_enumerator (decl_loc, value_loc,
> - &the_enum, enum_id, enum_value);
> + &the_enum, enum_id, enum_value);
> + if (enum_attrs)
> + decl_attributes (&TREE_PURPOSE (enum_decl), enum_attrs, 0);
> TREE_CHAIN (enum_decl) = values;
> values = enum_decl;
> seen_comma = false;
> diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
> index e0fbf5e..6b26cb1 100644
> --- gcc/cp/cp-tree.h
> +++ gcc/cp/cp-tree.h
> @@ -5400,7 +5400,7 @@ extern bool xref_basetypes (tree,
> tree);
> extern tree start_enum (tree, tree, tree,
> bool, bool *);
> extern void finish_enum_value_list (tree);
> extern void finish_enum (tree);
> -extern void build_enumerator (tree, tree, tree, location_t);
> +extern void build_enumerator (tree, tree, tree, tree,
> location_t);
> extern tree lookup_enumerator(tree, tree);
> extern bool start_preparsed_function (tree, tree, int);
> extern bool start_function (cp_decl_specifier_seq *,
> diff --git gcc/cp/decl.c gcc/cp/decl.c
> index 261a12d..ebbd585 100644
> --- gcc/cp/decl.c
> +++ gcc/cp/decl.c
> @@ -13067,11 +13067,12 @@ finish_enum (tree enumtype)
>
> /* Build and install a CONST_DECL for an enumeration constant of the
> enumeration type ENUMTYPE whose NAME and VALUE (if any) are provided.
> - LOC is the location of NAME.
> + Apply ATTRIBUTES if available. LOC is the location of NAME.
> Assignment of sequential values by default is handled here. */
>
> void
> -build_enumerator (tree name, tree value, tree enumtype, location_t loc)
> +build_enumerator (tree name, tree value, tree enumtype, tree attributes,
> + location_t loc)
> {
>tree decl;
>tree context;
> @@ -13234,6 +13235,9 @@ incre
Re: [gomp4] libgomp: Cope with DejaGnu having no mechanism to transfer environment variables to remote boards
On Thu, May 14, 2015 at 10:05:36AM +0200, Jakub Jelinek wrote: > On Thu, May 14, 2015 at 12:10:50AM +0200, Thomas Schwinge wrote: > > No doubt, looking forward to the day, when this can be reverted. > > > > libgomp/ > > * env.c (initialize_env): Remove static attribute. > > * libgomp.map (INTERNAL): Export initialize_env. > > Ugh. While you achieve what you want for the remote board cases, > doesn't this completely break all OpenMP and OpenACC programs not built > as part of the testsuite, because initialize_env won't be called in that case? Can't you just tweak *.exp files so that if dg-set-target-env-var is used or some forced env var is added to the same list through other means, you invoke on the remove side env VAR1=val1 VAR2=val2 program arguments instead of program arguments ? Jakub
Re: [PATCH, alpha]: Remove some_operand and some_ni_operand
On Wed, May 13, 2015 at 8:53 PM, Richard Henderson wrote:
> On 05/13/2015 11:11 AM, Uros Bizjak wrote:
>> We can use general_operand instead of some_operand.
>>
>> 2015-05-13 Uros Bizjak
>>
>> * config/alpha/alpha.md (extendqidi2): Use general_operand
>> instead of some_operand for operand[1] predicate.
>> (extendhidi2): Ditto.
>> (cbranchdi4): Use general_operand instead of some_operand
>> for operand[1] and operands[2] predicates.
>> (cstoredi4): Ditto.
>> * config/alpha/predicates.md (some_operand): Remove unused predicate.
>> (some_ni_operand): Ditto.
>>
>> Tested on alpha-linux-gnu.
>>
>> Richard, does this look OK to you, or is there any other reason that
>> general_operand predicates were not used here?
>
> For the extensions, it was put in by Kenner in 1997 (90f6b60d), to improve
> code
> for unaligned memories. That code was removed in 2011 by me (8b2983a3), so I
> think dropping some_operand there is fine.
>
> For the conditionals, it was added in 2004 by me (62350d6c), and that code is
> still there. Specifically,
>
> @@ -3177,11 +3177,17 @@ alpha_emit_conditional_branch (enum rtx_code code)
> cmp_code = NIL, branch_code = code;
>
> /* If the constants doesn't fit into an immediate, but can
> be generated by lda/ldah, we adjust the argument and
> compare against zero, so we can use beq/bne directly. */
> - else if (GET_CODE (op1) == CONST_INT && (code == EQ || code == NE))
> + /* ??? Don't do this when comparing against symbols, otherwise
> +we'll reduce (&x == 0x1234) to (&x-0x1234 == 0), which will
> +be declared false out of hand (at least for non-weak). */
> + else if (GET_CODE (op1) == CONST_INT
> + && (code == EQ || code == NE)
> + && !(symbolic_operand (op0, VOIDmode)
> + || (GET_CODE (op0) == REG && REG_POINTER (op0
>
> If I didn't use some_operand, the SYMBOL_REF would be lowered and we'll only
> see a REG here. Searching the mail archive I find
>
> https://gcc.gnu.org/ml/gcc-patches/2004-02/msg02436.html
>
> pointing to the test case gcc.dg/20040123-1.c
>
> Perhaps debugging that testcase to see what's reaching a_e_c_b in these modern
> times will tell you what's most appropriate.
The reason for removing some_operand is, that it is effectively
exactly equal to general_operand:
from gensupport.c:
{"general_operand", false, true, {SUBREG, REG, MEM}},
the second "true" stands for "bool allows_const_p", where:
if (std_preds[i].allows_const_p)
for (j = 0; j < NUM_RTX_CODE; j++)
if (GET_RTX_CLASS (j) == RTX_CONST_OBJ)
add_predicate_code (pred, (enum rtx_code) j);
and from rtl.def, these are all RTX_CONST_OBJs:
rtl.def:DEF_RTL_EXPR(CONST_INT, "const_int", "w", RTX_CONST_OBJ)
rtl.def:DEF_RTL_EXPR(CONST_WIDE_INT, "const_wide_int", "", RTX_CONST_OBJ)
rtl.def:DEF_RTL_EXPR(CONST_FIXED, "const_fixed", "www", RTX_CONST_OBJ)
rtl.def:DEF_RTL_EXPR(CONST_DOUBLE, "const_double",
CONST_DOUBLE_FORMAT, RTX_CONST_OBJ)
rtl.def:DEF_RTL_EXPR(CONST_VECTOR, "const_vector", "E", RTX_CONST_OBJ)
rtl.def:DEF_RTL_EXPR(CONST, "const", "e", RTX_CONST_OBJ)
rtl.def:DEF_RTL_EXPR(LABEL_REF, "label_ref", "u", RTX_CONST_OBJ)
rtl.def:DEF_RTL_EXPR(SYMBOL_REF, "symbol_ref", "s0", RTX_CONST_OBJ)
rtl.def:DEF_RTL_EXPR(HIGH, "high", "e", RTX_CONST_OBJ)
This is exactly the list of constant operands (minus const_fixed) from
some_operand predicate:
(define_predicate "some_operand"
(ior (match_code "reg,mem,const_int,const_wide_int,const_double,const_vector,
label_ref,symbol_ref,const,high")
(and (match_code "subreg")
(match_test "some_operand (SUBREG_REG (op), VOIDmode)"
So, the only question is about SUBREG processing here, but I don't
think it matters here.
Uros.
Re: [ARM][PR65768] Keep constants in register when expanding
On 27/04/15 00:07, Kugan wrote: While I support your goals, I think your approach needs some refinement. In particular, we DO NOT want another function that starts looking at constant values and tries to decide, on a case by case basis, what to do with that value. We need to keep the logic for that, as much as possible, in one small set of functions so that the compiler cannot end up with conflicting decisions coming from different bits of code. So const_ok_for_split has to go. Instead you should be using const_ok_for op (an existing routine) and a simple macro that encapsulates "optimize >= 2 && can_create_pseudo_p ()" as the gate for when to use a separate scratch register. Thanks for the review. Please find the patch attached that does this. Regression tested on qemu for arm-none-linux-gnueab with no new regressions. Bootstrapped successfully on chromebook. Is this OK for trunk? Thanks, Kugan gcc/ChangeLog: 2015-04-26 Kugan Vivekanandarajah Zhenqiang Chen PR target/65768 * config/arm/arm.h (CONST_OK_FOR_SPLIT): New macro. * config/arm/arm.md (subsi3, andsi3, iorsi3, xorsi3, movsi): Keep some large constants in register instead of splitting them. I think your macro should be renamed to "DONT_EARLY_SPLIT_CONSTANT" (and the logic for it inverted, so that you don't need '!' in front of every instance). OK with that change. R. gcc/testsuite/ChangeLog: 2015-04-26 Kugan Vivekanandarajah Zhenqiang Chen PR target/65768 * gcc.target/arm/maskdata.c: New test.
Re: [gomp4] libgomp: Cope with DejaGnu having no mechanism to transfer environment variables to remote boards
On Thu, May 14, 2015 at 10:54:07AM +0200, Jakub Jelinek wrote: > On Thu, May 14, 2015 at 10:05:36AM +0200, Jakub Jelinek wrote: > > On Thu, May 14, 2015 at 12:10:50AM +0200, Thomas Schwinge wrote: > > > No doubt, looking forward to the day, when this can be reverted. > > > > > > libgomp/ > > > * env.c (initialize_env): Remove static attribute. > > > * libgomp.map (INTERNAL): Export initialize_env. > > > > Ugh. While you achieve what you want for the remote board cases, > > doesn't this completely break all OpenMP and OpenACC programs not built > > as part of the testsuite, because initialize_env won't be called in that > > case? > > Can't you just tweak *.exp files so that if dg-set-target-env-var is used > or some forced env var is added to the same list through other means, > you invoke on the remove side env VAR1=val1 VAR2=val2 program arguments > instead of program arguments ? Talking about the libgomp testsuite, can we rename the libgomp/testsuite/libgomp-oacc-*/*.exp files to something unique? I mean, trying to run say just the OpenMP C tests is impossible since the OpenACC merge, because RUNTESTFLAGS=c.exp runs both OpenMP and OpenACC. If it was say acc-c.exp, then you can choose if you want to test just OpenACC, or just OpenMP, both, and which particular tests more accurately. Jakub
Re: [PATCH][AArch64] Use conditional negate for abs expansion
On Mon, Apr 27, 2015 at 05:57:26PM +0100, Wilco Dijkstra wrote:
> > James Greenhalgh wrote:
> > On Mon, Apr 27, 2015 at 02:42:36PM +0100, Wilco Dijkstra wrote:
> > > > -Original Message-
> > > > From: Wilco Dijkstra [mailto:wdijk...@arm.com]
> > > > Sent: 03 March 2015 16:19
> > > > To: GCC Patches
> > > > Subject: [PATCH][AArch64] Use conditional negate for abs expansion
> > > >
> > > > Expand abs into a compare and conditional negate. This is the most
> > > > obvious expansion,
> > enables
> > > > merging of the comparison into ALU instructions and is faster on all
> > > > implementations.
> > > > Bootstrapped & regression tested.
> > > >
> > > > int f(int x) { return abs (x + 1); }
> > > >
> > > > Before:
> > > > add w0, w0, 1
> > > > sxtwx0, w0
> > > > eor x1, x0, x0, asr 63
> > > > sub x1, x1, x0, asr 63
> > > > mov x0, x1
> > > > ret
> > > >
> > > > After:
> > > > addsw0, w0, 1
> > > > csneg w0, w0, w0, pl
> > > > ret
> > > >
> > > > ChangeLog:
> > > >
> > > > 2015-03-03 Wilco Dijkstra
> > > >
> > > > * gcc/config/aarch64/aarch64.md (absdi2): optimize abs
> > > > expansion.
> > > > (csneg3_insn): enable expansion of pattern.
> > > > * gcc/testsuite/gcc.target/aarch64/abs_1.c (abs64): update test
> > > > for new abs expansion. (abs64_in_dreg): likewise.
> >
> >
> > This looks like it breaks support for abs in a D register (for example
> > at the end of a loop, or extracted from Neon Intrinsics, etc).
> >
> > e.g. (totally contrived...)
> >
> > int64x1_t
> > abs_max (int64x2_t x, int64_t *wb)
> > {
> > int64_t y = vgetq_lane_s64 (x, 0);
> > if (y < 0)
> > y = -y;
> > return vdup_n_s64 (y);
> > }
> >
> > Which currently generates:
> >
> > abs_max:
> > abs d0, d0
> > ret
> >
> > I suppose we don't need to worry too much about that (and the current
> > implementation doesn't seem to catch it reliably anyway), but it would be
> > good if we could keep the support - even if it is rarely used.
>
> Well it may be possible to write a peephole for this rare case, but I hope
> people would use a vabs if that's what they wanted...
OK, I've seen some of the pain of our current abs expansion code, so I
suppose that we want to get the common case right first, rather
than be too concerned about contrived corner cases.
This patch is OK.
Thanks,
James
Re: [Patch, fortran, pr65548, 2nd take, v4] [5/6 Regression] gfc_conv_procedure_call
Hi Mikael, hi all,
please find attached the new version of this patch, where most of the source=
expression assignment to the object to allocate is handled by
gfc_trans_assignment (). To use trans_assignment with temporaries introduced
during the preparation of the source= expression, a gfc_expr is created from
the temporary identifier in the tree of expr3. This creation is done only,
when the tree is an artificial declaration, i.e., a temporary. The gfx_expr is
created only once and only for non-class objects, because for the latter
gfc_trans_assignment can't cope with class arrays, for which the
gfc_trans_allocate () needs the array-descriptor, which is not as easy to
transfer to gfc_trans_assignment (). For class objects gfc_trans_allocate ()
therefore cares about the assignment/data copy itself.
Bootstraps and regtests ok on x86_64-linux-gnu/f21.
Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2015-05-14 Andre Vehreschild
PR fortran/65548
* trans-stmt.c (gfc_trans_allocate): Always retrieve the
descriptor or a reference to a source= expression now for
arrays and non-arrays, respectively. Use a temporary
symbol and gfc_trans_assignment for all source=
assignments to allocated objects.
gcc/testsuite/ChangeLog:
2015-05-14 Andre Vehreschild
PR fortran/65548
* gfortran.dg/allocate_with_source_5.f90: Extend test.
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 814bdde..9688f71 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5088,7 +5088,7 @@ tree
gfc_trans_allocate (gfc_code * code)
{
gfc_alloc *al;
- gfc_expr *expr;
+ gfc_expr *expr, *e3rhs = NULL;
gfc_se se, se_sz;
tree tmp;
tree parm;
@@ -5148,14 +5148,11 @@ gfc_trans_allocate (gfc_code * code)
TREE_USED (label_finish) = 0;
}
- /* When an expr3 is present, try to evaluate it only once. In most
- cases expr3 is invariant for all elements of the allocation list.
- Only exceptions are arrays. Furthermore the standards prevent a
- dependency of expr3 on the objects in the allocate list. Therefore
- it is safe to pre-evaluate expr3 for complicated expressions, i.e.
- everything not a variable or constant. When an array allocation
- is wanted, then the following block nevertheless evaluates the
- _vptr, _len and element_size for expr3. */
+ /* When an expr3 is present evaluate it only once. The standards prevent a
+ dependency of expr3 on the objects in the allocate list. An expr3 can
+ be pre-evaluated in all cases. One just has to make sure, to use the
+ correct way, i.e., to get the descriptor or to get a reference
+ expression. */
if (code->expr3)
{
bool vtab_needed = false;
@@ -5168,75 +5165,91 @@ gfc_trans_allocate (gfc_code * code)
al = al->next)
vtab_needed = (al->expr->ts.type == BT_CLASS);
- /* A array expr3 needs the scalarizer, therefore do not process it
- here. */
- if (code->expr3->expr_type != EXPR_ARRAY
- && (code->expr3->rank == 0
- || code->expr3->expr_type == EXPR_FUNCTION)
- && (!code->expr3->symtree
- || !code->expr3->symtree->n.sym->as)
- && !gfc_is_class_array_ref (code->expr3, NULL))
- {
- /* When expr3 is a variable, i.e., a very simple expression,
+ /* When expr3 is a variable, i.e., a very simple expression,
then convert it once here. */
- if ((code->expr3->expr_type == EXPR_VARIABLE)
- || code->expr3->expr_type == EXPR_CONSTANT)
- {
- if (!code->expr3->mold
- || code->expr3->ts.type == BT_CHARACTER
- || vtab_needed)
- {
- /* Convert expr3 to a tree. */
- gfc_init_se (&se, NULL);
- se.want_pointer = 1;
- gfc_conv_expr (&se, code->expr3);
- if (!code->expr3->mold)
- expr3 = se.expr;
- else
- expr3_tmp = se.expr;
- expr3_len = se.string_length;
- gfc_add_block_to_block (&block, &se.pre);
- gfc_add_block_to_block (&post, &se.post);
- }
- /* else expr3 = NULL_TREE set above. */
- }
- else
+ if (code->expr3->expr_type == EXPR_VARIABLE
+ || code->expr3->expr_type == EXPR_ARRAY
+ || code->expr3->expr_type == EXPR_CONSTANT)
+ {
+ if (!code->expr3->mold
+ || code->expr3->ts.type == BT_CHARACTER
+ || vtab_needed)
{
- /* In all other cases evaluate the expr3 and create a
- temporary. */
+ /* Convert expr3 to a tree. */
gfc_init_se (&se, NULL);
- if (code->expr3->rank != 0
- && code->expr3->expr_type == EXPR_FUNCTION
- && code->expr3->value.function.isym)
+ /* For all "simple" expression just get the descriptor or the
+ reference, respectively, depending on the rank of the expr. */
+ if (code->expr3->rank != 0)
gfc_conv_expr_descriptor (&se, code->expr3);
else
gfc_conv_expr_reference (&se, code->expr3);
- if (code->expr3->ts.type
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
On May 14, 2015 10:10:35 AM GMT+02:00, Marek Polacek wrote: >On Thu, May 14, 2015 at 09:59:49AM +0200, Richard Biener wrote: >> Do the patches allow us to remove the restrictions from the folding >patterns? > >With the c_fully_fold_internal patches there's no need to tweak any >match.pd >patterns. So PR66127 + PR66066 are to be solved solely in the C FE. >Is that >what you're asking about? No, I'm asking whether we can remove the existing guards in match.pd. Richard. > Marek
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
On Thu, May 14, 2015 at 11:48:55AM +0200, Richard Biener wrote: > On May 14, 2015 10:10:35 AM GMT+02:00, Marek Polacek > wrote: > >On Thu, May 14, 2015 at 09:59:49AM +0200, Richard Biener wrote: > >> Do the patches allow us to remove the restrictions from the folding > >patterns? > > > >With the c_fully_fold_internal patches there's no need to tweak any > >match.pd > >patterns. So PR66127 + PR66066 are to be solved solely in the C FE. > >Is that > >what you're asking about? > > No, I'm asking whether we can remove the existing guards in match.pd. There is also the C++ FE... Jakub
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
On Thu, May 14, 2015 at 11:48:55AM +0200, Richard Biener wrote:
> On May 14, 2015 10:10:35 AM GMT+02:00, Marek Polacek
> wrote:
> >On Thu, May 14, 2015 at 09:59:49AM +0200, Richard Biener wrote:
> >> Do the patches allow us to remove the restrictions from the folding
> >patterns?
> >
> >With the c_fully_fold_internal patches there's no need to tweak any
> >match.pd
> >patterns. So PR66127 + PR66066 are to be solved solely in the C FE.
> >Is that
> >what you're asking about?
>
> No, I'm asking whether we can remove the existing guards in match.pd.
Sorry, I don't know which guards exactly you mean (side effects?) so can't
verify, but as Jakub points out, I doubt we can remove anything at this point
because of C++ FE. (c_fully_fold{,_internal} are never used in the C++ FE.)
Marek
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
On Wed, May 13, 2015 at 10:46:06PM +, Joseph Myers wrote:
> Yes. The two patches are OK together, though I think it would be better
Thanks.
> to add for_int_const checks also in the cases of unary operations, &&, ||
> and ?: (the last three being cases where it's only the evaluated operands
> that need to fold to INTEGER_CSTs, not any unevaluated operands). It may
> well be the case that no folding at present can fold any of those cases to
> an INTEGER_CST when it shouldn't be one, but I don't think we should rely
> on that.
Yeah, I couldn't find a case where it would trigger, but I added for_int_const
checks for the other cases all the same.
I'm attaching the patch here for archival purposes.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2015-05-14 Marek Polacek
PR c/66066
PR c/66127
* c-common.c (c_fully_fold): Pass false down to c_fully_fold_internal.
(c_fully_fold_internal): Fold C_MAYBE_CONST_EXPRs with
C_MAYBE_CONST_EXPR_INT_OPERANDS set. Add FOR_INT_CONST argument and
use it. If FOR_INT_CONST, require that all evaluated operands be
INTEGER_CSTs.
* c-typeck.c (digest_init): Call pedwarn_init with OPT_Wpedantic
rather than with 0.
* gcc.dg/pr14649-1.c: Add -Wpedantic.
* gcc.dg/pr19984.c: Likewise.
* gcc.dg/pr66066-1.c: New test.
* gcc.dg/pr66066-2.c: New test.
* gcc.dg/pr66066-3.c: New test.
diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 7e5ac72..31c4c0d 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -315,7 +315,7 @@ const struct fname_var_t fname_vars[] =
/* Global visibility options. */
struct visibility_flags visibility_options;
-static tree c_fully_fold_internal (tree expr, bool, bool *, bool *);
+static tree c_fully_fold_internal (tree expr, bool, bool *, bool *, bool);
static tree check_case_value (location_t, tree);
static bool check_case_bounds (location_t, tree, tree, tree *, tree *);
@@ -1148,7 +1148,7 @@ c_fully_fold (tree expr, bool in_init, bool *maybe_const)
expr = TREE_OPERAND (expr, 0);
}
ret = c_fully_fold_internal (expr, in_init, maybe_const,
- &maybe_const_itself);
+ &maybe_const_itself, false);
if (eptype)
ret = fold_convert_loc (loc, eptype, ret);
*maybe_const &= maybe_const_itself;
@@ -1161,11 +1161,13 @@ c_fully_fold (tree expr, bool in_init, bool
*maybe_const)
arithmetic overflow (for C90, *MAYBE_CONST_OPERANDS is carried from
both evaluated and unevaluated subexpressions while
*MAYBE_CONST_ITSELF is carried from only evaluated
- subexpressions). */
+ subexpressions). FOR_INT_CONST indicates if EXPR is an expression
+ with integer constant operands, and if any of the operands doesn't
+ get folded to an integer constant, don't fold the expression itself. */
static tree
c_fully_fold_internal (tree expr, bool in_init, bool *maybe_const_operands,
- bool *maybe_const_itself)
+ bool *maybe_const_itself, bool for_int_const)
{
tree ret = expr;
enum tree_code code = TREE_CODE (expr);
@@ -1209,7 +1211,11 @@ c_fully_fold_internal (tree expr, bool in_init, bool
*maybe_const_operands,
if (C_MAYBE_CONST_EXPR_NON_CONST (expr))
*maybe_const_operands = false;
if (C_MAYBE_CONST_EXPR_INT_OPERANDS (expr))
- *maybe_const_itself = false;
+ {
+ *maybe_const_itself = false;
+ inner = c_fully_fold_internal (inner, in_init, maybe_const_operands,
+maybe_const_itself, true);
+ }
if (pre && !in_init)
ret = build2 (COMPOUND_EXPR, TREE_TYPE (expr), pre, inner);
else
@@ -1259,7 +1265,7 @@ c_fully_fold_internal (tree expr, bool in_init, bool
*maybe_const_operands,
op1 = TREE_OPERAND (expr, 1);
op2 = TREE_OPERAND (expr, 2);
op0 = c_fully_fold_internal (op0, in_init, maybe_const_operands,
- maybe_const_itself);
+ maybe_const_itself, for_int_const);
STRIP_TYPE_NOPS (op0);
if (op0 != orig_op0)
ret = build3 (COMPONENT_REF, TREE_TYPE (expr), op0, op1, op2);
@@ -1276,10 +1282,10 @@ c_fully_fold_internal (tree expr, bool in_init, bool
*maybe_const_operands,
op2 = TREE_OPERAND (expr, 2);
op3 = TREE_OPERAND (expr, 3);
op0 = c_fully_fold_internal (op0, in_init, maybe_const_operands,
- maybe_const_itself);
+ maybe_const_itself, for_int_const);
STRIP_TYPE_NOPS (op0);
op1 = c_fully_fold_internal (op1, in_init, maybe_const_operands,
- maybe_const_itself);
+ maybe_const_itself, for_int_const);
STRIP_TYPE_NOPS (op1);
op1 = decl_constant_value_for_optimization (op1);
Re: [PATCH PR65447]Improve IV handling by grouping address type uses with same base and step
On Wed, May 13, 2015 at 7:38 PM, Richard Biener wrote: > On Fri, May 8, 2015 at 12:47 PM, Bin Cheng wrote: >> Hi, >> GCC's IVO currently handles every IV use independently, which is not right >> by learning from cases reported in PR65447. >> >> The rationale is: >> 1) Lots of address type IVs refer to the same memory object, share similar >> base and have same step. We should handle these IVs as a group in order to >> maximize CSE opportunities, prefer reg+offset addressing mode. >> 2) GCC's IVO algorithm is expensive and only is run when candidate set is >> small enough. By grouping same family uses, we can decrease the number of >> both uses and candidates. Before this patch, number of candidates for >> PR65447 is too big to run expensive IVO algorithm, resulting in bad assembly >> code on targets like AArch64 and Mips. >> 3) Even for cases the assembly code isn't improved, we can still get >> compilation time benefit with this patch. >> 4) This is a prerequisite for enabling auto-increment support in IVO on >> AArch64. >> >> For now, this is only done to address type IVs, in the future I may extend >> it to general IVs too. >> >> For AArch64: >> Benchmarks 470.lbm/spec2k6 and 173.applu/spec2k are improved obviously by >> this patch. A couple of cases from spec2k/fp appear regressed. I looked >> into generated assembly code and can confirm the regression is false alarm >> except one case (189.lucas). For that case, I think it's another issue >> exposed by this patch (GCC failed to CSE candidate setup code, resulting in >> bloated loop header). Anyway, I also fined tuned the patch to minimize the >> impact. >> >> For AArch32, this patch seems to be able to improve spec2kfp too, but I >> didn't look deep into it. I guess the reason is it can make life for >> auto-increment support in IVO better. >> >> One of defects of this patch is computation of max offset in >> compute_max_addr_offset is basically borrowed from get_address_cost. The >> comment says we should find a better way to compute all information. People >> also complained we need to refactor that part of code. I don't have good >> solution to that yet, though I did try best to keep compute_max_addr_offset >> simple. >> >> I believe this is a generally wanted change, bootstrap and test on x86_64 >> and AArch64, so is it ok? > > I'm a little bit worried about the linked list of sub-uses and the "sorting" > (that's quadratic). A little. I don't have any good idea but to use a > tree... > We don't seem to limit the number of sub-uses (if we'd do that it would > become O(1)). > > Similar is searching in the list of uses for a group with same base/step > (but ISTR IVOPTs has multiple similar loops?) Hi Richard, Thanks for reviewing. Instead of tree, I can also keep the linked list, then quick sort it by using a vector as temporary storage. This can avoid the complexity of BST operations without non-trivial overload. For the searching routine, a local hash table could help. > > Overall the patch looks like a good improvement to how we do IVO, so I think > it is ok as-is. Do you want me to do this change now, or I can pick it up later when dealing with compilation time issue? Also it would be nice if any compilation time issue will be reported after applying this version patch. Because we will have a IVO compilation time benchmark then. Thanks, bin > > Thanks, > Richard. > > >> >> 2015-05-08 Bin Cheng >> >> PR tree-optimization/65447 >> * tree-ssa-loop-ivopts.c (struct iv_use): New fields. >> (dump_use, dump_uses): Support to dump sub use. >> (record_use): New parameters to support sub use. Remove call to >> dump_use. >> (record_sub_use, record_group_use): New functions. >> (compute_max_addr_offset, split_all_small_groups): New functions. >> (group_address_uses, rewrite_use_address): New functions. >> (strip_offset): New declaration. >> (find_interesting_uses_address): Call record_group_use. >> (add_candidate): New assertion. >> (infinite_cost_p): Move definition forward. >> (add_costs): Check INFTY cost and return immediately. >> (get_computation_cost_at): Clear setup cost and dependent bitmap >> for sub uses. >> (determine_use_iv_cost_address): Compute cost for sub uses. >> (rewrite_use_address_1): Rename from old rewrite_use_address. >> (free_loop_data): Free sub uses. >> (tree_ssa_iv_optimize_loop): Call group_address_uses. >> >> gcc/testsuite/ChangeLog >> 2015-05-08 Bin Cheng >> >> PR tree-optimization/65447 >> * gcc.dg/tree-ssa/pr65447.c: New test.
Re: [PATCH, alpha]: Remove some_operand and some_ni_operand
On Wed, May 13, 2015 at 8:53 PM, Richard Henderson wrote:
> On 05/13/2015 11:11 AM, Uros Bizjak wrote:
>> We can use general_operand instead of some_operand.
>>
>> 2015-05-13 Uros Bizjak
>>
>> * config/alpha/alpha.md (extendqidi2): Use general_operand
>> instead of some_operand for operand[1] predicate.
>> (extendhidi2): Ditto.
>> (cbranchdi4): Use general_operand instead of some_operand
>> for operand[1] and operands[2] predicates.
>> (cstoredi4): Ditto.
>> * config/alpha/predicates.md (some_operand): Remove unused predicate.
>> (some_ni_operand): Ditto.
>>
>> Tested on alpha-linux-gnu.
>>
>> Richard, does this look OK to you, or is there any other reason that
>> general_operand predicates were not used here?
>
> For the extensions, it was put in by Kenner in 1997 (90f6b60d), to improve
> code
> for unaligned memories. That code was removed in 2011 by me (8b2983a3), so I
> think dropping some_operand there is fine.
>
> For the conditionals, it was added in 2004 by me (62350d6c), and that code is
> still there. Specifically,
>
> @@ -3177,11 +3177,17 @@ alpha_emit_conditional_branch (enum rtx_code code)
> cmp_code = NIL, branch_code = code;
>
> /* If the constants doesn't fit into an immediate, but can
> be generated by lda/ldah, we adjust the argument and
> compare against zero, so we can use beq/bne directly. */
> - else if (GET_CODE (op1) == CONST_INT && (code == EQ || code == NE))
> + /* ??? Don't do this when comparing against symbols, otherwise
> +we'll reduce (&x == 0x1234) to (&x-0x1234 == 0), which will
> +be declared false out of hand (at least for non-weak). */
> + else if (GET_CODE (op1) == CONST_INT
> + && (code == EQ || code == NE)
> + && !(symbolic_operand (op0, VOIDmode)
> + || (GET_CODE (op0) == REG && REG_POINTER (op0
>
> If I didn't use some_operand, the SYMBOL_REF would be lowered and we'll only
> see a REG here. Searching the mail archive I find
>
> https://gcc.gnu.org/ml/gcc-patches/2004-02/msg02436.html
>
> pointing to the test case gcc.dg/20040123-1.c
>
> Perhaps debugging that testcase to see what's reaching a_e_c_b in these modern
> times will tell you what's most appropriate.
Both, patched and unpatched compiler generate:
;; Generating RTL for gimple basic block 2
;; if (&a == 16384B)
(insn 5 4 6 (set (reg/f:DI 70)
(symbol_ref:DI ("a") [flags 0x40] )) 20040123-1.c:10 -1
(nil))
(insn 6 5 7 (set (reg:DI 71)
(const_int 16384 [0x4000])) 20040123-1.c:10 -1
(nil))
(insn 7 6 8 (set (reg:DI 72)
(eq:DI (reg/f:DI 70)
(reg:DI 71))) 20040123-1.c:10 -1
(nil))
(jump_insn 8 7 0 (set (pc)
(if_then_else (eq (reg:DI 72)
(const_int 0 [0]))
(label_ref 0)
(pc))) 20040123-1.c:10 -1
(int_list:REG_BR_PROB 9996 (nil)))
and gcc.dg/20040123-1.c passes for as long as I remember...
Uros.
Re: [PATCH, FT32] initial support
On Thu, May 14, 2015 at 01:44:48AM +, James Bowman wrote:
> > Compile with -da to get dump files, look at the .reload one (which is
> > for LRA if that is enabled), stare long and hard. I recommend coffee.
>
> OK! Looking more at this, the LRA is not actually looping on the link, but on
> an address calculation
[snip]
> And LRA loops on insn 37, repeatedly allocating a register for (reg:SI 97).
Now your job is to figure out why it does that. It prints out for
every innstruction what alternative it chose, and why it thinks
that is a good plan or not. Since nothing works, it puts in some
reload insns; it also shows those. But since in your case the
reloads do not in fact solve anything, it loops.
Since you have a frame pointer, was this a -O0 compile?
[snip, working case:]
> (insn 7 11 8 2 (set (reg:SI 2 $r0)
> (plus:SI (reg/f:SI 0 $fp)
> (reg:SI 43))) /home/james/tmp/x.c:31 2 {addsi3}
> (expr_list:REG_DEAD (reg:SI 43)
> (nil)))
>
> They look very similar. I am currently baffled.
This doesn't need reloading the dest of the set, since it already has
a hard register.
> > > Do you think it would be easier to make the submission as is, then debug
> > > the LRA issues from that point? If so, I have attached the current patch
> > > set.
> >
> > You should add a -mlra option so other people can easily enable it, too;
> > also handy later (when it defaults to on) when LRA blows up (you can
> > workaround with -mno-lra then).
>
> Sounds good to me. Would that be an acceptable way to get the FT32 port
> into the tree?
I don't make those decisions. Having -mlra is of course not enough;
but it can help you. And it's trivial to implement, so why are we
talking about this :-)
There are other things wrong with your port as well, so you'll take some
time to fix those up anyway, and maybe the LRA issue isn't so hard at all.
Having a -mlra option is nice in any case, as long as you haven't converted
over to LRA fully.
> I am very happy to go with the general flow towards LRA,
> but at this point perhaps it may be a little early?
I think LRA should work fine for you, I didn't see anything excitingly
different from other archs in your port (but I didn't look in detail).
Do you have test results?
Segher
Re: [PATCH, alpha]: Remove some_operand and some_ni_operand
On Thu, May 14, 2015 at 1:31 PM, Uros Bizjak wrote:
> On Wed, May 13, 2015 at 8:53 PM, Richard Henderson wrote:
>> On 05/13/2015 11:11 AM, Uros Bizjak wrote:
>>> We can use general_operand instead of some_operand.
>>>
>>> 2015-05-13 Uros Bizjak
>>>
>>> * config/alpha/alpha.md (extendqidi2): Use general_operand
>>> instead of some_operand for operand[1] predicate.
>>> (extendhidi2): Ditto.
>>> (cbranchdi4): Use general_operand instead of some_operand
>>> for operand[1] and operands[2] predicates.
>>> (cstoredi4): Ditto.
>>> * config/alpha/predicates.md (some_operand): Remove unused predicate.
>>> (some_ni_operand): Ditto.
>>>
>>> Tested on alpha-linux-gnu.
>>>
>>> Richard, does this look OK to you, or is there any other reason that
>>> general_operand predicates were not used here?
>>
>> For the extensions, it was put in by Kenner in 1997 (90f6b60d), to improve
>> code
>> for unaligned memories. That code was removed in 2011 by me (8b2983a3), so I
>> think dropping some_operand there is fine.
>>
>> For the conditionals, it was added in 2004 by me (62350d6c), and that code is
>> still there. Specifically,
>>
>> @@ -3177,11 +3177,17 @@ alpha_emit_conditional_branch (enum rtx_code code)
>> cmp_code = NIL, branch_code = code;
>>
>> /* If the constants doesn't fit into an immediate, but can
>> be generated by lda/ldah, we adjust the argument and
>> compare against zero, so we can use beq/bne directly. */
>> - else if (GET_CODE (op1) == CONST_INT && (code == EQ || code == NE))
>> + /* ??? Don't do this when comparing against symbols, otherwise
>> +we'll reduce (&x == 0x1234) to (&x-0x1234 == 0), which will
>> +be declared false out of hand (at least for non-weak). */
>> + else if (GET_CODE (op1) == CONST_INT
>> + && (code == EQ || code == NE)
>> + && !(symbolic_operand (op0, VOIDmode)
>> + || (GET_CODE (op0) == REG && REG_POINTER (op0
>>
>> If I didn't use some_operand, the SYMBOL_REF would be lowered and we'll only
>> see a REG here. Searching the mail archive I find
>>
>> https://gcc.gnu.org/ml/gcc-patches/2004-02/msg02436.html
>>
>> pointing to the test case gcc.dg/20040123-1.c
>>
>> Perhaps debugging that testcase to see what's reaching a_e_c_b in these
>> modern
>> times will tell you what's most appropriate.
>
> Both, patched and unpatched compiler generate:
>
> ;; Generating RTL for gimple basic block 2
>
> ;; if (&a == 16384B)
>
> (insn 5 4 6 (set (reg/f:DI 70)
> (symbol_ref:DI ("a") [flags 0x40] a>)) 20040123-1.c:10 -1
> (nil))
>
> (insn 6 5 7 (set (reg:DI 71)
> (const_int 16384 [0x4000])) 20040123-1.c:10 -1
> (nil))
>
> (insn 7 6 8 (set (reg:DI 72)
> (eq:DI (reg/f:DI 70)
> (reg:DI 71))) 20040123-1.c:10 -1
> (nil))
>
> (jump_insn 8 7 0 (set (pc)
> (if_then_else (eq (reg:DI 72)
> (const_int 0 [0]))
> (label_ref 0)
> (pc))) 20040123-1.c:10 -1
> (int_list:REG_BR_PROB 9996 (nil)))
>
> and gcc.dg/20040123-1.c passes for as long as I remember...
Bah, pushed send too fast.
This is what is received by a_e_c_b in both, patched and unpatched case:
Breakpoint 1, alpha_emit_conditional_branch (operands=0x7fffd6e0,
cmp_mode=DImode) at
/home/uros/gcc-svn/trunk/gcc/config/alpha/alpha.c:2508
2508alpha_emit_conditional_branch (rtx operands[], machine_mode cmp_mode)
(gdb) p debug_rtx (operands[0])
(ne (reg/f:DI 70)
(const_int 16384 [0x4000]))
$1 = void
(gdb) p debug_rtx (operands[1])
(reg/f:DI 70)
$2 = void
(gdb) p debug_rtx (operands[2])
(const_int 16384 [0x4000])
$3 = void
Uros.
Re: [PING][PATCH][PR65443] Add transform_to_exit_first_loop_alt
On 20-04-15 14:25, Richard Biener wrote:
On Wed, 15 Apr 2015, Tom de Vries wrote:
On 03-04-15 14:39, Tom de Vries wrote:
On 27-03-15 15:10, Tom de Vries wrote:
Hi,
this patch fixes PR65443, a todo in the parloops pass for function
transform_to_exit_first_loop:
...
TODO: the common case is that latch of the loop is empty and
immediately
follows the loop exit. In this case, it would be better not to copy
the
body of the loop, but only move the entry of the loop directly before
the
exit check and increase the number of iterations of the loop by one.
This may need some additional preconditioning in case NIT = ~0.
...
The current implementation of transform_to_exit_first_loop transforms the
loop
by moving and duplicating the loop body. This patch transforms the loop
into the
same normal form, but without the duplication, if that's possible
(determined by
try_transform_to_exit_first_loop_alt).
The actual transformation, done by transform_to_exit_first_loop_alt
transforms
this loop:
...
bb preheader:
...
goto
:
...
if (ivtmp < n)
goto ;
else
goto ;
:
ivtmp = ivtmp + inc;
goto
...
into this one:
...
bb preheader:
...
goto
:
...
goto ;
:
if (ivtmp < n + 1)
goto ;
else
goto ;
:
ivtmp = ivtmp + inc;
goto
...
Updated patch, now using redirect_edge_var_map and flush_pending_stmts.
Bootstrapped and reg-tested on x86_64.
OK for stage1 trunk?
Ping.
Hi Richard,
thanks for the review.
+static void
+replace_imm_uses (tree val, imm_use_iterator *imm_iter)
+{
+ use_operand_p use_p;
+
+ FOR_EACH_IMM_USE_ON_STMT (use_p, *imm_iter)
+SET_USE (use_p, val);
Use propagate_value. Why this odd interface passing a imm_iter?!
The replace_imm_uses function is common code factored out of
replace_uses_in_bb_by and replace_uses_in_bbs_by. I'm not sure what is odd about
the interface of the replace_imm_uses function, but I've removed the function.
I tried using propagate_value, but that one doesn't like virtuals.
In fact most of the "repair SSA" in transform_to_exit_first_loop_alt
looks too ad-hoc to me ... it also looks somewhat familiar to other
code ...
Unfortunately the comment before the function isn't in SSA form
so it's hard to follow the transform.
I've added the ssa bits in the transformation comment before the function, and
updated variable names and comments in the function.
I consider the parloops code bitrotten, no repair possible, so
I might be convinced to not care about new spaghetti in there...
+ /* Fix up loop structure. TODO: Check whether this is sufficient. */
+ loop->header = new_header;
+
no, surely not. Number of iterations (and estimates) are off
after the transform
The loop is cancelled at the end of gen_parallel_loop, and the estimations are
removed. We only seem to be using a limited set of the loop data until the loop
is cancelled. Updated comment accordingly.
and loop->latch might also need updating.
That one actually stays the same. Updated comment accordingly.
"Safest" is to simply schedule a fixup (but you'll lose any
loop annotation in that process).
Since the loop is cancelled, AFAIU we don't need that, but... You're referring
to the annotations mentioned in replace_loop_annotate_in_block? Losing the
annotations seems to be a generic problem of scheduling such a fixup, not
particular to this patch. Do you have a concern related to the patch and these
annotations?
+ /* Figure out whether nit + 1 overflows. */
+ if (TREE_CODE (nit) == INTEGER_CST)
+{
+ if (!tree_int_cst_equal (nit, TYPE_MAXVAL (nit_type)))
in case nit_type is a pointer type TYPE_MAXVAL will be NULL I think.
We've done ivcanon just before this point, so AFAIU we can assume we're dealing
with an unsigned integer.
Is the whole exercise for performance?
I'm trying to fix the todo in the code for parloops, which is about performance,
though I don't expect a large gain.
OTOH, my main focus is a related oacc kernels issue. For an oacc kernels region,
the entire loop is enclosed in a kernels region. Peeling of the last iteration
means I have to guard that iteration to run on only one thread, which currently
isn't done, so in that sense it's a correctness issue as well.
In that case using an
entirely new, unsigned IV, that runs from 0 to niter should be easiest and
Introducting such an IV would mean that we don't have to update the IV, but
still we have to connect the new IV to the uses of the old IV.
The current special handling of the IV variable is actually not that elaborate:
...
+ /* Replace ivtmp_a with ivtmp_c in condition 'if (ivtmp_a < n)'. */
+ replace_uses_in_bb_by (res_a, res_c, new_header);
...
So I'm not sure it's easier.
just run-time guard that niter == +INF case?
That doesn't work out nic
[patch] libstdc++/66018 avoid AC_SEARCH_LIBS test
The AC_STRUCT_DIRENT_D_TYPE autoconf macro expands to include AC_SEARCH_LIBS for opendir, which can't be used when cross-compiling. We don't actually care about crufty old systems that put opendir() somewhere weird, so this just replaces AC_STRUCT_DIRENT_D_TYPE with a manual check for the part we care about. Tested powerpc64le-linux, committed to trunk. commit 3f1454f94017afa9bb0f049fefba0d0f5bd229b4 Author: Jonathan Wakely Date: Thu May 14 12:31:17 2015 +0100 PR libstdc++/66018 * acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for struct dirent.d_type. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac (AC_STRUCT_DIRENT_D_TYPE): Remove. diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index 46e303c..b2b48cc 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -3875,6 +3875,22 @@ dnl ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -fno-exceptions" dnl + AC_MSG_CHECKING([for struct dirent.d_type]) + AC_CACHE_VAL(glibcxx_cv_dirent_d_type, [dnl +GCC_TRY_COMPILE_OR_LINK( + [#include ], + [ + struct dirent d; + if (sizeof d.d_type) return 0; + ], + [glibcxx_cv_dirent_d_type=yes], + [glibcxx_cv_dirent_d_type=no]) + ]) + if test $glibcxx_cv_dirent_d_type = yes; then +AC_DEFINE(_GLIBCXX_HAVE_STRUCT_DIRENT_D_TYPE, 1, [Define to 1 if `d_type' is a member of `struct dirent'.]) + fi + AC_MSG_RESULT($glibcxx_cv_dirent_d_type) +dnl AC_MSG_CHECKING([for realpath]) AC_CACHE_VAL(glibcxx_cv_realpath, [dnl GCC_TRY_COMPILE_OR_LINK( diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index 7eac8a1..96ff16f 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -403,7 +403,6 @@ GLIBCXX_CHECK_GTHREADS # For Filesystem TS. AC_CHECK_HEADERS([fcntl.h dirent.h sys/statvfs.h utime.h]) -AC_STRUCT_DIRENT_D_TYPE GLIBCXX_ENABLE_FILESYSTEM_TS GLIBCXX_CHECK_FILESYSTEM_DEPS
Re: [PATCH 1/7] [D] libiberty: Correctly decode white or non-printable characters
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
Hi,
Started these as separate patches, but as more came out of what I was
originally trying to achieve (see Patch 6/7), I thought it better to
have it as a running series.
These set out to update d-demangle.c for new ABI additions, general
bug fixes, and improved template support.
---
D templates can have string literals encoded inside them, which can
also include tabs, newlines, and other whitespace characters. For
example:
return getHost!q{
auto he = gethostbyname(toStringz(param));
}(name);
In this case, rather than decoding and writing out every character
directly, whitespace or other non-printable characters should be
represented as escape sequences.
---
libiberty/ChangeLog:
2015-05-13 Iain Buclaw
* d-demangle.c (dlang_parse_string): Represent embedded whitespace or
non-printable characters as hex or escape sequences.
* testsuite/d-demangle-expected: Add test for templates with tabs and
newlines embedded into the signature.
OK.
jeff
Re: [PATCH, FT32] initial support
On Thu, May 14, 2015 at 01:44:48AM +, James Bowman wrote: > > On Tue, May 12, 2015 at 10:17:01PM +, James Bowman wrote: > > > It seems that with whenever a function's frame is bigger than 512 bytes, > > > LRA loops. I cannot reproduce this with your testcase. Please post the *exact* testcase (nothing snipped) and the command line you used? Segher
Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.
---
libiberty/ChangeLog
2015-05-13 Iain Buclaw
* d-demangle.c (dlang_call_convention): Return NULL if have reached the
end of the symbol, but expected more.
(dlang_attributes): Likewise.
(dlang_function_type): Likewise.
(dlang_type): Likewise.
(dlang_identifier): Likewise.
(dlang_value): Likewise.
I spot checked various callers of these functions that not return NULL
and they looked reasonable. Though I was a bit concerned about the
callers of dlang_type, dlang_value and dlang_identifier.
In those cases we'll often still do the string_append, string_setlength
and other calls in the caller of dlang_{value,type,identifier}. I'm
assuming that's safe (the error still appears to be bubbling up properly).
If you can confirm that we're OK in those cases, then this is OK for the
trunk.
jeff
Re: [PATCH 7/7] [D] libiberty: Add support for cent and ucent types
On 05/13/2015 02:51 AM, Iain Buclaw wrote: The next version of D adds support for cent and ucent for platforms that are able to handle them natively. This adds support for demangling them. --- libiberty/ChangeLog: 2015-05-13 Iain Buclaw * d-demangle.c (dlang_type): Handle cent and ucent types. * testsuite/d-demangle-expected: Add coverage tests for cent and ucent. OK. jeff
Re: [PATCH 3/7] [D] libiberty: Include type modifiers in demangled function symbols
On 05/13/2015 02:51 AM, Iain Buclaw wrote: Like C++ const and volatile, in D mangled symbols can exist modifiers that represent the const, immutable, inout and shared-ness of the 'this' parameter. This information should be written out in the demangled symbol to show that each variant has a unique identity. --- libiberty/ChangeLog: 2015-05-13 Iain Buclaw * d-demangle.c (dlang_type_modifiers): New function. (dlang_type_modifier_p): New function. (dlang_call_convention_p): Ignore any kind of type modifier. (dlang_type): Handle and emit the type modifier after delegate types. (dlang_parse_symbol): Handle and emit the type modifier after the symbol. * testsuite/d-demangle-expected: Add coverage tests for all valid usages of function symbols with type modifiers. OK. jeff
Re: [PATCH 4/7] [D] libiberty: Check symbol length before using strncmp
On 05/13/2015 02:51 AM, Iain Buclaw wrote: This addresses a subtle logic error, noticed when I was in the middle of testing out some other tightening up of parsing checks. --- libiberty/ChangeLog 2015-05-13 Iain Buclaw * d-demangle.c (dlang_identifier): Check encoded length of identifier to verify strncmp matches entire string. * testsuite/d-demangle-expected: Fix wrong test for postblit symbols. That's some pretty obtuse code. Looks like it's easy to get wrong. OK. jeff
Re: [PATCH 5/7] [D] libiberty: Add support for return parameter and attributes
On 05/13/2015 02:51 AM, Iain Buclaw wrote: The next version of D introduces two new mangle conventions. - Nj to represent methods whose 'this' parameter is also the function return value - Nk to represent a 'ref' parameter that is also the function return value This patch introduces support for these two symbols. --- libiberty/ChangeLog: 2015-05-13 Iain Buclaw * d-demangle.c (dlang_attributes): Handle return attributes, ignoring return parameters in the mangled string. Return NULL if have encountered an unknown attribute. (dlang_function_args): Handle return parameters in the mangled string. * testsuite/d-demangle-expected: Add coverage tests for functions with return parameters and return attributes. OK. jeff
Re: [PATCH, FT32] initial support
On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote: > I cannot reproduce this with your testcase. Please post the *exact* > testcase (nothing snipped) and the command line you used? Making the array volatile and using optimisation helped. Kaboom. It wants to reload pretty much everything. Looking at your code, it seems you use the ancient interfaces instead of TARGET_LEGITIMATE_ADDRESS_P, I don't think LRA works with that? Segher
Re: [PATCH 8/7] [D] libiberty: Add support for specialized template parameters
On 05/13/2015 03:14 PM, Iain Buclaw wrote: One last thing that was added in the next D version's ABI (and I subsequently missed). This is a trivial patch to just ignore the new mangle symbol. --- libiberty/ChangeLog: 2015-05-13 Iain Buclaw * d-demangle.c (dlang_template_args): Skip over specialized template parameters in mangled symbol. * testsuite/d-demangle-expected: Add coverage and unittest for specialized template parameters. OK. jeff
RE: [PATCH][AArch64] Use conditional negate for abs expansion
> James Greenhalgh wrote:
> On Mon, Apr 27, 2015 at 05:57:26PM +0100, Wilco Dijkstra wrote:
> > > James Greenhalgh wrote:
> > > On Mon, Apr 27, 2015 at 02:42:36PM +0100, Wilco Dijkstra wrote:
> > > > > -Original Message-
> > > > > From: Wilco Dijkstra [mailto:wdijk...@arm.com]
> > > > > Sent: 03 March 2015 16:19
> > > > > To: GCC Patches
> > > > > Subject: [PATCH][AArch64] Use conditional negate for abs expansion
> > > > >
> > > > > Expand abs into a compare and conditional negate. This is the most
> > > > > obvious expansion,
> > > enables
> > > > > merging of the comparison into ALU instructions and is faster on all
> > > > > implementations.
> > > > > Bootstrapped & regression tested.
> > > > >
> > > > > int f(int x) { return abs (x + 1); }
> > > > >
> > > > > Before:
> > > > > add w0, w0, 1
> > > > > sxtwx0, w0
> > > > > eor x1, x0, x0, asr 63
> > > > > sub x1, x1, x0, asr 63
> > > > > mov x0, x1
> > > > > ret
> > > > >
> > > > > After:
> > > > > addsw0, w0, 1
> > > > > csneg w0, w0, w0, pl
> > > > > ret
> > > > >
> > > > > ChangeLog:
> > > > >
> > > > > 2015-03-03 Wilco Dijkstra
> > > > >
> > > > > * gcc/config/aarch64/aarch64.md (absdi2): optimize abs
> > > > > expansion.
> > > > > (csneg3_insn): enable expansion of pattern.
> > > > > * gcc/testsuite/gcc.target/aarch64/abs_1.c (abs64): update test
> > > > > for new abs expansion. (abs64_in_dreg): likewise.
> > >
> > >
> > > This looks like it breaks support for abs in a D register (for example
> > > at the end of a loop, or extracted from Neon Intrinsics, etc).
> > >
> > > e.g. (totally contrived...)
> > >
> > > int64x1_t
> > > abs_max (int64x2_t x, int64_t *wb)
> > > {
> > > int64_t y = vgetq_lane_s64 (x, 0);
> > > if (y < 0)
> > > y = -y;
> > > return vdup_n_s64 (y);
> > > }
> > >
> > > Which currently generates:
> > >
> > > abs_max:
> > > abs d0, d0
> > > ret
> > >
> > > I suppose we don't need to worry too much about that (and the current
> > > implementation doesn't seem to catch it reliably anyway), but it would be
> > > good if we could keep the support - even if it is rarely used.
> >
> > Well it may be possible to write a peephole for this rare case, but I hope
> > people would use a vabs if that's what they wanted...
>
> OK, I've seen some of the pain of our current abs expansion code, so I
> suppose that we want to get the common case right first, rather
> than be too concerned about contrived corner cases.
>
> This patch is OK.
Jiong, could you check this in please?
Wilco
---
gcc/config/aarch64/aarch64.md| 33 +++-
gcc/testsuite/gcc.target/aarch64/abs_1.c | 5 ++---
2 files changed, 9 insertions(+), 29 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 1f4169e..46b7a63 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -2172,35 +2172,16 @@
[(set_attr "type" "alu_ext")]
)
-(define_insn_and_split "absdi2"
- [(set (match_operand:DI 0 "register_operand" "=&r,w")
- (abs:DI (match_operand:DI 1 "register_operand" "r,w")))]
+(define_expand "abs2"
+ [(match_operand:GPI 0 "register_operand" "")
+ (match_operand:GPI 1 "register_operand" "")]
""
- "@
- #
- abs\\t%d0, %d1"
- "reload_completed
- && GP_REGNUM_P (REGNO (operands[0]))
- && GP_REGNUM_P (REGNO (operands[1]))"
- [(const_int 0)]
{
-emit_insn (gen_rtx_SET (VOIDmode, operands[0],
- gen_rtx_XOR (DImode,
-gen_rtx_ASHIFTRT (DImode,
- operands[1],
- GEN_INT (63)),
-operands[1])));
-emit_insn (gen_rtx_SET (VOIDmode,
- operands[0],
- gen_rtx_MINUS (DImode,
- operands[0],
- gen_rtx_ASHIFTRT (DImode,
-operands[1],
-GEN_INT (63);
+rtx ccreg = aarch64_gen_compare_reg (LT, operands[1], const0_rtx);
+rtx x = gen_rtx_LT (VOIDmode, ccreg, const0_rtx);
+emit_insn (gen_csneg3_insn (operands[0], x, operands[1],
operands[1]));
DONE;
}
- [(set_attr "type" "alu_sreg")
- (set_attr "simd" "no,yes")]
)
(define_insn "neg2"
@@ -2879,7 +2860,7 @@
[(set_attr "type" "csel")]
)
-(define_insn "*csneg3_insn"
+(define_insn "csneg3_insn"
[(set (match_operand:GPI 0 "register_operand" "=r")
(if_then_else:GPI
(match_operand 1 "aarch64_comparison_operation" "")
diff --git a/gcc/testsuite/gcc.target/aarch64/abs_1.c
b/gcc/testsuite/gcc.target/aarch64/abs_1.c
inde
Re: [PATCH 6/7] [D] libiberty: Improve support for demangling D2 templates
On 05/13/2015 02:51 AM, Iain Buclaw wrote: In my tests, this gives the demangler near-complete support. Of a sample of about 75k symbols pulled from the standard library unittester, all but 20 were successfully parsed. --- libiberty/ChangeLog: 2015-05-13 Iain Buclaw * d-demangle.c (dlang_symbol_kinds): New enum. (dlang_parse_symbol): Update signature. Handle an ambiguity between mangle symbol for pascal and template value arguments. Only check for a type if parsing a function, or at the top level. Return failure if the entire symbol was not successfully demangled. (dlang_identifier): Update signature. Handle an ambiguity between two adjacent digits in a mangled symbol string. (dlang_type): Update call to dlang_parse_symbol. (dlang_template_args): Likewise. (dlang_parse_template): Likewise. (dlang_demangle): Likewise. * testsuite/d-demangle-expected: Fix bad tests found, and add problematic examples to the unittests. OK. I'm going to trust the code to dis-ambiguate the adjacent digits in dlang_identifier is correct. The rest of the changes were pretty easy to follow :-0 Jeff
[patch] libstdc++/66011 Fix various filesystem operations
The PR is due to missing the third argument to open(3) but there are
some other errors in the same function as well as some unimplemented
features, and some bad error handling elsewhere.
The autoconf check for sendfile is intentionally conservative because
some BSDs define a sendfile() function with different semantics (it
can only copy a file to a socket, not another regular file).
Tested powerpc64le-linux, committed to trunk.
commit 65987fba7d5bd477458b586bea557c572a39bf63
Author: Jonathan Wakely
Date: Thu May 14 12:54:24 2015 +0100
PR libstdc++/66011
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for fchmod and
sendfile.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/filesystem/ops.cc (do_copy_file): Fix arguments to open(). Do
not return after copying contents. Use fchmod, fchmodat, and sendfile
when available.
(current_path, permissions, space): Use errno not return value.
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index b2b48cc..8340572 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3939,6 +3939,19 @@ dnl
fi
AC_MSG_RESULT($glibcxx_cv_st_mtim)
dnl
+ AC_MSG_CHECKING([for fchmod])
+ AC_CACHE_VAL(glibcxx_cv_fchmod, [dnl
+GCC_TRY_COMPILE_OR_LINK(
+ [#include ],
+ [fchmod(1, S_IWUSR);],
+ [glibcxx_cv_fchmod=yes],
+ [glibcxx_cv_fchmod=no])
+ ])
+ if test $glibcxx_cv_fchmod = yes; then
+AC_DEFINE(_GLIBCXX_USE_FCHMOD, 1, [Define if fchmod is available in .])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_fchmod)
+dnl
AC_MSG_CHECKING([for fchmodat])
AC_CACHE_VAL(glibcxx_cv_fchmodat, [dnl
GCC_TRY_COMPILE_OR_LINK(
@@ -3955,6 +3968,26 @@ dnl
fi
AC_MSG_RESULT($glibcxx_cv_fchmodat)
dnl
+ AC_MSG_CHECKING([for sendfile that can copy files])
+ AC_CACHE_VAL(glibcxx_cv_sendfile, [dnl
+case "${target_os}" in
+ gnu* | linux* | solaris*)
+GCC_TRY_COMPILE_OR_LINK(
+ [#include ],
+ [sendfile(1, 2, (off_t*)NULL, sizeof 1);],
+ [glibcxx_cv_sendfile=yes],
+ [glibcxx_cv_sendfile=no])
+;;
+ *)
+glibcxx_cv_sendfile=no
+;;
+esac
+ ])
+ if test $glibcxx_cv_sendfile = yes; then
+AC_DEFINE(_GLIBCXX_USE_SENDFILE, 1, [Define if sendfile is available in .])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_sendfile)
+dnl
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
])
diff --git a/libstdc++-v3/src/filesystem/ops.cc b/libstdc++-v3/src/filesystem/ops.cc
index aa1ab04..f24cc19 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -41,7 +41,7 @@
#ifdef _GLIBCXX_HAVE_SYS_STATVFS_H
# include
#endif
-#ifdef _GLIBCXX_HAVE_GNU_SENDFILE
+#ifdef _GLIBCXX_USE_SENDFILE
# include
#else
# include
@@ -241,6 +241,8 @@ namespace
}
f = make_file_status(*from_st);
+using opts = fs::copy_options;
+
if (exists(t))
{
if (!is_other(t) && !is_other(f)
@@ -251,12 +253,12 @@ namespace
return false;
}
- if (is_set(option, fs::copy_options::skip_existing))
+ if (is_set(option, opts::skip_existing))
{
ec.clear();
return false;
}
- else if (is_set(option, fs::copy_options::update_existing))
+ else if (is_set(option, opts::update_existing))
{
if (file_time(*from_st) <= file_time(*to_st))
{
@@ -264,7 +266,7 @@ namespace
return false;
}
}
- else if (!is_set(option, fs::copy_options::overwrite_existing))
+ else if (!is_set(option, opts::overwrite_existing))
{
ec = std::make_error_code(std::errc::file_exists);
return false;
@@ -282,14 +284,22 @@ namespace
ec.assign(errno, std::generic_category());
return false;
}
-CloseFD out = { ::open(to.c_str(), O_WRONLY|O_CREAT) };
+int oflag = O_WRONLY|O_CREAT;
+if (is_set(option, opts::overwrite_existing|opts::update_existing))
+ oflag |= O_TRUNC;
+else
+ oflag |= O_EXCL;
+CloseFD out = { ::open(to.c_str(), oflag, S_IWUSR) };
if (out.fd == -1)
{
- ec.assign(errno, std::generic_category());
+ if (errno == EEXIST && is_set(option, opts::skip_existing))
+ ec.clear();
+ else
+ ec.assign(errno, std::generic_category());
return false;
}
-#ifdef _GLIBCXX_HAVE_GNU_SENDFILE
+#ifdef _GLIBCXX_USE_SENDFILE
auto n = ::sendfile(out.fd, in.fd, nullptr, from_st->st_size);
if (n != from_st->st_size)
{
@@ -299,20 +309,17 @@ namespace
#else
__gnu_cxx::stdio_filebuf sbin(in.fd, std::ios::in);
__gnu_cxx::stdio_filebuf sbout(out.fd, std::ios::out);
-if (std::ostream(&sbout) << &sbin)
- {
- ec.clear();
- return true;
- }
-else
+if ( !(std::ostream(&sbout) << &sbin) )
{
ec = std::make_error_code(std::errc::io_error);
return false;
}
#endif
-#ifdef _GLIBCXX_HAVE_FCHMOD
+#ifdef _GLIBCXX_USE_FCHMOD
if (::fchmod(out.fd, from_st->st_mode))
+#elif _GLIBCXX_USE_FCHMODAT
+if (::fchmodat(AT_FDCWD, to.c_str(), from
Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
On 14 May 2015 at 14:58, Jeff Law wrote:
> On 05/13/2015 02:51 AM, Iain Buclaw wrote:
>>
>> If a symbol that has so far been valid abruptly ends then we will want
>> to fail the process rather than silently succeed.
>>
>> ---
>> libiberty/ChangeLog
>>
>> 2015-05-13 Iain Buclaw
>>
>> * d-demangle.c (dlang_call_convention): Return NULL if have reached
>> the
>> end of the symbol, but expected more.
>> (dlang_attributes): Likewise.
>> (dlang_function_type): Likewise.
>> (dlang_type): Likewise.
>> (dlang_identifier): Likewise.
>> (dlang_value): Likewise.
>
> I spot checked various callers of these functions that not return NULL and
> they looked reasonable. Though I was a bit concerned about the callers of
> dlang_type, dlang_value and dlang_identifier.
>
> In those cases we'll often still do the string_append, string_setlength and
> other calls in the caller of dlang_{value,type,identifier}. I'm assuming
> that's safe (the error still appears to be bubbling up properly).
>
The string routines should be safe for that (appending a string with a
zero length does nothing, for instance).
> If you can confirm that we're OK in those cases, then this is OK for the
> trunk.
>
I can start fuzzing mangle strings to test that failures actually fail
gracefully. There's already a fuzzer that exists for C++, I think the
only change that would be required for D is exchanging "_Z" for "_D"
and calling cplus_demangle with DMGL_DLANG.
Regards
Iain
Re: [PATCH] [gcc, combine] Backport to GCC 5.0 branch "PR46164: Don't combine the insns if a volatile register is contained".
On Thu, May 14, 2015 at 01:56:54PM +0800, Hale Wang wrote: > > >> gcc/ChangeLog: > > >> 2015-04-22 Hale Wang > > >> Terry Guo > > >> > > >>PR rtl-optimization/64818 > > >>* combine.c (can_combine_p): Don't combine user-specified register > > if > > >>it is in an asm input. > > >> > > >> gcc/testsuite/ChangeLog: > > >> 2015-04-22 Hale Wang > > >> Terry Guo > > >> > > >>PR rtl-optimization/64818 > > >>* gcc.target/arm/pr64818.c: New. > This patch applies cleanly on GCC 5.0 branch. Bootstrap and regression test > are OK for X86_64. > > Can we backport this patch to GCC 5.0 branch? It should be perfectly safe, and it's a pretty nasty bug. But it is technically not a regression (or is it?), so I'll defer to the release managers. Segher
[patch] libstdc++/66055 add missing constructors to unordered containers
Reported by Nathan and fixed by his patch. I added the tests.
Tested powerpc64le-linux, committed to trunk. This should be
backported too.
commit f859cb0e4a369bdade09d5d77f9c8bb78d388294
Author: Jonathan Wakely
Date: Thu May 14 14:36:20 2015 +0100
2015-05-14 Nathan Myers
Jonathan Wakely
PR libstdc++/66055
* include/std/unordered_map (unordered_map, unordered_multimap): Add
missing constructors.
* include/std/unordered_set (unordered_set, unordered_multiset):
Likewise.
* testsuite/23_containers/unordered_map/cons/66055.cc: New.
* testsuite/23_containers/unordered_multimap/cons/66055.cc: New.
* testsuite/23_containers/unordered_multiset/cons/66055.cc: New.
* testsuite/23_containers/unordered_set/cons/66055.cc: New.
diff --git a/libstdc++-v3/include/bits/unordered_map.h b/libstdc++-v3/include/bits/unordered_map.h
index 92b75d1..069b859 100644
--- a/libstdc++-v3/include/bits/unordered_map.h
+++ b/libstdc++-v3/include/bits/unordered_map.h
@@ -146,6 +146,17 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
: _M_h(__n, __hf, __eql, __a)
{ }
+ unordered_map(size_type __n, const allocator_type& __a)
+ : _M_h(__n, hasher(), key_equal(), __a)
+ { }
+
+ explicit
+ unordered_map(size_type __n,
+ const hasher& __hf,
+ const allocator_type& __a)
+ : _M_h(__n, __hf, key_equal(), __a)
+ { }
+
/**
* @brief Builds an %unordered_map from a range.
* @param __first An input iterator.
@@ -861,6 +872,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
: _M_h(__n, __hf, __eql, __a)
{ }
+ unordered_multimap(size_type __n, const allocator_type& __a)
+ : _M_h(__n, hasher(), key_equal(), __a)
+ { }
+
+ unordered_multimap(size_type __n,
+ const hasher& __hf,
+ const allocator_type& __a)
+ : _M_h(__n, __hf, key_equal(), __a)
+ { }
+
/**
* @brief Builds an %unordered_multimap from a range.
* @param __first An input iterator.
diff --git a/libstdc++-v3/include/bits/unordered_set.h b/libstdc++-v3/include/bits/unordered_set.h
index 7a2546c..c91eab8 100644
--- a/libstdc++-v3/include/bits/unordered_set.h
+++ b/libstdc++-v3/include/bits/unordered_set.h
@@ -140,6 +140,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
: _M_h(__n, __hf, __eql, __a)
{ }
+ unordered_set(size_type __n, const allocator_type& __a)
+ : _M_h(__n, hasher(), key_equal(), __a)
+ { }
+
+ unordered_set(size_type __n,
+const hasher& __hf,
+const allocator_type& __a)
+ : unordered_set(__n, __hf, key_equal(), __a)
+ { }
+
/**
* @brief Builds an %unordered_set from a range.
* @param __first An input iterator.
@@ -779,6 +789,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
: _M_h(__n, __hf, __eql, __a)
{ }
+ unordered_multiset(size_type __n, const allocator_type& __a)
+ : _M_h(__n, hasher(), key_equal(), __a)
+ { }
+
+ unordered_multiset(size_type __n,
+ const hasher& __hf,
+ const allocator_type& __a)
+ : _M_h(__n, __hf, key_equal(), __a)
+ { }
+
/**
* @brief Builds an %unordered_multiset from a range.
* @param __first An input iterator.
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_map/cons/66055.cc b/libstdc++-v3/testsuite/23_containers/unordered_map/cons/66055.cc
new file mode 100644
index 000..0d3e384
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/unordered_map/cons/66055.cc
@@ -0,0 +1,30 @@
+// 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
+//
Re: [PATCH] rs6000: Improve rtx_costs for EQ a bit (PR30967)
On Wed, May 13, 2015 at 1:29 PM, Segher Boessenkool wrote: > On Wed, May 13, 2015 at 01:25:16PM -0400, David Edelsohn wrote: >> > PR rtl-optimization/30967 >> > * config/rs6000/rs6000.c (rs6000_rtx_costs): Don't consider >> > destination mode for the cost of scc patterns. >> >> Okay. >> >> Should this be applied to GCC 5 branch? > > [ Testing is still in progress. ] > > It should be prefectly safe to backport; OTOH, it is just one of very > many cases where we generate an extra sign-extend, so I don't think it > is particularly useful. Your choice :-) The other prereqs are backported, so probably should backport this also. Fixing this is a process, not an event. - David
Re: [PATCH 6/7] [D] libiberty: Improve support for demangling D2 templates
On 14 May 2015 at 15:24, Jeff Law wrote: > On 05/13/2015 02:51 AM, Iain Buclaw wrote: >> >> In my tests, this gives the demangler near-complete support. Of a >> sample of about 75k symbols pulled from the standard library >> unittester, all but 20 were successfully parsed. >> >> --- >> libiberty/ChangeLog: >> >> 2015-05-13 Iain Buclaw >> >> * d-demangle.c (dlang_symbol_kinds): New enum. >> (dlang_parse_symbol): Update signature. Handle an ambiguity between >> mangle >> symbol for pascal and template value arguments. Only check for a >> type >> if parsing a function, or at the top level. Return failure if the >> entire symbol was not successfully demangled. >> (dlang_identifier): Update signature. Handle an ambiguity between >> two >> adjacent digits in a mangled symbol string. >> (dlang_type): Update call to dlang_parse_symbol. >> (dlang_template_args): Likewise. >> (dlang_parse_template): Likewise. >> (dlang_demangle): Likewise. >> * testsuite/d-demangle-expected: Fix bad tests found, and add >> problematic >> examples to the unittests. > > OK. > > I'm going to trust the code to dis-ambiguate the adjacent digits in > dlang_identifier is correct. The rest of the changes were pretty easy to > follow :-0 > This was the hardest one to get right! ;-) In the briefest of possible explanations, for the following symbol: S213std11parallelism3run We go through the following loop: (ptr = std11parallelism3run, len = 213) => Pointer doesn't start with a digit or _D, move back by 1. (ptr = 3std11parallelism3run, len = 21) => Parse returns std.parallelism.run, length matches, return success! In a fail example, for instance if we instead had 214: (ptr = std11parallelism3run, len = 214) => Pointer doesn't start with a digit or _D, move back by 1. (ptr = 4std11parallelism3run, len = 21) => Parse returns std1.p, length doesn't match, move pointer back by 1. (ptr = 14std11parallelism3run, len = 2) => Parse returns std11paralleli, length doesn't match, move pointer back by 1. (ptr = 214std11parallelism3run, len = 214) => Reached the beginning, reset length and parse the entire symbol. Length is too big, return NULL. Granted, there could be some very small room for false positives, but if we find an match that succeeds incorrectly, there is very little change that the rest of the symbol will be demangled correctly. Regards Iain.
Re: [RFA] More type narrowing in match.pd V2
On Fri, 1 May 2015, Jeff Law wrote:
Slight refactoring of the condition by using types_match as suggested by
Richi. I also applied the new types_match to 2 other patterns in match.pd
where it seemed clearly appropriate.
I would like to propose this small tweak (regtested ok). If we had a
different type for trees and types, this would be overloading the
function. We already do this in a few places, and I find the resulting
shorter code more readable.
2015-05-14 Marc Glisse
* generic-match-head.c (types_match): Handle non-types.
* gimple-match-head.c (types_match): Likewise.
* match.pd: Remove unnecessary TREE_TYPE for types_match.
--
Marc GlisseIndex: gcc/generic-match-head.c
===
--- gcc/generic-match-head.c(revision 223194)
+++ gcc/generic-match-head.c(working copy)
@@ -76,6 +76,11 @@
static inline bool
types_match (tree t1, tree t2)
{
+ if (!TYPE_P (t1))
+t1 = TREE_TYPE (t1);
+ if (!TYPE_P (t2))
+t2 = TREE_TYPE (t2);
+
return TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2);
}
Index: gcc/gimple-match-head.c
===
--- gcc/gimple-match-head.c (revision 223194)
+++ gcc/gimple-match-head.c (working copy)
@@ -867,6 +867,11 @@
static inline bool
types_match (tree t1, tree t2)
{
+ if (!TYPE_P (t1))
+t1 = TREE_TYPE (t1);
+ if (!TYPE_P (t2))
+t2 = TREE_TYPE (t2);
+
return types_compatible_p (t1, t2);
}
Index: gcc/match.pd
===
--- gcc/match.pd(revision 223194)
+++ gcc/match.pd(working copy)
@@ -289,7 +289,7 @@
(if (((TREE_CODE (@1) == INTEGER_CST
&& INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& int_fits_type_p (@1, TREE_TYPE (@0)))
- || types_match (TREE_TYPE (@0), TREE_TYPE (@1)))
+ || types_match (@0, @1))
/* ??? This transform conflicts with fold-const.c doing
Convert (T)(x & c) into (T)x & (T)c, if c is an integer
constants (if x has signed type, the sign bit cannot be set
@@ -948,7 +948,7 @@
/* Unordered tests if either argument is a NaN. */
(simplify
(bit_ior (unordered @0 @0) (unordered @1 @1))
- (if (types_match (TREE_TYPE (@0), TREE_TYPE (@1)))
+ (if (types_match (@0, @1))
(unordered @0 @1)))
(simplify
(bit_ior:c (unordered @0 @0) (unordered:c@2 @0 @1))
@@ -1068,8 +1068,8 @@
&& TYPE_PRECISION (type) == GET_MODE_PRECISION (TYPE_MODE (type))
/* The inner conversion must be a widening conversion. */
&& TYPE_PRECISION (TREE_TYPE (@2)) > TYPE_PRECISION (TREE_TYPE (@0))
-&& types_match (TREE_TYPE (@0), TREE_TYPE (@1))
-&& types_match (TREE_TYPE (@0), type)
+&& types_match (@0, @1)
+&& types_match (@0, type)
&& single_use (@4))
(if (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
(convert (op @0 @1)))
@@ -1099,7 +1099,7 @@
&& TYPE_PRECISION (type) == GET_MODE_PRECISION (TYPE_MODE (type))
/* The inner conversion must be a widening conversion. */
&& TYPE_PRECISION (TREE_TYPE (@2)) > TYPE_PRECISION (TREE_TYPE (@0))
-&& types_match (TREE_TYPE (@0), TREE_TYPE (@1))
+&& types_match (@0, @1)
&& (tree_int_cst_min_precision (@4, UNSIGNED)
<= TYPE_PRECISION (TREE_TYPE (@0)))
&& single_use (@5))
Re: Fix RTL checking failure in emit_pattern_{after|before}_setloc
On 05/11/2015 04:10 PM, Eric Botcazou wrote:
This fixes an RTL checking failure I ran into while working on a change and it
is latent in the pristine compiler. emit_pattern_{after|before}_setloc have:
if (active_insn_p (after) && !INSN_LOCATION (after))
if (active_insn_p (first) && !INSN_LOCATION (first))
Now active_insn_p still has the FIXME:
int
active_insn_p (const_rtx insn)
{
return (CALL_P (insn) || JUMP_P (insn)
|| JUMP_TABLE_DATA_P (insn) /* FIXME */
|| (NONJUMP_INSN_P (insn)
&& (! reload_completed
|| (GET_CODE (PATTERN (insn)) != USE
&& GET_CODE (PATTERN (insn)) != CLOBBER;
}
so if AFTER or FIRST are JUMP_TABLE_DATA_P, INSN_LOCATION is invoked on them
and this triggers the RTL checking failure.
Fixed thusly, tested on x86_64-suse-linux, applied on the mainline.
2015-05-11 Eric Botcazou
* emit-rtl.c (emit_pattern_after_setloc): Add missing guard.
(emit_pattern_before_setloc): Likewise.
OK.
You might consider a comment in active_insn_p and
emit_pattern_{after,before}_setloc so that if someone fixes
active_insn_p, they'll know to fix emit_pattern_{after,before}_setloc.
"FIXME" doesn't capture this interaction at all ;-)
jeff
Re: [RFA] More type narrowing in match.pd V2
On 05/14/2015 08:04 AM, Marc Glisse wrote: On Fri, 1 May 2015, Jeff Law wrote: Slight refactoring of the condition by using types_match as suggested by Richi. I also applied the new types_match to 2 other patterns in match.pd where it seemed clearly appropriate. I would like to propose this small tweak (regtested ok). If we had a different type for trees and types, this would be overloading the function. We already do this in a few places, and I find the resulting shorter code more readable. 2015-05-14 Marc Glisse * generic-match-head.c (types_match): Handle non-types. * gimple-match-head.c (types_match): Likewise. * match.pd: Remove unnecessary TREE_TYPE for types_match. Update the comment for types_match and this is fine. jeff
[PATCH, MIPS]: Fix internal compiler error: in check_bool_attrs, at recog.c:2218 for micromips attribute
Hi,
This patch fixes an internal compiler error when micromips/nomicromips
attributes are used.
The problem here was that the cached boolean attributes for the current
target did not agree with the uncached attributes throwing an assertion error.
It appears that saving and restoring the state for micromips was missing,
just like there is for mips16. OK to apply?
Regards,
Robert
gcc/
* config/mips/mips.c (micromips_globals): New variable.
(mips_set_compression_mode): Save and reinitialize target-dependent
state for microMIPS.
gcc/testsuite
* gcc.target/mips/umips-attr.c: New test.
---
gcc/config/mips/mips.c | 10 ++
gcc/testsuite/gcc.target/mips/umips-attr.c | 13 +
2 files changed, 23 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/mips/umips-attr.c
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index bf69850..959a672 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -676,6 +676,9 @@ const char *mips_hi_relocs[NUM_SYMBOL_TYPES];
/* Target state for MIPS16. */
struct target_globals *mips16_globals;
+/* Target state for MICROMIPS. */
+struct target_globals *micromips_globals;
+
/* Cached value of can_issue_more. This is cached in mips_variable_issue hook
and returned from mips_sched_reorder2. */
static int cached_can_issue_more;
@@ -17182,6 +17185,13 @@ mips_set_compression_mode (unsigned int
compression_mode)
else
restore_target_globals (mips16_globals);
}
+ else if (compression_mode & MASK_MICROMIPS)
+{
+ if (!micromips_globals)
+ micromips_globals = save_target_globals_default_opts ();
+ else
+ restore_target_globals (micromips_globals);
+}
else
restore_target_globals (&default_target_globals);
diff --git a/gcc/testsuite/gcc.target/mips/umips-attr.c
b/gcc/testsuite/gcc.target/mips/umips-attr.c
new file mode 100644
index 000..f8c4517
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/umips-attr.c
@@ -0,0 +1,13 @@
+/* { dg-options "(-mmicromips)" } */
+
+int MICROMIPS
+foo (int a)
+{
+ return a;
+}
+
+int NOMICROMIPS
+foo2 (int a)
+{
+ return a;
+}
--
2.2.2
Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
On 05/14/2015 07:36 AM, Iain Buclaw wrote:
On 14 May 2015 at 14:58, Jeff Law wrote:
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.
---
libiberty/ChangeLog
2015-05-13 Iain Buclaw
* d-demangle.c (dlang_call_convention): Return NULL if have reached
the
end of the symbol, but expected more.
(dlang_attributes): Likewise.
(dlang_function_type): Likewise.
(dlang_type): Likewise.
(dlang_identifier): Likewise.
(dlang_value): Likewise.
I spot checked various callers of these functions that not return NULL and
they looked reasonable. Though I was a bit concerned about the callers of
dlang_type, dlang_value and dlang_identifier.
In those cases we'll often still do the string_append, string_setlength and
other calls in the caller of dlang_{value,type,identifier}. I'm assuming
that's safe (the error still appears to be bubbling up properly).
The string routines should be safe for that (appending a string with a
zero length does nothing, for instance).
If you can confirm that we're OK in those cases, then this is OK for the
trunk.
I can start fuzzing mangle strings to test that failures actually fail
gracefully. There's already a fuzzer that exists for C++, I think the
only change that would be required for D is exchanging "_Z" for "_D"
and calling cplus_demangle with DMGL_DLANG.
Your call whether to fuzz before or after committing the changes.
jeff
Re: [patch] Update SJLJ buffer after dynamic stack allocation
On 05/13/2015 04:45 AM, Eric Botcazou wrote: Hi, the SJLJ EH schemes manipulate a buffer that contains a few pointers and, in particular, the stack pointer. Therefore, when dynamic stack allocation is also used, you need to update its value in the buffer, otherwise Bad Things will happen if you resume execution where the stack is shifted. GNAT uses a manual SJLJ EH scheme that is piggybacked on the __builtin_setjmp __builtin_longjmp machinery and has this block in gcc-interface/decl.c: /* If we are defining an object with variable size or an object with fixed size that will be dynamically allocated, and we are using the setjmp/longjmp exception mechanism, update the setjmp buffer. */ if (definition && Exception_Mechanism == Setjmp_Longjmp && get_block_jmpbuf_decl () && DECL_SIZE_UNIT (gnu_decl) && (TREE_CODE (DECL_SIZE_UNIT (gnu_decl)) != INTEGER_CST || (flag_stack_check == GENERIC_STACK_CHECK && compare_tree_int (DECL_SIZE_UNIT (gnu_decl), STACK_CHECK_MAX_VAR_SIZE) > 0))) add_stmt_with_node (build_call_n_expr (update_setjmp_buf_decl, 1, build_unary_op (ADDR_EXPR, NULL_TREE, get_block_jmpbuf_decl ())), gnat_entity); It is necessary if you want to pass the ACATS testsuite. But the regular SJLJ scheme (--enable-sjlj-exceptions) doesn't do this update and, therefore, doesn't play nice with dynamic stack allocation. It's a long- standing issue and you can find messages about it in the archives. On the other hand, this update has always been done for non-local gotos (they also use a buffer, the non-local goto save area). The attached patch implements this update for the regular SJLJ scheme and yields a clean ACATS testsuite. Tested on x86_64-suse-linux with --enable- sjlj-exceptions, OK for the mainline? 2015-05-13 Eric Botcazou Tristan Gingold * insn-notes.def (UPDATE_SJLJ_CONTEXT): New note. * builtins.c (expand_builtin_update_setjmp_buf): Make global. (expand_stack_restore): Call record_new_stack_level. (expand_stack_save): Do not call do_pending_stack_adjust. * builtins.h (expand_builtin_update_setjmp_buf): Declare. * calls.c (expand_call): Call record_new_stack_level for alloca. * except.c (sjlj_mark_call_sites): Expand builtin_update_setjmp_buf wherever a NOTE_INSN_UPDATE_SJLJ_CONTEXT note is present. (update_sjlj_context): New global function. * except.h (update_sjlj_context): Declare. * explow.c (record_new_stack_level): New global function. (allocate_dynamic_stack_space): Call record_new_stack_level. * explow.h (record_new_stack_level): Declare. * final.c (final_scan_insn): Deal with NOTE_INSN_UPDATE_SJLJ_CONTEXT. * cfgrtl.c (duplicate_insn_chain): Likewise. OK. Thanks for tackling this. jeff
Re: [PATCH][PR66010] Don't take address of ap unless necessary
On 12-05-15 12:04, Richard Biener wrote:
The fact that we have to handle this specially in both build_va_arg and
>gimplify_va_arg makes me wonder whether we should be dealing with all this in
>build_va_arg already.
>
>That is, determine whether we take the address, and add the address operator
>if so in build_va_arg already. Likewise, determine do_deref and pass that as
>extra operand.
That would certainly be a nice cleanup.
I've implemented this cleanup.
Furthermore, I realized that in expand_ifn_va_arg_1, 'do_deref == 0' disables
code:
...
if (do_deref == integer_one_node)
ap = build_fold_indirect_ref (ap);
...
that has a copy in the target hook:
...
gpr = build3 (COMPONENT_REF, TREE_TYPE (f_gpr),
build_va_arg_indirect_ref (valist), f_gpr, NULL_TREE);
valist = build_va_arg_indirect_ref (valist);
...
It's easier to remove that code from the few target hooks that do that, execute
the 'do_deref == 1' code unconditionally in expand_ifn_va_arg_1 and simply
remove all do_deref propagation (that also means we don't have to add an operand
to VA_ARG_EXPR).
Bootstrapped and reg-tested on x86_64, with and without -m32.
Did partial build and compiled a few va_arg test-cases on the other targets.
OK for trunk?
Thanks,
- Tom
Move array-type va_list handling to build_va_arg
2015-05-13 Tom de Vries
* gimplify.c (gimplify_modify_expr): Remove do_deref handling.
(gimplify_va_arg_expr): Remove do_deref handling. Remove adding of
address operator to va_list operand.
* tree-stdarg.c (expand_ifn_va_arg_1): Do deref of va_list operand
unconditionally.
* config/i386/i386.c (ix86_gimplify_va_arg): Remove deref on va_list
operand.
* config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Same.
* config/s390/s390.c (s390_gimplify_va_arg): Same.
* config/spu/spu.c (spu_gimplify_va_arg_expr): Same.
* c-common.c (build_va_arg_1): New function.
(build_va_arg): Add address operator to va_list operand if necessary.
---
gcc/c-family/c-common.c| 127 +++--
gcc/config/i386/i386.c | 6 +--
gcc/config/rs6000/rs6000.c | 1 -
gcc/config/s390/s390.c | 1 -
gcc/config/spu/spu.c | 1 -
gcc/gimplify.c | 37 ++---
gcc/tree-stdarg.c | 14 ++---
7 files changed, 125 insertions(+), 62 deletions(-)
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 7e5ac72..8f9657d 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5915,6 +5915,20 @@ set_compound_literal_name (tree decl)
DECL_NAME (decl) = get_identifier (name);
}
+/* build_va_arg helper function. Return a VA_ARG_EXPR with location LOC, type
+ TYPE and operand OP. */
+
+static tree
+build_va_arg_1 (location_t loc, tree type, tree op)
+{
+ tree expr = build1 (VA_ARG_EXPR, type, op);
+ SET_EXPR_LOCATION (expr, loc);
+ return expr;
+}
+
+/* Return a VA_ARG_EXPR corresponding to a source-level expression
+ va_arg (EXPR, TYPE) at source location LOC. */
+
tree
build_va_arg (location_t loc, tree expr, tree type)
{
@@ -5923,24 +5937,107 @@ build_va_arg (location_t loc, tree expr, tree type)
? NULL_TREE
: targetm.canonical_va_list_type (va_type));
- if (canon_va_type != NULL)
+ if (va_type == error_mark_node
+ || canon_va_type == NULL_TREE)
{
- /* When the va_arg ap argument is a parm decl with declared type va_list,
- and the va_list type is an array, then grokdeclarator changes the type
- of the parm decl to the corresponding pointer type. We know that that
- pointer is constant, so there's no need to modify it, so there's no
- need to pass it around using an address operator, so there's no need to
- mark it addressable. */
- if (!(TREE_CODE (canon_va_type) == ARRAY_TYPE
- && TREE_CODE (va_type) != ARRAY_TYPE))
- /* In gimplify_va_arg_expr we take the address of the ap argument, mark
- it addressable now. */
- mark_addressable (expr);
+ /* Let's handle things neutrallly, if expr:
+ - has undeclared type, or
+ - is not an va_list type. */
+ return build_va_arg_1 (loc, type, expr);
}
- expr = build1 (VA_ARG_EXPR, type, expr);
- SET_EXPR_LOCATION (expr, loc);
- return expr;
+ if (TREE_CODE (canon_va_type) != ARRAY_TYPE)
+{
+ /* Case 1: Not an array type. */
+
+ /* Take the address, to get '&ap'. */
+ mark_addressable (expr);
+ expr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (expr)), expr);
+
+ /* Verify that &ap is still recognized as having va_list type. */
+ tree canon_expr_type
+ = targetm.canonical_va_list_type (TREE_TYPE (expr));
+ gcc_assert (canon_expr_type != NULL_TREE);
+
+ return build_va_arg_1 (loc, type, expr);
+}
+
+ /* Case 2: Array type.
+
+ Background:
+
+ For contrast, let's start with the simple case (case 1). If
+ canon_va_type is not an array type, but say a char *, then when
+ passing-by-value a va_list, the type of the va_
RE: [PATCH, FT32] initial support
> On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote: > > I cannot reproduce this with your testcase. Please post the *exact* > > testcase (nothing snipped) and the command line you used? > > Making the array volatile and using optimisation helped. Kaboom. > > It wants to reload pretty much everything. Looking at your code, > it seems you use the ancient interfaces instead of > TARGET_LEGITIMATE_ADDRESS_P, I don't think LRA works with that? The FT32 target uses TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P (ft32.c line 856). The FT32 itself is a Harvard architecture, and the ft32 port uses address spaces to distinguish between program and data memory. Of the ports that currently support LRA (arc, mips, rs6000, s380, sh) none use address spaces. Perhaps this port's use of address spaces is causing the problem? -- James Bowman FTDI Open Source Liaison
Re: [PATCH 4/4] Replace line_map union with C++ class hierarchy
On 05/04/2015 03:27 PM, David Malcolm wrote:
@@ -158,7 +158,7 @@ expand_location_1 (source_location loc,
location (toward the expansion point) that is not reserved;
that is, the first location that is in real source code. */
loc = linemap_unwind_to_first_non_reserved_loc (line_table,
- loc, &map);
+ loc, NULL);
Is that really correct?
I believe so. The old code had (in gcc/input.c's expand_location_1):
[ ... ]
THanks for walking through it. Mostly it just stuck out as "odd".
Given that we're depending on "not read" behaviour and latter calls
writing into that object again (thus making the original object in
memory "dead"), it'd be good to try and clean this up a little.
You could argue that passing in NULL like you did *is* actually that
cleanup and I'd probably agree with the hesitation that for it to be a
valid cleanup, linemap_resolve_location must never read what's in that
location.
linemap_resolve_location's function header indicates it's an output, so
I think we're OK.
So, concern eliminated :-)
/* Return the map at a given index. */
inline line_map *
LINEMAPS_MAP_AT (const line_maps *set, bool map_kind, int index)
{
- return &(LINEMAPS_MAPS (set, map_kind)[index]);
+ if (map_kind)
+return &set->info_macro.maps[index];
+ else
+return &set->info_ordinary.maps[index];
}
I see this pattern repeated regularly. Any thoughts on how painful
it'll be to drop the map_kind argument and instead not vary the kind?
I'm not sure I understand your question.
Given that kind of code, I'd be looking at the callers to determine if
there's a reasonable way to bubble up the if (map_kind) test.
This is particularly good if bubbling it up ultimately results in
somewhere in the call chain a statically determined map_kind.
I don't consider resolving this a requirement to go forward and it looks
like you tried implementing this stuff with templates and ran afoul of
gengtype. Fair enough :-0
So I think at this point the patch is good to go.
Jeff
Re: [PATCH, alpha]: Some further HWI == 64 improvements
On Wed, May 13, 2015 at 9:05 PM, Richard Henderson wrote:
> On 05/13/2015 10:53 AM, Uros Bizjak wrote:
>> The only part that actually processes CONST_WIDE_INT is
>> alpha_legitimate_constant and movti expander. The latter immediately
>> splits any TImode CONST_WIDE_INTs.
>>
>
> Indeed. Also probably worth cleaning up is using CONST_SCALAR_INT_P, where
> both CONST_INT and CONST_WIDE_INT are allowed.
I will do this in the last patch, when all uses of CONST_WIDE_INT and
CONST_DOUBLE are reviewed.
For now, I have prepared following patch that cleans
alpha_extract_integer and callers. Please also note that
alpha_legitimate_constant_p now checks full 128 bit constant.
2015-05-14 Uros Bizjak
* config/alpha/alpha.c (alpha_extract_integer): Do not handle
CONST_WIDE_INT and CONST_DOUBLE. Assert CONST_INT_P (x).
(alpha_legitimate_constant_p) : Check high and
low part of the constant using alpha_emit_set_const_1.
(alpha_expand_mov): Do not handle CONST_WIDE_INT and CONST_DOUBLE.
The patch passes bootstrap on alphaev68-linux-gnu, regression test is
in progress.
OK if regtest passes?
Uros.
Index: config/alpha/alpha.c
===
--- config/alpha/alpha.c(revision 223190)
+++ config/alpha/alpha.c(working copy)
@@ -2105,8 +2105,7 @@ alpha_emit_set_long_const (rtx target, HOST_WIDE_I
return target;
}
-/* Given an integral CONST_INT, CONST_WIDE_INT, CONST_DOUBLE,
- or CONST_VECTOR, return the low 64 bits. */
+/* Given an integral CONST_INT or CONST_VECTOR, return the low 64 bits. */
static HOST_WIDE_INT
alpha_extract_integer (rtx x)
@@ -2114,17 +2113,9 @@ alpha_extract_integer (rtx x)
if (GET_CODE (x) == CONST_VECTOR)
x = simplify_subreg (DImode, x, GET_MODE (x), 0);
- switch (GET_CODE (x))
-{
-case CONST_INT:
- return INTVAL (x);
-case CONST_WIDE_INT:
- return CONST_WIDE_INT_ELT (x, 0);
-case CONST_DOUBLE:
- return CONST_DOUBLE_LOW (x);
-default:
- gcc_unreachable ();
-}
+ gcc_assert (CONST_INT_P (x));
+
+ return INTVAL (x);
}
/* Implement TARGET_LEGITIMATE_CONSTANT_P. This is all constants for which
@@ -2152,7 +2143,6 @@ alpha_legitimate_constant_p (machine_mode mode, rt
if (GET_CODE (x) != SYMBOL_REF)
return true;
-
/* FALLTHRU */
case SYMBOL_REF:
@@ -2160,8 +2150,16 @@ alpha_legitimate_constant_p (machine_mode mode, rt
return SYMBOL_REF_TLS_MODEL (x) == 0;
case CONST_WIDE_INT:
+ if (TARGET_BUILD_CONSTANTS)
+ return true;
if (x == CONST0_RTX (mode))
return true;
+ mode = DImode;
+ gcc_assert (CONST_WIDE_INT_NUNITS (x) == 2);
+ i0 = CONST_WIDE_INT_ELT (x, 1);
+ if (alpha_emit_set_const_1 (NULL_RTX, mode, i0, 3, true) == NULL)
+ return false;
+ i0 = CONST_WIDE_INT_ELT (x, 0);
goto do_integer;
case CONST_DOUBLE:
@@ -2176,14 +2174,14 @@ alpha_legitimate_constant_p (machine_mode mode, rt
return false;
if (GET_MODE_SIZE (mode) != 8)
return false;
- goto do_integer;
+ /* FALLTHRU */
case CONST_INT:
-do_integer:
if (TARGET_BUILD_CONSTANTS)
return true;
i0 = alpha_extract_integer (x);
- return alpha_emit_set_const_1 (x, mode, i0, 3, true) != NULL;
+do_integer:
+ return alpha_emit_set_const_1 (NULL_RTX, mode, i0, 3, true) != NULL;
default:
return false;
@@ -2248,8 +2246,6 @@ alpha_expand_mov (machine_mode mode, rtx *operands
/* Split large integers. */
if (CONST_INT_P (operands[1])
- || GET_CODE (operands[1]) == CONST_WIDE_INT
- || GET_CODE (operands[1]) == CONST_DOUBLE
|| GET_CODE (operands[1]) == CONST_VECTOR)
{
if (alpha_split_const_mov (mode, operands))
Re: [PATCH 6/7] [D] libiberty: Improve support for demangling D2 templates
On 14 May 2015 at 15:24, Jeff Law wrote: > On 05/13/2015 02:51 AM, Iain Buclaw wrote: >> >> In my tests, this gives the demangler near-complete support. Of a >> sample of about 75k symbols pulled from the standard library >> unittester, all but 20 were successfully parsed. >> >> --- >> libiberty/ChangeLog: >> >> 2015-05-13 Iain Buclaw >> >> * d-demangle.c (dlang_symbol_kinds): New enum. >> (dlang_parse_symbol): Update signature. Handle an ambiguity between >> mangle >> symbol for pascal and template value arguments. Only check for a >> type >> if parsing a function, or at the top level. Return failure if the >> entire symbol was not successfully demangled. >> (dlang_identifier): Update signature. Handle an ambiguity between >> two >> adjacent digits in a mangled symbol string. >> (dlang_type): Update call to dlang_parse_symbol. >> (dlang_template_args): Likewise. >> (dlang_parse_template): Likewise. >> (dlang_demangle): Likewise. >> * testsuite/d-demangle-expected: Fix bad tests found, and add >> problematic >> examples to the unittests. > > OK. > > I'm going to trust the code to dis-ambiguate the adjacent digits in > dlang_identifier is correct. The rest of the changes were pretty easy to > follow :-0 > > Jeff > Actually, the one snippest that we should be OK without in that dis-ambiguate section is the while loop with the comment: "handle any overflow". On another note, I've found out why the remaining 20 symbols in my 75k sample failed. They don't fail at all! It's just that they were all greater than 33,000 characters in length, and my test used c++filt, which trims anything bigger than 32767 (whoops!). Iain.
Re: [PATCH, alpha]: Some further HWI == 64 improvements
On 05/14/2015 08:32 AM, Uros Bizjak wrote: > 2015-05-14 Uros Bizjak > > * config/alpha/alpha.c (alpha_extract_integer): Do not handle > CONST_WIDE_INT and CONST_DOUBLE. Assert CONST_INT_P (x). > (alpha_legitimate_constant_p) : Check high and > low part of the constant using alpha_emit_set_const_1. > (alpha_expand_mov): Do not handle CONST_WIDE_INT and CONST_DOUBLE. > > The patch passes bootstrap on alphaev68-linux-gnu, regression test is > in progress. > > OK if regtest passes? Looks good. r~
[PATCH] Introduce TV_INITIALIZE_RTL
Before this patch, jit.dg/test-benchmark.c at optlevel 0, 100 iterations
showed "rest of compilation" as taking a significant chunk of time:
rest of compilation : 1.53 (64%) usr 0.06 (32%) sys 1.60 (27%) wall
1388 kB ( 6%) ggc
This turned out to be almost entirely spent inside initialize_rtl; adding a
TV_INITIALIZE_RTL for this indicates this cost clearly:
initialize rtl : 1.46 (61%) usr 0.01 ( 5%) sys 1.42 (24%) wall
1156 kB ( 5%) ggc
rest of compilation : 0.05 ( 2%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
232 kB ( 1%) ggc
I'm experimenting with a followup patch to amortize this away by making RTL
initialization a one-time deal, but in the meantime, this patch adds
accounting for it.
OK for trunk? (assuming bootstrap and testing)
gcc/ChangeLog:
* timevar.def (TV_INITIALIZE_RTL): New.
* toplev.c (initialize_rtl): Use an auto_timevar to account this
function's time to TV_INITIALIZE_RTL.
---
gcc/timevar.def | 1 +
gcc/toplev.c| 2 ++
2 files changed, 3 insertions(+)
diff --git a/gcc/timevar.def b/gcc/timevar.def
index 711bbed..cf8f37d 100644
--- a/gcc/timevar.def
+++ b/gcc/timevar.def
@@ -268,6 +268,7 @@ DEFTIMEVAR (TV_PLUGIN_RUN, "plugin execution")
DEFTIMEVAR (TV_GIMPLE_SLSR , "straight-line strength reduction")
DEFTIMEVAR (TV_VTABLE_VERIFICATION , "vtable verification")
DEFTIMEVAR (TV_TREE_UBSAN, "tree ubsan")
+DEFTIMEVAR (TV_INITIALIZE_RTL, "initialize rtl")
/* Everything else in rest_of_compilation not included above. */
DEFTIMEVAR (TV_EARLY_LOCAL , "early local passes")
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 3c1ba38..54eefcd 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1818,6 +1818,8 @@ static int rtl_initialized;
void
initialize_rtl (void)
{
+ auto_timevar tv (TV_INITIALIZE_RTL);
+
/* Initialization done just once per compilation, but delayed
till code generation. */
if (!rtl_initialized)
--
1.8.5.3
PING: [PATCH diagnostics] Handle two locations for the same diagnostic. Convert all gfc_warning_1 and gfc_notify_std_1 calls
PING: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00772.html The Fortran part was already approved, only the diagnostics part is pending. Thanks, Manuel.
[PATCH] Fix two leaks in postreload-gcse.c
Running jit.dg/test-sum-of-squares.c under valgrind showed a couple of leaks: 608 bytes in 4 blocks are definitely lost in loss record 184 of 229 at 0x4A081D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x5BC88B0: xcalloc (xmalloc.c:162) by 0x524F72D: alloc_mem() (postreload-gcse.c:352) by 0x5252611: gcse_after_reload_main(rtx_def*) (postreload-gcse.c:1390) by 0x5252828: rest_of_handle_gcse2() (postreload-gcse.c:1444) by 0x52528DA: (anonymous namespace)::pass_gcse2::execute(function*) (postreload-gcse.c:1478) by 0x5249D2A: execute_one_pass(opt_pass*) (passes.c:2317) by 0x5249FB1: execute_pass_list_1(opt_pass*) (passes.c:2370) by 0x5249FE2: execute_pass_list_1(opt_pass*) (passes.c:2371) by 0x5249FE2: execute_pass_list_1(opt_pass*) (passes.c:2371) by 0x524A01F: execute_pass_list(function*, opt_pass*) (passes.c:2381) by 0x4EC075C: cgraph_node::expand() (cgraphunit.c:1895) 608 bytes in 4 blocks are definitely lost in loss record 185 of 229 at 0x4A081D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x5BC88B0: xcalloc (xmalloc.c:162) by 0x524F754: alloc_mem() (postreload-gcse.c:355) by 0x5252611: gcse_after_reload_main(rtx_def*) (postreload-gcse.c:1390) by 0x5252828: rest_of_handle_gcse2() (postreload-gcse.c:1444) by 0x52528DA: (anonymous namespace)::pass_gcse2::execute(function*) (postreload-gcse.c:1478) by 0x5249D2A: execute_one_pass(opt_pass*) (passes.c:2317) by 0x5249FB1: execute_pass_list_1(opt_pass*) (passes.c:2370) by 0x5249FE2: execute_pass_list_1(opt_pass*) (passes.c:2371) by 0x5249FE2: execute_pass_list_1(opt_pass*) (passes.c:2371) by 0x524A01F: execute_pass_list(function*, opt_pass*) (passes.c:2381) by 0x4EC075C: cgraph_node::expand() (cgraphunit.c:1895) The following patch fixes them (verified via rerunning under valgrind). OK for trunk? (assuming I bootstrap and test it) gcc/ChangeLog: * postreload-gcse.c (free_mem): Free modify_mem_list and canon_modify_mem_list. --- gcc/postreload-gcse.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/postreload-gcse.c b/gcc/postreload-gcse.c index 9014d69..ae6fdd0 100644 --- a/gcc/postreload-gcse.c +++ b/gcc/postreload-gcse.c @@ -381,6 +381,8 @@ free_mem (void) BITMAP_FREE (blocks_with_calls); BITMAP_FREE (modify_mem_list_set); free (reg_avail_info); + free (modify_mem_list); + free (canon_modify_mem_list); } -- 1.8.5.3
PR64454: (x % y) % y
Hello,
after this patch I think I'll close the PR. This was regtested on
ppc64le-redhat-linux.
Apparently I wrote this patch in a file that already had a trivial hunk:
-1-A -> ~A is rejected for complex while -A-1 isn't, there is no reason
for this difference (maybe there was before integer_all_onesp /
integer_minus_onep was introduced), I hope you don't mind.
I am wondering if we want some helper (like :c for commutative operations)
to avoid duplicating patterns for xx. We could also, when a
comparison x<=y doesn't simplify, see if !!(x<=y) simplifies better, but
that's becoming a bit complicated.
2015-05-15 Marc Glisse
PR tree-optimization/64454
gcc/
* match.pd ((X % Y) % Y, (X % Y) < Y): New patterns.
(-1 - A -> ~A): Remove unnecessary condition.
gcc/testsuite/
* gcc.dg/modmod.c: New testcase.
--
Marc GlisseIndex: gcc/match.pd
===
--- gcc/match.pd(revision 223199)
+++ gcc/match.pd(working copy)
@@ -204,33 +204,49 @@ along with GCC; see the file COPYING3.
(if (!integer_zerop (@1))
@0))
/* X % 1 is always zero. */
(simplify
(mod @0 integer_onep)
{ build_zero_cst (type); })
/* X % -1 is zero. */
(simplify
(mod @0 integer_minus_onep@1)
(if (!TYPE_UNSIGNED (type))
- { build_zero_cst (type); })))
+ { build_zero_cst (type); }))
+ /* (X % Y) % Y is just X % Y. */
+ (simplify
+ (mod (mod@2 @0 @1) @1)
+ @2))
/* X % -C is the same as X % C. */
(simplify
(trunc_mod @0 INTEGER_CST@1)
(if (TYPE_SIGN (type) == SIGNED
&& !TREE_OVERFLOW (@1)
&& wi::neg_p (@1)
&& !TYPE_OVERFLOW_TRAPS (type)
/* Avoid this transformation if C is INT_MIN, i.e. C == -C. */
&& !sign_bit_p (@1, @1))
(trunc_mod @0 (negate @1
+/* X % Y is smaller than Y. */
+(for cmp (lt ge)
+ (simplify
+ (cmp (trunc_mod @0 @1) @1)
+ (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
+ { constant_boolean_node (cmp == LT_EXPR, type); })))
+(for cmp (gt le)
+ (simplify
+ (cmp @1 (trunc_mod @0 @1))
+ (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
+ { constant_boolean_node (cmp == GT_EXPR, type); })))
+
/* x | ~0 -> ~0 */
(simplify
(bit_ior @0 integer_all_onesp@1)
@1)
/* x & 0 -> 0 */
(simplify
(bit_and @0 integer_zerop@1)
@1)
@@ -526,22 +542,21 @@ along with GCC; see the file COPYING3.
/* -A - 1 -> ~A */
(simplify
(minus (convert? (negate @0)) integer_each_onep)
(if (!TYPE_OVERFLOW_TRAPS (type)
&& tree_nop_conversion_p (type, TREE_TYPE (@0)))
(bit_not (convert @0
/* -1 - A -> ~A */
(simplify
(minus integer_all_onesp @0)
- (if (TREE_CODE (type) != COMPLEX_TYPE)
-(bit_not @0)))
+ (bit_not @0))
/* (T)(P + A) - (T)P -> (T) A */
(for add (plus pointer_plus)
(simplify
(minus (convert (add @0 @1))
(convert @0))
(if (element_precision (type) <= element_precision (TREE_TYPE (@1))
/* For integer types, if A has a smaller type
than T the result depends on the possible
overflow in P + A.
Index: gcc/testsuite/gcc.dg/modmod.c
===
--- gcc/testsuite/gcc.dg/modmod.c (revision 0)
+++ gcc/testsuite/gcc.dg/modmod.c (working copy)
@@ -0,0 +1,13 @@
+/* { dg-options "-O -fdump-tree-optimized-raw" } */
+
+int f(int a, int b){
+ a %= b;
+ return a % b;
+}
+int g(unsigned a, unsigned b){
+ a %= b;
+ return a < b;
+}
+
+/* { dg-final { scan-tree-dump-times "trunc_mod_expr" 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
Marek,
This may be unrelated to your patches for PR 66127 and 66066 but I am
having a new failure when building the latest glibc with the latest GCC.
I haven't yet tracked down exactly which patch caused the problem. Included
is a cutdown test case from libio/memstream.c in glibc that results in a
strict-aliasing error. Is this is something you already know about or have
seen?
In the mean time I will try to figure out exactly which patch caused this error
to trigger.
Steve Ellcey
sell...@imgtec.com
typedef unsigned int size_t;
extern void *malloc (size_t __size) __attribute__ ((__nothrow__ )) __attribute__
((__malloc__)) ;
struct _IO_FILE_plus { void *vtable; };
void *_IO_mem_jumps;
struct _IO_streambuf { };
typedef struct _IO_strfile_
{
struct _IO_streambuf _sbf;
} _IO_strfile;
struct _IO_FILE_memstream
{
_IO_strfile _sf;
};
void open_memstream (int bufloc, int sizeloc)
{
struct locked_FILE
{
struct _IO_FILE_memstream fp;
} *new_f;
new_f = (struct locked_FILE *) malloc (sizeof (struct locked_FILE));
((struct _IO_FILE_plus *) &new_f->fp._sf._sbf)->vtable = &_IO_mem_jumps;
}
x.c: In function 'open_memstream':
x.c:28:12: error: dereferencing type-punned pointer will break strict-aliasing
rules [-Werror=strict-aliasing]
((struct _IO_FILE_plus *) &new_f->fp._sf._sbf)->vtable = &_IO_mem_jumps;
^
cc1: all warnings being treated as errors
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
On Thu, 2015-05-14 at 09:42 -0700, Steve Ellcey wrote: > Marek, > > This may be unrelated to your patches for PR 66127 and 66066 but I am > having a new failure when building the latest glibc with the latest GCC. > > I haven't yet tracked down exactly which patch caused the problem. Included > is a cutdown test case from libio/memstream.c in glibc that results in a > strict-aliasing error. Is this is something you already know about or have > seen? > > In the mean time I will try to figure out exactly which patch caused this > error > to trigger. > > Steve Ellcey > sell...@imgtec.com Sorry for the noise, it looks like this failure is not related to any recent changes in GCC. I still get the error in older GCC's so I think something must have changed in glibc. I will start digging there. Steve Ellcey sell...@imgtec.com
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
On Thu, May 14, 2015 at 10:07:56AM -0700, Steve Ellcey wrote: > Sorry for the noise, it looks like this failure is not related to any > recent changes in GCC. I still get the error in older GCC's so I think > something must have changed in glibc. I will start digging there. Yeah -- strict aliasing should be unrelated to the changes I've recently done in the C FE. Marek
Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax
On Wed, 13 May 2015, Jan Hubicka wrote:
> Thank you! This looks fine. Please add also the testcase that should break if
> the new test was wrong andosmeone fixed postreload to allow use of the same
> register
> this check will prevent wrong code?
I'm checking in a patch with the following additional test.
diff --git a/gcc/testsuite/gcc.target/i386/sibcall-8.c
b/gcc/testsuite/gcc.target/i386/sibcall-8.c
index e69de29..3ab3809 100644
--- a/gcc/testsuite/gcc.target/i386/sibcall-8.c
+++ b/gcc/testsuite/gcc.target/i386/sibcall-8.c
@@ -0,0 +1,24 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+extern void abort (void);
+
+static int __attribute__((regparm(1)))
+bar(void *arg)
+{
+ return arg != bar;
+}
+
+static int __attribute__((noinline,noclone,regparm(1)))
+foo(int (__attribute__((regparm(1))) **bar)(void*))
+{
+ return (*bar)(*bar);
+}
+
+int main()
+{
+ int (__attribute__((regparm(1))) *p)(void*) = bar;
+ if (foo(&p))
+abort();
+ return 0;
+}
Re: [PATCH, FT32] initial support
On Thu, May 14, 2015 at 03:20:46PM +, James Bowman wrote:
> > It wants to reload pretty much everything. Looking at your code,
> > it seems you use the ancient interfaces instead of
> > TARGET_LEGITIMATE_ADDRESS_P, I don't think LRA works with that?
>
> The FT32 target uses TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
> (ft32.c line 856).
Ah I see.
> The FT32 itself is a Harvard architecture, and the ft32 port uses
> address spaces to distinguish between program and data memory.
>
> Of the ports that currently support LRA (arc, mips, rs6000, s380, sh) none
> use address spaces.
> Perhaps this port's use of address spaces is causing the problem?
That could certainly cause problems. I don't think it's likely
it causes all this though.
Adding some debug, it looks like LRA never calls the
TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
hook? Not during the spilling it does, anyway. Here is what it
_does_ do:
Choosing alt 1 in insn 12: (0) r (1) r (2) r {addsi3}
Creating newreg=58 from oldreg=56, assigning class GENERAL_REGS to r58
12: r58:SI=$fp:SI+r55:SI
REG_DEAD r55:SI
REG_EQUIV $fp:SI-0x384
Inserting insn reload after:
32: r56:SI=r58:SI
so it decides to use the "r" constraint everywhere in that addsi3 insn, thinks
it isn't all okay yet (and it isn't, r56 was allocated to mem (see the ira
dump),
has no hard reg yet), and solves it by generating an extra move. That should be
a move from the reg to mem, but it doesn't want to:
0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
alt=0,overall=608,losers=1,rld_nregs=1
alt=1: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=2: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=3: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=4: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=5: Bad operand -- refuse
alt=6: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=7: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=8: Bad operand -- refuse
Choosing alt 0 in insn 32: (0) =r (1) r {*movsi}
Creating newreg=59 from oldreg=56, assigning class GENERAL_REGS to r59
32: r59:SI=r58:SI
Inserting insn reload after:
33: r56:SI=r59:SI
The alternative that allows move to mem is alt 1, but it thinks the operand
doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy.
"B" should match it seems?
(Why does IRA think r56 should be in memory? Yeah, good question.)
Segher
Re: [PATCH] Fix two leaks in postreload-gcse.c
On 05/14/2015 10:38 AM, David Malcolm wrote: Running jit.dg/test-sum-of-squares.c under valgrind showed a couple of leaks: 608 bytes in 4 blocks are definitely lost in loss record 184 of 229 at 0x4A081D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x5BC88B0: xcalloc (xmalloc.c:162) by 0x524F72D: alloc_mem() (postreload-gcse.c:352) by 0x5252611: gcse_after_reload_main(rtx_def*) (postreload-gcse.c:1390) by 0x5252828: rest_of_handle_gcse2() (postreload-gcse.c:1444) by 0x52528DA: (anonymous namespace)::pass_gcse2::execute(function*) (postreload-gcse.c:1478) by 0x5249D2A: execute_one_pass(opt_pass*) (passes.c:2317) by 0x5249FB1: execute_pass_list_1(opt_pass*) (passes.c:2370) by 0x5249FE2: execute_pass_list_1(opt_pass*) (passes.c:2371) by 0x5249FE2: execute_pass_list_1(opt_pass*) (passes.c:2371) by 0x524A01F: execute_pass_list(function*, opt_pass*) (passes.c:2381) by 0x4EC075C: cgraph_node::expand() (cgraphunit.c:1895) 608 bytes in 4 blocks are definitely lost in loss record 185 of 229 at 0x4A081D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x5BC88B0: xcalloc (xmalloc.c:162) by 0x524F754: alloc_mem() (postreload-gcse.c:355) by 0x5252611: gcse_after_reload_main(rtx_def*) (postreload-gcse.c:1390) by 0x5252828: rest_of_handle_gcse2() (postreload-gcse.c:1444) by 0x52528DA: (anonymous namespace)::pass_gcse2::execute(function*) (postreload-gcse.c:1478) by 0x5249D2A: execute_one_pass(opt_pass*) (passes.c:2317) by 0x5249FB1: execute_pass_list_1(opt_pass*) (passes.c:2370) by 0x5249FE2: execute_pass_list_1(opt_pass*) (passes.c:2371) by 0x5249FE2: execute_pass_list_1(opt_pass*) (passes.c:2371) by 0x524A01F: execute_pass_list(function*, opt_pass*) (passes.c:2381) by 0x4EC075C: cgraph_node::expand() (cgraphunit.c:1895) The following patch fixes them (verified via rerunning under valgrind). OK for trunk? (assuming I bootstrap and test it) gcc/ChangeLog: * postreload-gcse.c (free_mem): Free modify_mem_list and canon_modify_mem_list. OK. Not sure how I missed them when I added that code. jeff
Re: PR64454: (x % y) % y
On 05/14/2015 10:33 AM, Marc Glisse wrote: Hello, after this patch I think I'll close the PR. This was regtested on ppc64le-redhat-linux. Apparently I wrote this patch in a file that already had a trivial hunk: -1-A -> ~A is rejected for complex while -A-1 isn't, there is no reason for this difference (maybe there was before integer_all_onesp / integer_minus_onep was introduced), I hope you don't mind. I am wondering if we want some helper (like :c for commutative operations) to avoid duplicating patterns for xx. We could also, when a comparison x<=y doesn't simplify, see if !!(x<=y) simplifies better, but that's becoming a bit complicated. 2015-05-15 Marc Glisse PR tree-optimization/64454 gcc/ * match.pd ((X % Y) % Y, (X % Y) < Y): New patterns. (-1 - A -> ~A): Remove unnecessary condition. gcc/testsuite/ * gcc.dg/modmod.c: New testcase. OK. jeff
Re: [PATCH] Introduce TV_INITIALIZE_RTL
On 05/14/2015 10:29 AM, David Malcolm wrote: Before this patch, jit.dg/test-benchmark.c at optlevel 0, 100 iterations showed "rest of compilation" as taking a significant chunk of time: rest of compilation : 1.53 (64%) usr 0.06 (32%) sys 1.60 (27%) wall 1388 kB ( 6%) ggc This turned out to be almost entirely spent inside initialize_rtl; adding a TV_INITIALIZE_RTL for this indicates this cost clearly: initialize rtl : 1.46 (61%) usr 0.01 ( 5%) sys 1.42 (24%) wall 1156 kB ( 5%) ggc rest of compilation : 0.05 ( 2%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 232 kB ( 1%) ggc I'm experimenting with a followup patch to amortize this away by making RTL initialization a one-time deal, but in the meantime, this patch adds accounting for it. OK for trunk? (assuming bootstrap and testing) gcc/ChangeLog: * timevar.def (TV_INITIALIZE_RTL): New. * toplev.c (initialize_rtl): Use an auto_timevar to account this function's time to TV_INITIALIZE_RTL. We should done this a long time ago -- initialization/startup items are a real issue. OK. jeff
Re: [PATCH 6/7] [D] libiberty: Improve support for demangling D2 templates
On Thu, 14 May 2015, Iain Buclaw wrote: > On another note, I've found out why the remaining 20 symbols in my 75k > sample failed. They don't fail at all! It's just that they were all > greater than 33,000 characters in length, and my test used c++filt, > which trims anything bigger than 32767 (whoops!). That would be a bug in c++filt (failure to follow the GNU Coding Standards regarding having no arbitrary limits). -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH, alpha]: Remove some_operand and some_ni_operand
On 05/14/2015 04:40 AM, Uros Bizjak wrote:
> On Thu, May 14, 2015 at 1:31 PM, Uros Bizjak wrote:
>> On Wed, May 13, 2015 at 8:53 PM, Richard Henderson wrote:
>>> On 05/13/2015 11:11 AM, Uros Bizjak wrote:
We can use general_operand instead of some_operand.
2015-05-13 Uros Bizjak
* config/alpha/alpha.md (extendqidi2): Use general_operand
instead of some_operand for operand[1] predicate.
(extendhidi2): Ditto.
(cbranchdi4): Use general_operand instead of some_operand
for operand[1] and operands[2] predicates.
(cstoredi4): Ditto.
* config/alpha/predicates.md (some_operand): Remove unused predicate.
(some_ni_operand): Ditto.
Tested on alpha-linux-gnu.
Richard, does this look OK to you, or is there any other reason that
general_operand predicates were not used here?
>>>
>>> For the extensions, it was put in by Kenner in 1997 (90f6b60d), to improve
>>> code
>>> for unaligned memories. That code was removed in 2011 by me (8b2983a3), so
>>> I
>>> think dropping some_operand there is fine.
>>>
>>> For the conditionals, it was added in 2004 by me (62350d6c), and that code
>>> is
>>> still there. Specifically,
>>>
>>> @@ -3177,11 +3177,17 @@ alpha_emit_conditional_branch (enum rtx_code code)
>>> cmp_code = NIL, branch_code = code;
>>>
>>> /* If the constants doesn't fit into an immediate, but can
>>> be generated by lda/ldah, we adjust the argument and
>>> compare against zero, so we can use beq/bne directly. */
>>> - else if (GET_CODE (op1) == CONST_INT && (code == EQ || code ==
>>> NE))
>>> + /* ??? Don't do this when comparing against symbols, otherwise
>>> +we'll reduce (&x == 0x1234) to (&x-0x1234 == 0), which will
>>> +be declared false out of hand (at least for non-weak). */
>>> + else if (GET_CODE (op1) == CONST_INT
>>> + && (code == EQ || code == NE)
>>> + && !(symbolic_operand (op0, VOIDmode)
>>> + || (GET_CODE (op0) == REG && REG_POINTER (op0
>>>
>>> If I didn't use some_operand, the SYMBOL_REF would be lowered and we'll only
>>> see a REG here. Searching the mail archive I find
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2004-02/msg02436.html
>>>
>>> pointing to the test case gcc.dg/20040123-1.c
>>>
>>> Perhaps debugging that testcase to see what's reaching a_e_c_b in these
>>> modern
>>> times will tell you what's most appropriate.
>>
>> Both, patched and unpatched compiler generate:
>>
>> ;; Generating RTL for gimple basic block 2
>>
>> ;; if (&a == 16384B)
>>
>> (insn 5 4 6 (set (reg/f:DI 70)
>> (symbol_ref:DI ("a") [flags 0x40] > a>)) 20040123-1.c:10 -1
>> (nil))
>>
>> (insn 6 5 7 (set (reg:DI 71)
>> (const_int 16384 [0x4000])) 20040123-1.c:10 -1
>> (nil))
>>
>> (insn 7 6 8 (set (reg:DI 72)
>> (eq:DI (reg/f:DI 70)
>> (reg:DI 71))) 20040123-1.c:10 -1
>> (nil))
>>
>> (jump_insn 8 7 0 (set (pc)
>> (if_then_else (eq (reg:DI 72)
>> (const_int 0 [0]))
>> (label_ref 0)
>> (pc))) 20040123-1.c:10 -1
>> (int_list:REG_BR_PROB 9996 (nil)))
>>
>> and gcc.dg/20040123-1.c passes for as long as I remember...
>
> Bah, pushed send too fast.
>
> This is what is received by a_e_c_b in both, patched and unpatched case:
>
> Breakpoint 1, alpha_emit_conditional_branch (operands=0x7fffd6e0,
> cmp_mode=DImode) at
> /home/uros/gcc-svn/trunk/gcc/config/alpha/alpha.c:2508
> 2508alpha_emit_conditional_branch (rtx operands[], machine_mode cmp_mode)
> (gdb) p debug_rtx (operands[0])
> (ne (reg/f:DI 70)
> (const_int 16384 [0x4000]))
> $1 = void
> (gdb) p debug_rtx (operands[1])
> (reg/f:DI 70)
Ok, gotcha -- the REG_POINTER_P section of the test is still triggering. I
suspect that the symbolic_operand test can no longer trigger.
I think the whole patch is ok.
r~
Re: [PATCH, FT32] initial support
On 05/14/2015 09:20 AM, James Bowman wrote:
On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
I cannot reproduce this with your testcase. Please post the *exact*
testcase (nothing snipped) and the command line you used?
Making the array volatile and using optimisation helped. Kaboom.
It wants to reload pretty much everything. Looking at your code,
it seems you use the ancient interfaces instead of
TARGET_LEGITIMATE_ADDRESS_P, I don't think LRA works with that?
The FT32 target uses TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
(ft32.c line 856).
The FT32 itself is a Harvard architecture, and the ft32 port uses
address spaces to distinguish between program and data memory.
Of the ports that currently support LRA (arc, mips, rs6000, s380, sh) none
use address spaces.
Perhaps this port's use of address spaces is causing the problem?
I don't think so, it feels like something else to me. But I do have a
larger concern that if LRA hasn't been used much, if at all, on targets
that have multiple address spaces, then we may have other lurking issues.
Anyway:
In .ira we have:
(insn 11 7 12 2 (set (reg:SI 51)
(const_int -900 [0xfc7c])) j.c:7 25 {*movsi}
(expr_list:REG_EQUIV (const_int -900 [0xfc7c])
(nil)))
(insn 12 11 18 2 (set (reg/f:SI 50)
(plus:SI (reg/f:SI 0 $fp)
(reg:SI 51))) j.c:7 2 {addsi3}
(expr_list:REG_DEAD (reg:SI 51)
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 0 $fp)
(const_int -900 [0xfc7c]))
(nil
Where r51 will get a hard reg, but r50 will not. This is confirmed by
looking at the coloring dump in .ira:
Loop 0 (parent -1, header bb2, depth 0)
bbs: 4 3 2
all: 0r45 1r54 2r50 3r51 4r48 5r44 10r52 11r43
modified regnos: 43 44 45 48 50 51 52 54
border:
Pressure: GENERAL_REGS=6
Hard reg set forest:
0:( 2-29)@0
1:( 2-6 8-29)@87680
Spill a2(r50,l0)
So r50 gets spilled to memory. That's going to cause insn 12 to have an
output reload because it can't store into memory directly.
Choosing alt 1 in insn 12: (0) r (1) r (2) r {addsi3}
Creating newreg=55 from oldreg=50, assigning class GENERAL_REGS
to r55
12: r55:SI=$fp:SI+r51:SI
REG_DEAD r51:SI
REG_EQUIV $fp:SI-0x384
Inserting insn reload after:
32: r50:SI=r55:SI
So we're going to use r55 to hold the result of the arithmetic, then
shove it into the stack slot allocated for r50. That all seems normal.
But for some reason things blow up after that, it's almost as if LRA
doesn't like the trival reg-reg copy emitted to handle the output reload.
At this point I'd recommend committing the port as-is and attacking LRA
as a follow-up.
jeff
Re: [PATCH, FT32] initial support
On 05/14/2015 11:36 AM, Segher Boessenkool wrote: The alternative that allows move to mem is alt 1, but it thinks the operand doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy. "B" should match it seems? (Why does IRA think r56 should be in memory? Yeah, good question.) Independent of that, if a reg-reg move generated by LRA (which is really a mem->reg or reg->mem) blows up on this target for some reason, then that needs to be addressed independently of whether or not IRA might have made a bad choice for which pseudo to spill. Jeff
Re: [PATCH 6/7] [D] libiberty: Improve support for demangling D2 templates
On May 14, 2015, at 8:30 AM, Iain Buclaw wrote: > > On another note, I've found out why the remaining 20 symbols in my 75k > sample failed. They don't fail at all! It's just that they were all > greater than 33,000 characters in length, and my test used c++filt, > which trims anything bigger than 32767 (whoops!). We blew past 32k more than a decade or two ago.
Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
On 14 May 2015 at 16:51, Jeff Law wrote:
> On 05/14/2015 07:36 AM, Iain Buclaw wrote:
>>
>> On 14 May 2015 at 14:58, Jeff Law wrote:
>>>
>>> On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.
---
libiberty/ChangeLog
2015-05-13 Iain Buclaw
* d-demangle.c (dlang_call_convention): Return NULL if have
reached
the
end of the symbol, but expected more.
(dlang_attributes): Likewise.
(dlang_function_type): Likewise.
(dlang_type): Likewise.
(dlang_identifier): Likewise.
(dlang_value): Likewise.
>>>
>>>
>>> I spot checked various callers of these functions that not return NULL
>>> and
>>> they looked reasonable. Though I was a bit concerned about the callers of
>>> dlang_type, dlang_value and dlang_identifier.
>>>
>>> In those cases we'll often still do the string_append, string_setlength
>>> and
>>> other calls in the caller of dlang_{value,type,identifier}. I'm assuming
>>> that's safe (the error still appears to be bubbling up properly).
>>>
>>
>> The string routines should be safe for that (appending a string with a
>> zero length does nothing, for instance).
>>
>>> If you can confirm that we're OK in those cases, then this is OK for the
>>> trunk.
>>>
>>
>> I can start fuzzing mangle strings to test that failures actually fail
>> gracefully. There's already a fuzzer that exists for C++, I think the
>> only change that would be required for D is exchanging "_Z" for "_D"
>> and calling cplus_demangle with DMGL_DLANG.
>
> Your call whether to fuzz before or after committing the changes.
>
> jeff
Iant commited in the changes first time around. I don't have write
after approval access in GCC just yet, probably should go about
getting that sorted out if this is to become a regular thing. I dealt
with copyright assignments back in September.
Iain.
Re: [PATCH, FT32] initial support
On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote: > On 05/14/2015 11:36 AM, Segher Boessenkool wrote: > >The alternative that allows move to mem is alt 1, but it thinks the operand > >doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy. > > > >"B" should match it seems? > > > >(Why does IRA think r56 should be in memory? Yeah, good question.) > Independent of that, if a reg-reg move generated by LRA (which is really > a mem->reg or reg->mem) blows up on this target for some reason, then > that needs to be addressed independently of whether or not IRA might > have made a bad choice for which pseudo to spill. Yes. It probably is because of the "volatile" I inserted for it to fail at all, anyway. Changing constraints ABWef to be define_memory_constraint (instead of define_constraint) makes this testcase pass. It also makes the build pass (it failed before; 90 reloads in libgcc). Pretty miserable code for those memory accesses, but hey, better than an ICE ;-) Segher
Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting
On 04/24/2015 10:18 AM, Jiong Wang wrote: 2015-04-21 Jiong Wang gcc/ * loop-invariant.c (find_defs): Enable DF_DU_CHAIN build. (vfp_const_iv): New hash table. (expensive_addr_check_p): New boolean. (init_inv_motion_data): Initialize new variables.> (free_inv_motion_data): Release hash table. (create_new_invariant): Set cheap_address to false for iv in vfp_const_iv table. (find_invariant_insn): Skip dependencies check for iv in vfp_const_iv table. (use_for_single_du): New function. (reshuffle_insn_with_vfp): Likewise. (find_invariants_bb): Call reshuffle_insn_with_vfp. gcc/testsuite/ * gcc.dg/pr62173.c: New testcase. So ultimately isn't this just a specialized version of reassociation of pointer arithmetic? And if so, don't we have all the usual problems around introducing overflow? ISTM if this is going to go forward (ie, we somehow convince ourselves that this kind of reassociation is OK), then should it be made to apply on pointers in general rather than restricting to stack, frame, virtual-frame? Jeff, Thanks for the review. This transformation is not reassociation of pointer arithmetic. ^^^ The idea of this patch is, given two instructions with variable value, we may get new instruction sequences with fixed value by reassociating their operands. And currently GCC only generate such instruction sequences for local array accessing as far as I known. Which is precisely reassociation of pointer arithmetic. Given: x = a + b y = *(x + c) You're generating: x = a + c y = *(x + b) That's reassociation of pointer arithmetic. For all kinds of reassociation we have to concern ourselves with adding overflow where it didn't already occur. Assuming a 32 bit architecture we could get overflow if A is 0x7fff, b is -4 and and c = 3 0x7fff + -4 = 0x7ffb 0x7ffb + 3 = 0x7ffe If you make the transformation you're suggesting we get 0x7fff + 3 = 0x8002 OVERFLOW 0x8002 - 4 = 0x7ffe Now if you always know pointers are unsigned, then the overflow is defined and you'd be OK. But that's a property of the target and one that's not well modeled within GCC (we have POINTER_EXTEND_UNSIGNED which kind of tells us something in this space). In addition to worrying about overflow, you have to worry about segmented architectures with implicit segment selection -- especially if the segment selection comes from the base register than the entire effective address. On such architectures a + b != b + a when used in a memory reference. The HPPA and mn103 ports immediately come to mind. I'm sure there's at least one more since I recall helping someone with these issues in the past. Anyway So given x = a + b; y = *(x + c) Can only be transformed into x = a + c y = *(x + b) If and only if a + b would choose the same segment as a + c. On the PA that wouldn't be true for something like a = 0x400 b = 0x10 c = -4 a + b is 0x4010 a + c is 0x3ffc Those select different segments. Even though the full address is the same (0x400c). Sadly we don't expose this aspect of target characteristics at all. To proceed, you'd probably need ways to conditionalize these transformations. ie, target hooks. Jeff
Re: [PATCH, FT32] initial support
On 05/14/2015 01:24 PM, Segher Boessenkool wrote: On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote: On 05/14/2015 11:36 AM, Segher Boessenkool wrote: The alternative that allows move to mem is alt 1, but it thinks the operand doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy. "B" should match it seems? (Why does IRA think r56 should be in memory? Yeah, good question.) Independent of that, if a reg-reg move generated by LRA (which is really a mem->reg or reg->mem) blows up on this target for some reason, then that needs to be addressed independently of whether or not IRA might have made a bad choice for which pseudo to spill. Yes. It probably is because of the "volatile" I inserted for it to fail at all, anyway. Changing constraints ABWef to be define_memory_constraint (instead of define_constraint) makes this testcase pass. It also makes the build pass (it failed before; 90 reloads in libgcc). Pretty miserable code for those memory accesses, but hey, better than an ICE ;-) Makes sense if it wasn't defined as a memory constraint that LRA would be having trouble -- odds are reload would have barf'd at some point too. The only difference is I'm actually still better at understanding what reload's doing from its dumps than LRA. It's hard to throw away decades of retained knowledge earned the hard way. James, can you go ahead and make that change to ABWef and enable LRA and commit your changes to the trunk? Thanks, jeff
Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
On 05/14/2015 01:15 PM, Iain Buclaw wrote: Iant commited in the changes first time around. I don't have write after approval access in GCC just yet, probably should go about getting that sorted out if this is to become a regular thing. I dealt with copyright assignments back in September. Yea, let's get write access sorted out. I don't mind occasionally committing changes for random contributors, but you're around here enough that you should just have access. See authenticated access on this page: https://gcc.gnu.org/svnwrite.html List me as your sponsor :-) jeff
patch for PR65862
The following patch is for solution of PR65862 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 In some cases, calculations of reg class costs are not enough to choose the right class. For example, in some cases you don't want to start fp unit for energy saving considerations if you don't really need it. Such case can occur when we have non-floating point mode pseudo and calculation costs in ira says that it would be profitable to put it in a floating point register. The full solution will need to add a hook to mips.c. I hope mips maintainers will do that soon. The patch was bootstrapped on x86-64. Committed as rev. 223202. 2015-05-14 Vladimir Makarov PR rtl-optimization/65862 * target.def (ira_change_pseudo_allocno_class): New hook. * targhooks.c (default_ira_change_pseudo_allocno_class): Default value of the hook. * targhooks.h (default_ira_change_pseudo_allocno_class): New extern * doc/tm.texi.in (TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Add the hook. * ira-costs.c (find_costs_and_classes): Call the hook and change classes when it is necessary. * doc/tm.texi: Update.
Re: patch for PR65862
On 05/14/2015 04:42 PM, Vladimir Makarov wrote:
The following patch is for solution of PR65862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
In some cases, calculations of reg class costs are not enough to
choose the right class. For example, in some cases you don't want to
start fp unit for energy saving considerations if you don't really
need it. Such case can occur when we have non-floating point mode
pseudo and calculation costs in ira says that it would be profitable
to put it in a floating point register.
The full solution will need to add a hook to mips.c. I hope mips
maintainers will do that soon.
The patch was bootstrapped on x86-64.
Committed as rev. 223202.
2015-05-14 Vladimir Makarov
PR rtl-optimization/65862
* target.def (ira_change_pseudo_allocno_class): New hook.
* targhooks.c (default_ira_change_pseudo_allocno_class): Default
value of the hook.
* targhooks.h (default_ira_change_pseudo_allocno_class): New
extern
* doc/tm.texi.in (TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Add
the
hook.
* ira-costs.c (find_costs_and_classes): Call the hook and change
classes when it is necessary.
* doc/tm.texi: Update.
Sorry, I missed to attach the patch. Here it is.
Index: doc/tm.texi
===
--- doc/tm.texi (revision 223198)
+++ doc/tm.texi (working copy)
@@ -2837,6 +2837,13 @@ as below:
@end smallexample
@end defmac
+@deftypefn {Target Hook} reg_class_t TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS (int, @var{reg_class_t})
+A target hook which can change allocno class for given pseudo from
+ allocno class calculated by IRA.
+
+ The default version of this target hook always returns given class.
+@end deftypefn
+
@deftypefn {Target Hook} bool TARGET_LRA_P (void)
A target hook which returns true if we use LRA instead of reload pass. It means that LRA was ported to the target.The default version of this target hook returns always false.
@end deftypefn
Index: doc/tm.texi.in
===
--- doc/tm.texi.in (revision 223198)
+++ doc/tm.texi.in (working copy)
@@ -2475,6 +2475,8 @@ as below:
@end smallexample
@end defmac
+@hook TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
+
@hook TARGET_LRA_P
@hook TARGET_REGISTER_PRIORITY
Index: ira-costs.c
===
--- ira-costs.c (revision 223198)
+++ ira-costs.c (working copy)
@@ -1636,7 +1636,7 @@ find_costs_and_classes (FILE *dump_file)
int i, k, start, max_cost_classes_num;
int pass;
basic_block bb;
- enum reg_class *regno_best_class;
+ enum reg_class *regno_best_class, new_class;
init_recog ();
regno_best_class
@@ -1878,6 +1878,18 @@ find_costs_and_classes (FILE *dump_file)
ira_assert (regno_aclass[i] != NO_REGS
&& ira_reg_allocno_class_p[regno_aclass[i]]);
}
+ if ((new_class
+ = (reg_class) (targetm.ira_change_pseudo_allocno_class
+ (i, regno_aclass[i]))) != regno_aclass[i])
+ {
+ regno_aclass[i] = new_class;
+ if (hard_reg_set_subset_p (reg_class_contents[new_class],
+ reg_class_contents[best]))
+ best = new_class;
+ if (hard_reg_set_subset_p (reg_class_contents[new_class],
+ reg_class_contents[alt_class]))
+ alt_class = new_class;
+ }
if (pass == flag_expensive_optimizations)
{
if (best_cost > i_mem_cost)
Index: target.def
===
--- target.def (revision 223198)
+++ target.def (working copy)
@@ -4763,6 +4763,16 @@ This is currently used only by the C and
tree, (tree type, tree expr),
hook_tree_tree_tree_null)
+/* Change pseudo allocno class calculated by IRA. */
+DEFHOOK
+(ira_change_pseudo_allocno_class,
+ "A target hook which can change allocno class for given pseudo from\n\
+ allocno class calculated by IRA.\n\
+ \n\
+ The default version of this target hook always returns given class.",
+ reg_class_t, (int, reg_class_t),
+ default_ira_change_pseudo_allocno_class)
+
/* Return true if we use LRA instead of reload. */
DEFHOOK
(lra_p,
Index: targhooks.c
===
--- targhooks.c (revision 223198)
+++ targhooks.c (working copy)
@@ -914,6 +914,13 @@ default_branch_target_register_class (vo
return NO_REGS;
}
+reg_class_t
+default_ira_change_pseudo_allocno_class (int regno ATTRIBUTE_UNUSED,
+ reg_class_t cl)
+{
+ return cl;
+}
+
extern bool
default_lra_p (void)
{
Index: targhooks.h
===
--- targhooks.h (revision 223198)
+++ targhooks.h (working copy)
@@ -140,6 +140,7 @@ extern rtx default_static_chain (const_t
extern void default_trampoline_init (rtx, tree, rtx);
extern int default_return_pops_args (tree, tree, int);
extern reg_class_t default_branch_
Re: C/C++ PATCH to allow deprecating enum values (PR c/47043)
On Thu, 14 May 2015, Marek Polacek wrote: > Ping. > Joseph, do you have any further comments on the patch? The C front-end changes are OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting
Jeff Law writes: > For all kinds of reassociation we have to concern ourselves with adding > overflow where it didn't already occur. Assuming a 32 bit architecture > we could get overflow if A is 0x7fff, b is -4 and and c = 3 > > 0x7fff + -4 = 0x7ffb > 0x7ffb + 3 = 0x7ffe > > > If you make the transformation you're suggesting we get > > 0x7fff + 3 = 0x8002 OVERFLOW > 0x8002 - 4 = 0x7ffe > > Now if you always know pointers are unsigned, then the overflow is > defined and you'd be OK. But that's a property of the target and one > that's not well modeled within GCC (we have POINTER_EXTEND_UNSIGNED > which kind of tells us something in this space). I see, understood, cool! Thanks for such detailed explanation. Above scenario do may happen for general pointer arith reassociation. One thing may make life easier as my reassociation is restricted within frame pointer. the "(plus (plus fp, index_reg) + const_off)" pattern was to address some variable on stack. index_reg, const_off were part of the stack offset of the variable. Reassociate them means reorder two parts of the stack offset. There may be way to prove the transformation will not add extra overflow risk, especially when the index_reg is unsigned. I understand for general pointer arith reassociation, there do have big risk, as the involved operands largely come from irrelevant instruction, no relationship between the values from those operands, we can deduce nothing. > > In addition to worrying about overflow, you have to worry about > segmented architectures with implicit segment selection -- especially if > the segment selection comes from the base register than the entire > effective address. > Hmm, understood! This let me recall something as dark as x86 segment descriptor in protecting mode... > > Sadly we don't expose this aspect of target characteristics at all. > > > To proceed, you'd probably need ways to conditionalize these > transformations. ie, target hooks. > > Jeff -- Regards, Jiong
[PING] Re: [PATCH] add self-tuning to x86 hardware fast path in libitm
Ping!
Could someone who can approve please review the patch?
Thanks,
-Andi
Nuno Diegues writes:
> Hello,
>
> I have taken the chance to improve the patch by addressing the
> comments above in this thread.
> Namely:
> - to use a simple random generator managed inside the library only
> - removed floating point usage and replaced by fixed arithmetic
> - added some comments where relevant
>
> Re-running the STAMP benchmarks shows similar gains (to those shown
> above) with respect to an unmodified GCC 5.0.0:
>
> benchmark: speedup
> genome: 1.58
> intruder: 1.78
> labyrinth: 1.0
> ssca2: 1.01
> yada: 1.0
> kmeans-high: 1.16
> kmeans-low: 1.16
> vacation-high: 2.05
> vacation-low: 2.81
>
> I appreciate any feedback and comments!
>
> Index: libitm/libitm_i.h
> ===
> --- libitm/libitm_i.h (revision 219316)
> +++ libitm/libitm_i.h (working copy)
> @@ -242,6 +242,9 @@ struct gtm_thread
>uint32_t restart_reason[NUM_RESTARTS];
>uint32_t restart_total;
>
> + // Keeps track of how many transactions were successfully executed.
> + uint64_t number_executed_txns;
> +
>// *** The shared part of gtm_thread starts here. ***
>// Shared state is on separate cachelines to avoid false sharing with
>// thread-local parts of gtm_thread.
> @@ -286,6 +289,8 @@ struct gtm_thread
>static void *operator new(size_t);
>static void operator delete(void *);
>
> + static void reoptimize_htm_execution();
> +
>// Invoked from assembly language, thus the "asm" specifier on
>// the name, avoiding complex name mangling.
>static uint32_t begin_transaction(uint32_t, const gtm_jmpbuf *)
> @@ -309,6 +314,59 @@ struct gtm_thread
>void commit_user_actions ();
> };
>
> +// Different ways to deal with capacity aborts in HTM execution.
> +enum gtm_capacity_abort_mode
> +{
> + STUBBORN,
> + HALVEN,
> + GIVEUP
> +};
> +
> +// Definition of fixed point arithmetic types.
> +// Half the bits are dedicated to the fractional type, and the rest to the
> +// "whole" part.
> +#define FIXED_PT_WIDTH 64
> +#define FIXED_PT_INTEGER_WIDTH 32
> +typedef uint64_t fixed_pt_t;
> +typedef __uint128_t fixed_pt_td;
> +
> +#define FIXED_PT_FRAC_WIDTH (FIXED_PT_WIDTH - FIXED_PT_INTEGER_WIDTH)
> +#define FIXED_PT_ONE((fixed_pt_t)((fixed_pt_t)1 << FIXED_PT_FRAC_WIDTH))
> +#define FIXED_PT_TWO(FIXED_PT_ONE + FIXED_PT_ONE)
> +
> +#define fixed_mul(A,B) \
> + ((fixed_pt_t)(((fixed_pt_td)(A) * (fixed_pt_td)(B)) >>
> FIXED_PT_FRAC_WIDTH))
> +#define fixed_div(A,B) \
> + ((fixed_pt_t)(((fixed_pt_td)(A) << FIXED_PT_FRAC_WIDTH) /
> (fixed_pt_td)(B)))
> +#define fixed_const(R) \
> + ((fixed_pt_t)((R) * FIXED_PT_ONE + ((R) >= 0 ? 0.5 : -0.5)))
> +
> +// Maintains the current values optimized for HTM execution and the
> +// corresponding statistics gathered for the decision-making.
> +struct gtm_global_optimizer
> +{
> + // Mode chosen to currently deal with capacity aborts.
> + gtm_capacity_abort_mode optimized_mode;
> + // Number of attempts chosen to currently insist on HTM execution.
> + uint32_t optimized_attempts;
> +
> + uint64_t last_cycles;
> + uint64_t last_total_txs_executed;
> +
> + fixed_pt_t last_throughput;
> + uint32_t last_attempts;
> +
> + fixed_pt_t best_ever_throughput;
> + uint32_t best_ever_attempts;
> +
> + uint64_t txns_while_stubborn;
> + uint64_t cycles_while_stubborn;
> + uint64_t txns_while_halven;
> + uint64_t cycles_while_halven;
> + uint64_t txns_while_giveup;
> + uint64_t cycles_while_giveup;
> +};
> +
> } // namespace GTM
>
> #include "tls.h"
> @@ -346,6 +404,9 @@ extern gtm_cacheline_mask gtm_mask_stack(gtm_cache
> // the name, avoiding complex name mangling.
> extern uint32_t htm_fastpath __asm__(UPFX "gtm_htm_fastpath");
>
> +// Maintains the optimization for HTM execution.
> +extern gtm_global_optimizer optimizer;
> +
> } // namespace GTM
>
> #endif // LIBITM_I_H
> Index: libitm/libitm.h
> ===
> --- libitm/libitm.h (revision 219316)
> +++ libitm/libitm.h (working copy)
> @@ -101,7 +101,8 @@ typedef enum
> /* These are not part of the ABI but used for custom HTM fast paths. See
>ITM_beginTransaction and gtm_thread::begin_transaction. */
> pr_HTMRetryableAbort = 0x80,
> - pr_HTMRetriedAfterAbort = 0x100
> + pr_HTMRetriedAfterAbort = 0x100,
> + pr_HTMCapacityAbort = 0x200
> } _ITM_codeProperties;
>
> /* Result from startTransaction that describes what actions to take.
> Index: libitm/method-serial.cc
> ===
> --- libitm/method-serial.cc (revision 219316)
> +++ libitm/method-serial.cc (working copy)
> @@ -223,7 +223,23 @@ struct htm_mg : public method_group
> // initially disabled.
> #ifdef USE_HTM_FASTPATH
> htm_fastpath = htm_init();
> +#ifdef HAVE_AS_RTM
> +optimizer.optimized_mode = STUBBORN;
> +o
Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting
On 05/14/2015 03:13 PM, Jiong Wang wrote: Jeff Law writes: For all kinds of reassociation we have to concern ourselves with adding overflow where it didn't already occur. Assuming a 32 bit architecture we could get overflow if A is 0x7fff, b is -4 and and c = 3 0x7fff + -4 = 0x7ffb 0x7ffb + 3 = 0x7ffe If you make the transformation you're suggesting we get 0x7fff + 3 = 0x8002 OVERFLOW 0x8002 - 4 = 0x7ffe Now if you always know pointers are unsigned, then the overflow is defined and you'd be OK. But that's a property of the target and one that's not well modeled within GCC (we have POINTER_EXTEND_UNSIGNED which kind of tells us something in this space). I see, understood, cool! Thanks for such detailed explanation. Above scenario do may happen for general pointer arith reassociation. One thing may make life easier as my reassociation is restricted within frame pointer. the "(plus (plus fp, index_reg) + const_off)" pattern was to address some variable on stack. index_reg, const_off were part of the stack offset of the variable. Reassociate them means reorder two parts of the stack offset. There may be way to prove the transformation will not add extra overflow risk, especially when the index_reg is unsigned. I understand for general pointer arith reassociation, there do have big risk, as the involved operands largely come from irrelevant instruction, no relationship between the values from those operands, we can deduce nothing. Given the special status of SP, FP and ARGP and a known constant part, we can probably do something here. More below... In addition to worrying about overflow, you have to worry about segmented architectures with implicit segment selection -- especially if the segment selection comes from the base register than the entire effective address. Hmm, understood! This let me recall something as dark as x86 segment descriptor in protecting mode... Possibly, I've actually never studied the segmented aspects of the x86. But I'm painfully familiar with the others mentioned :( My recollection for the segmented stuff on the PA is we only had a single guard page at both ends of the segment. So we only allowed an offset of +-4k when doing address reassociations in legitimize_address. This was possible because we had callouts from the right places in the RTL generators/optimizers to allow targets to rewrite address arithmetic. So we could naturally bury the target details away from the code generator/optimizers. So we could possibly parameterize the transformation around similar concepts. The design issue here is it's introducing more target dependencies in places where we've really wanted to avoid them. In theory the gimple optimizers are supposed to be target independent. Reality is some stuff bleeds into them (the one that's mentioned the most often is branch costing, but there's others). *If* we decide to go forward with using some target hooks here. I'd be tempted to do 2. One that's effective a tri-state. Full reassociation, limited reassociation, no reassociation. The second would bound the constants in the limited reassociation case. Thoughts? Jeff
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
On Thu, 2015-05-14 at 19:22 +0200, Marek Polacek wrote: > On Thu, May 14, 2015 at 10:07:56AM -0700, Steve Ellcey wrote: > > Sorry for the noise, it looks like this failure is not related to any > > recent changes in GCC. I still get the error in older GCC's so I think > > something must have changed in glibc. I will start digging there. > > Yeah -- strict aliasing should be unrelated to the changes I've recently done > in the C FE. > > Marek FYI: I finally found the change that caused this failure, it is a GCC patch after all. It starts with Richard's fix to PR middle-end/66110. I sent some email to glibc but I am not sure (again) if we want to change GCC or glibc. https://sourceware.org/ml/libc-alpha/2015-05/msg00258.html Steve Ellcey sell...@imgtec.com
[patch,gomp4] acc exit data bug fix
This patch addresses the libgomp testsuite failure in
libgomp.oacc-fortran/data-2.f90 on nvidia targets. There are a couple of
things going on in here. The major underlying problem involved how
gomp_acc_remove_pointer was clearing target_mem_desc.to_free and
.tgt_end. That caused both a memory leak (.to_free) and memory
corruption (.tgt_end). This memory corruption could be triggered by an
'acc enter data pcreate' followed by an 'acc exit data copyout'.
In the process of fixing this bug, I noticed that GOACC_enter_exit_data
wasn't handling pointer mappings properly. So in the process of fixing
the memory corruption bug, I fixed that issue too.
I've applied this patch to gomp-4_0-branch.
Cesar
2015-05-14 Cesar Philippidis
libgomp/
* oacc-mem.c (gomp_acc_remove_pointer): Fix a memory leak preventing
target_mem_desc.to_free from being deallocated with acc exit data.
* oacc-parallel.c (find_pset): Remove.
(find_pointer): New function.
(GOACC_enter_exit_data): Handle pointer maps with
gomp_acc_insert_pointer and gomp_acc_remove_pointer.
diff --git a/libgomp/oacc-mem.c b/libgomp/oacc-mem.c
index c9213af..7fcf199 100644
--- a/libgomp/oacc-mem.c
+++ b/libgomp/oacc-mem.c
@@ -668,10 +668,8 @@ gomp_acc_remove_pointer (void *h, bool force_copyfrom, int async, int mapnum)
if (t->refcount == minrefs)
{
/* This is the last reference, so pull the descriptor off the
- chain. This avoids gomp_unmap_vars via gomp_unmap_tgt from
+ chain. This pevents gomp_unmap_vars via gomp_unmap_tgt from
freeing the device memory. */
- t->tgt_end = 0;
- t->to_free = 0;
for (tp = NULL, t = acc_dev->openacc.data_environ; t != NULL;
tp = t, t = t->prev)
@@ -687,8 +685,7 @@ gomp_acc_remove_pointer (void *h, bool force_copyfrom, int async, int mapnum)
}
}
- if (force_copyfrom)
-t->list[0]->copy_from = 1;
+ t->list[0]->copy_from = force_copyfrom ? 1 : 0;
gomp_mutex_unlock (&acc_dev->lock);
diff --git a/libgomp/oacc-parallel.c b/libgomp/oacc-parallel.c
index 3174020..513d0bc 100644
--- a/libgomp/oacc-parallel.c
+++ b/libgomp/oacc-parallel.c
@@ -38,15 +38,23 @@
#include
#include
+/* Returns the number of mappings associated with the pointer or pset. PSET
+ have three mappings, whereas pointer have two. */
+
static int
-find_pset (int pos, size_t mapnum, unsigned short *kinds)
+find_pointer (int pos, size_t mapnum, unsigned short *kinds)
{
if (pos + 1 >= mapnum)
return 0;
unsigned char kind = kinds[pos+1] & 0xff;
- return kind == GOMP_MAP_TO_PSET;
+ if (kind == GOMP_MAP_TO_PSET)
+return 3;
+ else if (kind == GOMP_MAP_POINTER)
+return 2;
+
+ return 0;
}
static void *__goacc_host_ganglocal_ptr;
@@ -325,47 +333,39 @@ GOACC_enter_exit_data (int device, size_t mapnum,
kind);
}
+ /* In c, non-pointers and arrays are represented by a single data clause.
+ Dynamically allocated arrays and subarrays are represented by a data
+ clause followed by an internal GOMP_MAP_POINTER.
+
+ In fortran, scalars and not allocated arrays are represented by a
+ single data clause. Allocated arrays and subarrays have three mappings:
+ 1) the original data clause, 2) a PSET 3) a pointer to the array data.
+ */
+
if (data_enter)
{
for (i = 0; i < mapnum; i++)
{
unsigned char kind = kinds[i] & 0xff;
- /* Scan for PSETs. */
- int psets = find_pset (i, mapnum, kinds);
+ /* Scan for pointers and PSETs. */
+ int pointer = find_pointer (i, mapnum, kinds);
- if (!psets)
+ if (!pointer)
{
switch (kind)
{
- case GOMP_MAP_POINTER:
- gomp_acc_insert_pointer (1, &hostaddrs[i], &sizes[i],
- &kinds[i]);
+ case GOMP_MAP_ALLOC:
+ acc_present_or_create (hostaddrs[i], sizes[i]);
break;
case GOMP_MAP_FORCE_ALLOC:
- case GOMP_MAP_ALLOC:
- if ((i + 1) < mapnum &&
- kind == GOMP_MAP_ALLOC &&
- ((kinds[i + 1] & 0xff) == GOMP_MAP_POINTER) &&
- acc_is_present (hostaddrs[i], sizes[i]))
- i++;
- else if (kind == GOMP_MAP_ALLOC)
- acc_present_or_create (hostaddrs[i], sizes[i]);
- else
- acc_create (hostaddrs[i], sizes[i]);
+ acc_create (hostaddrs[i], sizes[i]);
break;
- case GOMP_MAP_FORCE_PRESENT:
- case GOMP_MAP_FORCE_TO:
case GOMP_MAP_TO:
- if ((i + 1) < mapnum &&
- kind == GOMP_MAP_TO &&
- ((kinds[i + 1] & 0xff) == GOMP_MAP_POINTER) &&
- acc_is_present (hostaddrs[i], sizes[i]))
- i++;
- else if (kind == GOMP_MAP_TO)
- acc_present_or_copyin (hostaddrs[i], sizes[i]);
- else
- acc_copyin (hostaddrs[i], sizes[i]);
+ acc_present_or_copyin (hostaddrs[i], sizes[i]);
+ break;
+ case GOMP_MAP_FORCE_TO:
+ acc_copyin (hostaddrs[i], sizes[i]);
break;
default:
gomp_fatal (" GOACC_enter_exit_data UNHANDLED kind 0x%.2x",
@@ -377,14 +377,14 @@ GOACC_enter_exit_data (int device, size_t mapnum,
{
if (!acc_is_present (hostaddrs[i], sizes[i]))
RE: [PATCH, FT32] initial support
> On 05/14/2015 01:24 PM, Segher Boessenkool wrote: > > On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote: > >> On 05/14/2015 11:36 AM, Segher Boessenkool wrote: > >>> The alternative that allows move to mem is alt 1, but it thinks the > >>> operand > >>> doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy. > >>> > >>> "B" should match it seems? > >>> > >>> (Why does IRA think r56 should be in memory? Yeah, good question.) > >> Independent of that, if a reg-reg move generated by LRA (which is really > >> a mem->reg or reg->mem) blows up on this target for some reason, then > >> that needs to be addressed independently of whether or not IRA might > >> have made a bad choice for which pseudo to spill. > > > > Yes. It probably is because of the "volatile" I inserted for it > > to fail at all, anyway. > > > > Changing constraints ABWef to be define_memory_constraint (instead of > > define_constraint) makes this testcase pass. It also makes the build > > pass (it failed before; 90 reloads in libgcc). > > > > Pretty miserable code for those memory accesses, but hey, better > > than an ICE ;-) > Makes sense if it wasn't defined as a memory constraint that LRA would > be having trouble -- odds are reload would have barf'd at some point too. > > The only difference is I'm actually still better at understanding what > reload's doing from its dumps than LRA. It's hard to throw away decades > of retained knowledge earned the hard way. > > James, can you go ahead and make that change to ABWef and enable LRA and > commit your changes to the trunk? OK, ABWef changes made, and fixed a couple of pattern holes that they exposed. Added a new target option "-mlra" to enable LRA. Updated invoking.texi. Please can someone commit this, if appropriate, as I do not have write access to the tree. Thanks very much. ChangeLog entry: 2015-05-14 James Bowman * configure.ac: FT32 target added * libgcc/config.host: FT32 target added * gcc/config/ft32/: FT32 target added * libgcc/config/ft32/: FT32 target added * gcc/doc/install.texi, invoke.texi, md.texi: FT32 details added * gcc/doc/contrib.texi: self added * contrib/config-list.mk: FT32 target added * configure: Regenerated -- James Bowman FTDI Open Source Liaison gcc-ft32.txt.gz Description: gcc-ft32.txt.gz
Last part of verify_type_vairant checks
Hi,
this patch adds checks of tree_base and type_common flags/fields. I also
refactored
code to use verify_type_variant_flag macro for better brevity and added a
comment
of what can differ between variants and why. Hope it will be useful :)
There seems to be 3 issues:
- C++ FE seems to build type variants that differ in TYPE_FINAL that is not
supposed
to happen. I will try to debug it tomorrow.
- Ada builds !TYPE_ARTIFICIAL variant of TYPE_ARTIFICIAL type.
Eric, I can not really make sense of this. Is this expected?
If we have artificial type, how it can become not?
- During Ada builds there are types that differ in TYPE_SIZES_GIMPLIFIED.
This is probably harmless but I am not sure it ishappen to happen.
Bootstrapped/regtested ppc64-linux, will commit it tomorrow if there are no
complains.
Honza
* tree.c (verify_type_variant): Verify tree_base and type_common flags.
(verify_type): Verify STRING_FLAG
Index: tree.c
===
--- tree.c (revision 223021)
+++ tree.c (working copy)
@@ -12474,6 +12474,7 @@ element_mode (const_tree t)
t = TREE_TYPE (t);
return TYPE_MODE (t);
}
+
/* Veirfy that basic properties of T match TV and thus T can be a variant of
TV. TV should be the more specified variant (i.e. the main variant). */
@@ -12481,85 +12482,129 @@ element_mode (const_tree t)
static bool
verify_type_variant (const_tree t, tree tv)
{
- if (TREE_CODE (t) != TREE_CODE (tv))
-{
- error ("type variant has different TREE_CODE");
- debug_tree (tv);
- return false;
-}
- if (COMPLETE_TYPE_P (t) && TYPE_SIZE (t) != TYPE_SIZE (tv))
-{
- error ("type variant has different TYPE_SIZE");
- debug_tree (tv);
- error ("type variant's TYPE_SIZE");
- debug_tree (TYPE_SIZE (tv));
- error ("type's TYPE_SIZE");
- debug_tree (TYPE_SIZE (t));
- return false;
-}
- if (COMPLETE_TYPE_P (t)
- && TYPE_SIZE_UNIT (t) != TYPE_SIZE_UNIT (tv)
- /* FIXME: ideally we should compare pointer equality, but java FE produce
-variants where size is INTEGER_CST of different type (int wrt
size_type)
-during libjava biuld. */
- && !operand_equal_p (TYPE_SIZE_UNIT (t), TYPE_SIZE_UNIT (tv), 0))
-{
- error ("type variant has different TYPE_SIZE_UNIT");
- debug_tree (tv);
- error ("type variant's TYPE_SIZE_UNIT");
- debug_tree (TYPE_SIZE_UNIT (tv));
- error ("type's TYPE_SIZE_UNIT");
- debug_tree (TYPE_SIZE_UNIT (t));
- return false;
+ /* Type variant can differ by:
+
+ - TYPE_QUALS: TYPE_READONLY, TYPE_VOLATILE, TYPE_ATOMIC, TYPE_RESTRICT,
+ ENCODE_QUAL_ADDR_SPACE.
+ - main variant may be TYPE_COMPLETE_P and variant types !TYPE_COMPLETE_P
+ in this case some values may not be set in the variant types
+ (see TYPE_COMPLETE_P checks).
+ - it is possible to have TYPE_ARTIFICIAL variant of non-artifical type
+ - by TYPE_NAME and attributes (i.e. when variant originate by typedef)
+ - TYPE_CANONICAL (TYPE_ALIAS_SET is the same among variants)
+ - by the alignment: TYPE_ALIGN and TYPE_USER_ALIGN
+ - during LTO by TYPE_CONTEXT if type is TYPE_FILE_SCOPE_P
+ this is necessary to make it possible to merge types form different TUs
+ - arrays, pointers and references may have TREE_TYPE that is a variant
+ of TREE_TYPE of their main variants.
+ - aggregates may have new TYPE_FIELDS list that list variants of
+ the main variant TYPE_FIELDS.
+ - vector types may differ by TYPE_VECTOR_OPAQUE
+ - TYPE_METHODS is always NULL for vairant types and maintained for
+ main variant only.
+ */
+
+ /* Convenience macro for matching individual fields. */
+#define verify_variant_match(flag) \
+ do { \
+if (flag (tv) != flag (t)) \
+ {
\
+ error ("type variant differs by " #flag "."); \
+ debug_tree (tv);\
+ return false; \
+ }
\
+ } while (false)
+
+ /* tree_base checks. */
+
+ verify_variant_match (TREE_CODE);
+ /* FIXME: Ada builds non-artificial variants of artificial types. */
+ if (TYPE_ARTIFICIAL (tv) && 0)
+verify_variant_match (TYPE_ARTIFICIAL);
+ if (POINTER_TYPE_P (tv))
+verify_variant_match (TYPE_REF_CAN_ALIAS_ALL);
+ /* FIXME: TYPE_SIZES_GIMPLIFIED may differs for Ada build. */
+ verify_variant_match (TYPE_UNSIGNED);
+ verify_variant_match (TYPE_ALIGN_OK);
+ verify_variant_match (TYPE_PACKED);
+ if (TREE_CODE (t) == REFERENCE_TYPE
[patch, fortran] fix for PR 60780, PR 40958
Patch below prevents printing of duplicate statements in module files.
Without it module files grow exponentially in size with nested use of
modules that contain equivalence statements. Tested on x86-64-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
2015-05-14
PR fortran 60780
* module.c (load_equiv) : add check for duplicate modules
Index: module.c
===
--- module.c(revision 223202)
+++ module.c(working copy)
@@ -4479,8 +4479,8 @@
static void
load_equiv (void)
{
- gfc_equiv *head, *tail, *end, *eq;
- bool unused;
+ gfc_equiv *head, *tail, *end, *eq, *equiv;
+ bool unused, duplicate;
mio_lparen ();
in_load_equiv = true;
@@ -4523,8 +4523,20 @@
}
}
-if (unused)
+/* Check for duplicate equivalences being loaded from different
modules */
+duplicate = false;
+for (equiv = gfc_current_ns->equiv; equiv; equiv = equiv->next)
{
+if (equiv->module && head->module
+ && strcmp (equiv->module, head->module) == 0)
+ {
+duplicate = true;
+break;
+ }
+ }
+
+if (unused || duplicate)
+ {
for (eq = head; eq; eq = head)
{
head = eq->eq;
Re: [patch, fortran] fix for PR 60780, PR 40958
On Thu, May 14, 2015 at 08:53:11PM -0700, Russell Whitesides wrote: > Patch below prevents printing of duplicate statements in module files. > Without it module files grow exponentially in size with nested use of > modules that contain equivalence statements. Tested on x86-64-linux. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 > Sorry, but I don't recognize your name. Do you have a copyright assignment on file with FSF? -- Steve
Re: [patch, fortran] fix for PR 60780, PR 40958
On 05/14/2015 09:36 PM, Steve Kargl wrote: On Thu, May 14, 2015 at 08:53:11PM -0700, Russell Whitesides wrote: Patch below prevents printing of duplicate statements in module files. Without it module files grow exponentially in size with nested use of modules that contain equivalence statements. Tested on x86-64-linux. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Sorry, but I don't recognize your name. Do you have a copyright assignment on file with FSF? I do not.
Re: [patch, fortran] fix for PR 60780, PR 40958
On Thu, May 14, 2015 at 09:39:03PM -0700, Russell Whitesides wrote: > > On 05/14/2015 09:36 PM, Steve Kargl wrote: > > On Thu, May 14, 2015 at 08:53:11PM -0700, Russell Whitesides wrote: > >> Patch below prevents printing of duplicate statements in module files. > >> Without it module files grow exponentially in size with nested use of > >> modules that contain equivalence statements. Tested on x86-64-linux. > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 > >> > > > > Sorry, but I don't recognize your name. Do you > > have a copyright assignment on file with FSF? > > > > I do not. The change may be small enough that an assignment isn't needed. We (ie, the gfortran developers) will need to check. Having an assignment will help when you submit additional patches. :-) -- Steve
Re: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual alignment value to output_constant_pool_2
On 05/05/2015 01:59 AM, rohitarul...@freescale.com wrote: Jeff, the issue is still reproducible with GCC v4.8 branch but not with GCC v4.9 or trunk. Was it fixed by some other approach or has the bug gone latent? Obviously if the former, then the patch is only relevant to gcc-4.8 if the latter, then we'll still want to get it fixed on the trunk and possibly in the release branches. Can you please investigate if the bug has been fixed by other means or if it's just gone latent on the trunk? Jeff, Just to summarize: By default in GCC v4.7.x, all the constants are put into '.rodata.str1.4' section. In GCC v4.8.x from r192719 onwards, one of the move instruction of the string constant ".LC0" is getting spilled. The reload pass, for any constants that aren't allowed and can't be reloaded in to registers tries to change them into memory references. Then while emitting that string constant to asm code (A:varasm.c: output_constant_pool_1), it explicitly passes the alignment as 1 which prevents the generation of fix-up table entries in 'B: rs6000.c:rs6000_assemble_integer' because the data is considered unaligned now. The bug seems to have gone latent with an unrelated trunk commit r204695 [* tree-ssa-loop-ivopts.c (force_expr_to_var_cost): Refactor the code. Handle type conversion.]. This commit chooses different spill candidates hence all the string constants are being put in to '.rodata.str1.4´section. The check I had in the test case is that if there is a '.data.rel.ro.local', then there should be '.fixup' section generated. Please let me know if you need any other details. Thanks. Even though I wasn't able to trigger the bug with the testcase from 65018, I went ahead and committed this patch to the trunk. It can't hurt and it's the right thing to do. Thanks for your patience, Jeff
Re: [PATCH, FT32] initial support
On 05/14/2015 06:43 PM, James Bowman wrote: On 05/14/2015 01:24 PM, Segher Boessenkool wrote: On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote: On 05/14/2015 11:36 AM, Segher Boessenkool wrote: The alternative that allows move to mem is alt 1, but it thinks the operand doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy. "B" should match it seems? (Why does IRA think r56 should be in memory? Yeah, good question.) Independent of that, if a reg-reg move generated by LRA (which is really a mem->reg or reg->mem) blows up on this target for some reason, then that needs to be addressed independently of whether or not IRA might have made a bad choice for which pseudo to spill. Yes. It probably is because of the "volatile" I inserted for it to fail at all, anyway. Changing constraints ABWef to be define_memory_constraint (instead of define_constraint) makes this testcase pass. It also makes the build pass (it failed before; 90 reloads in libgcc). Pretty miserable code for those memory accesses, but hey, better than an ICE ;-) Makes sense if it wasn't defined as a memory constraint that LRA would be having trouble -- odds are reload would have barf'd at some point too. The only difference is I'm actually still better at understanding what reload's doing from its dumps than LRA. It's hard to throw away decades of retained knowledge earned the hard way. James, can you go ahead and make that change to ABWef and enable LRA and commit your changes to the trunk? OK, ABWef changes made, and fixed a couple of pattern holes that they exposed. Added a new target option "-mlra" to enable LRA. Updated invoking.texi. Please can someone commit this, if appropriate, as I do not have write access to the tree. Thanks very much. ChangeLog entry: 2015-05-14 James Bowman * configure.ac: FT32 target added * libgcc/config.host: FT32 target added * gcc/config/ft32/: FT32 target added * libgcc/config/ft32/: FT32 target added * gcc/doc/install.texi, invoke.texi, md.texi: FT32 details added * gcc/doc/contrib.texi: self added * contrib/config-list.mk: FT32 target added * configure: Regenerated Well, the plan will be for you to maintain the port. So you should go ahead and get write access so that you can commit changes to the port. See authenticated access on this page https://gcc.gnu.org/svnwrite.html List me as your sponsor Thanks for your patience, Jeff
[ARM] fix arm bootstrap
Hi Richard, r223090 seem to miss a parenthesis and seem to be causing: from ../../widen/gcc/fold-const.c:46: ../../widen/gcc/fold-const.c: In function 'tree_node* fold_range_test(location_t, tree_code, tree, tree, tree)': ../../widen/gcc/config/arm/arm.h:2068:4: error: enumeral and non-enumeral type in conditional expression [-Werror=extra] ? (TARGET_THUMB ? false : true) \ ^ ../../widen/gcc/fold-const.c:5234:12: note: in expansion of macro 'LOGICAL_OP_NON_SHORT_CIRCUIT' else if (LOGICAL_OP_NON_SHORT_CIRCUIT ^ ../../widen/gcc/fold-const.c: In function 'tree_node* fold_truth_andor(location_t, tree_code, tree, tree, tree, tree, tree)': ../../widen/gcc/config/arm/arm.h:2068:4: error: enumeral and non-enumeral type in conditional expression [-Werror=extra] ? (TARGET_THUMB ? false : true) \ ^ ../../widen/gcc/fold-const.c:8431:7: note: in expansion of macro 'LOGICAL_OP_NON_SHORT_CIRCUIT' if (LOGICAL_OP_NON_SHORT_CIRCUIT Regression testing for arm-none-linux-gnueab is ongoing. Is this OK for trunk if no regression? Thanks, Kugan gcc/ChangeLog: 2015-05-15 Kugan Vivekanandarajah * config/arm/arm.h (enum arm_auto_incmodes): Add parenthesis. diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index 8574388..6968a3d 100644 --- a/gcc/config/arm/arm.h +++ b/gcc/config/arm/arm.h @@ -2060,8 +2060,8 @@ enum arm_auto_incmodes #define LOGICAL_OP_NON_SHORT_CIRCUIT \ ((optimize_size) \ ? (TARGET_THUMB ? false : true) \ - : TARGET_THUMB ? current_tune->logical_op_non_short_circuit_thumb \ - : current_tune->logical_op_non_short_circuit_arm) + : (TARGET_THUMB ? current_tune->logical_op_non_short_circuit_thumb \ + : current_tune->logical_op_non_short_circuit_arm)) /* Position Independent Code. */
[PATCH] Handle OS X deployment targets correctly
As described in PR target/63810, this addresses several problems with
the validation and encoding of deployment target version strings for the
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro. There are
currently four testcases exercising inputs to -mmacosx-version-min
(gcc/testsuite/gcc.dg/darwin-minversion-*), but they provide minimal
coverage, and one is incorrect.
* The tiny number is now respected, if present. Thus "10.9.4"
correctly becomes "1094" instead of "1090", and "10.10.1" becomes
"101001" instead of "101000".
* Zero padding is now ignored. Thus "10.09" correctly becomes "1090"
instead of "100900", and "10.00010" becomes "101000" instead of being
treated as invalid.
* Deployment targets that are missing minor and tiny numbers are no
longer considered invalid. Thus "10" is treated as "10.0.0", which
becomes "1000" without causing an error.
With this change, trunk matches the behavior of Apple LLVM Compiler
6.1.0 on 8,451 of 8,464 generated test inputs. (The discrepancies are
due to a bug in Clang.) I don't notice any testsuite regressions on
OS X 10.10 Yosemite x86-64.
2015-05-15 Lawrence Velázquez
PR target/63810
* gcc/config/darwin-c.c (version_components): New global enum.
(parse_version, version_as_legacy_macro)
(version_as_modern_macro, macosx_version_as_macro): New functions.
(version_as_macro): Remove.
(darwin_cpp_builtins): Use new function.
* gcc/testsuite/gcc.dg/darwin-minversion-3.c: Update testcase.
* gcc/testsuite/gcc.dg/darwin-minversion-4.c: Ditto.
* gcc/testsuite/gcc.dg/darwin-minversion-5.c: New testcase.
* gcc/testsuite/gcc.dg/darwin-minversion-6.c: Ditto.
* gcc/testsuite/gcc.dg/darwin-minversion-7.c: Ditto.
* gcc/testsuite/gcc.dg/darwin-minversion-8.c: Ditto.
* gcc/testsuite/gcc.dg/darwin-minversion-9.c: Ditto.
* gcc/testsuite/gcc.dg/darwin-minversion-10.c: Ditto.
* gcc/testsuite/gcc.dg/darwin-minversion-11.c: Ditto.
* gcc/testsuite/gcc.dg/darwin-minversion-12.c: Ditto.
---
Please Cc me in any replies, as I'm not subscribed to the list.
gcc/config/darwin-c.c | 190
gcc/testsuite/gcc.dg/darwin-minversion-10.c | 16 +++
gcc/testsuite/gcc.dg/darwin-minversion-11.c | 16 +++
gcc/testsuite/gcc.dg/darwin-minversion-12.c | 16 +++
gcc/testsuite/gcc.dg/darwin-minversion-3.c | 6 +-
gcc/testsuite/gcc.dg/darwin-minversion-4.c | 6 +-
gcc/testsuite/gcc.dg/darwin-minversion-5.c | 16 +++
gcc/testsuite/gcc.dg/darwin-minversion-6.c | 15 +++
gcc/testsuite/gcc.dg/darwin-minversion-7.c | 15 +++
gcc/testsuite/gcc.dg/darwin-minversion-8.c | 16 +++
gcc/testsuite/gcc.dg/darwin-minversion-9.c | 15 +++
11 files changed, 295 insertions(+), 32 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/darwin-minversion-10.c
create mode 100644 gcc/testsuite/gcc.dg/darwin-minversion-11.c
create mode 100644 gcc/testsuite/gcc.dg/darwin-minversion-12.c
create mode 100644 gcc/testsuite/gcc.dg/darwin-minversion-5.c
create mode 100644 gcc/testsuite/gcc.dg/darwin-minversion-6.c
create mode 100644 gcc/testsuite/gcc.dg/darwin-minversion-7.c
create mode 100644 gcc/testsuite/gcc.dg/darwin-minversion-8.c
create mode 100644 gcc/testsuite/gcc.dg/darwin-minversion-9.c
diff --git a/gcc/config/darwin-c.c b/gcc/config/darwin-c.c
index 3803e75..cf38416 100644
--- a/gcc/config/darwin-c.c
+++ b/gcc/config/darwin-c.c
@@ -599,42 +599,180 @@ find_subframework_header (cpp_reader *pfile, const char
*header, cpp_dir **dirp)
return 0;
}
-/* Return the value of darwin_macosx_version_min suitable for the
- __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro, so '10.4.2'
- becomes 1040 and '10.10.0' becomes 101000. The lowest digit is
- always zero, as is the second lowest for '10.10.x' and above.
- Print a warning if the version number can't be understood. */
+/* Given an OS X version VERSION_STR, return it as a statically-allocated array
+ of three integers. If VERSION_STR is invalid, return NULL.
+
+ VERSION_STR must consist of one, two, or three tokens, each separated by
+ a single period. Each token must contain only the characters '0' through
+ '9' and is converted to an equivalent non-negative decimal integer. Omitted
+ tokens become zeros. For example:
+
+"10" becomes {10,0,0}
+"10.10" becomes {10,10,0}
+"10.10.1" becomes {10,10,1}
+"10.10.1" becomes {10,10,1}
+"10.010.001" becomes {10,10,1}
+"10.10.1" becomes {10,10,1}
+".9.1"is invalid
+"10..9" is invalid
+"10.10." is invalid */
+
+enum version_components { MAJOR, MINOR, TINY };
+
+static const unsigned long *
+parse_version (const char *version_str)
+{
+ size_t version_len;
+ char *end;
+ static unsigned long version_arra
Re: [ARM] fix arm bootstrap
Sorry, this is not the right fix. Looking at it. Thanks, Kugan On 15/05/15 16:41, Kugan wrote: > Hi Richard, > > r223090 seem to miss a parenthesis and seem to be causing: > > from ../../widen/gcc/fold-const.c:46: > ../../widen/gcc/fold-const.c: In function 'tree_node* > fold_range_test(location_t, tree_code, tree, tree, tree)': > ../../widen/gcc/config/arm/arm.h:2068:4: error: enumeral and > non-enumeral type in conditional expression [-Werror=extra] > ? (TARGET_THUMB ? false : true) \ > ^ > ../../widen/gcc/fold-const.c:5234:12: note: in expansion of macro > 'LOGICAL_OP_NON_SHORT_CIRCUIT' >else if (LOGICAL_OP_NON_SHORT_CIRCUIT > ^ > ../../widen/gcc/fold-const.c: In function 'tree_node* > fold_truth_andor(location_t, tree_code, tree, tree, tree, tree, tree)': > ../../widen/gcc/config/arm/arm.h:2068:4: error: enumeral and > non-enumeral type in conditional expression [-Werror=extra] > ? (TARGET_THUMB ? false : true) \ > ^ > ../../widen/gcc/fold-const.c:8431:7: note: in expansion of macro > 'LOGICAL_OP_NON_SHORT_CIRCUIT' >if (LOGICAL_OP_NON_SHORT_CIRCUIT > > > Regression testing for arm-none-linux-gnueab is ongoing. > Is this OK for trunk if no regression? > > Thanks, > Kugan > > gcc/ChangeLog: > > 2015-05-15 Kugan Vivekanandarajah > > * config/arm/arm.h (enum arm_auto_incmodes): Add parenthesis. >
