[PATCH] [PR82155] Fix crash in dwarf2out_abstract_function
Hello, This patch is an attempt to fix the crash reported in PR82155. When generating a C++ class method for a class that is itself nested in a class method, dwarf2out_early_global_decl currently leaves the existing context DIE as it is if it already exists. However, it is possible that this call happens at a point where this context DIE is just a declaration that is itself not located in its own context. >From there, if dwarf2out_early_global_decl is not called on any of the FUNCTION_DECL in the context chain, DIEs will be left badly scoped and some (such as the nested method) will be removed by the type pruning machinery. As a consequence, dwarf2out_abstract_function will will crash when called on the corresponding DECL because it asserts that the DECL has a DIE. This patch fixes this crash making dwarf2out_early_global_decl process context DIEs the same way we process abstract origins for FUNCTION_DECL: if the corresponding DIE exists but is only a declaration, call dwarf2out_decl anyway on it so that it is turned into a more complete DIE and so that it is relocated in the proper context. Bootstrapped and regtested on x86_64-linux. The crash this addresses is present both on trunk and on the gcc-7 branch: I suggest we commit this patch on both branches. Ok to commit? Thank you in advance! gcc/ PR debug/82155 * dwarf2out.c (dwarf2out_early_global_decl): Call dwarf2out_decl on the FUNCTION_DECL function context if it has a DIE that is a declaration. gcc/testsuite/ * g++.dg/pr82155.C: New testcase. --- gcc/dwarf2out.c| 10 -- gcc/testsuite/g++.dg/pr82155.C | 36 2 files changed, 44 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/g++.dg/pr82155.C diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index 00d6d951ba3..4cfc9c186af 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -25500,10 +25500,16 @@ dwarf2out_early_global_decl (tree decl) so that all nested DIEs are generated at the proper scope in the first shot. */ tree context = decl_function_context (decl); - if (context != NULL && lookup_decl_die (context) == NULL) + if (context != NULL) { + dw_die_ref context_die = lookup_decl_die (context); current_function_decl = context; - dwarf2out_decl (context); + + /* Avoid emitting DIEs multiple times, but still process CONTEXT +enough so that it lands in its own context. This avoids type +pruning issues later on. */ + if (context_die == NULL || is_declaration_die (context_die)) + dwarf2out_decl (context); } /* Emit an abstract origin of a function first. This happens diff --git a/gcc/testsuite/g++.dg/pr82155.C b/gcc/testsuite/g++.dg/pr82155.C new file mode 100644 index 000..75d9b615f39 --- /dev/null +++ b/gcc/testsuite/g++.dg/pr82155.C @@ -0,0 +1,36 @@ +/* { dg-do compile { target c++11 } } */ +/* { dg-options "-g -O2" } */ + +template struct b { a c; }; +template struct e { d *operator->(); }; +template class h { +public: + typedef e ag; +}; +class i { +protected: + i(int); +}; +class j { + virtual void k(int) = 0; + +public: + int f; + void l() { k(f); } +}; +struct m : i { + int cn; + m() : i(cn) { +struct n : j { + n() {} + void k(int) {} +}; + } +}; +struct o { + o() { +for (h>>::ag g;;) + g->c.c->l(); + } +}; +void fn1() { o(); } -- 2.14.1
Re: confirm subscribe to gcc-patches@gcc.gnu.org
-- Shane On Tue, Sep 12, 2017, at 09:56 AM, gcc-patches-h...@gcc.gnu.org wrote: > Hi! This is the ezmlm program. I'm managing the > gcc-patches@gcc.gnu.org mailing list. > > To confirm that you would like > >general+...@matley.com.au > > added to the gcc-patches mailing list, please send > an empty reply to this address: > > > gcc-patches-sc.1505174215.ncimaapkeeadlpneppim-general+gcc=matley.com...@gcc.gnu.org > > Usually, this happens when you just hit the "reply" button. > If this does not work, simply copy the address and paste it into > the "To:" field of a new message. > > This confirmation serves two purposes. First, it verifies that I am able > to get mail through to you. Second, it protects you in case someone > forges a subscription request in your name. > > Some mail programs are broken and cannot handle long addresses. If you > cannot reply to this request, instead send a message to > and put the > entire address listed above into the "Subject:" line. > > > --- Administrative commands for the gcc-patches list --- > > I can handle administrative requests automatically. Please > do not send them to the list address! Instead, send > your message to the correct command address: > > To subscribe to the list, send a message to: > > > To remove your address from the list, send a message to: > > > Send mail to the following for info and FAQ for this list: > > > > Similar addresses exist for the digest list: > > > > To get messages 123 through 145 (a maximum of 100 per request), mail: > > > To get an index with subject and author for messages 123-456 , mail: > > > They are always returned as sets of 100, max 2000 per request, > so you'll actually get 100-499. > > To receive all messages with the same subject as message 12345, > send an empty message to: > > > The messages do not really need to be empty, but I will ignore > their content. Only the ADDRESS you send to is important. > > You can start a subscription for an alternate address, > for example "john@host.domain", just add a hyphen and your > address (with '=' instead of '@') after the command word: > > > To stop subscription for this address, mail: > > > In both cases, I'll send a confirmation message to that address. When > you receive it, simply reply to it to complete your subscription. > > If despite following these instructions, you do not get the > desired results, please contact my owner at > gcc-patches-ow...@gcc.gnu.org. Please be patient, my owner is a > lot slower than I am ;-) > > --- Enclosed is a copy of the request I received. > > Return-Path: > Received: (qmail 50909 invoked by uid 48); 11 Sep 2017 23:56:54 - > Message-ID: <20170911235654.50905.qm...@sourceware.org> > From: anonym...@sourceware.org > Date: Tue, 12 Sep 2017 05:26:54 +0530 > To: gcc-patches-subscribe-general+gcc=matley.com...@sourceware.org > User-Agent: Heirloom mailx 12.4 7/29/08 > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > >
Re: backwards threader cleanups
On 09/02/2017 11:43 AM, Aldy Hernandez wrote: > On Fri, Sep 1, 2017 at 6:11 PM, Jeff Law wrote: >> On 09/01/2017 02:18 PM, Aldy Hernandez wrote: >>> Hi. >>> >>> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends. >>> The main gist of the patch is making the path vectors live in the >>> heap, not GC. But I also cleaned up some comments to reflect reality, >>> and renamed VAR_BB which could use a more meaningful name. Finally, I >>> abstracted some common code to >>> register_jump_thread_path_if_profitable() in preparation for some >>> upcoming work by me :). >>> >>> Tested on x86-64 Linux. >> It looks like you dropped a level of indirection for path in >> profitable_jump_thread_path and perhaps others that push blocks onto the >> path? Does your change from having the vectors in the GC space to the >> heap also change them from embeddable vectors to a space efficient >> vector? It has to for this change to be safe. > > Part of my initial motivation was eliminating the double indirection > as well as removing the out-of-line calls to vec_alloc() and > vec_whatever_push(). > > And yes, the default plain vector<> uses the heap: > > template typename A = va_heap, > typename L = typename A::default_layout> > struct GTY((user)) vec > { > }; > > ...and va_heap defaults to the space efficient vector: > > struct va_heap > { > typedef vl_ptr default_layout; > ... > } > >> >> See the discussion in vec.h >> >> I don't recall any inherent reason we use the embedded vector layout. >> It's the default which is probably why it's used here more than anything. > > Just a wild guess, but this may be why: > >FIXME - Ideally, they would all be vl_ptr to encourage using regular >instances for vectors, but the existing GTY machinery is limited >in that it can only deal with GC objects that are pointers >themselves. > > and: > > /* Use vl_embed as the default layout for GC vectors. Due to GTY > limitations, GC vectors must always be pointers, so it is more > efficient to use a pointer to the vl_embed layout, rather than > using a pointer to a pointer as would be the case with vl_ptr. */ > >> >> Otherwise the change looks good. I think you just to make sure you're >> not using the embedded layout. Which I think is just a different type >> when you declare the vec. > > I have made the vectors auto_vec as Trevor suggested. As auto_vec is > just an inherited plain vec<> with some magic allocation sauce, they > can be passed around interchangeably. > > I also changed the hash sets so they live on the stack as opposed to > allocating memory dynamically, at Trevor's request as well. > > Bootstraps. OK pending another round of tests? Yes. Thanks for double-checking on the embedded vs space efficient stuff. jeff
Re: [PATCH] fix PR translation/82185
On 09/11/2017 03:59 PM, Max Filippov wrote: > Hi Richard, > > On Mon, Sep 11, 2017 at 2:36 PM, Richard Sandiford > wrote: >> Max Filippov writes: >>> 2017-09-11 Max Filippov >>> gcc/ >>> * expmed.c (emit_store_flag_int): Initialize rtx tem. >> >> LGTM, thanks, but I can't approve it. >> >> This makes the later "tem = 0;" redundant, so perhaps it would make >> sense to delete that too? There again, it was redundant before the >> split as well. >> >> An alternative would be to only test tem when we've done something >> with it, as below, but I don't know if that's better or a step backwards. > > this works for me too, so whichever fix you like better. I like narrowing the scope better -- it's a lot easier to reason about the code when the def and uses are close and there's not a ton of control flow. Jeff
Re: Turn HARD_REGNO_NREGS into a target hook
On 09/11/2017 11:18 AM, Richard Sandiford wrote: > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > Also tested by comparing the testsuite assembly output on at least one > target per CPU directory. OK to install? > > Richard > > > gcc/ > * target.def (hard_regno_nregs): New hook. > (class_max_nregs): Refer to it instead of HARD_REGNO_NREGS. > * targhooks.h (default_hard_regno_nregs): Declare. > * targhooks.c (default_hard_regno_nregs): New function. > * doc/tm.texi.in (HARD_REGNO_NREGS): Replace with... > (TARGET_HARD_REGNO_NREGS): ...this hook. > (HARD_REGNO_NREGS_HAS_PADDING): Update accordingly. > (CLASS_MAX_NREGS): Likewise. > * doc/tm.texi: Regenerate. > * reginfo.c (init_reg_modes_target): Use targetm.hard_regno_nregs > instead of HARD_REGNO_NREGS. > * rtl.h (REG_NREGS): Refer to TARGET_HARD_REGNO_NREGS rather than > HARD_REGNO_NREGS in the comment. > * config/aarch64/aarch64.h (HARD_REGNO_NREGS): Delete. > * config/aarch64/aarch64-protos.h (aarch64_hard_regno_nregs): Delete. > * config/aarch64/aarch64.c (aarch64_hard_regno_nregs): Make static. > Return an unsigned int. > (TARGET_HARD_REGNO_NREGS): Redefine. > * config/alpha/alpha.h (HARD_REGNO_NREGS): Delete. > * config/arc/arc.h (HARD_REGNO_NREGS): Delete. > * config/arc/arc.c (TARGET_HARD_REGNO_NREGS): Redefine. > (arc_hard_regno_nregs): New function. > * config/arm/arm.h (HARD_REGNO_NREGS): Delete. > * config/arm/arm.c (TARGET_HARD_REGNO_NREGS): Redefine. > (arm_hard_regno_nregs): New function. > * config/avr/avr.h (HARD_REGNO_NREGS): Delete. > * config/bfin/bfin.h (HARD_REGNO_NREGS): Delete. > * config/bfin/bfin.c (bfin_hard_regno_nregs): New function. > (TARGET_HARD_REGNO_NREGS): Redefine. > * config/c6x/c6x.h (HARD_REGNO_NREGS): Delete. > * config/cr16/cr16.h (LONG_REG_P): Use targetm.hard_regno_nregs. > (HARD_REGNO_NREGS): Delete. > * config/cr16/cr16.c (TARGET_HARD_REGNO_NREGS): Redefine. > (cr16_hard_regno_nregs): New function. > (cr16_memory_move_cost): Use it instead of HARD_REGNO_NREGS. > * config/cris/cris.h (HARD_REGNO_NREGS): Delete. > * config/cris/cris.c (TARGET_HARD_REGNO_NREGS): Redefine. > (cris_hard_regno_nregs): New function. > * config/epiphany/epiphany.h (HARD_REGNO_NREGS): Delete. > * config/fr30/fr30.h (HARD_REGNO_NREGS): Delete. > (CLASS_MAX_NREGS): Use targetm.hard_regno_nregs. > * config/frv/frv.h (HARD_REGNO_NREGS): Delete. > (CLASS_MAX_NREGS): Remove outdated copy of documentation. > * config/frv/frv-protos.h (frv_hard_regno_nregs): Delete. > * config/frv/frv.c (TARGET_HARD_REGNO_NREGS): Redefine. > (frv_hard_regno_nregs): Make static. Take and return an > unsigned int. > (frv_class_max_nregs): Remove outdated copy of documentation. > * config/ft32/ft32.h (HARD_REGNO_NREGS): Delete. > * config/h8300/h8300.h (HARD_REGNO_NREGS): Delete. > * config/h8300/h8300-protos.h (h8300_hard_regno_nregs): Delete. > * config/h8300/h8300.c (h8300_hard_regno_nregs): Delete. > * config/i386/i386.h (HARD_REGNO_NREGS): Delete. > * config/i386/i386.c (ix86_hard_regno_nregs): New function. > (TARGET_HARD_REGNO_NREGS): Redefine. > * config/ia64/ia64.h (HARD_REGNO_NREGS): Delete. > (CLASS_MAX_NREGS): Update comment. > * config/ia64/ia64.c (TARGET_HARD_REGNO_NREGS): Redefine. > (ia64_hard_regno_nregs): New function. > * config/iq2000/iq2000.h (HARD_REGNO_NREGS): Delete. > * config/lm32/lm32.h (HARD_REGNO_NREGS): Delete. > * config/m32c/m32c.h (HARD_REGNO_NREGS): Delete. > * config/m32c/m32c-protos.h (m32c_hard_regno_nregs): Delete. > * config/m32c/m32c.c (m32c_hard_regno_nregs_1): Take and return > an unsigned int. > (m32c_hard_regno_nregs): Likewise. Make static. > (TARGET_HARD_REGNO_NREGS): Redefine. > * config/m32r/m32r.h (HARD_REGNO_NREGS): Delete. > * config/m68k/m68k.h (HARD_REGNO_NREGS): Delete. > * config/m68k/m68k.c (TARGET_HARD_REGNO_NREGS): Redefine. > (m68k_hard_regno_nregs): New function. > * config/mcore/mcore.h (HARD_REGNO_NREGS): Delete. > * config/microblaze/microblaze.h (HARD_REGNO_NREGS): Delete. > * config/mips/mips.h (HARD_REGNO_NREGS): Delete. > * config/mips/mips-protos.h (mips_hard_regno_nregs): Delete. > * config/mips/mips.c (mips_hard_regno_nregs): Make static. > Take and return an unsigned int. > (TARGET_HARD_REGNO_NREGS): Redefine. > * config/mmix/mmix.h (HARD_REGNO_NREGS): Delete. > (CLASS_MAX_NREGS): Use targetm.hard_regno_nregs. > * config/mn10300/mn10300.h (HARD_REGNO_NREGS): Delete. > * config/moxie/moxie.h (HARD_REGNO_NREGS): Delete. > * config/msp430/msp430.h (HARD_REGNO_NREGS): Delete. >
Re: [patch, fortran, RFC] warn about out-of-bounds errors in DO loops
Well, here's a version which actually throws a hard error in obvious cases; the other cases are reserved for -Wextra. Turns up a few bugs in the testsuite, too. An interesting one is unconstrained_commons.f, where the code quite happily saves and stores outside a common block array with a single element. Illegal, but apparently wanted with a special option. So, what do you think? Should I proceed like this and make this a formal submission? Regards Thomas Index: frontend-passes.c === --- frontend-passes.c (Revision 251951) +++ frontend-passes.c (Arbeitskopie) @@ -39,6 +39,8 @@ static bool optimize_lexical_comparison (gfc_expr static void optimize_minmaxloc (gfc_expr **); static bool is_empty_string (gfc_expr *e); static void doloop_warn (gfc_namespace *); +static int do_intent (gfc_expr **); +static int do_subscript (gfc_expr **); static void optimize_reduction (gfc_namespace *); static int callback_reduction (gfc_expr **, int *, void *); static void realloc_strings (gfc_namespace *); @@ -98,10 +100,20 @@ static int iterator_level; /* Keep track of DO loop levels. */ -static vec doloop_list; +typedef struct { + gfc_code *c; + int branch_level; + bool seen_goto; +} do_t; +static vec doloop_list; static int doloop_level; +/* Keep track of if and select case levels. */ + +static int if_level; +static int select_level; + /* Vector of gfc_expr * to keep track of DO loops. */ struct my_struct *evec; @@ -133,6 +145,8 @@ gfc_run_passes (gfc_namespace *ns) change. */ doloop_level = 0; + if_level = 0; + select_level = 0; doloop_warn (ns); doloop_list.release (); int w, e; @@ -2231,6 +2245,8 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR gfc_formal_arglist *f; gfc_actual_arglist *a; gfc_code *cl; + do_t loop, *lp; + bool seen_goto; co = *c; @@ -2239,16 +2255,67 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR if ((unsigned) doloop_level < doloop_list.length()) doloop_list.truncate (doloop_level); + seen_goto = false; switch (co->op) { case EXEC_DO: if (co->ext.iterator && co->ext.iterator->var) - doloop_list.safe_push (co); + loop.c = co; else - doloop_list.safe_push ((gfc_code *) NULL); + loop.c = NULL; + + loop.branch_level = if_level + select_level; + loop.seen_goto = false; + doloop_list.safe_push (loop); break; + /* If anything could transfer control away from a suspicious + subscript, make sure to set seen_goto in the current DO loop + (if any). */ +case EXEC_GOTO: +case EXEC_EXIT: +case EXEC_STOP: +case EXEC_ERROR_STOP: +case EXEC_CYCLE: + seen_goto = true; + break; + +case EXEC_OPEN: + if (co->ext.open->err) + seen_goto = true; + break; + +case EXEC_CLOSE: + if (co->ext.close->err) + seen_goto = true; + break; + +case EXEC_BACKSPACE: +case EXEC_ENDFILE: +case EXEC_REWIND: +case EXEC_FLUSH: + + if (co->ext.filepos->err) + seen_goto = true; + break; + +case EXEC_INQUIRE: + if (co->ext.filepos->err) + seen_goto = true; + break; + +case EXEC_READ: +case EXEC_WRITE: + if (co->ext.dt->err || co->ext.dt->end || co->ext.dt->eor) + seen_goto = true; + break; + +case EXEC_WAIT: + if (co->ext.wait->err || co->ext.wait->end || co->ext.wait->eor) + loop.seen_goto = true; + break; + case EXEC_CALL: if (co->resolved_sym == NULL) @@ -2265,9 +2332,10 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR while (a && f) { - FOR_EACH_VEC_ELT (doloop_list, i, cl) + FOR_EACH_VEC_ELT (doloop_list, i, lp) { gfc_symbol *do_sym; + cl = lp->c; if (cl == NULL) break; @@ -2282,14 +2350,14 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR "value inside loop beginning at %L as " "INTENT(OUT) argument to subroutine %qs", do_sym->name, &a->expr->where, - &doloop_list[i]->loc, + &(doloop_list[i].c->loc), co->symtree->n.sym->name); else if (f->sym->attr.intent == INTENT_INOUT) gfc_error_now ("Variable %qs at %L not definable inside " "loop beginning at %L as INTENT(INOUT) " "argument to subroutine %qs", do_sym->name, &a->expr->where, - &doloop_list[i]->loc, + &(doloop_list[i].c->loc), co->symtree->n.sym->name); } } @@ -2301,20 +2369,314 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR default: break; } + if (seen_goto && doloop_level > 0) +doloop_list[doloop_level-1].seen_goto = true; + return 0; } -/* Callback function for functions checking that we do not pass a DO variable - to an INTENT(OUT) or INTENT(INOUT) dummy variable. */ +/* Callback function to warn about different things within DO loops. */ static int do_function (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
Re: Turn SLOW_UNALIGNED_ACCESS into a target hook
On 09/11/2017 11:13 AM, Richard Sandiford wrote: > Pretty mechanical conversion. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > Also tested by comparing the testsuite assembly output on at least one > target per CPU directory. OK to install? > > Richard > > > 2017-09-11 Richard Sandiford > Alan Hayward > David Sherwood > > gcc/ > * defaults.h (SLOW_UNALIGNED_ACCESS): Delete. > * target.def (slow_unaligned_access): New hook. > * targhooks.h (default_slow_unaligned_access): Declare. > * targhooks.c (default_slow_unaligned_access): New function. > * doc/tm.texi.in (SLOW_UNALIGNED_ACCESS): Replace with... > (TARGET_SLOW_UNALIGNED_ACCESS): ...this. > * doc/tm.texi: Regenerate. > * config/alpha/alpha.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/arm/arm.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/i386/i386.h (SLOW_UNALIGNED_ACCESS): Delete commented-out > definition. > * config/powerpcspe/powerpcspe.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/powerpcspe/powerpcspe.c (TARGET_SLOW_UNALIGNED_ACCESS): > Redefine. > (rs6000_slow_unaligned_access): New function. > (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS. > (expand_block_compare): Likewise. > (expand_strn_compare): Likewise. > (rs6000_rtx_costs): Likewise. > * config/riscv/riscv.h (SLOW_UNALIGNED_ACCESS): Delete. > (riscv_slow_unaligned_access): Likewise. > * config/riscv/riscv.c (riscv_slow_unaligned_access): Rename to... > (riscv_slow_unaligned_access_p): ...this and make static. > (riscv_option_override): Update accordingly. > (riscv_slow_unaligned_access): New function. > (TARGET_SLOW_UNALIGNED_ACCESS): Redefine. > * config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/rs6000/rs6000.c (TARGET_SLOW_UNALIGNED_ACCESS): Redefine. > (rs6000_slow_unaligned_access): New function. > (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS. > (rs6000_rtx_costs): Likewise. > * config/rs6000/rs6000-string.c (expand_block_compare) > (expand_strn_compare): Use targetm.slow_unaligned_access instead > of SLOW_UNALIGNED_ACCESS. > * config/tilegx/tilegx.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/tilepro/tilepro.h (SLOW_UNALIGNED_ACCESS): Delete. > * calls.c (expand_call): Use targetm.slow_unaligned_access instead > of SLOW_UNALIGNED_ACCESS. > * expmed.c (simple_mem_bitfield_p): Likewise. > * expr.c (alignment_for_piecewise_move): Likewise. > (emit_group_load_1): Likewise. > (emit_group_store): Likewise. > (copy_blkmode_from_reg): Likewise. > (emit_push_insn): Likewise. > (expand_assignment): Likewise. > (store_field): Likewise. > (expand_expr_real_1): Likewise. > * gimple-fold.c (gimple_fold_builtin_memory_op): Likewise. > * lra-constraints.c (simplify_operand_subreg): Likewise. > * stor-layout.c (bit_field_mode_iterator::next_mode): Likewise. > * gimple-ssa-store-merging.c: Likewise in block comment at start > of file. > * tree-ssa-strlen.c: Include target.h. > (handle_builtin_memcmp): Use targetm.slow_unaligned_access instead > of SLOW_UNALIGNED_ACCESS. > * system.h (SLOW_UNALIGNED_ACCESS): Poison. OK jeff
Re: Use hard_regno_nregs instead of HARD_REGNO_NREGS
On 09/11/2017 11:18 AM, Richard Sandiford wrote: > This patch converts some places that use HARD_REGNO_NREGS to use > hard_regno_nregs, in places where the initialisation has obviously > already taken place. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > Also tested by comparing the testsuite assembly output on at least one > target per CPU directory. OK to install? > > Richard > > > 2017-09-11 Richard Sandiford > > gcc/ > * config/arm/arm.h (THUMB_SECONDARY_INPUT_RELOAD_CLASS): Use > hard_regno_nregs instead of HARD_REGNO_NREGS. > (THUMB_SECONDARY_OUTPUT_RELOAD_CLASS): Likewise. > * config/c6x/c6x.c (c6x_expand_prologue): Likewise. > (c6x_expand_epilogue): Likewise. > * config/frv/frv.c (frv_alloc_temp_reg): Likewise. > (frv_read_iacc_argument): Likewise. > * config/sh/sh.c: Include regs.h. > (sh_print_operand): Use hard_regno_nregs instead of HARD_REGNO_NREGS. > (regs_used): Likewise. > (output_stack_adjust): Likewise. > * config/xtensa/xtensa.c (xtensa_copy_incoming_a7): Likewise. > * expmed.c: Include regs.h. > (store_bit_field_1): Use hard_regno_nregs instead of HARD_REGNO_NREGS. > * ree.c: Include regs.h. > (combine_reaching_defs): Use hard_regno_nregs instead of > HARD_REGNO_NREGS. > (add_removable_extension): Likewise. OK. jeff
Re: Convert hard_regno_nregs to a function
On 09/11/2017 11:17 AM, Richard Sandiford wrote: > This patch converts hard_regno_nregs into an inline function, which > in turn allows hard_regno_nregs to be used as the name of a targetm > field. This is just a mechanical change. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > Also tested by comparing the testsuite assembly output on at least one > target per CPU directory. OK to install? > > Richard > > > 2017-09-11 Richard Sandiford > > gcc/ > * regs.h (hard_regno_nregs): Turn into a function. > (end_hard_regno): Update accordingly. > * caller-save.c (setup_save_areas): Likewise. > (save_call_clobbered_regs): Likewise. > (replace_reg_with_saved_mem): Likewise. > (insert_restore): Likewise. > (insert_save): Likewise. > * combine.c (can_change_dest_mode): Likewise. > (move_deaths): Likewise. > (distribute_notes): Likewise. > * config/mips/mips.c (mips_hard_regno_call_part_clobbered): Likewise. > * config/powerpcspe/powerpcspe.c (rs6000_cannot_change_mode_class) > (rs6000_split_multireg_move): Likewise. > (rs6000_register_move_cost): Likewise. > (rs6000_memory_move_cost): Likewise. > * config/rs6000/rs6000.c (rs6000_cannot_change_mode_class): Likewise. > (rs6000_split_multireg_move): Likewise. > (rs6000_register_move_cost): Likewise. > (rs6000_memory_move_cost): Likewise. > * cselib.c (cselib_reset_table): Likewise. > (cselib_lookup_1): Likewise. > * emit-rtl.c (set_mode_and_regno): Likewise. > * function.c (aggregate_value_p): Likewise. > * ira-color.c (setup_profitable_hard_regs): Likewise. > (check_hard_reg_p): Likewise. > (calculate_saved_nregs): Likewise. > (assign_hard_reg): Likewise. > (improve_allocation): Likewise. > (calculate_spill_cost): Likewise. > * ira-emit.c (modify_move_list): Likewise. > * ira-int.h (ira_hard_reg_set_intersection_p): Likewise. > (ira_hard_reg_in_set_p): Likewise. > * ira.c (setup_reg_mode_hard_regset): Likewise. > (clarify_prohibited_class_mode_regs): Likewise. > (check_allocation): Likewise. > * lra-assigns.c (find_hard_regno_for_1): Likewise. > (lra_setup_reg_renumber): Likewise. > (setup_try_hard_regno_pseudos): Likewise. > (spill_for): Likewise. > (assign_hard_regno): Likewise. > (setup_live_pseudos_and_spill_after_risky_transforms): Likewise. > * lra-constraints.c (in_class_p): Likewise. > (lra_constraint_offset): Likewise. > (simplify_operand_subreg): Likewise. > (lra_constraints): Likewise. > (split_reg): Likewise. > (split_if_necessary): Likewise. > (invariant_p): Likewise. > (inherit_in_ebb): Likewise. > * lra-lives.c (process_bb_lives): Likewise. > * lra-remat.c (reg_overlap_for_remat_p): Likewise. > (get_hard_regs): Likewise. > (do_remat): Likewise. > * lra-spills.c (assign_spill_hard_regs): Likewise. > * mode-switching.c (create_pre_exit): Likewise. > * postreload.c (reload_combine_recognize_pattern): Likewise. > * recog.c (peep2_find_free_register): Likewise. > * regcprop.c (kill_value_regno): Likewise. > (set_value_regno): Likewise. > (copy_value): Likewise. > (maybe_mode_change): Likewise. > (find_oldest_value_reg): Likewise. > (copyprop_hardreg_forward_1): Likewise. > * regrename.c (check_new_reg_p): Likewise. > (regrename_do_replace): Likewise. > * reload.c (push_reload): Likewise. > (combine_reloads): Likewise. > (find_dummy_reload): Likewise. > (operands_match_p): Likewise. > (find_reloads): Likewise. > (find_equiv_reg): Likewise. > (reload_adjust_reg_for_mode): Likewise. > * reload1.c (count_pseudo): Likewise. > (count_spilled_pseudo): Likewise. > (find_reg): Likewise. > (clear_reload_reg_in_use): Likewise. > (free_for_value_p): Likewise. > (allocate_reload_reg): Likewise. > (choose_reload_regs): Likewise. > (reload_adjust_reg_for_temp): Likewise. > (emit_reload_insns): Likewise. > (delete_output_reload): Likewise. > * rtlanal.c (subreg_get_info): Likewise. > * sched-deps.c (sched_analyze_reg): Likewise. > * sel-sched.c (init_regs_for_mode): Likewise. > (mark_unavailable_hard_regs): Likewise. > (choose_best_reg_1): Likewise. > (verify_target_availability): Likewise. > * valtrack.c (dead_debug_insert_temp): Likewise. > * var-tracking.c (track_loc_p): Likewise. > (emit_note_insn_var_location): Likewise. > * varasm.c (make_decl_rtl): Likewise. > * reginfo.c (choose_hard_reg_mode): Likewise. > (init_reg_modes_target): Refer directly to > this_target_regs->x_hard_regno_nregs. OK. jeff
Re: Make more use of in_hard_reg_set_p
On 09/11/2017 11:16 AM, Richard Sandiford wrote: > An upcoming patch will convert hard_regno_nregs into an inline > function, which in turn allows hard_regno_nregs to be used as the > name of a targetm field. This patch rewrites a use that can use > in_hard_reg_set_p instead. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > Also tested by comparing the testsuite assembly output on at least one > target per CPU directory. OK to install? > > Richard > > > 2017-09-11 Richard Sandiford > > gcc/ > * ira-costs.c (record_operand_costs): Use in_hard_reg_set_p > instead of hard_regno_nregs. OK. jeff
Re: Make more use of end_hard_regno
On 09/11/2017 11:16 AM, Richard Sandiford wrote: > An upcoming patch will convert hard_regno_nregs into an inline > function, which in turn allows hard_regno_nregs to be used as the > name of a targetm field. This patch rewrites uses that can use > end_hard_regno instead. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > Also tested by comparing the testsuite assembly output on at least one > target per CPU directory. OK to install? > > Richard > > > 2017-09-11 Richard Sandiford > > gcc/ > * config/aarch64/aarch64.c (aarch64_hard_regno_mode_ok): Use > end_hard_regno instead of hard_regno_nregs. > * config/s390/s390.c (s390_reg_clobbered_rtx): Likewise. > * config/sparc/sparc.h (ASM_DECLARE_REGISTER_GLOBAL): Likewise. > * config/visium/visium.c (visium_hard_regno_mode_ok): Likewise. > * ira-color.c (improve_allocation): Likewise. > * lra-assigns.c (find_hard_regno_for_1): Likewise. > * lra-lives.c (mark_regno_live): Likewise. > (mark_regno_dead): Likewise. > * lra-remat.c (operand_to_remat): Likewise. > * lra.c (collect_non_operand_hard_regs): Likewise. > * postreload.c (reload_combine_note_store): Likewise. > (move2add_valid_value_p): Likewise. > * reload.c (regno_clobbered_p): Likewise. OK. Jeff
Re: std::forward_list optim for always equal allocator
On 11/09/17 22:39 +0200, Daniel Krügler wrote: 2017-09-11 22:36 GMT+02:00 François Dumont : [..] So my remark was rather for the: _Fwd_list_iterator() noexcept : _M_node() { } that could simply be _Fwd_list_iterator() = default; no ? Yes, that should be fine. I'm not sure there's much benefit to that change.
Re: [PATCH] fix PR translation/82185
Hi Richard, On Mon, Sep 11, 2017 at 2:36 PM, Richard Sandiford wrote: > Max Filippov writes: >> 2017-09-11 Max Filippov >> gcc/ >> * expmed.c (emit_store_flag_int): Initialize rtx tem. > > LGTM, thanks, but I can't approve it. > > This makes the later "tem = 0;" redundant, so perhaps it would make > sense to delete that too? There again, it was redundant before the > split as well. > > An alternative would be to only test tem when we've done something > with it, as below, but I don't know if that's better or a step backwards. this works for me too, so whichever fix you like better. -- Thanks. -- Max
[PATCH] PR libstdc++/70483 make std::string_view fully constexpr
This adds 'constexpr' everywhere it's missing from std::basic_string_view. PR libstdc++/70483 * include/bits/string_view.tcc (basic_string_view::find) (basic_string_view::rfind, basic_string_view::find_first_of) (basic_string_view::find_last_of, basic_string_view::find_first_not_of) (basic_string_view::find_last_not_of): Add constexpr specifier. * include/std/string_view (basic_string_view::operator=) (basic_string_view::rbegin, basic_string_view::rend) (basic_string_view::crbegin, basic_string_view::crend) (basic_string_view::remove_prefix, basic_string_view::remove_suffix) (basic_string_view::swap, basic_string_view::compare) (basic_string_view::find, basic_string_view::rfind) (basic_string_view::find_first_of, basic_string_view::find_last_of) (basic_string_view::find_first_not_of) (basic_string_view::find_last_not_of, basic_string_view::_M_check) (basic_string_view::_M_limit, operator==, operator!=, operator<) (operator>, operator<=, operator>=): Likewise. * testsuite/21_strings/basic_string_view/modifiers/remove_prefix/ char/1.cc: Repeat tests in constexpr context. * testsuite/21_strings/basic_string_view/modifiers/remove_prefix/ wchar_t/1.cc: Likewise. * testsuite/21_strings/basic_string_view/modifiers/remove_suffix/ char/1.cc: Likewise. * testsuite/21_strings/basic_string_view/modifiers/remove_suffix/ wchar_t/1.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/find/char/1.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/find/char/2.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/find/char/3.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/find/wchar_t/1.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/find/wchar_t/2.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/find/wchar_t/3.cc: Likewise. * testsuite/21_strings/basic_string_view/operators/char/2.cc: Likewise. * testsuite/21_strings/basic_string_view/operators/wchar_t/2.cc: Likewise. * testsuite/21_strings/basic_string_view/range_access/char/1.cc: Test cbegin, cend, rbegin, rend, crbegin and crend. * testsuite/21_strings/basic_string_view/range_access/wchar_t/1.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/compare/char/1.cc: Remove trailing whitespace. * testsuite/21_strings/basic_string_view/operations/compare/wchar_t/ 1.cc: Likewise. * testsuite/21_strings/basic_string_view/modifiers/swap/char/1.cc: New. * testsuite/21_strings/basic_string_view/modifiers/swap/wchar_t/1.cc: New. * testsuite/21_strings/basic_string_view/operations/compare/char/2.cc: New. * testsuite/21_strings/basic_string_view/operations/compare/wchar_t/ 2.cc: New. Tested powerpc64le-linux, committed to trunk. commit 280c8e2870fc50a27a174a1b0fdb9d2a4d0a8d28 Author: Jonathan Wakely Date: Mon Sep 11 22:03:23 2017 +0100 PR libstdc++/70483 make std::string_view fully constexpr PR libstdc++/70483 * include/bits/string_view.tcc (basic_string_view::find) (basic_string_view::rfind, basic_string_view::find_first_of) (basic_string_view::find_last_of, basic_string_view::find_first_not_of) (basic_string_view::find_last_not_of): Add constexpr specifier. * include/std/string_view (basic_string_view::operator=) (basic_string_view::rbegin, basic_string_view::rend) (basic_string_view::crbegin, basic_string_view::crend) (basic_string_view::remove_prefix, basic_string_view::remove_suffix) (basic_string_view::swap, basic_string_view::compare) (basic_string_view::find, basic_string_view::rfind) (basic_string_view::find_first_of, basic_string_view::find_last_of) (basic_string_view::find_first_not_of) (basic_string_view::find_last_not_of, basic_string_view::_M_check) (basic_string_view::_M_limit, operator==, operator!=, operator<) (operator>, operator<=, operator>=): Likewise. * testsuite/21_strings/basic_string_view/modifiers/remove_prefix/ char/1.cc: Repeat tests in constexpr context. * testsuite/21_strings/basic_string_view/modifiers/remove_prefix/ wchar_t/1.cc: Likewise. * testsuite/21_strings/basic_string_view/modifiers/remove_suffix/ char/1.cc: Likewise. * testsuite/21_strings/basic_string_view/modifiers/remove_suffix/ wchar_t/1.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/find/char/1.cc: Lik
Re: [PATCH] fix PR translation/82185
Max Filippov writes: > 2017-09-11 Max Filippov > gcc/ > * expmed.c (emit_store_flag_int): Initialize rtx tem. LGTM, thanks, but I can't approve it. This makes the later "tem = 0;" redundant, so perhaps it would make sense to delete that too? There again, it was redundant before the split as well. An alternative would be to only test tem when we've done something with it, as below, but I don't know if that's better or a step backwards. Thanks, Richard gcc/ * expmed.c (emit_store_flag_int): Only test tem if it has been initialized. Index: gcc/expmed.c === --- gcc/expmed.c(revision 251980) +++ gcc/expmed.c(working copy) @@ -5601,7 +5601,6 @@ emit_store_flag_int (rtx target, rtx sub { machine_mode target_mode = target ? GET_MODE (target) : VOIDmode; rtx_insn *last = get_last_insn (); - rtx tem; /* If this is an equality comparison of integers, we can try to exclusive-or (or subtract) the two operands and use a recursive call to try the @@ -5610,8 +5609,8 @@ emit_store_flag_int (rtx target, rtx sub if ((code == EQ || code == NE) && op1 != const0_rtx) { - tem = expand_binop (mode, xor_optab, op0, op1, subtarget, 1, - OPTAB_WIDEN); + rtx tem = expand_binop (mode, xor_optab, op0, op1, subtarget, 1, + OPTAB_WIDEN); if (tem == 0) tem = expand_binop (mode, sub_optab, op0, op1, subtarget, 1, @@ -5643,26 +5642,28 @@ emit_store_flag_int (rtx target, rtx sub && rtx_cost (GEN_INT (normalizep), mode, PLUS, 1, optimize_insn_for_speed_p ()) == 0) { - tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0, - STORE_FLAG_VALUE, target_mode); + rtx tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0, + STORE_FLAG_VALUE, target_mode); if (tem != 0) tem = expand_binop (target_mode, add_optab, tem, gen_int_mode (normalizep, target_mode), target, 0, OPTAB_WIDEN); + if (tem != 0) + return tem; } else if (!want_add && rtx_cost (trueval, mode, XOR, 1, optimize_insn_for_speed_p ()) == 0) { - tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0, - normalizep, target_mode); + rtx tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0, + normalizep, target_mode); if (tem != 0) tem = expand_binop (target_mode, xor_optab, tem, trueval, target, INTVAL (trueval) >= 0, OPTAB_WIDEN); + if (tem != 0) + return tem; } - if (tem != 0) - return tem; delete_insns_since (last); } @@ -5680,7 +5681,7 @@ emit_store_flag_int (rtx target, rtx sub /* Try to put the result of the comparison in the sign bit. Assume we can't do the necessary operation below. */ - tem = 0; + rtx tem = 0; /* To see if A <= 0, compute (A | (A - 1)). A <= 0 iff that result has the sign bit set. */
Re: [PATCH 1/13] D: The front-end (DMD) language implementation and license.
On 9/11/2017 10:26 AM, Iain Buclaw wrote: On 11 September 2017 at 17:12, Jeff Law wrote: On 05/28/2017 03:02 PM, Iain Buclaw wrote: (Sorry, repost as I rushed the first one a bit). This patch adds the DMD front-end proper and license (Boost) files, comprised of a lexer, parser, and semantic analyzer. Split 1/4 Gzipped because of size limitations. So for 1/13, these are all bits that are maintained on github and we're just a downstream user, right? Meaning I don't need to do a deep dive in this patch within the series, right? Does this stuff get bound into GCC? The reason I ask is the files are under the Boost license with ownership by Digital Mars. While we often have a fair amount of leeway with runtime systems, we may not have the same kind of license/ownership leeway with things that are actually part of the compiler itself. Did the discussions between the FSF, Digital Mars and Walter touch in these issues at all? Have you received any guidance from the parties on this issue? Is there any way this stuff could be a separate executable or DSO? That might make things easier on the licensing front. Jeff I am under the impression that Walter had assigned copyrights of the DMD frontend to the FSF in 2011. The license change to Boost came about in 2014, all core maintainers of DMD did copyright assignments to Digital Mars as a prerequisite for the transition. Walter can you confirm the above is the case? Yes. I would be making an assumption here that there are no problems given the current arrangement as I understand it, but would be best to check this with the FSF legal be sure. Iain.
Re: [PATCH] xtensa: fix PR target/82181
On Mon, Sep 11, 2017 at 2:18 PM, augustine.sterl...@gmail.com wrote: > On Mon, Sep 11, 2017 at 2:16 PM, Max Filippov wrote: >> 2017-09-11 Max Filippov >> gcc/ >> * config/xtensa/xtensa.c (xtensa_mem_offset): Check that both >> words of E_DImode object are reachable by xtensa_uimm8x4 access. > > Approved. Please apply. Applied to trunk, thanks. I will also backport the fix to 5.x, 6.x and 7.x branches. -- Max
Re: [PATCH] xtensa: fix PR target/82181
On Mon, Sep 11, 2017 at 2:16 PM, Max Filippov wrote: > 2017-09-11 Max Filippov > gcc/ > * config/xtensa/xtensa.c (xtensa_mem_offset): Check that both > words of E_DImode object are reachable by xtensa_uimm8x4 access. Approved. Please apply.
[PATCH] xtensa: fix PR target/82181
2017-09-11 Max Filippov gcc/ * config/xtensa/xtensa.c (xtensa_mem_offset): Check that both words of E_DImode object are reachable by xtensa_uimm8x4 access. --- gcc/config/xtensa/xtensa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c index f7ce08478aa2..0f84cf3a7a04 100644 --- a/gcc/config/xtensa/xtensa.c +++ b/gcc/config/xtensa/xtensa.c @@ -615,6 +615,7 @@ xtensa_mem_offset (unsigned v, machine_mode mode) case E_HImode: return xtensa_uimm8x2 (v); +case E_DImode: case E_DFmode: return (xtensa_uimm8x4 (v) && xtensa_uimm8x4 (v + 4)); -- 2.1.4
[PATCH] fix PR translation/82185
2017-09-11 Max Filippov gcc/ * expmed.c (emit_store_flag_int): Initialize rtx tem. --- gcc/expmed.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/expmed.c b/gcc/expmed.c index 7f0cb0a0ec05..945ab3d656a2 100644 --- a/gcc/expmed.c +++ b/gcc/expmed.c @@ -5601,7 +5601,7 @@ emit_store_flag_int (rtx target, rtx subtarget, enum rtx_code code, rtx op0, { machine_mode target_mode = target ? GET_MODE (target) : VOIDmode; rtx_insn *last = get_last_insn (); - rtx tem; + rtx tem = NULL_RTX; /* If this is an equality comparison of integers, we can try to exclusive-or (or subtract) the two operands and use a recursive call to try the -- 2.1.4
Re: std::forward_list optim for always equal allocator
2017-09-11 22:36 GMT+02:00 François Dumont : [..] > So my remark was rather for the: > > _Fwd_list_iterator() noexcept > : _M_node() { } > > that could simply be > > _Fwd_list_iterator() = default; > > no ? Yes, that should be fine. - Daniel
Re: std::forward_list optim for always equal allocator
On 11/09/2017 14:11, Jonathan Wakely wrote: On 11/09/17 07:44 +0200, Daniel Krügler wrote: 2017-09-11 7:12 GMT+02:00 François Dumont : When user declare a container iterator like that: std::forward_list::iterator it; There is no reason to initialize it with a null node pointer. It is just an uninitialized iterator which is invalid to use except to initialize it. While that is correct, for every forward iterator (and std::forward_list::iterator meets these requirements), it is also required that a value-initialized iterator can be compared against other initialized iterators, so this reduces the amount of freedom to define a default constructor for such iterators even when used to default-initialize. This is not meant as a showstopper argument, since I have not fully understood of what you are planning, but just a reminder. Right, which means that std::forward_list::iterator it = {}; must initialize the node pointer to nullptr. If we remove the initialization of _Fwd_list_iterator::_M_node from the default constructor then it would be left uninitialized. But I'm confused, François was talking about removing the initialization of _Fwd_list_node_base::_M_next, what has that got to do with forward_list::iterator? Thee is no node-base in the iterator. So I'm still wondering why the initialization of _M_next should be removed. Indeed, the iterator contains a _Fwd_list_node_base*. So my remark was rather for the: _Fwd_list_iterator() noexcept : _M_node() { } that could simply be _Fwd_list_iterator() = default; no ? François
Re: [patch] Fix wrong code with small structure return on PowerPC
> I think the issue is that we set SUBREG_PROMOTED_* on something that is > possibly not so (aka uninitialized in this case). Yes, that's what I called inherent weakness of the promoted subregs mechanism. > We may only set it if either the ABI or a previous operation forced it to. > Maybe this is also the reason why we need this zero init pass in some cases > (though that isn't a full solution either). Do you think that we should zero-init all the unsigned promoted subregs (and sign-extend-init all the signed promoted subregs)? That sounds like a big hammer to me, but I can give it a try. -- Eric Botcazou
Re: Make more use of REG_NREGS
On 09/11/2017 11:14 AM, Richard Sandiford wrote: > An upcoming patch will convert hard_regno_nregs into an inline > function, which in turn allows hard_regno_nregs to be used as the > name of a targetm field. This patch rewrites uses that are more > easily (and efficiently) written as REG_NREGS. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > Also tested by comparing the testsuite assembly output on at least one > target per CPU directory. OK to install? > > Richard > > > 2017-09-11 Richard Sandiford > > gcc/ > * caller-save.c (add_used_regs): Use REG_NREGS instead of > hard_regno_nregs. > * config/aarch64/aarch64.c (aarch64_split_combinev16qi): Likewise. > * config/arm/arm.c (output_move_neon): Likewise. > (arm_attr_length_move_neon): Likewise. > (neon_split_vcombine): Likewise. > * config/c6x/c6x.c (c6x_mark_reg_read): Likewise. > (c6x_mark_reg_written): Likewise. > (c6x_dwarf_register_span): Likewise. > * config/i386/i386.c (ix86_save_reg): Likewise. > * config/ia64/ia64.c (mark_reg_gr_used_mask): Likewise. > (rws_access_reg): Likewise. > * config/s390/s390.c (s390_call_saved_register_used): Likewise. > * mode-switching.c (create_pre_exit): Likewise. > * ree.c (combine_reaching_defs): Likewise. > (add_removable_extension): Likewise. > * regcprop.c (find_oldest_value_reg): Likewise. > (copyprop_hardreg_forward_1): Likewise. > * reload.c (reload_inner_reg_of_subreg): Likewise. > (push_reload): Likewise. > (combine_reloads): Likewise. > (find_dummy_reload): Likewise. > (reload_adjust_reg_for_mode): Likewise. > * reload1.c (find_reload_regs): Likewise. > (forget_old_reloads_1): Likewise. > (reload_reg_free_for_value_p): Likewise. > (reload_adjust_reg_for_temp): Likewise. > (emit_reload_insns): Likewise. > (delete_output_reload): Likewise. > * sel-sched.c (choose_best_reg_1): Likewise. > (choose_best_pseudo_reg): Likewise. OK. jeff
Re: [Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors
Hi Paul, > I have fixed all the PDT bugs that have been reported to me so far in > the attached patch. The patch is straightforward and is commented for > clarity where necessary. Please note that whitespace changes have been > suppressed. For this reason, if you are tempted to try the patch use > the -l option when you apply it. > > Bootstrapped and regtested on FC23/x86_64 - OK for trunk? yes, looks good to me (except that you seem to confuse me with Thomas - I recognize those test cases as mine ;) Thanks for taking care of this so quickly! Cheers, Janus
Re: [Ada] Pragma Atomic wrongly rejected on composite component
> That regresses on gnat.dg/specs/atomic1.ads for aarch64/-mabi=ilp32, > missing the error on line 13. The missing error on line 9 is > preexisting. That's sort of expected, since the point of the patch is to make the 2 situations equivalent wrt atomicity. Clearly the test is not portable and will fail on targets for which pointer size and word size are not equal. -- Eric Botcazou
Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer
On Sun, Jul 9, 2017 at 11:43 AM, Paul Richard Thomas wrote: > Hi Thomas, Hi All, > > Please find attached what I believe is the final version of the patch. > > The problem concerning temporaries being generated in lieu of the > descriptor being passed directly - see pointer_array_7.f90 and the > change to subref_array_4.f90. This latter necessitated a thread on clf > to get right. Thanks are due to Thomas for initiating it. > > I took the opportunity of the delay, while the bounds issue was being > discussed on clf, to fix class pointer arrays. They now function > correctly, as evidenced by pointer_array_8.f90. > > A possible final tweak - as asked before, should I bump up the module > version number? My inclination is to say that we should. > > Bootstrapped and regtested on FC23/x86_64 - OK for trunk? > > Paul > > 2017-07-09 Paul Thomas > > PR fortran/34640 > PR fortran/40737 > PR fortran/55763 > PR fortran/57019 > PR fortran/57116 > > * expr.c (is_subref_array): Add class pointer array dummies > to the list of expressions that return true. > * trans-array.c: Add SPAN_FIELD and update indices for > subsequent fields. > (gfc_conv_descriptor_span, gfc_conv_descriptor_span_get, > gfc_conv_descriptor_span_set, is_pointer_array, > get_array_span): New functions. > (gfc_get_descriptor_offsets_for_info): New function to preserve > API for access to descriptor fields for trans-types.c. > (gfc_conv_scalarized_array_ref): If the expression is a subref > array, make sure that info->descriptor is a descriptor type. > Otherwise, if info->descriptor is a pointer array, set 'decl' > and fix it if it is a component reference. > (build_array_ref): Simplify handling of class array refs by > passing the vptr to gfc_build_array_ref rather than generating > the pointer arithmetic in this function. > (gfc_conv_array_ref): As in gfc_conv_scalarized_array_ref, set > 'decl'. > (gfc_array_allocate): Set the span field if this is a pointer > array. Use the expr3 element size if it is available, so that > the dynamic type element size is used. > (gfc_conv_expr_descriptor): Set the span field for pointer > assignments. > * trans-array.h: Prototypes for gfc_conv_descriptor_span_get > gfc_conv_descriptor_span_set and > gfc_get_descriptor_offsets_for_info added. > trans-decl.c (gfc_get_symbol_decl): If a non-class pointer > array, mark the declaration as a GFC_DECL_PTR_ARRAY_P. Remove > the setting of GFC_DECL_SPAN. > (gfc_trans_deferred_vars): Set the span field to zero in thge > originating scope. > * trans-expr.c (gfc_conv_procedure_call): Do not use copy-in/ > copy-out to pass subref expressions to a pointer dummy. > (gfc_trans_pointer_assignment): Remove code for setting of > GFC_DECL_SPAN. Set the 'span' field for non-class pointers to > class function results. Likewise for rank remap. > * trans-intrinsic.c (conv_expr_ref_to_caf_ref): Pick up the > 'token' offset from the field decl in the descriptor. > (conv_isocbinding_subroutine): Set the 'span' field. > * trans-io.c (gfc_trans_transfer): Always scalarize pointer > array io. > * trans-stmt.c (trans_associate_var): Set the 'span' field. > * trans-types.c (gfc_get_array_descriptor_base): Add the 'span' > field to the array descriptor. > (gfc_get_derived_type): Pointer array components are marked as > GFC_DECL_PTR_ARRAY_P. > (gfc_get_array_descr_info): Replaced API breaking code for > descriptor offset calling gfc_get_descriptor_offsets_for_info. > * trans.c (get_array_span): New function. > (gfc_build_array_ref): Simplify by calling get_array_span and > obtain 'span' if 'decl' or 'vptr' present. > * trans.h : Rename DECL_LANG_FLAG_6, GFC_DECL_SUBREF_ARRAY_P, > as GFC_DECL_PTR_ARRAY_P. > > > 2017-07-09 Paul Thomas > > PR fortran/34640 > * gfortran.dg/assumed_type_2.f90: Adjust some of the tree dump > checks. > * gfortran.dg/no_arg_check_2.f90: Likewise. > * gfortran.dg/pointer_array_1.f90: New test. > * gfortran.dg/pointer_array_2.f90: New test. > * gfortran.dg/pointer_array_7.f90: New test. > * gfortran.dg/pointer_array_8.f90: New test. > * gfortran.dg/pointer_array_component_1.f90: New test. > * gfortran.dg/pointer_array_component_2.f90: New test. > * gfortran.dg/goacc/kernels-alias-4.f95: Bump up both tree scan > counts by 1. > * gfortran.dg/subref_array_pointer_4.f90: Use the passed lower > bound for 'Q' to provide an offset for array element access. > > PR fortran/40737 > * gfortran.dg/pointer_array_3.f90: New test. > > PR fortran/57116 > * gfortran.dg/pointer_array_4.f90: New test. > > PR fortran/55763 > * gfortran.dg/pointer_array_5.f90: New test. > > PR fortran/57019 > * gfortran.dg/pointer_array_6.f90: New test. > > 2017-07-09 Paul Thomas > > P
[Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors
Dear Thomas, dear All, I have fixed all the PDT bugs that have been reported to me so far in the attached patch. The patch is straightforward and is commented for clarity where necessary. Please note that whitespace changes have been suppressed. For this reason, if you are tempted to try the patch use the -l option when you apply it. Bootstrapped and regtested on FC23/x86_64 - OK for trunk? Since I really want to get on with other things, if I do not receive any contrary comments I will commit tomorrow night. Cheers Paul 2017-09-11 Paul Thomas PR fortran/82173 PR fortran/82168 * decl.c (variable_decl): Check pdt template components for appearance of KIND/LEN components in the type parameter name list, that components corresponding to type parameters have either KIND or LEN attributes and that KIND or LEN components are scalar. Copy the initializer to the parameter value. (gfc_get_pdt_instance): Add a label 'error_return' and follow it with repeated code, while replacing this code with a jump. Check if a parameter appears as a component in the template. Make sure that the parameter expressions are integer. Validate KIND expressions. (gfc_match_decl_type_spec): Search for pdt_types in the parent namespace since they are instantiated in the template ns. * expr.c (gfc_extract_int): Use a KIND parameter if it appears as a component expression. (gfc_check_init_expr): Allow expressions with the pdt_kind attribute. *primary.c (gfc_match_actual_arglist): Make sure that the first keyword argument is recognised when 'pdt' is set. 2017-09-11 Paul Thomas PR fortran/82173 * gfortran.dg/pdt_4.f03 : Remove the 'is being used before it is defined' error. * gfortran.dg/pdt_6.f03 : New test. * gfortran.dg/pdt_7.f03 : New test. * gfortran.dg/pdt_8.f03 : New test. PR fortran/82168 * gfortran.dg/pdt_9.f03 : New test. -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein Index: gcc/fortran/decl.c === *** gcc/fortran/decl.c (revision 251948) --- gcc/fortran/decl.c (working copy) *** variable_decl (int elem) *** 2537,2542 --- 2537,2575 goto cleanup; } + if (gfc_current_state () == COMP_DERIVED + && gfc_current_block ()->attr.pdt_template) + { + gfc_symbol *param; + gfc_find_symbol (name, gfc_current_block ()->f2k_derived, + 0, ¶m); + if (!param && (current_attr.pdt_kind || current_attr.pdt_len)) + { + gfc_error ("The component with KIND or LEN attribute at %C does not " +"not appear in the type parameter list at %L", +&gfc_current_block ()->declared_at); + m = MATCH_ERROR; + goto cleanup; + } + else if (param && !(current_attr.pdt_kind || current_attr.pdt_len)) + { + gfc_error ("The component at %C that appears in the type parameter " +"list at %L has neither the KIND nor LEN attribute", +&gfc_current_block ()->declared_at); + m = MATCH_ERROR; + goto cleanup; + } + else if (as && (current_attr.pdt_kind || current_attr.pdt_len)) + { + gfc_error ("The component at %C which is a type parameter must be " +"a scalar"); + m = MATCH_ERROR; + goto cleanup; + } + else if (param && initializer) + param->value = gfc_copy_expr (initializer); + } + /* Add the initializer. Note that it is fine if initializer is NULL here, because we sometimes also need to check if a declaration *must* have an initialization expression. */ *** gfc_get_pdt_instance (gfc_actual_arglist *** 3193,3200 { gfc_error ("The type parameter spec list at %C cannot contain " "both ASSUMED and DEFERRED parameters"); ! gfc_free_actual_arglist (type_param_spec_list); ! return MATCH_ERROR; } } --- 3226,3232 { gfc_error ("The type parameter spec list at %C cannot contain " "both ASSUMED and DEFERRED parameters"); ! goto error_return; } } *** gfc_get_pdt_instance (gfc_actual_arglist *** 3202,3211 name_seen = true; param = type_param_name_list->sym; kind_expr = NULL; if (!name_seen) { ! if (actual_param && actual_param->spec_type == SPEC_EXPLICIT) kind_expr = gfc_copy_expr (actual_param->expr); } else --- 3234,3260 name_seen = true; param = type_param_name_list->sym; + c1 = gfc_find_component (pdt, param->name, false, true, NULL); + if (!pdt->attr.use_assoc && !c1) + { + gfc_er
Re: [PATCH] Improve alloca alignment
Jeff Law wrote: > On 09/09/2017 02:51 AM, Eric Botcazou wrote: > >> No, the stack never gets misaligned - my patch doesn't change that at all. > > > > Yes, it does. Dynamic allocation works like this: the amount to be > > allocated > > is added to VIRTUAL_STACK_DYNAMIC_REGNUM and the result is then dynamically > > aligned. Your patch assumes that VIRTUAL_STACK_DYNAMIC_REGNUM is as > > aligned > > as the stack pointer, i.e. STACK_BOUNDARY, but that's wrong for 32-bit > > SPARC > > at least (that's why I put the ??? note at line 5746 in emit-rtl.c). > This seems like a SPARC target problem to me -- essentially it's > claiming a higher STACK_BOUNDARY than it really has. > > Presumably there's a good reason for this and some kind of hack may be > needed to deal with it in dynamically allocated space. But it does not > seem like we should be forcing all targets to allocate unnecessary space > to deal with this. It's not just STACK_BOUNDARY, the outgoing argument offset is incorrect too. These snippets of code from PR78468 (comment 20) look very wrong: sub %sp, %g2, %sp add %sp, 108, %g3 ; g3 = fp - 28 (x) sub %sp, %g2, %sp add %sp, 108, %g2 ; g2 = fp - 44 (d) sub %sp, %g1, %sp add %sp, 112, %g1 ; g1 = fp - 56 (e) There are several different outgoing argument offsets used here (108 and 112). This not only results in alloca blocks being unaligned (when they should be at least aligned to STACK_BOUNDARY, ideally PREFERRED_STACK_BOUNDARY), but this also means you end up with different alloca blocks overlapping and corrupting each other in non-trivial ways... Wilco
Re: Make more use of END_REGNO
On 09/11/2017 11:15 AM, Richard Sandiford wrote: > An upcoming patch will convert hard_regno_nregs into an inline > function, which in turn allows hard_regno_nregs to be used as the > name of a targetm field. This patch rewrites uses that are more > easily (and efficiently) written as END_REGNO. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > Also tested by comparing the testsuite assembly output on at least one > target per CPU directory. OK to install? > > Richard > > > 2017-09-11 Richard Sandiford > > gcc/ > * config/frv/frv.c (FOR_EACH_REGNO): Use END_REGNO instead of > hard_regno_nregs. > * config/v850/v850.c (v850_reorg): Likewise. > * reload.c (refers_to_regno_for_reload_p): Likewise. > (find_equiv_reg): Likewise. > * reload1.c (reload_reg_reaches_end_p): Likewise. OK. jeff
[PATCH] Fix PR 81096 (ttest failures)
This patch fixes the ttest failures on aarch64 by adding AM_CFLAGS to the test options, like btest already does and as Wilco says works for him in Comment #4 of the bug report. Tested by me on aarch64. Ok to checkin? Steve Ellcey sell...@cavium.com 2017-09-11 Steve Ellcey PR other/81096 * libbacktrace/Makefile.in (HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_CFLAGS): Add $(AM_CFLAGS) diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in index 5b2159d..2d8c212 100644 --- a/libbacktrace/Makefile.in +++ b/libbacktrace/Makefile.in @@ -352,7 +352,7 @@ TESTS = $(check_PROGRAMS) @NATIVE_TRUE@edtest_SOURCES = edtest.c edtest2_build.c testlib.c @NATIVE_TRUE@edtest_LDADD = libbacktrace.la @HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_SOURCES = ttest.c testlib.c -@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_CFLAGS = -pthread +@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_CFLAGS = $(AM_CFLAGS) -pthread @HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_LDADD = libbacktrace.la # We can't use automake's automatic dependency tracking, because it
Re: [PATCH] Improve alloca alignment
On 09/09/2017 02:51 AM, Eric Botcazou wrote: >> No, the stack never gets misaligned - my patch doesn't change that at all. > > Yes, it does. Dynamic allocation works like this: the amount to be allocated > is added to VIRTUAL_STACK_DYNAMIC_REGNUM and the result is then dynamically > aligned. Your patch assumes that VIRTUAL_STACK_DYNAMIC_REGNUM is as aligned > as the stack pointer, i.e. STACK_BOUNDARY, but that's wrong for 32-bit SPARC > at least (that's why I put the ??? note at line 5746 in emit-rtl.c). This seems like a SPARC target problem to me -- essentially it's claiming a higher STACK_BOUNDARY than it really has. Presumably there's a good reason for this and some kind of hack may be needed to deal with it in dynamically allocated space. But it does not seem like we should be forcing all targets to allocate unnecessary space to deal with this. Jeff
Re: [Ada] Pragma Atomic wrongly rejected on composite component
On Sep 09 2017, Eric Botcazou wrote: > * gcc-interface/decl.c (promote_object_alignment): New function taken > from... > (gnat_to_gnu_entity) : ...here. Invoke it. > (gnat_to_gnu_field): If the field is Atomic or VFA, invoke it and > create a padding type on success before doing the atomic check. That regresses on gnat.dg/specs/atomic1.ads for aarch64/-mabi=ilp32, missing the error on line 13. The missing error on line 9 is preexisting. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH v2 11/13] D: GCC builtins and runtime support.
On Mon, Sep 11, 2017 at 08:04:02PM +0200, Iain Buclaw wrote: > > You may need to bump the copyright dates. > > > > I thought I bumped all copyright dates in v2 of the patch. I will check > again. Regarding copyright dates, after everything is committed, we should also adjust contrib/update-copyright.py so that it is able to update the copyright on the D source files where we want to bump them. Jakub
Re: [PATCH v2 11/13] D: GCC builtins and runtime support.
On 11 September 2017 at 18:40, Jeff Law wrote: > On 06/24/2017 11:53 AM, Iain Buclaw wrote: >> On 28 May 2017 at 23:17, Iain Buclaw wrote: >>> This patch adds GCC builtins and runtime support for GDC compiled code. >>> >>> - module __entrypoint defines the C main function. Its contents are >>> parsed and compiled in during compilation, but only if needed. >>> - module gcc.atomic is a deprecated module that defines templated >>> __sync builtins. It's original user, core.atomic, now uses the GCC >>> __atomic builtins. >>> - module gcc.attribute exposes GDC-specific attributes. >>> - module gcc.backtrace implements backtrace support for GDC. >>> - module gcc.builtins exposes GCC builtins to D code. >>> - module gcc.config exposes things determined at configure time to D code. >>> - module gcc.deh implements D unwind EH. >>> - module gcc.libbacktrace defines C bindings to libbacktrace. >>> - module gcc.unwind defines C bindings to libgcc unwind library. >>> - libgphobos.spec contains a list of libraries to link in that are >>> dependencies of D runtime and/or the Phobos standard library. It is >>> used by the GDC driver. >>> >>> --- >> Added GCC Runtime Library Exception to gcc modules as requested. > Nothing particularly concerning here now that the license is fixed. > Based on my reading, this is all code that the FSF will own, so we don't > have to worry about alternate upstreams, license exceptions, etc which > makes things so much easier. > > You may need to bump the copyright dates. > I thought I bumped all copyright dates in v2 of the patch. I will check again. However, I will prep a v3 of the patch, as it has been some time since June - I have made no changes to any of these files anyway. Iain
Re: [PATCH 4/13] D: The front-end (GDC) config, makefile, and manpages.
On 11 September 2017 at 18:05, Jeff Law wrote: > On 05/28/2017 03:12 PM, Iain Buclaw wrote: >> This patch adds the D frontend language configure make files, as >> described on the anatomy of a language front-end. >> >> --- >> >> >> 04-d-frontend-misc.patch >> >> > > >> + >> +You can specify more than one input file on the @command{gdc} command line, >> +in which case they will all be compiled. If you specify a >> +@code{-o @var{file}} option, all the input files will be compiled together, >> +producing a single output file, named @var{file}. This is allowed even >> +when using @code{-S} or @code{-c}. > So out of curiosity, when multiple sources are specified on the command > line, are they subject to IPA as a group or are they handled individually? > >> +@item -fno-bounds-check >> +@cindex @option{-fbounds-check} >> +@cindex @option{-fno-bounds-check} >> +Turns off array bounds checking for all functions, which can improve >> +performance for code that uses array extensively. Note that this >> +can result in unpredictable behavior if the code in question actually >> +does violate array bounds constraints. It is safe to use this option >> +if you are sure that your code will never throw a @code{RangeError}. > So I don't know the internals of where you keep the bounds and how you > generate code for checking, but it might be worth looking at what Roger > Sayle did for Java array index checking back in 2016: > > https://gcc.gnu.org/ml/java-patches/2016-q1/msg00014.html > > I don't know if his trick of exposing an extra write would apply to D, > but it's worth reviewing. > A dynamic array is a struct { size_t length, void* ptr }. So if the length was set in a place where the compiler can infer the value, then it will be removed by the usual const propagation / dce passes. Having a quick look, I am pretty sure that the code generation for D is as such that, that particular case is handled without the extra write - the length setting should already be exposed. >> + >> +@item -funittest >> +@cindex @option{-funittest} >> +@cindex @option{-fno-unittest} >> +Turns on compilation of @code{unittest} code, and turns on the >> +@code{version(unittest)} identifier. This implies @option{-fassert}. > I think we're using -fselftest elsewhere for unit testing bits within > the compiler. Can you look and see if your unit tests are comparable > and perhaps consider using the same option if they are? > A unittest is a D language feature, D unittests are not compiled in by default. This turns them on. Contrived example: double pow2 (double x) { return x ^^ 2; } unittest { assert (pow2 (2) == 4); } > >> + >> +@node Code Generation >> +@section Code Generation >> +@cindex options, code generation >> + >> +In addition to the many @command{gcc} options controlling code generation, >> +@command{gdc} has several options specific to itself. >> + >> +@table @gcctabopt >> + >> +@item -M >> +@cindex @option{-M} >> +Output the module dependencies of all source files being compiled in a >> +format suitable for @command{make}. The compiler outputs one >> +@command{make} rule containing the object file name for that source file, >> +a colon, and the names of all imported files. > [ ... Many -M options ... ] > Note we recently allowed generation of the dependency files even in the > case some errors. Please consider doing the same if it makes sense. > See the Sept change to c_common_finish. > OK, thanks, I'll have a look. The idea was to be closely resemble C/C++, even though there is no preprocessor in D, and it outputs the dependencies between module files. > >> + >> +@c man begin ENVIRONMENT >> + >> +In addition to the many @command{gcc} environment variables that control >> +its operation, @command{gdc} has a few environment variables specific to >> +itself. >> + >> +@vtable @env >> + >> +@item D_IMPORT_PATH >> +@findex D_IMPORT_PATH >> +The value of @env{D_IMPORT_PATH} is a list of directories separated by a >> +special character, much like @env{PATH}, in which to look for imports. >> +The special character, @code{PATH_SEPARATOR}, is target-dependent and >> +determined at GCC build time. For Microsoft Windows-based targets it is a >> +semicolon, and for almost all other targets it is a colon. >> + >> +@item DDOCFILE >> +@findex DDOCFILE >> +If @env{DDOCFILE} is set, it specifies a text file of macro definitions >> +to be read and used by the Ddoc generator. This overrides any macros >> +defined in other @file{.ddoc} files. > How important are the environment variables to the existing user base? > We generally try to avoid changing much behavior based on environment > variables. Can these be made command line options? > > jeff For D_IMPORT_PATH, there's -I /somedir, I wouldn't say that it needs to be there, its just an equivalent of something that gcc exposes. DDOCFILE I found in the DMD front-end implementation, and so thought it best to say something about it. Iain.
Re: [PATCH 3/13] D: The front-end (GDC) changelogs.
On 11 September 2017 at 17:43, Jeff Law wrote: > On 05/28/2017 03:11 PM, Iain Buclaw wrote: >> This patch just includes all changelogs for the D front-end (GDC), >> going back to the dawn of time itself. >> >> Change logs for the DMD front-end and libraries are kept on the dlang site. > Your call on how much of the historical record you want to keep. > > jeff I'll paraphrase the words of Alan at the Cauldron last weekend: Would you want your name removed from the Changelog without you knowing? This front-end has been going for over a decade now, and I wouldn't feel comfortable removing the original authors from that history. Iain.
Re: [PATCH 2/13] D: The front-end (GDC) implementation.
On 11 September 2017 at 17:42, Jeff Law wrote: > On 05/28/2017 03:11 PM, Iain Buclaw wrote: >> This patch adds the D front-end implementation, the only part of the >> compiler that interacts with GCC directly, and being the parts that I >> maintain, is something that I can talk about more directly. >> >> For the actual code generation pass, that converts the front-end AST >> to GCC trees, most parts use a separate Visitor interfaces to do a >> certain kind of lowering, for instance, types.cc builds *_TYPE trees >> from AST Type's. The Visitor class is part of the DMD front-end, and >> is defined in dfrontend/visitor.h. >> >> There are also a few interfaces which have their headers in the DMD >> frontend, but are implemented here because they do something that >> requires knowledge of the GCC backend (d-target.cc), does something >> that may not be portable, or differ between D compilers >> (d-frontend.cc) or are a thin wrapper around something that is managed >> by GCC (d-diagnostic.cc). >> >> Many high level operations result in generation of calls to D runtime >> library functions (runtime.def), all with require some kind of runtime >> type information (typeinfo.cc). The compiler also generates functions >> for registering/deregistering compiled modules with the D runtime >> library (modules.cc). >> >> As well as the D language having it's own built-in functions >> (intrinsics.cc), we also expose GCC builtins to D code via a >> `gcc.builtins' module (d-builtins.cc), and give special treatment to a >> number of UDAs that could be applied to functions (d-attribs.cc). >> >> >> That is roughly the high level jist of how things are currently organized. >> >> Regards >> Iain >> >> --- >> > Presumably the types and interfaces which are capitalized in violation > of GNU standards are done so to interface the the DMD implementation? > Correct, I define my own code generation "passes" which handle the AST returned by DMD. > Which implies the answer to a question in my prior message, namely that > the DMD implementation does get linked into GCC itself. So I think we > need the SC to rule on whether or not that's allowed. > > I'm not going to dive deep into this code -- it's essentially converting > between the different representations and is code that you'd be maintaining. > > You probably want to review the #ifdefs you've got in here to make sure > they're not supposed to be checked via #if or runtime checks (there's > only a half-dozen or so): > > +#ifdef STACK_GROWS_DOWNWARD > +#ifdef HAVE_LD_STATIC_DYNAMIC > +#ifdef HAVE_LD_STATIC_DYNAMIC > +#ifdef BIGGEST_FIELD_ALIGNMENT > +#ifdef ADJUST_FIELD_ALIGN > +#ifdef ENABLE_TREE_CHECKING > > Joseph already commented on Target::critsecsize. > Target::critsecsize was dealt with in v2 of this patch. I think I can justify all #ifdef's being there, except for ENABLE_TREE_CHECKING which can be a runtime if (flag_checking). Iain.
Re: [PATCH 6/13] D: Add D language support to GCC proper.
On 09/11/2017 11:27 AM, Mike Stump wrote: > On Sep 11, 2017, at 9:34 AM, Jeff Law wrote: >> >> On 05/28/2017 03:15 PM, Iain Buclaw wrote: >>> This patch adds D language support to GCC itself. >>> >>> --- >>> >>> >>> 06-d-gcc-proper.patch >>> >>> >>> gcc/ChangeLog >>> >>> * config/rs6000/rs6000.c (rs6000_output_function_epilogue): >>> Support GNU D by using 0 as the language type. >>> * dwarf2out.c (is_dlang): New function. >>> (gen_compile_unit_die): Use DW_LANG_D for D. >>> (declare_in_namespace): Return module die for D, instead of adding >>> extra declarations into the namespace. >>> (gen_namespace_die): Generate DW_TAG_module for D. >>> (gen_decl_die, dwarf2out_decl): Handle CONST_DECLSs for D. >>> * gcc.c (default_compilers): Add entries for ".d", ".dd" and ".di".This >>> is fine when prereqs are approved. >> >> jeff > > ENOCOMMENT Arggh. It somehow got run onto the end of the ChangeLog. "This is fine when the prereqs are approved." :-) jeff
Re: [PATCH 6/13] D: Add D language support to GCC proper.
On Sep 11, 2017, at 9:34 AM, Jeff Law wrote: > > On 05/28/2017 03:15 PM, Iain Buclaw wrote: >> This patch adds D language support to GCC itself. >> >> --- >> >> >> 06-d-gcc-proper.patch >> >> >> gcc/ChangeLog >> >> * config/rs6000/rs6000.c (rs6000_output_function_epilogue): >> Support GNU D by using 0 as the language type. >> * dwarf2out.c (is_dlang): New function. >> (gen_compile_unit_die): Use DW_LANG_D for D. >> (declare_in_namespace): Return module die for D, instead of adding >> extra declarations into the namespace. >> (gen_namespace_die): Generate DW_TAG_module for D. >> (gen_decl_die, dwarf2out_decl): Handle CONST_DECLSs for D. >> * gcc.c (default_compilers): Add entries for ".d", ".dd" and ".di".This >> is fine when prereqs are approved. > > jeff ENOCOMMENT
Re: [PATCH 1/13] D: The front-end (DMD) language implementation and license.
On 11 September 2017 at 17:12, Jeff Law wrote: > On 05/28/2017 03:02 PM, Iain Buclaw wrote: >> (Sorry, repost as I rushed the first one a bit). >> >> This patch adds the DMD front-end proper and license (Boost) files, >> comprised of a lexer, parser, and semantic analyzer. >> >> Split 1/4 >> >> Gzipped because of size limitations. > So for 1/13, these are all bits that are maintained on github and we're > just a downstream user, right? Meaning I don't need to do a deep dive > in this patch within the series, right? > > Does this stuff get bound into GCC? The reason I ask is the files are > under the Boost license with ownership by Digital Mars. While we often > have a fair amount of leeway with runtime systems, we may not have the > same kind of license/ownership leeway with things that are actually part > of the compiler itself. > > Did the discussions between the FSF, Digital Mars and Walter touch in > these issues at all? Have you received any guidance from the parties on > this issue? > > Is there any way this stuff could be a separate executable or DSO? That > might make things easier on the licensing front. > > Jeff I am under the impression that Walter had assigned copyrights of the DMD frontend to the FSF in 2011. The license change to Boost came about in 2014, all core maintainers of DMD did copyright assignments to Digital Mars as a prerequisite for the transition. Walter can you confirm the above is the case? I would be making an assumption here that there are no problems given the current arrangement as I understand it, but would be best to check this with the FSF legal be sure. Iain.
Re: [PATCH] PR c++/81852 define feature-test macro for -fthreadsafe-statics
On 09/09/17 10:33 +0200, Jason Merrill wrote: On Fri, Sep 8, 2017 at 10:03 PM, Jonathan Wakely wrote: Define the __cpp_lib_threadsafe_static_init feature-test macro as per recent SD-6 drafts. Tested powerpc64le-linux and x86_64-linux. OK for trunk? The branches too? Yes. Jason I've committed this change to https://gcc.gnu.org/projects/cxx-status.html documenting the new macro. Index: htdocs/projects/cxx-status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v retrieving revision 1.41 diff -u -r1.41 cxx-status.html --- htdocs/projects/cxx-status.html 11 Apr 2017 22:28:24 - 1.41 +++ htdocs/projects/cxx-status.html 11 Sep 2017 17:19:49 - @@ -866,7 +866,7 @@ Dynamic initialization and destruction with concurrency http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm";>N2660 GCC 4.3 - + __cpp_threadsafe_static_init >= 200806
Turn HARD_REGNO_NREGS into a target hook
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. Also tested by comparing the testsuite assembly output on at least one target per CPU directory. OK to install? Richard gcc/ * target.def (hard_regno_nregs): New hook. (class_max_nregs): Refer to it instead of HARD_REGNO_NREGS. * targhooks.h (default_hard_regno_nregs): Declare. * targhooks.c (default_hard_regno_nregs): New function. * doc/tm.texi.in (HARD_REGNO_NREGS): Replace with... (TARGET_HARD_REGNO_NREGS): ...this hook. (HARD_REGNO_NREGS_HAS_PADDING): Update accordingly. (CLASS_MAX_NREGS): Likewise. * doc/tm.texi: Regenerate. * reginfo.c (init_reg_modes_target): Use targetm.hard_regno_nregs instead of HARD_REGNO_NREGS. * rtl.h (REG_NREGS): Refer to TARGET_HARD_REGNO_NREGS rather than HARD_REGNO_NREGS in the comment. * config/aarch64/aarch64.h (HARD_REGNO_NREGS): Delete. * config/aarch64/aarch64-protos.h (aarch64_hard_regno_nregs): Delete. * config/aarch64/aarch64.c (aarch64_hard_regno_nregs): Make static. Return an unsigned int. (TARGET_HARD_REGNO_NREGS): Redefine. * config/alpha/alpha.h (HARD_REGNO_NREGS): Delete. * config/arc/arc.h (HARD_REGNO_NREGS): Delete. * config/arc/arc.c (TARGET_HARD_REGNO_NREGS): Redefine. (arc_hard_regno_nregs): New function. * config/arm/arm.h (HARD_REGNO_NREGS): Delete. * config/arm/arm.c (TARGET_HARD_REGNO_NREGS): Redefine. (arm_hard_regno_nregs): New function. * config/avr/avr.h (HARD_REGNO_NREGS): Delete. * config/bfin/bfin.h (HARD_REGNO_NREGS): Delete. * config/bfin/bfin.c (bfin_hard_regno_nregs): New function. (TARGET_HARD_REGNO_NREGS): Redefine. * config/c6x/c6x.h (HARD_REGNO_NREGS): Delete. * config/cr16/cr16.h (LONG_REG_P): Use targetm.hard_regno_nregs. (HARD_REGNO_NREGS): Delete. * config/cr16/cr16.c (TARGET_HARD_REGNO_NREGS): Redefine. (cr16_hard_regno_nregs): New function. (cr16_memory_move_cost): Use it instead of HARD_REGNO_NREGS. * config/cris/cris.h (HARD_REGNO_NREGS): Delete. * config/cris/cris.c (TARGET_HARD_REGNO_NREGS): Redefine. (cris_hard_regno_nregs): New function. * config/epiphany/epiphany.h (HARD_REGNO_NREGS): Delete. * config/fr30/fr30.h (HARD_REGNO_NREGS): Delete. (CLASS_MAX_NREGS): Use targetm.hard_regno_nregs. * config/frv/frv.h (HARD_REGNO_NREGS): Delete. (CLASS_MAX_NREGS): Remove outdated copy of documentation. * config/frv/frv-protos.h (frv_hard_regno_nregs): Delete. * config/frv/frv.c (TARGET_HARD_REGNO_NREGS): Redefine. (frv_hard_regno_nregs): Make static. Take and return an unsigned int. (frv_class_max_nregs): Remove outdated copy of documentation. * config/ft32/ft32.h (HARD_REGNO_NREGS): Delete. * config/h8300/h8300.h (HARD_REGNO_NREGS): Delete. * config/h8300/h8300-protos.h (h8300_hard_regno_nregs): Delete. * config/h8300/h8300.c (h8300_hard_regno_nregs): Delete. * config/i386/i386.h (HARD_REGNO_NREGS): Delete. * config/i386/i386.c (ix86_hard_regno_nregs): New function. (TARGET_HARD_REGNO_NREGS): Redefine. * config/ia64/ia64.h (HARD_REGNO_NREGS): Delete. (CLASS_MAX_NREGS): Update comment. * config/ia64/ia64.c (TARGET_HARD_REGNO_NREGS): Redefine. (ia64_hard_regno_nregs): New function. * config/iq2000/iq2000.h (HARD_REGNO_NREGS): Delete. * config/lm32/lm32.h (HARD_REGNO_NREGS): Delete. * config/m32c/m32c.h (HARD_REGNO_NREGS): Delete. * config/m32c/m32c-protos.h (m32c_hard_regno_nregs): Delete. * config/m32c/m32c.c (m32c_hard_regno_nregs_1): Take and return an unsigned int. (m32c_hard_regno_nregs): Likewise. Make static. (TARGET_HARD_REGNO_NREGS): Redefine. * config/m32r/m32r.h (HARD_REGNO_NREGS): Delete. * config/m68k/m68k.h (HARD_REGNO_NREGS): Delete. * config/m68k/m68k.c (TARGET_HARD_REGNO_NREGS): Redefine. (m68k_hard_regno_nregs): New function. * config/mcore/mcore.h (HARD_REGNO_NREGS): Delete. * config/microblaze/microblaze.h (HARD_REGNO_NREGS): Delete. * config/mips/mips.h (HARD_REGNO_NREGS): Delete. * config/mips/mips-protos.h (mips_hard_regno_nregs): Delete. * config/mips/mips.c (mips_hard_regno_nregs): Make static. Take and return an unsigned int. (TARGET_HARD_REGNO_NREGS): Redefine. * config/mmix/mmix.h (HARD_REGNO_NREGS): Delete. (CLASS_MAX_NREGS): Use targetm.hard_regno_nregs. * config/mn10300/mn10300.h (HARD_REGNO_NREGS): Delete. * config/moxie/moxie.h (HARD_REGNO_NREGS): Delete. * config/msp430/msp430.h (HARD_REGNO_NREGS): Delete. * config/msp430/msp430-protos.h (msp430_hard_regno_nregs):
Use hard_regno_nregs instead of HARD_REGNO_NREGS
This patch converts some places that use HARD_REGNO_NREGS to use hard_regno_nregs, in places where the initialisation has obviously already taken place. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. Also tested by comparing the testsuite assembly output on at least one target per CPU directory. OK to install? Richard 2017-09-11 Richard Sandiford gcc/ * config/arm/arm.h (THUMB_SECONDARY_INPUT_RELOAD_CLASS): Use hard_regno_nregs instead of HARD_REGNO_NREGS. (THUMB_SECONDARY_OUTPUT_RELOAD_CLASS): Likewise. * config/c6x/c6x.c (c6x_expand_prologue): Likewise. (c6x_expand_epilogue): Likewise. * config/frv/frv.c (frv_alloc_temp_reg): Likewise. (frv_read_iacc_argument): Likewise. * config/sh/sh.c: Include regs.h. (sh_print_operand): Use hard_regno_nregs instead of HARD_REGNO_NREGS. (regs_used): Likewise. (output_stack_adjust): Likewise. * config/xtensa/xtensa.c (xtensa_copy_incoming_a7): Likewise. * expmed.c: Include regs.h. (store_bit_field_1): Use hard_regno_nregs instead of HARD_REGNO_NREGS. * ree.c: Include regs.h. (combine_reaching_defs): Use hard_regno_nregs instead of HARD_REGNO_NREGS. (add_removable_extension): Likewise. Index: gcc/config/arm/arm.h === --- gcc/config/arm/arm.h2017-09-11 17:16:50.096976100 +0100 +++ gcc/config/arm/arm.h2017-09-11 17:23:20.345191442 +0100 @@ -1211,7 +1211,7 @@ #define THUMB_SECONDARY_INPUT_RELOAD_CLA (lra_in_progress ? NO_REGS \ : ((CLASS) != LO_REGS && (CLASS) != BASE_REGS \ ? ((true_regnum (X) == -1 ? LO_REGS \ - : (true_regnum (X) + HARD_REGNO_NREGS (0, MODE) > 8) ? LO_REGS \ + : (true_regnum (X) + hard_regno_nregs (0, MODE) > 8) ? LO_REGS \ : NO_REGS)) \ : NO_REGS)) @@ -1219,7 +1219,7 @@ #define THUMB_SECONDARY_OUTPUT_RELOAD_CL (lra_in_progress ? NO_REGS \ : (CLASS) != LO_REGS && (CLASS) != BASE_REGS \ ? ((true_regnum (X) == -1 ? LO_REGS \ - : (true_regnum (X) + HARD_REGNO_NREGS (0, MODE) > 8) ? LO_REGS \ + : (true_regnum (X) + hard_regno_nregs (0, MODE) > 8) ? LO_REGS \ : NO_REGS)) \ : NO_REGS) Index: gcc/config/c6x/c6x.c === --- gcc/config/c6x/c6x.c2017-09-11 17:16:57.875552068 +0100 +++ gcc/config/c6x/c6x.c2017-09-11 17:23:20.346191298 +0100 @@ -2834,7 +2834,7 @@ c6x_expand_prologue (void) reg); RTX_FRAME_RELATED_P (insn) = 1; - nsaved += HARD_REGNO_NREGS (regno, save_mode); + nsaved += hard_regno_nregs (regno, save_mode); } } gcc_assert (nsaved == frame.nregs); @@ -2922,7 +2922,7 @@ c6x_expand_epilogue (bool sibcall) emit_move_insn (reg, adjust_address (mem, save_mode, off)); off += GET_MODE_SIZE (save_mode); - nsaved += HARD_REGNO_NREGS (regno, save_mode); + nsaved += hard_regno_nregs (regno, save_mode); } } if (!frame_pointer_needed) Index: gcc/config/frv/frv.c === --- gcc/config/frv/frv.c2017-09-11 17:17:46.893352269 +0100 +++ gcc/config/frv/frv.c2017-09-11 17:23:20.347191155 +0100 @@ -1509,7 +1509,7 @@ frv_alloc_temp_reg ( } } - nr = HARD_REGNO_NREGS (regno, mode); + nr = hard_regno_nregs (regno, mode); info->next_reg[ (int)rclass ] = regno + nr; if (mark_as_used) @@ -8650,7 +8650,7 @@ frv_read_iacc_argument (machine_mode mod avoid creating lots of unnecessary call_insn rtl when IACCs aren't being used. */ regno = INTVAL (op) + IACC_FIRST; - for (i = 0; i < HARD_REGNO_NREGS (regno, mode); i++) + for (i = 0; i < hard_regno_nregs (regno, mode); i++) global_regs[regno + i] = 1; return gen_rtx_REG (mode, regno); Index: gcc/config/sh/sh.c === --- gcc/config/sh/sh.c 2017-09-04 11:50:08.537340396 +0100 +++ gcc/config/sh/sh.c 2017-09-11 17:23:20.348191011 +0100 @@ -63,6 +63,7 @@ #define INCLUDE_VECTOR #include "context.h" #include "builtins.h" #include "rtl-iter.h" +#include "regs.h" /* This file should be included last. */ #include "target-def.h" @@ -1392,8 +1393,8 @@ sh_print_operand (FILE *stream, rtx x, i /* Floating point register pairs are always big endian; general purpose registers are 64 bit wide. */ regno = REGNO (inner); - regn
Convert hard_regno_nregs to a function
This patch converts hard_regno_nregs into an inline function, which in turn allows hard_regno_nregs to be used as the name of a targetm field. This is just a mechanical change. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. Also tested by comparing the testsuite assembly output on at least one target per CPU directory. OK to install? Richard 2017-09-11 Richard Sandiford gcc/ * regs.h (hard_regno_nregs): Turn into a function. (end_hard_regno): Update accordingly. * caller-save.c (setup_save_areas): Likewise. (save_call_clobbered_regs): Likewise. (replace_reg_with_saved_mem): Likewise. (insert_restore): Likewise. (insert_save): Likewise. * combine.c (can_change_dest_mode): Likewise. (move_deaths): Likewise. (distribute_notes): Likewise. * config/mips/mips.c (mips_hard_regno_call_part_clobbered): Likewise. * config/powerpcspe/powerpcspe.c (rs6000_cannot_change_mode_class) (rs6000_split_multireg_move): Likewise. (rs6000_register_move_cost): Likewise. (rs6000_memory_move_cost): Likewise. * config/rs6000/rs6000.c (rs6000_cannot_change_mode_class): Likewise. (rs6000_split_multireg_move): Likewise. (rs6000_register_move_cost): Likewise. (rs6000_memory_move_cost): Likewise. * cselib.c (cselib_reset_table): Likewise. (cselib_lookup_1): Likewise. * emit-rtl.c (set_mode_and_regno): Likewise. * function.c (aggregate_value_p): Likewise. * ira-color.c (setup_profitable_hard_regs): Likewise. (check_hard_reg_p): Likewise. (calculate_saved_nregs): Likewise. (assign_hard_reg): Likewise. (improve_allocation): Likewise. (calculate_spill_cost): Likewise. * ira-emit.c (modify_move_list): Likewise. * ira-int.h (ira_hard_reg_set_intersection_p): Likewise. (ira_hard_reg_in_set_p): Likewise. * ira.c (setup_reg_mode_hard_regset): Likewise. (clarify_prohibited_class_mode_regs): Likewise. (check_allocation): Likewise. * lra-assigns.c (find_hard_regno_for_1): Likewise. (lra_setup_reg_renumber): Likewise. (setup_try_hard_regno_pseudos): Likewise. (spill_for): Likewise. (assign_hard_regno): Likewise. (setup_live_pseudos_and_spill_after_risky_transforms): Likewise. * lra-constraints.c (in_class_p): Likewise. (lra_constraint_offset): Likewise. (simplify_operand_subreg): Likewise. (lra_constraints): Likewise. (split_reg): Likewise. (split_if_necessary): Likewise. (invariant_p): Likewise. (inherit_in_ebb): Likewise. * lra-lives.c (process_bb_lives): Likewise. * lra-remat.c (reg_overlap_for_remat_p): Likewise. (get_hard_regs): Likewise. (do_remat): Likewise. * lra-spills.c (assign_spill_hard_regs): Likewise. * mode-switching.c (create_pre_exit): Likewise. * postreload.c (reload_combine_recognize_pattern): Likewise. * recog.c (peep2_find_free_register): Likewise. * regcprop.c (kill_value_regno): Likewise. (set_value_regno): Likewise. (copy_value): Likewise. (maybe_mode_change): Likewise. (find_oldest_value_reg): Likewise. (copyprop_hardreg_forward_1): Likewise. * regrename.c (check_new_reg_p): Likewise. (regrename_do_replace): Likewise. * reload.c (push_reload): Likewise. (combine_reloads): Likewise. (find_dummy_reload): Likewise. (operands_match_p): Likewise. (find_reloads): Likewise. (find_equiv_reg): Likewise. (reload_adjust_reg_for_mode): Likewise. * reload1.c (count_pseudo): Likewise. (count_spilled_pseudo): Likewise. (find_reg): Likewise. (clear_reload_reg_in_use): Likewise. (free_for_value_p): Likewise. (allocate_reload_reg): Likewise. (choose_reload_regs): Likewise. (reload_adjust_reg_for_temp): Likewise. (emit_reload_insns): Likewise. (delete_output_reload): Likewise. * rtlanal.c (subreg_get_info): Likewise. * sched-deps.c (sched_analyze_reg): Likewise. * sel-sched.c (init_regs_for_mode): Likewise. (mark_unavailable_hard_regs): Likewise. (choose_best_reg_1): Likewise. (verify_target_availability): Likewise. * valtrack.c (dead_debug_insert_temp): Likewise. * var-tracking.c (track_loc_p): Likewise. (emit_note_insn_var_location): Likewise. * varasm.c (make_decl_rtl): Likewise. * reginfo.c (choose_hard_reg_mode): Likewise. (init_reg_modes_target): Refer directly to this_target_regs->x_hard_regno_nregs. Index: gcc/regs.h === --- gcc/regs.h 2017-09-04 11:48:57.532452460 +0100 +++ gcc/regs.h 2017
Make more use of in_hard_reg_set_p
An upcoming patch will convert hard_regno_nregs into an inline function, which in turn allows hard_regno_nregs to be used as the name of a targetm field. This patch rewrites a use that can use in_hard_reg_set_p instead. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. Also tested by comparing the testsuite assembly output on at least one target per CPU directory. OK to install? Richard 2017-09-11 Richard Sandiford gcc/ * ira-costs.c (record_operand_costs): Use in_hard_reg_set_p instead of hard_regno_nregs. Index: gcc/ira-costs.c === --- gcc/ira-costs.c 2017-09-04 11:48:57.531552460 +0100 +++ gcc/ira-costs.c 2017-09-11 17:21:26.382315018 +0100 @@ -1386,7 +1386,7 @@ record_operand_costs (rtx_insn *insn, en cost_classes_t cost_classes_ptr = regno_cost_classes[regno]; enum reg_class *cost_classes = cost_classes_ptr->classes; reg_class_t rclass; - int k, nr; + int k; i = regno == (int) REGNO (src) ? 1 : 0; for (k = cost_classes_ptr->num - 1; k >= 0; k--) @@ -1398,18 +1398,9 @@ record_operand_costs (rtx_insn *insn, en { if (reg_class_size[rclass] == 1) op_costs[i]->cost[k] = -frequency; - else - { - for (nr = 0; - nr < hard_regno_nregs[other_regno][mode]; - nr++) - if (! TEST_HARD_REG_BIT (reg_class_contents[rclass], -other_regno + nr)) - break; - - if (nr == hard_regno_nregs[other_regno][mode]) - op_costs[i]->cost[k] = -frequency; - } + else if (in_hard_reg_set_p (reg_class_contents[rclass], + mode, other_regno)) + op_costs[i]->cost[k] = -frequency; } } }
Make more use of end_hard_regno
An upcoming patch will convert hard_regno_nregs into an inline function, which in turn allows hard_regno_nregs to be used as the name of a targetm field. This patch rewrites uses that can use end_hard_regno instead. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. Also tested by comparing the testsuite assembly output on at least one target per CPU directory. OK to install? Richard 2017-09-11 Richard Sandiford gcc/ * config/aarch64/aarch64.c (aarch64_hard_regno_mode_ok): Use end_hard_regno instead of hard_regno_nregs. * config/s390/s390.c (s390_reg_clobbered_rtx): Likewise. * config/sparc/sparc.h (ASM_DECLARE_REGISTER_GLOBAL): Likewise. * config/visium/visium.c (visium_hard_regno_mode_ok): Likewise. * ira-color.c (improve_allocation): Likewise. * lra-assigns.c (find_hard_regno_for_1): Likewise. * lra-lives.c (mark_regno_live): Likewise. (mark_regno_dead): Likewise. * lra-remat.c (operand_to_remat): Likewise. * lra.c (collect_non_operand_hard_regs): Likewise. * postreload.c (reload_combine_note_store): Likewise. (move2add_valid_value_p): Likewise. * reload.c (regno_clobbered_p): Likewise. Index: gcc/config/aarch64/aarch64.c === --- gcc/config/aarch64/aarch64.c2017-09-11 17:20:21.469287471 +0100 +++ gcc/config/aarch64/aarch64.c2017-09-11 17:20:21.705282714 +0100 @@ -1106,8 +1106,7 @@ aarch64_hard_regno_mode_ok (unsigned reg if (FP_REGNUM_P (regno)) { if (aarch64_vect_struct_mode_p (mode)) - return - (regno + aarch64_hard_regno_nregs (regno, mode) - 1) <= V31_REGNUM; + return end_hard_regno (mode, regno) - 1 <= V31_REGNUM; else return true; } Index: gcc/config/s390/s390.c === --- gcc/config/s390/s390.c 2017-09-11 17:20:21.469287471 +0100 +++ gcc/config/s390/s390.c 2017-09-11 17:20:21.706282694 +0100 @@ -9630,7 +9630,7 @@ s390_reg_clobbered_rtx (rtx setreg, cons return; for (i = regno; - i < regno + HARD_REGNO_NREGS (regno, mode); + i < end_hard_regno (mode, regno); i++) regs_ever_clobbered[i] = 1; } Index: gcc/config/sparc/sparc.h === --- gcc/config/sparc/sparc.h2017-09-11 17:20:21.469287471 +0100 +++ gcc/config/sparc/sparc.h2017-09-11 17:20:21.707282674 +0100 @@ -1248,7 +1248,7 @@ #define ASM_DECLARE_REGISTER_GLOBAL(FILE do { \ if (TARGET_ARCH64) \ { \ - int end = HARD_REGNO_NREGS ((REGNO), DECL_MODE (decl)) + (REGNO); \ + int end = end_hard_regno (DECL_MODE (decl), REGNO); \ int reg; \ for (reg = (REGNO); reg < 8 && reg < end; reg++) \ if ((reg & ~1) == 2 || (reg & ~1) == 6) \ Index: gcc/config/visium/visium.c === --- gcc/config/visium/visium.c 2017-09-11 17:20:21.469287471 +0100 +++ gcc/config/visium/visium.c 2017-09-11 17:20:21.707282674 +0100 @@ -857,7 +857,7 @@ visium_hard_regno_rename_ok (unsigned in visium_hard_regno_mode_ok (unsigned int regno, machine_mode mode) { if (GP_REGISTER_P (regno)) -return GP_REGISTER_P (regno + HARD_REGNO_NREGS (regno, mode) - 1); +return GP_REGISTER_P (end_hard_regno (mode, regno) - 1); if (FP_REGISTER_P (regno)) return mode == SFmode || (mode == SImode && TARGET_FPU_IEEE); Index: gcc/ira-color.c === --- gcc/ira-color.c 2017-09-11 17:20:21.469287471 +0100 +++ gcc/ira-color.c 2017-09-11 17:20:21.708282653 +0100 @@ -2893,7 +2893,7 @@ improve_allocation (void) conflict_nregs = hard_regno_nregs[conflict_hregno][ALLOCNO_MODE (conflict_a)]; for (r = conflict_hregno; - r >= 0 && r + hard_regno_nregs[r][mode] > conflict_hregno; + r >= 0 && (int) end_hard_regno (mode, r) > conflict_hregno; r--) if (check_hard_reg_p (a, r, conflicting_regs, profitable_hard_regs)) Index: gcc/lra-assigns.c === --- gcc/lra-assigns.c 2017-09-11 17:20:21.469287471 +0100 +++ gcc/lra-assigns.c 2017-09-11 17:20:21.708282653 +0100 @@ -578,7 +578,7 @@ find_hard_regno_for_1 (int regno, int *c hr++) SET_HARD_REG_BIT (impossible_start_hard_regs, hr); for (hr = conflict_hr - 1; - hr >= 0 && hr + hard_regno_nreg
Make more use of END_REGNO
An upcoming patch will convert hard_regno_nregs into an inline function, which in turn allows hard_regno_nregs to be used as the name of a targetm field. This patch rewrites uses that are more easily (and efficiently) written as END_REGNO. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. Also tested by comparing the testsuite assembly output on at least one target per CPU directory. OK to install? Richard 2017-09-11 Richard Sandiford gcc/ * config/frv/frv.c (FOR_EACH_REGNO): Use END_REGNO instead of hard_regno_nregs. * config/v850/v850.c (v850_reorg): Likewise. * reload.c (refers_to_regno_for_reload_p): Likewise. (find_equiv_reg): Likewise. * reload1.c (reload_reg_reaches_end_p): Likewise. Index: gcc/config/frv/frv.c === --- gcc/config/frv/frv.c2017-09-04 11:50:08.510328712 +0100 +++ gcc/config/frv/frv.c2017-09-11 17:17:46.893352269 +0100 @@ -135,9 +135,7 @@ #define CLEAR_PACKING_FLAG(INSN) PUT_MOD /* Loop with REG set to each hard register in rtx X. */ #define FOR_EACH_REGNO(REG, X) \ - for (REG = REGNO (X); \ - REG < REGNO (X) + HARD_REGNO_NREGS (REGNO (X), GET_MODE (X)); \ - REG++) + for (REG = REGNO (X); REG < END_REGNO (X); REG++) /* This structure contains machine specific function data. */ struct GTY(()) machine_function Index: gcc/config/v850/v850.c === --- gcc/config/v850/v850.c 2017-09-04 11:50:08.540941953 +0100 +++ gcc/config/v850/v850.c 2017-09-11 17:17:46.893352269 +0100 @@ -1376,12 +1376,11 @@ v850_reorg (void) for the register */ if (GET_CODE (dest) == REG) { - machine_mode mode = GET_MODE (dest); int regno; int endregno; regno = REGNO (dest); - endregno = regno + HARD_REGNO_NREGS (regno, mode); + endregno = END_REGNO (dest); if (!use_ep) { Index: gcc/reload.c === --- gcc/reload.c2017-09-11 17:16:57.896550936 +0100 +++ gcc/reload.c2017-09-11 17:17:46.894352229 +0100 @@ -6439,10 +6439,7 @@ refers_to_regno_for_reload_p (unsigned i return 0; } - return (endregno > r - && regno < r + (r < FIRST_PSEUDO_REGISTER - ? hard_regno_nregs[r][GET_MODE (x)] - : 1)); + return endregno > r && regno < END_REGNO (x); case SUBREG: /* If this is a SUBREG of a hard reg, we can see exactly which @@ -6889,15 +6886,11 @@ find_equiv_reg (rtx goal, rtx_insn *insn { int i; for (i = 0; i < n_reloads; i++) - if (rld[i].reg_rtx != 0 && rld[i].in) - { - int regno1 = REGNO (rld[i].reg_rtx); - int nregs1 = hard_regno_nregs[regno1] -[GET_MODE (rld[i].reg_rtx)]; - if (regno1 < valueno + valuenregs - && regno1 + nregs1 > valueno) - return 0; - } + if (rld[i].reg_rtx != 0 + && rld[i].in + && (int) REGNO (rld[i].reg_rtx) < valueno + valuenregs + && (int) END_REGNO (rld[i].reg_rtx) > valueno) + return 0; } if (goal_mem) @@ -6963,15 +6956,11 @@ find_equiv_reg (rtx goal, rtx_insn *insn if (REG_P (dest)) { int xregno = REGNO (dest); - int xnregs; - if (REGNO (dest) < FIRST_PSEUDO_REGISTER) - xnregs = hard_regno_nregs[xregno][GET_MODE (dest)]; - else - xnregs = 1; - if (xregno < regno + nregs && xregno + xnregs > regno) + int end_xregno = END_REGNO (dest); + if (xregno < regno + nregs && end_xregno > regno) return 0; if (xregno < valueno + valuenregs - && xregno + xnregs > valueno) + && end_xregno > valueno) return 0; if (goal_mem_addr_varies && reg_overlap_mentioned_for_reload_p (dest, goal)) @@ -7006,16 +6995,12 @@ find_equiv_reg (rtx goal, rtx_insn *insn if (REG_P (dest)) { int xregno = REGNO (dest); - int xnregs; - if (REGNO (dest) < FIRST_PSEUDO_REGISTER) - xnregs = hard_regno_nregs[xregno][GET_MODE (dest)]; - else - xnregs = 1; + int end_xregno = END_REGNO (dest);
Re: Turn SLOW_UNALIGNED_ACCESS into a target hook
Richard Sandiford writes: > Pretty mechanical conversion. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > Also tested by comparing the testsuite assembly output on at least one > target per CPU directory. OK to install? > > Richard > > > 2017-09-11 Richard Sandiford > Alan Hayward > David Sherwood > > gcc/ > * defaults.h (SLOW_UNALIGNED_ACCESS): Delete. > * target.def (slow_unaligned_access): New hook. > * targhooks.h (default_slow_unaligned_access): Declare. > * targhooks.c (default_slow_unaligned_access): New function. > * doc/tm.texi.in (SLOW_UNALIGNED_ACCESS): Replace with... > (TARGET_SLOW_UNALIGNED_ACCESS): ...this. > * doc/tm.texi: Regenerate. > * config/alpha/alpha.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/arm/arm.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/i386/i386.h (SLOW_UNALIGNED_ACCESS): Delete commented-out > definition. > * config/powerpcspe/powerpcspe.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/powerpcspe/powerpcspe.c (TARGET_SLOW_UNALIGNED_ACCESS): > Redefine. > (rs6000_slow_unaligned_access): New function. > (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS. > (expand_block_compare): Likewise. > (expand_strn_compare): Likewise. > (rs6000_rtx_costs): Likewise. > * config/riscv/riscv.h (SLOW_UNALIGNED_ACCESS): Delete. > (riscv_slow_unaligned_access): Likewise. > * config/riscv/riscv.c (riscv_slow_unaligned_access): Rename to... > (riscv_slow_unaligned_access_p): ...this and make static. > (riscv_option_override): Update accordingly. > (riscv_slow_unaligned_access): New function. > (TARGET_SLOW_UNALIGNED_ACCESS): Redefine. > * config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/rs6000/rs6000.c (TARGET_SLOW_UNALIGNED_ACCESS): Redefine. > (rs6000_slow_unaligned_access): New function. > (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS. > (rs6000_rtx_costs): Likewise. > * config/rs6000/rs6000-string.c (expand_block_compare) > (expand_strn_compare): Use targetm.slow_unaligned_access instead > of SLOW_UNALIGNED_ACCESS. > * config/tilegx/tilegx.h (SLOW_UNALIGNED_ACCESS): Delete. > * config/tilepro/tilepro.h (SLOW_UNALIGNED_ACCESS): Delete. > * calls.c (expand_call): Use targetm.slow_unaligned_access instead > of SLOW_UNALIGNED_ACCESS. > * expmed.c (simple_mem_bitfield_p): Likewise. > * expr.c (alignment_for_piecewise_move): Likewise. > (emit_group_load_1): Likewise. > (emit_group_store): Likewise. > (copy_blkmode_from_reg): Likewise. > (emit_push_insn): Likewise. > (expand_assignment): Likewise. > (store_field): Likewise. > (expand_expr_real_1): Likewise. > * gimple-fold.c (gimple_fold_builtin_memory_op): Likewise. > * lra-constraints.c (simplify_operand_subreg): Likewise. > * stor-layout.c (bit_field_mode_iterator::next_mode): Likewise. > * gimple-ssa-store-merging.c: Likewise in block comment at start > of file. > * tree-ssa-strlen.c: Include target.h. > (handle_builtin_memcmp): Use targetm.slow_unaligned_access instead > of SLOW_UNALIGNED_ACCESS. > * system.h (SLOW_UNALIGNED_ACCESS): Poison. Index: gcc/defaults.h === --- gcc/defaults.h 2017-09-11 17:11:24.124638853 +0100 +++ gcc/defaults.h 2017-09-11 17:13:33.706325564 +0100 @@ -1170,10 +1170,6 @@ #define MINIMUM_ALIGNMENT(EXP,MODE,ALIGN #define ATTRIBUTE_ALIGNED_VALUE BIGGEST_ALIGNMENT #endif -#ifndef SLOW_UNALIGNED_ACCESS -#define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) STRICT_ALIGNMENT -#endif - /* For most ports anything that evaluates to a constant symbolic or integer value is acceptable as a constant address. */ #ifndef CONSTANT_ADDRESS_P Index: gcc/target.def === --- gcc/target.def 2017-09-11 17:11:24.124638853 +0100 +++ gcc/target.def 2017-09-11 17:13:33.712325341 +0100 @@ -3512,6 +3512,25 @@ negative number from this hook.", default_compare_by_pieces_branch_ratio) DEFHOOK +(slow_unaligned_access, + "This hook returns true if memory accesses described by the\n\ +@var{mode} and @var{alignment} parameters have a cost many times greater\n\ +than aligned accesses, for example if they are emulated in a trap handler.\n\ +This hook is invoked only for unaligned accesses, i.e. when\n\ +@code{@var{alignment} < GET_MODE_ALIGNMENT (@var{mode})}.\n\ +\n\ +When this hook returns true, the compiler will act as if\n\ +@code{STRICT_ALIGNMENT} were true when generating code for block\n\ +moves. This can cause significantly more instructions to be produced.\n\ +Therefore, do not make this hook return true if unaligned accesses only\n\ +add a cycle or two to the time
Make more use of REG_NREGS
An upcoming patch will convert hard_regno_nregs into an inline function, which in turn allows hard_regno_nregs to be used as the name of a targetm field. This patch rewrites uses that are more easily (and efficiently) written as REG_NREGS. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. Also tested by comparing the testsuite assembly output on at least one target per CPU directory. OK to install? Richard 2017-09-11 Richard Sandiford gcc/ * caller-save.c (add_used_regs): Use REG_NREGS instead of hard_regno_nregs. * config/aarch64/aarch64.c (aarch64_split_combinev16qi): Likewise. * config/arm/arm.c (output_move_neon): Likewise. (arm_attr_length_move_neon): Likewise. (neon_split_vcombine): Likewise. * config/c6x/c6x.c (c6x_mark_reg_read): Likewise. (c6x_mark_reg_written): Likewise. (c6x_dwarf_register_span): Likewise. * config/i386/i386.c (ix86_save_reg): Likewise. * config/ia64/ia64.c (mark_reg_gr_used_mask): Likewise. (rws_access_reg): Likewise. * config/s390/s390.c (s390_call_saved_register_used): Likewise. * mode-switching.c (create_pre_exit): Likewise. * ree.c (combine_reaching_defs): Likewise. (add_removable_extension): Likewise. * regcprop.c (find_oldest_value_reg): Likewise. (copyprop_hardreg_forward_1): Likewise. * reload.c (reload_inner_reg_of_subreg): Likewise. (push_reload): Likewise. (combine_reloads): Likewise. (find_dummy_reload): Likewise. (reload_adjust_reg_for_mode): Likewise. * reload1.c (find_reload_regs): Likewise. (forget_old_reloads_1): Likewise. (reload_reg_free_for_value_p): Likewise. (reload_adjust_reg_for_temp): Likewise. (emit_reload_insns): Likewise. (delete_output_reload): Likewise. * sel-sched.c (choose_best_reg_1): Likewise. (choose_best_pseudo_reg): Likewise. Index: gcc/caller-save.c === --- gcc/caller-save.c 2017-09-11 17:15:13.626435353 +0100 +++ gcc/caller-save.c 2017-09-11 17:16:57.862552768 +0100 @@ -1341,8 +1341,7 @@ add_used_regs (rtx *loc, void *data) { unsigned int regno = REGNO (x); if (HARD_REGISTER_NUM_P (regno)) - bitmap_set_range ((regset) data, regno, - hard_regno_nregs[regno][GET_MODE (x)]); + bitmap_set_range ((regset) data, regno, REG_NREGS (x)); else gcc_checking_assert (reg_renumber[regno] < 0); } Index: gcc/config/aarch64/aarch64.c === --- gcc/config/aarch64/aarch64.c2017-09-11 17:15:13.562442282 +0100 +++ gcc/config/aarch64/aarch64.c2017-09-11 17:16:57.864552661 +0100 @@ -13105,7 +13105,7 @@ aarch64_split_combinev16qi (rtx operands unsigned int src1 = REGNO (operands[1]); unsigned int src2 = REGNO (operands[2]); machine_mode halfmode = GET_MODE (operands[1]); - unsigned int halfregs = HARD_REGNO_NREGS (src1, halfmode); + unsigned int halfregs = REG_NREGS (operands[1]); rtx destlo, desthi; gcc_assert (halfmode == V16QImode); Index: gcc/config/arm/arm.c === --- gcc/config/arm/arm.c2017-09-11 17:14:25.531400365 +0100 +++ gcc/config/arm/arm.c2017-09-11 17:16:57.874552121 +0100 @@ -18589,7 +18589,7 @@ output_move_neon (rtx *operands) gcc_assert (REG_P (reg)); regno = REGNO (reg); - nregs = HARD_REGNO_NREGS (regno, mode) / 2; + nregs = REG_NREGS (reg) / 2; gcc_assert (VFP_REGNO_OK_FOR_DOUBLE (regno) || NEON_REGNO_OK_FOR_QUAD (regno)); gcc_assert (VALID_NEON_DREG_MODE (mode) @@ -18722,7 +18722,6 @@ arm_attr_length_move_neon (rtx_insn *ins gcc_assert (MEM_P (mem)); - mode = GET_MODE (reg); addr = XEXP (mem, 0); /* Strip off const from addresses like (const (plus (...))). */ @@ -18731,7 +18730,7 @@ arm_attr_length_move_neon (rtx_insn *ins if (GET_CODE (addr) == LABEL_REF || GET_CODE (addr) == PLUS) { - int insns = HARD_REGNO_NREGS (REGNO (reg), mode) / 2; + int insns = REG_NREGS (reg) / 2; return insns * 4; } else @@ -23713,7 +23712,7 @@ neon_split_vcombine (rtx operands[3]) unsigned int src1 = REGNO (operands[1]); unsigned int src2 = REGNO (operands[2]); machine_mode halfmode = GET_MODE (operands[1]); - unsigned int halfregs = HARD_REGNO_NREGS (src1, halfmode); + unsigned int halfregs = REG_NREGS (operands[1]); rtx destlo, desthi; if (src1 == dest && src2 == dest + halfregs) Index: gcc/config/c6x/c6x.c === --- gcc/config/c6x/c6x.c2017-09-11 17:14:25.531400365 +0100 +++ gcc/config/c6x/c6x.c2017-09-11 17:16:57.875552068 +0100 @@ -4025,7 +4025,7 @@ c6x_mark_regno_
Turn SLOW_UNALIGNED_ACCESS into a target hook
Pretty mechanical conversion. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. Also tested by comparing the testsuite assembly output on at least one target per CPU directory. OK to install? Richard 2017-09-11 Richard Sandiford Alan Hayward David Sherwood gcc/ * defaults.h (SLOW_UNALIGNED_ACCESS): Delete. * target.def (slow_unaligned_access): New hook. * targhooks.h (default_slow_unaligned_access): Declare. * targhooks.c (default_slow_unaligned_access): New function. * doc/tm.texi.in (SLOW_UNALIGNED_ACCESS): Replace with... (TARGET_SLOW_UNALIGNED_ACCESS): ...this. * doc/tm.texi: Regenerate. * config/alpha/alpha.h (SLOW_UNALIGNED_ACCESS): Delete. * config/arm/arm.h (SLOW_UNALIGNED_ACCESS): Delete. * config/i386/i386.h (SLOW_UNALIGNED_ACCESS): Delete commented-out definition. * config/powerpcspe/powerpcspe.h (SLOW_UNALIGNED_ACCESS): Delete. * config/powerpcspe/powerpcspe.c (TARGET_SLOW_UNALIGNED_ACCESS): Redefine. (rs6000_slow_unaligned_access): New function. (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS. (expand_block_compare): Likewise. (expand_strn_compare): Likewise. (rs6000_rtx_costs): Likewise. * config/riscv/riscv.h (SLOW_UNALIGNED_ACCESS): Delete. (riscv_slow_unaligned_access): Likewise. * config/riscv/riscv.c (riscv_slow_unaligned_access): Rename to... (riscv_slow_unaligned_access_p): ...this and make static. (riscv_option_override): Update accordingly. (riscv_slow_unaligned_access): New function. (TARGET_SLOW_UNALIGNED_ACCESS): Redefine. * config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Delete. * config/rs6000/rs6000.c (TARGET_SLOW_UNALIGNED_ACCESS): Redefine. (rs6000_slow_unaligned_access): New function. (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS. (rs6000_rtx_costs): Likewise. * config/rs6000/rs6000-string.c (expand_block_compare) (expand_strn_compare): Use targetm.slow_unaligned_access instead of SLOW_UNALIGNED_ACCESS. * config/tilegx/tilegx.h (SLOW_UNALIGNED_ACCESS): Delete. * config/tilepro/tilepro.h (SLOW_UNALIGNED_ACCESS): Delete. * calls.c (expand_call): Use targetm.slow_unaligned_access instead of SLOW_UNALIGNED_ACCESS. * expmed.c (simple_mem_bitfield_p): Likewise. * expr.c (alignment_for_piecewise_move): Likewise. (emit_group_load_1): Likewise. (emit_group_store): Likewise. (copy_blkmode_from_reg): Likewise. (emit_push_insn): Likewise. (expand_assignment): Likewise. (store_field): Likewise. (expand_expr_real_1): Likewise. * gimple-fold.c (gimple_fold_builtin_memory_op): Likewise. * lra-constraints.c (simplify_operand_subreg): Likewise. * stor-layout.c (bit_field_mode_iterator::next_mode): Likewise. * gimple-ssa-store-merging.c: Likewise in block comment at start of file. * tree-ssa-strlen.c: Include target.h. (handle_builtin_memcmp): Use targetm.slow_unaligned_access instead of SLOW_UNALIGNED_ACCESS. * system.h (SLOW_UNALIGNED_ACCESS): Poison.
Re: [PATCH 10/13] D: The D runtime library and license.
On 05/28/2017 03:47 PM, Iain Buclaw wrote: > This patch adds the D runtime library and license (Boost) files. D > runtime is a low level that implements the building blocks of the > runtime environment, as well as C and C++ platform bindings. Many > high level operations are lowered to generate calls to various > functions defined in this library. > > I've uploaded the patch to my ftp, sorry about the impromptu of this, > I had everything neatly lined up, but stumbled after being rejected by > the mail daemon. So with libphobos the big question is whether or not the library is supposed to be a part of GCC or if we're just a downstream user of a library with a reasonably permissive license (and I'm going to assume that all the files are under a suitable license, I spot checked, but did not look at each and every one). There's a lot of code in here I'd want to look at more closely if we're maintaining it within the GCC project, but which I'd let go if we're strictly downstream. Jeff
Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)
On 04/09/17 16:48 +0100, Jonathan Wakely wrote: On 30/07/17 15:01 +0200, Daniel Krügler wrote: 2017-07-28 22:40 GMT+02:00 Daniel Krügler : 2017-07-28 22:29 GMT+02:00 Daniel Krügler : 2017-07-28 22:25 GMT+02:00 Tim Song : On Fri, Jul 28, 2017 at 4:10 PM, Daniel Krügler wrote: + // Performs an implicit conversion from _Tp to __sv_type. + template +static __sv_type _S_to_string_view(const _Tp& __svt) +{ + return __svt; +} I might have gone for +static __sv_type _S_to_string_view(__sv_type __svt) noexcept +{ + return __svt; +} With that, we can also use noexcept(_S_to_string_view(__t)) to make up for the absence of is_nothrow_convertible (basically the same thing I did in LWG 2993's PR). Agreed, that makes very much sense. I will adjust the P/R, but before I resubmit I would like to get feedback whether the other two compare functions also should become conditionally noexcept. Locally I have now performed the sole change of the _S_to_string_view declaration getting rid of the template, but would also like to gather feedback from the maintainers whether I should also change the form of the conditional noexcept to use the expression noexcept(_S_to_string_view(__t)) instead of the current is_same<_Tp, __sv_type>::value as suggested by Tim Song. I'm asking also, because I have a paper proposing to standardize is_nothrow_convertible submitted for the upcoming C++ mailing - This would be one of the first applications in the library ;-) A slightly revised patch update: It replaces the _S_to_string_view template by a simpler _S_to_string_view function as of Tim Song's suggestion, but still uses the simplified noexcept specification deferring it to a future application case for is_nothrow_convertible. Furthermore now all three compare function templates are now (conditionally) noexcept by an (off-list) suggestion from Jonathan Wakely. I've committed this, after some whitespace fixes and testing. Thanks! We also need this tweak, to account for the fact that the old std::string has this signature: basic_string& replace(iterator __i1, iterator __i2, initializer_list<_CharT> __l) Tested powerpc64le-linux, committed to trunk. commit c435fd7ed919ae54fc8f730844c7466822787ff8 Author: Jonathan Wakely Date: Mon Sep 11 17:29:34 2017 +0100 Adjust test to pass with old std::string * testsuite/21_strings/basic_string/lwg2946.cc: Adjust for compatibility with old COW std::string. diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/lwg2946.cc b/libstdc++-v3/testsuite/21_strings/basic_string/lwg2946.cc index 74d5a5c89a7..fe1f15553fb 100644 --- a/libstdc++-v3/testsuite/21_strings/basic_string/lwg2946.cc +++ b/libstdc++-v3/testsuite/21_strings/basic_string/lwg2946.cc @@ -29,7 +29,7 @@ int main() s.assign({"abc", 1}); s.insert(0, {"abc", 1}); s.replace(0, 1, {"abc", 1}); - s.replace(s.cbegin(), s.cbegin(), {"abc", 1}); + s.replace(s.begin(), s.begin(), {"abc", 1}); s.find({"abc", 1}); s.rfind({"abc", 1}); s.find_first_of({"abc", 1});
Re: [PATCH v2 11/13] D: GCC builtins and runtime support.
On 06/24/2017 11:53 AM, Iain Buclaw wrote: > On 28 May 2017 at 23:17, Iain Buclaw wrote: >> This patch adds GCC builtins and runtime support for GDC compiled code. >> >> - module __entrypoint defines the C main function. Its contents are >> parsed and compiled in during compilation, but only if needed. >> - module gcc.atomic is a deprecated module that defines templated >> __sync builtins. It's original user, core.atomic, now uses the GCC >> __atomic builtins. >> - module gcc.attribute exposes GDC-specific attributes. >> - module gcc.backtrace implements backtrace support for GDC. >> - module gcc.builtins exposes GCC builtins to D code. >> - module gcc.config exposes things determined at configure time to D code. >> - module gcc.deh implements D unwind EH. >> - module gcc.libbacktrace defines C bindings to libbacktrace. >> - module gcc.unwind defines C bindings to libgcc unwind library. >> - libgphobos.spec contains a list of libraries to link in that are >> dependencies of D runtime and/or the Phobos standard library. It is >> used by the GDC driver. >> >> --- > Added GCC Runtime Library Exception to gcc modules as requested. Nothing particularly concerning here now that the license is fixed. Based on my reading, this is all code that the FSF will own, so we don't have to worry about alternate upstreams, license exceptions, etc which makes things so much easier. You may need to bump the copyright dates. jeff
Re: [PATCH 6/13] D: Add D language support to GCC proper.
On 05/28/2017 03:15 PM, Iain Buclaw wrote: > This patch adds D language support to GCC itself. > > --- > > > 06-d-gcc-proper.patch > > > gcc/ChangeLog > > * config/rs6000/rs6000.c (rs6000_output_function_epilogue): > Support GNU D by using 0 as the language type. > * dwarf2out.c (is_dlang): New function. > (gen_compile_unit_die): Use DW_LANG_D for D. > (declare_in_namespace): Return module die for D, instead of adding > extra declarations into the namespace. > (gen_namespace_die): Generate DW_TAG_module for D. > (gen_decl_die, dwarf2out_decl): Handle CONST_DECLSs for D. > * gcc.c (default_compilers): Add entries for ".d", ".dd" and ".di".This > is fine when prereqs are approved. jeff
Re: [PATCH 5/13] D: GCC configuration file changes and documentation.
On 05/28/2017 03:15 PM, Iain Buclaw wrote: > This patch adds the D language front-end to GCC documentation and > configuration files, as described on the anatomy of a language > front-end. > > --- > > > 05-d-gcc-config.patch > > > ChangeLog: > > * Makefile.def (target_modules): Add libphobos. > (flags_to_pass): Add GDC_FOR_TARGET. > (dependencies): Add dependency from configure-target-libphobos to > configure-target-zlib. Add dependency from all-target-libphobos to > all-target-zlib. > (language): Add languge d. > * Makefile.in: Rebuild. > * Makefile.tpl (BUILT_EXPORTS): Add GDC. > (HOST_EXPORTS): Add GDC. > (BASE_TARGET_EXPORTS): Add GDC. > (GDC_FOR_BUILD, GDC_FOR_TARGET): New variables. > (EXTRA_HOST_FLAGS): Add GDC. > (EXTRA_TARGET_FLAGS): Add GDC. > * config-ml.in: Treat GDC and GDCFLAGS like other compiler/flag > environment variables. > * configure: Rebuild. > * configure.ac: Add target-libphobos to target_libraries. Set and > substitute GDC_FOR_BUILD and GDC_FOR_TARGET. > > config/ChangeLog: > > * multi.m4: Set GDC. > > gcc/ChangeLog: > > * doc/contrib.texi (Contributors): Add self for the D frontend. > * doc/frontends.texi (G++ and GCC): Mention D as a supported language. > * doc/install.texi (Configuration): Mention libphobos as an option for > --enable-shared. Mention d as an option for --enable-languages. > (Testing): Mention check-d as a target. > * doc/invoke.texi (Overall Options): Mention .d, .dd, and .di as file > name suffixes. Mention d as a -x option. > * doc/sourcebuild.texi (Top Level): Mention libphobos. > * doc/standards.texi (Standards): Add section on D language. I don't see anything in here which concerns me -- it's mostly boilerplate stuff. Jeff
[PATCH, rs6000] add vectorization to vec_mule and vec_mulo builtins
GCC Maintainers: The following patch re-adds the vectorization support for the vec_mule() and vec_mul0() builtins to the tree. The vectorization support was part of the original patch, commit 249424, to add the builtin funtionality. But the vectorization part was pulled as part of commit 250295 due to an underlying bug in the GCC vectorization support. Bill Schmidt fixed the underlying vectorization support in commit 251161 on 8/16/17 allowing the vectorization support to be re-added for these builtins. I have tested the patch on powerpc64le-unknown-linux-gnu (Power 8 LE), powerpc64-unknown-linux-gnu (Power 8 BE) systems with no regressions. Please let me know if the following patch is acceptable. Thanks. Carl Love gcc/ChangeLog: 2017-09-11 Carl Love * config/rs6000/altivec.md (vec_widen_umult_even_v4si, vec_widen_smult_even_v4si): Add define expands for vmuleuw, vmulesw, vmulouw, vmulosw. * config/rs6000/rs6000-builtin.def (VMLEUW, VMULESW, VMULOUW, VMULOSW): Add definitions. * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add ALTIVEC_BUILTIN_VMULESW, ALTIVEC_BUILTIN_VMULEUW, ALTIVEC_BUILTIN_VMULOSW, ALTIVEC_BUILTIN_VMULOUW entries. * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin, builtin_function_type): Add ALTIVEC_BUILTIN_* case statements. --- gcc/config/rs6000/altivec.md | 54 gcc/config/rs6000/rs6000-builtin.def | 8 +++--- gcc/config/rs6000/rs6000-c.c | 9 ++ gcc/config/rs6000/rs6000.c | 4 +++ 4 files changed, 71 insertions(+), 4 deletions(-) diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md index 0aa1e30..168cdb3 100644 --- a/gcc/config/rs6000/altivec.md +++ b/gcc/config/rs6000/altivec.md @@ -1428,6 +1428,32 @@ DONE; }) +(define_expand "vec_widen_umult_even_v4si" + [(use (match_operand:V2DI 0 "register_operand")) + (use (match_operand:V4SI 1 "register_operand")) + (use (match_operand:V4SI 2 "register_operand"))] + "TARGET_P8_VECTOR" +{ + if (VECTOR_ELT_ORDER_BIG) +emit_insn (gen_altivec_vmuleuw (operands[0], operands[1], operands[2])); + else +emit_insn (gen_altivec_vmulouw (operands[0], operands[1], operands[2])); + DONE; +}) + +(define_expand "vec_widen_smult_even_v4si" + [(use (match_operand:V2DI 0 "register_operand")) + (use (match_operand:V4SI 1 "register_operand")) + (use (match_operand:V4SI 2 "register_operand"))] + "TARGET_P8_VECTOR" +{ + if (VECTOR_ELT_ORDER_BIG) +emit_insn (gen_altivec_vmulesw (operands[0], operands[1], operands[2])); + else +emit_insn (gen_altivec_vmulosw (operands[0], operands[1], operands[2])); + DONE; +}) + (define_expand "vec_widen_umult_odd_v16qi" [(use (match_operand:V8HI 0 "register_operand" "")) (use (match_operand:V16QI 1 "register_operand" "")) @@ -1480,6 +1506,34 @@ DONE; }) +(define_expand "vec_widen_umult_odd_v4si" + [(use (match_operand:V2DI 0 "register_operand")) + (use (match_operand:V4SI 1 "register_operand")) + (use (match_operand:V4SI 2 "register_operand"))] + "TARGET_P8_VECTOR" +{ + if (VECTOR_ELT_ORDER_BIG) +emit_insn (gen_altivec_vmulouw (operands[0], operands[1], operands[2])); + else +emit_insn (gen_altivec_vmuleuw (operands[0], operands[1], operands[2])); + DONE; +}) + +(define_expand "vec_widen_smult_odd_v4si" + [(use (match_operand:V2DI 0 "register_operand" "")) + (use (match_operand:V4SI 1 "register_operand" "")) + (use (match_operand:V4SI 2 "register_operand" ""))] + "TARGET_P8_VECTOR" +{ + if (VECTOR_ELT_ORDER_BIG) +emit_insn (gen_altivec_vmulosw (operands[0], operands[1], + operands[2])); + else +emit_insn (gen_altivec_vmulesw (operands[0], operands[1], + operands[2])); + DONE; +}) + (define_insn "altivec_vmuleub" [(set (match_operand:V8HI 0 "register_operand" "=v") (unspec:V8HI [(match_operand:V16QI 1 "register_operand" "v") diff --git a/gcc/config/rs6000/rs6000-builtin.def b/gcc/config/rs6000/rs6000-builtin.def index 850164a..18db576 100644 --- a/gcc/config/rs6000/rs6000-builtin.def +++ b/gcc/config/rs6000/rs6000-builtin.def @@ -1031,14 +1031,14 @@ BU_ALTIVEC_2 (VMULEUB,"vmuleub",CONST, vec_widen_umult_even_v16qi) BU_ALTIVEC_2 (VMULESB, "vmulesb",CONST, vec_widen_smult_even_v16qi) BU_ALTIVEC_2 (VMULEUH, "vmuleuh",CONST, vec_widen_umult_even_v8hi) BU_ALTIVEC_2 (VMULESH, "vmulesh",CONST, vec_widen_smult_even_v8hi) -BU_ALTIVEC_2 (VMULEUW, "vmuleuw",CONST, altivec_vmuleuw) -BU_ALTIVEC_2 (VMULESW, "vmulesw",CONST, altivec_vmulesw) +BU_ALTIVEC_2 (VMULEUW, "vmuleuw",CONST, vec_widen_umult_even_v4si) +BU_ALTIVEC_2 (VMULESW, "vmulesw",CONST, vec_widen_
Re: [PING, Makefile] improve libsubdir variable transmission to sub-makes (for Windows)
Hello Michael, > On Sep 11, 2017, at 17:28 , Michael Haubenwallner > wrote: >>> Makefile.in: >>> ... >>> export libsubdir >>> >>> This is not working well on cygwin environments where environment >>> variable names are translated to uppercase (so sub-makes evaluating >>> the variable with the lowercase name don't get the value). > > just wondering if you can't update your Cygwin setup, as turning environment > variables to uppercase is not done by default in recent Cygwin any more, see > https://cygwin.com/cygwin-ug-net/using-cygwinenv.html Thanks for your input and for the pointer! Maybe we could update our environment locally and forget about it. This might be useful for other contexts as well. Now it might be difficult, if not impossible, for some people, so if passing the variable through an explicit assignment is expected to work as well, the change would remain of interest IMO, just removing a dependency on a particular environment setup. With Kind Regards, Olivier
Re: [PATCH 4/13] D: The front-end (GDC) config, makefile, and manpages.
On 05/28/2017 03:12 PM, Iain Buclaw wrote: > This patch adds the D frontend language configure make files, as > described on the anatomy of a language front-end. > > --- > > > 04-d-frontend-misc.patch > > > + > +You can specify more than one input file on the @command{gdc} command line, > +in which case they will all be compiled. If you specify a > +@code{-o @var{file}} option, all the input files will be compiled together, > +producing a single output file, named @var{file}. This is allowed even > +when using @code{-S} or @code{-c}. So out of curiosity, when multiple sources are specified on the command line, are they subject to IPA as a group or are they handled individually? > +@item -fno-bounds-check > +@cindex @option{-fbounds-check} > +@cindex @option{-fno-bounds-check} > +Turns off array bounds checking for all functions, which can improve > +performance for code that uses array extensively. Note that this > +can result in unpredictable behavior if the code in question actually > +does violate array bounds constraints. It is safe to use this option > +if you are sure that your code will never throw a @code{RangeError}. So I don't know the internals of where you keep the bounds and how you generate code for checking, but it might be worth looking at what Roger Sayle did for Java array index checking back in 2016: https://gcc.gnu.org/ml/java-patches/2016-q1/msg00014.html I don't know if his trick of exposing an extra write would apply to D, but it's worth reviewing. > + > +@item -funittest > +@cindex @option{-funittest} > +@cindex @option{-fno-unittest} > +Turns on compilation of @code{unittest} code, and turns on the > +@code{version(unittest)} identifier. This implies @option{-fassert}. I think we're using -fselftest elsewhere for unit testing bits within the compiler. Can you look and see if your unit tests are comparable and perhaps consider using the same option if they are? > + > +@node Code Generation > +@section Code Generation > +@cindex options, code generation > + > +In addition to the many @command{gcc} options controlling code generation, > +@command{gdc} has several options specific to itself. > + > +@table @gcctabopt > + > +@item -M > +@cindex @option{-M} > +Output the module dependencies of all source files being compiled in a > +format suitable for @command{make}. The compiler outputs one > +@command{make} rule containing the object file name for that source file, > +a colon, and the names of all imported files. [ ... Many -M options ... ] Note we recently allowed generation of the dependency files even in the case some errors. Please consider doing the same if it makes sense. See the Sept change to c_common_finish. > + > +@c man begin ENVIRONMENT > + > +In addition to the many @command{gcc} environment variables that control > +its operation, @command{gdc} has a few environment variables specific to > +itself. > + > +@vtable @env > + > +@item D_IMPORT_PATH > +@findex D_IMPORT_PATH > +The value of @env{D_IMPORT_PATH} is a list of directories separated by a > +special character, much like @env{PATH}, in which to look for imports. > +The special character, @code{PATH_SEPARATOR}, is target-dependent and > +determined at GCC build time. For Microsoft Windows-based targets it is a > +semicolon, and for almost all other targets it is a colon. > + > +@item DDOCFILE > +@findex DDOCFILE > +If @env{DDOCFILE} is set, it specifies a text file of macro definitions > +to be read and used by the Ddoc generator. This overrides any macros > +defined in other @file{.ddoc} files. How important are the environment variables to the existing user base? We generally try to avoid changing much behavior based on environment variables. Can these be made command line options? jeff
Re: [PATCH 3/13] D: The front-end (GDC) changelogs.
On 05/28/2017 03:11 PM, Iain Buclaw wrote: > This patch just includes all changelogs for the D front-end (GDC), > going back to the dawn of time itself. > > Change logs for the DMD front-end and libraries are kept on the dlang site. Your call on how much of the historical record you want to keep. jeff
Re: [PATCH 2/13] D: The front-end (GDC) implementation.
On 05/28/2017 03:11 PM, Iain Buclaw wrote: > This patch adds the D front-end implementation, the only part of the > compiler that interacts with GCC directly, and being the parts that I > maintain, is something that I can talk about more directly. > > For the actual code generation pass, that converts the front-end AST > to GCC trees, most parts use a separate Visitor interfaces to do a > certain kind of lowering, for instance, types.cc builds *_TYPE trees > from AST Type's. The Visitor class is part of the DMD front-end, and > is defined in dfrontend/visitor.h. > > There are also a few interfaces which have their headers in the DMD > frontend, but are implemented here because they do something that > requires knowledge of the GCC backend (d-target.cc), does something > that may not be portable, or differ between D compilers > (d-frontend.cc) or are a thin wrapper around something that is managed > by GCC (d-diagnostic.cc). > > Many high level operations result in generation of calls to D runtime > library functions (runtime.def), all with require some kind of runtime > type information (typeinfo.cc). The compiler also generates functions > for registering/deregistering compiled modules with the D runtime > library (modules.cc). > > As well as the D language having it's own built-in functions > (intrinsics.cc), we also expose GCC builtins to D code via a > `gcc.builtins' module (d-builtins.cc), and give special treatment to a > number of UDAs that could be applied to functions (d-attribs.cc). > > > That is roughly the high level jist of how things are currently organized. > > Regards > Iain > > --- > Presumably the types and interfaces which are capitalized in violation of GNU standards are done so to interface the the DMD implementation? Which implies the answer to a question in my prior message, namely that the DMD implementation does get linked into GCC itself. So I think we need the SC to rule on whether or not that's allowed. I'm not going to dive deep into this code -- it's essentially converting between the different representations and is code that you'd be maintaining. You probably want to review the #ifdefs you've got in here to make sure they're not supposed to be checked via #if or runtime checks (there's only a half-dozen or so): +#ifdef STACK_GROWS_DOWNWARD +#ifdef HAVE_LD_STATIC_DYNAMIC +#ifdef HAVE_LD_STATIC_DYNAMIC +#ifdef BIGGEST_FIELD_ALIGNMENT +#ifdef ADJUST_FIELD_ALIGN +#ifdef ENABLE_TREE_CHECKING Joseph already commented on Target::critsecsize. Jeff Jeff
Re: [RFC, vectorizer] Allow single element vector types for vector reduction operations
On Tue, Sep 05, 2017 at 03:12:47PM +0200, Richard Biener wrote: > On Tue, 5 Sep 2017, Tamar Christina wrote: > > > > > > > > -Original Message- > > > From: Richard Biener [mailto:rguent...@suse.de] > > > Sent: 05 September 2017 13:51 > > > To: Tamar Christina > > > Cc: Andrew Pinski; Andreas Schwab; Jon Beniston; gcc-patches@gcc.gnu.org; > > > nd > > > Subject: RE: [RFC, vectorizer] Allow single element vector types for > > > vector > > > reduction operations > > > > > > On Tue, 5 Sep 2017, Richard Biener wrote: > > > > > > > On Tue, 5 Sep 2017, Tamar Christina wrote: > > > > > > > > > Hi Richard, > > > > > > > > > > That was an really interesting analysis, thanks for the details! > > > > > > > > > > Would you be submitting the patch you proposed at the end as a fix? > > > > > > > > I'm testing it currently. > > > > > > Unfortunately it breaks some required lowering. I'll have to more closely > > > look at this. > > > > Ah, ok. In the meantime, can this patch be reverted? It's currently > > breaking spec for us so we're > > Not able to get any benchmarking numbers. > > Testing the following instead: Any news on this? VP. > > Index: gcc/tree-vect-generic.c > === > --- gcc/tree-vect-generic.c (revision 251642) > +++ gcc/tree-vect-generic.c (working copy) > @@ -1640,7 +1640,7 @@ expand_vector_operations_1 (gimple_stmt_ >|| code == VEC_UNPACK_FLOAT_LO_EXPR) > type = TREE_TYPE (rhs1); > > - /* For widening/narrowing vector operations, the relevant type is of > the > + /* For widening vector operations, the relevant type is of the > arguments, not the widened result. VEC_UNPACK_FLOAT_*_EXPR is > calculated in the same way above. */ >if (code == WIDEN_SUM_EXPR > @@ -1650,9 +1650,6 @@ expand_vector_operations_1 (gimple_stmt_ >|| code == VEC_WIDEN_MULT_ODD_EXPR >|| code == VEC_UNPACK_HI_EXPR >|| code == VEC_UNPACK_LO_EXPR > - || code == VEC_PACK_TRUNC_EXPR > - || code == VEC_PACK_SAT_EXPR > - || code == VEC_PACK_FIX_TRUNC_EXPR >|| code == VEC_WIDEN_LSHIFT_HI_EXPR >|| code == VEC_WIDEN_LSHIFT_LO_EXPR) > type = TREE_TYPE (rhs1); > > > also fix for a bug uncovered by the previous one: > > Index: gcc/gimple-ssa-strength-reduction.c > === > --- gcc/gimple-ssa-strength-reduction.c (revision 251710) > +++ gcc/gimple-ssa-strength-reduction.c (working copy) > @@ -1742,8 +1742,7 @@ find_candidates_dom_walker::before_dom_c > slsr_process_ref (gs); > >else if (is_gimple_assign (gs) > - && SCALAR_INT_MODE_P > - (TYPE_MODE (TREE_TYPE (gimple_assign_lhs (gs) > + && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (gs > { > tree rhs1 = NULL_TREE, rhs2 = NULL_TREE; > >
Re: [PATCH][ARM] Remove Thumb-2 iordi_not patterns
Any further comments? Kyrill Tkachov wrote: > > After Bernd's change almost all DI mode instructions are split before > > register > > allocation. So instructions using DI mode no longer exist and thus these > > extend variants can never be matched and are thus redundant. > > Bernd's patch splits them when we don't have NEON. When NEON is > available though > they still maintain the DImode so we'd still benefit from these > transformations, no? While you're right it may be possible to trigger these instructions, ORN is already so rare that it is hardly beneficial to have an instruction for it, and ORN of an extended value never ever happens. So there is absolutely no benefit in keeping these versions temporarily until we fix Neon too. For the Neon case my proposal is to use the VFP early expansion (so you get an efficient expansion by default in all cases). You can then use -mneon-for-64bits to enable the use of Neon instructions (which may be even better in some cases). There are quite a few patches in this series already and more to come soon! Wilco
Re: [PING, Makefile] improve libsubdir variable transmission to sub-makes (for Windows)
Hi Oliver, On 09/11/2017 04:30 PM, Olivier Hainque wrote: > Hello, > > Ping for https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00017.html > >> Makefile.in: >> ... >> export libsubdir >> >> This is not working well on cygwin environments where environment >> variable names are translated to uppercase (so sub-makes evaluating >> the variable with the lowercase name don't get the value). just wondering if you can't update your Cygwin setup, as turning environment variables to uppercase is not done by default in recent Cygwin any more, see https://cygwin.com/cygwin-ug-net/using-cygwinenv.html /haubi/
RE: [PATCH] Add 'short_call' attribute for MIPS targets
Simon Atanasyan writes: > Here is the updated patch with chnaged e-mail address and fixed > indentation issues: > -8< > Currently GCC supports 'long_call', 'far', and 'near' attributes. The > 'long_call' and 'far' attributes are synonyms. This patch adds support > for the 'short_call' attribute as a synonym for `near` to make this list > complete, consistent with other targets, and compatible with attributes > supported by the Clang. > > Tested on mipsel-linux-gnu. > > 2017-08-18 Simon Atanasyan > > gcc/ > * config/mips/mips.c (mips_attribute_table): Add 'short_call' > attribute. > (mips_near_type_p): Add 'short_call' attribute as a synonym > for 'near'. > * doc/extend.texi (short_call): Document new function attribute. > > gcc/testsuite > > * gcc.target/mips/near-far-1.c: Add check for 'short_call' > attribute. > * gcc.target/mips/near-far-2.c: Likewise. > * gcc.target/mips/near-far-3.c: Likewise. > * gcc.target/mips/near-far-4.c: Likewise. OK to commit, thanks. Matthew
Re: [PATCH 1/13] D: The front-end (DMD) language implementation and license.
On 05/28/2017 03:02 PM, Iain Buclaw wrote: > (Sorry, repost as I rushed the first one a bit). > > This patch adds the DMD front-end proper and license (Boost) files, > comprised of a lexer, parser, and semantic analyzer. > > Split 1/4 > > Gzipped because of size limitations. So for 1/13, these are all bits that are maintained on github and we're just a downstream user, right? Meaning I don't need to do a deep dive in this patch within the series, right? Does this stuff get bound into GCC? The reason I ask is the files are under the Boost license with ownership by Digital Mars. While we often have a fair amount of leeway with runtime systems, we may not have the same kind of license/ownership leeway with things that are actually part of the compiler itself. Did the discussions between the FSF, Digital Mars and Walter touch in these issues at all? Have you received any guidance from the parties on this issue? Is there any way this stuff could be a separate executable or DSO? That might make things easier on the licensing front. Jeff
Re: [PING, Makefile] improve default cpu selection for e500v2
Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01783.html > config.gcc already has a provision for a good default > cpu selection for SPE with double precision floats > when the latter is explicitly requested with an explicit > --enable command line option. ... > The attached patch is a proposal to refine this to select 8548 also > when we were configured for an e500v2 target cpu (canonicalized to > match powerpc-*spe), regardless of enable_e500_double. > 2017-08-31 Olivier Hainque > >* gcc/config.gcc (powerpc*-*-*spe*): Pick 8548 as the > default with_cpu for an e500v2 target cpu name, in addition > to --enable-e500-double. Thanks in advance, With Kind Regards, Olivier
Re: [PING, Makefile] improve libsubdir variable transmission to sub-makes (for Windows)
Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00017.html > Makefile.in: > ... > export libsubdir > > This is not working well on cygwin environments where environment > variable names are translated to uppercase (so sub-makes evaluating > the variable with the lowercase name don't get the value). > 2017-09-01 Jerome Lambourg > > * Makefile.in (FLAGS_TO_PASS): Add libsubdir. Thanks much in advance! With Kind Regards, Olivier
Re: [COMMITTED][arm] Revert r251800 & r251799
Now with the patch :-) VP. On Mon, Sep 11, 2017 at 03:20:12PM +0100, Vidya Praveen wrote: > Hello, > > The following two related patches need to be reverted as it causes > cross-native > builds to fail with the following message: > > g++ -c -DIN_GCC -DGENERATOR_FILE -I. [...] \ > -o build/genpreds.o /path/to/src/gcc/gcc/genpreds.c > In file included from ./options.h:8:0, > from ./tm.h:23, > from /path/to/src/gcc/gcc/genpreds.c:26: > /path/to/src/gcc/gcc/config/arm/arm-opts.h:29:21: fatal error: arm-isa.h: No > such file or directory > #include "arm-isa.h" > ^ > genpreds depends on GTM_H which does not depend on options.h, or any of its > dependencies. Nevertheless, it still tries to include options.h when reading > tm.h, so we miss the rule to build arm-isa.h. It is unclear why it is only an > issue with the cross-native builds. > > For now, in order to keep the builds going, I am reverting these patches. > > > r251800 | rearnsha | 2017-09-06 14:42:54 +0100 (Wed, 06 Sep 2017) | 16 lines > > [arm] Improve error checking in parsecpu.awk > > This patch adds a bit more error checking to parsecpu.awk to ensure > that statements are not missing arguments or have excess arguments > beyond those permitted. It also slightly improves the handling of > errors so that we terminate properly if parsing fails and be as > helpful as we can while in the parsing phase. > > * config/arm/parsecpu.awk (fatal): Note that we've encountered an > error. Only quit immediately if parsing is complete. > (BEGIN): Initialize fatal_err and parse_done. > (begin fpu, end fpu): Check number of arguments. > (begin arch, end arch): Likewise. > (begin cpu, end cpu): Likewise. > (cname, tune for, tune flags, architecture, fpu, option): Likewise. > (optalias): Likewise. > > r251799 | rearnsha | 2017-09-06 14:42:46 +0100 (Wed, 06 Sep 2017) | 31 lines > > [arm] auto-generate arm-isa.h from CPU descriptions > > This patch autogenerates arm-isa.h from new entries in arm-cpus.in. > This has the primary advantage that it makes the description file more > self-contained, but it also solves the 'array dimensioning' problem > that Tamar recently encountered. It adds two new constructs to > arm-cpus.in: features and fgroups. Fgroups are simply a way of naming > a group of feature bits so that they can be referenced together. We > follow the convention that feature bits are all lower case, while > fgroups are (predominantly) upper case. This is helpful as in some > contexts they share the same namespace. Most of the minor changes in > this patch are related to adopting this new naming convention. > > * config.gcc (arm*-*-*): Don't add arm-isa.h to tm_p_file. > * config/arm/arm-isa.h: Delete. Move definitions to ... > * arm-cpus.in: ... here. Use new feature and fgroup values. > * config/arm/arm.c (arm_option_override): Use lower case for feature > bit names. > * config/arm/arm.h (TARGET_HARD_FLOAT): Likewise. > (TARGET_VFP3, TARGET_VFP5, TARGET_FMA): Likewise. > * config/arm/parsecpu.awk (END): Add new command 'isa'. > (isa_pfx): Delete. > (print_isa_bits_for): New function. > (gen_isa): New function. > (gen_comm_data): Use print_isa_bits_for. > (define feature): New keyword. > (define fgroup): New keyword. > * config/arm/t-arm (OPTIONS_H_EXTRA): Add arm-isa.h > (arm-isa.h): Add rule to generate file. > * common/config/arm/arm-common.c: (arm_canon_arch_option): Use lower > case for feature bit names. > > Regards, > VP. > > > gcc/ChangeLog: > > 2017-09-11 Vidya Praveen > > Revert r251800 and r251799. diff --git a/gcc/common/config/arm/arm-common.c b/gcc/common/config/arm/arm-common.c index 7cb99ec..38bd3a7 100644 --- a/gcc/common/config/arm/arm-common.c +++ b/gcc/common/config/arm/arm-common.c @@ -574,7 +574,7 @@ arm_canon_arch_option (int argc, const char **argv) { /* The easiest and safest way to remove the default fpu capabilities is to look for a '+no..' option that removes - the base FPU bit (isa_bit_vfpv2). If that doesn't exist + the base FPU bit (isa_bit_VFPv2). If that doesn't exist then the best we can do is strip out all the bits that might be part of the most capable FPU we know about, which is "crypto-neon-fp-armv8". */ @@ -586,7 +586,7 @@ arm_canon_arch_option (int argc, const char **argv) ++ext) { if (ext->remove - && check_isa_bits_for (ext->isa_bits, isa_bit_vfpv2)) + && check_isa_bits_for (ext->isa_bits, isa_bit_VFPv2)) { arm_initialize_isa (fpu_isa, ext->isa_bits); bitmap_and_compl (target_isa, target_isa, fpu_isa); @@ -620,7 +620,7 @@ arm_canon_arch_option (int argc, const char **argv) { /* Clearing the VFPv2
[COMMITTED][arm] Revert r251800 & r251799
Hello, The following two related patches need to be reverted as it causes cross-native builds to fail with the following message: g++ -c -DIN_GCC -DGENERATOR_FILE -I. [...] \ -o build/genpreds.o /path/to/src/gcc/gcc/genpreds.c In file included from ./options.h:8:0, from ./tm.h:23, from /path/to/src/gcc/gcc/genpreds.c:26: /path/to/src/gcc/gcc/config/arm/arm-opts.h:29:21: fatal error: arm-isa.h: No such file or directory #include "arm-isa.h" ^ genpreds depends on GTM_H which does not depend on options.h, or any of its dependencies. Nevertheless, it still tries to include options.h when reading tm.h, so we miss the rule to build arm-isa.h. It is unclear why it is only an issue with the cross-native builds. For now, in order to keep the builds going, I am reverting these patches. r251800 | rearnsha | 2017-09-06 14:42:54 +0100 (Wed, 06 Sep 2017) | 16 lines [arm] Improve error checking in parsecpu.awk This patch adds a bit more error checking to parsecpu.awk to ensure that statements are not missing arguments or have excess arguments beyond those permitted. It also slightly improves the handling of errors so that we terminate properly if parsing fails and be as helpful as we can while in the parsing phase. * config/arm/parsecpu.awk (fatal): Note that we've encountered an error. Only quit immediately if parsing is complete. (BEGIN): Initialize fatal_err and parse_done. (begin fpu, end fpu): Check number of arguments. (begin arch, end arch): Likewise. (begin cpu, end cpu): Likewise. (cname, tune for, tune flags, architecture, fpu, option): Likewise. (optalias): Likewise. r251799 | rearnsha | 2017-09-06 14:42:46 +0100 (Wed, 06 Sep 2017) | 31 lines [arm] auto-generate arm-isa.h from CPU descriptions This patch autogenerates arm-isa.h from new entries in arm-cpus.in. This has the primary advantage that it makes the description file more self-contained, but it also solves the 'array dimensioning' problem that Tamar recently encountered. It adds two new constructs to arm-cpus.in: features and fgroups. Fgroups are simply a way of naming a group of feature bits so that they can be referenced together. We follow the convention that feature bits are all lower case, while fgroups are (predominantly) upper case. This is helpful as in some contexts they share the same namespace. Most of the minor changes in this patch are related to adopting this new naming convention. * config.gcc (arm*-*-*): Don't add arm-isa.h to tm_p_file. * config/arm/arm-isa.h: Delete. Move definitions to ... * arm-cpus.in: ... here. Use new feature and fgroup values. * config/arm/arm.c (arm_option_override): Use lower case for feature bit names. * config/arm/arm.h (TARGET_HARD_FLOAT): Likewise. (TARGET_VFP3, TARGET_VFP5, TARGET_FMA): Likewise. * config/arm/parsecpu.awk (END): Add new command 'isa'. (isa_pfx): Delete. (print_isa_bits_for): New function. (gen_isa): New function. (gen_comm_data): Use print_isa_bits_for. (define feature): New keyword. (define fgroup): New keyword. * config/arm/t-arm (OPTIONS_H_EXTRA): Add arm-isa.h (arm-isa.h): Add rule to generate file. * common/config/arm/arm-common.c: (arm_canon_arch_option): Use lower case for feature bit names. Regards, VP. gcc/ChangeLog: 2017-09-11 Vidya Praveen Revert r251800 and r251799.
Re: Announcing ARM and AArch64 port maintainers.
On 09/09/17 12:44, Ramana Radhakrishnan wrote: I'm pleased to announce that the steering committee has appointed - James Greenhalgh as a full maintainer for the AArch64 port and - Kyrylo Tkachov as a full maintainer for the ARM port. James & Kyrylo, if you could update your entries in the MAINTAINERS file to reflect these roles, it would be appreciated. Thank you for your trust. I look forward to continuing contributing to GCC! I've committed this patch to trunk as r251979. Kyrill 2017-09-11 Kyrylo Tkachov * MAINTAINERS (Reviewers): Move myself from here... (CPU Port Maintainers): ... to here. commit ec06d430aba1698fa4e653b8dc93bcad10852fb3 Author: Kyrylo Tkachov Date: Mon Sep 11 10:27:00 2017 +0100 [MAINTAINERS] Add myself as ARM maintainer diff --git a/MAINTAINERS b/MAINTAINERS index 2ed1ef9..e5b9bc1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -47,6 +47,7 @@ arc port Joern Rennecke arm port Nick Clifton arm port Richard Earnshaw arm port Ramana Radhakrishnan +arm port Kyrylo Tkachov avr port Denis Chertykov bfin port Jie Zhang c6x port Bernd Schmidt @@ -252,7 +253,6 @@ check in changes outside of the parts of the compiler they maintain. arc port Andrew Burgess arc port Claudiu Zissulescu -arm port Kyrylo Tkachov C front end Marek Polacek dataflow Paolo Bonzini dataflow Seongbae Park
Re: [PATCH] Improve alloca alignment
Eric Botcazou wrote: >> No, the stack never gets misaligned - my patch doesn't change that at all. > > Yes, it does. No. Look at the diffs, there is not a single change in alignment anywhere for all of the alloca variants. If the alignment is incorrect after my patch, it is also incorrect before my patch. This is the diff for pr78668.c on AArch64: >diff pr78668.before pr78668.after < add x0, x0, 18 --- > add x0, x0, 15 90c90 < add x0, x0, 18 --- > add x0, x0, 15 120c120 < add x0, x0, 22 --- > add x0, x0, 15 149c149 < add x0, x0, 22 --- > add x0, x0, 15 179c179 < add x0, x0, 30 --- > add x0, x0, 15 208c208 < add x0, x0, 30 --- > add x0, x0, 15 238c238 < add x0, x0, 46 --- > add x0, x0, 31 268c268 < add x0, x0, 46 --- > add x0, x0, 31 The mid-end always ensures that the stack is decremented by a value that is a multiple of STACK_BOUNDARY. My change does not make any difference here, but if SP is not aligned to STACK_BOUNDARY then it's obviously broken before my patch. For example the relevant instructions for t2_a8 are: add x0, x0, 15 and x0, x0, -16 sub sp, sp, x0 add x0, sp, 32 As you can see, it always rounds up and aligns to STACK_BOUNDARY before adjusting SP. When computing the final alloca address (the last add above) you must also keep that STACK_BOUNDARY alignment. To conclude my change just avoids inserting redundant padding based on the alignment promise that is made by the backend. The alignment itself is unchanged and is already incorrect on Sparc before my change. >> The issue is that Sparc backend doesn't correctly set STACK_BOUNDSARY and >> neither aligns the outgoing args. Run my test which proves alloca was >> broken before my patch. > > How could this have been broken for so long, realistically? The SPARC back- > end is parameterized according to the ABI and the documented interface > between > middle-end and back-end. It clearly gets the ABI wrong as it sets STACK_BOUNDARY and then doesn't keep the alignment promise it makes. Wilco
Re: [PATCH] Add 'short_call' attribute for MIPS targets
Here is the updated patch with chnaged e-mail address and fixed indentation issues: -8< Currently GCC supports 'long_call', 'far', and 'near' attributes. The 'long_call' and 'far' attributes are synonyms. This patch adds support for the 'short_call' attribute as a synonym for `near` to make this list complete, consistent with other targets, and compatible with attributes supported by the Clang. Tested on mipsel-linux-gnu. 2017-08-18 Simon Atanasyan gcc/ * config/mips/mips.c (mips_attribute_table): Add 'short_call' attribute. (mips_near_type_p): Add 'short_call' attribute as a synonym for 'near'. * doc/extend.texi (short_call): Document new function attribute. gcc/testsuite * gcc.target/mips/near-far-1.c: Add check for 'short_call' attribute. * gcc.target/mips/near-far-2.c: Likewise. * gcc.target/mips/near-far-3.c: Likewise. * gcc.target/mips/near-far-4.c: Likewise. Index: gcc/config/mips/mips.c === --- gcc/config/mips/mips.c (revision 251918) +++ gcc/config/mips/mips.c (working copy) @@ -598,6 +598,7 @@ static const struct attribute_spec mips_attribute_ /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler, om_diagnostic } */ { "long_call", 0, 0, false, true, true, NULL, false }, + { "short_call", 0, 0, false, true, true, NULL, false }, { "far",0, 0, false, true, true, NULL, false }, { "near",0, 0, false, true, true, NULL, false }, /* We would really like to treat "mips16" and "nomips16" as type @@ -1171,13 +1172,14 @@ mflip_mips16_use_mips16_p (tree decl) return *slot; } -/* Predicates to test for presence of "near" and "far"/"long_call" +/* Predicates to test for presence of "near"/"short_call" and "far"/"long_call" attributes on the given TYPE. */ static bool mips_near_type_p (const_tree type) { - return lookup_attribute ("near", TYPE_ATTRIBUTES (type)) != NULL; + return (lookup_attribute ("short_call", TYPE_ATTRIBUTES (type)) != NULL + || lookup_attribute ("near", TYPE_ATTRIBUTES (type)) != NULL); } static bool Index: gcc/doc/extend.texi === --- gcc/doc/extend.texi (revision 251918) +++ gcc/doc/extend.texi (working copy) @@ -4528,10 +4528,12 @@ void __attribute__ ((interrupt("vector=hw3"))) v9 @end smallexample @item long_call +@itemx short_call @itemx near @itemx far @cindex indirect calls, MIPS @cindex @code{long_call} function attribute, MIPS +@cindex @code{short_call} function attribute, MIPS @cindex @code{near} function attribute, MIPS @cindex @code{far} function attribute, MIPS These attributes specify how a particular function is called on MIPS@. @@ -4539,8 +4541,9 @@ The attributes override the @option{-mlong-calls} command-line switch. The @code{long_call} and @code{far} attributes are synonyms, and cause the compiler to always call the function by first loading its address into a register, and then using -the contents of that register. The @code{near} attribute has the opposite -effect; it specifies that non-PIC calls should be made using the more +the contents of that register. The @code{short_call} and @code{near} +attributes are synonyms, and have the opposite +effect; they specify that non-PIC calls should be made using the more efficient @code{jal} instruction. @item mips16 Index: gcc/testsuite/gcc.target/mips/near-far-1.c === --- gcc/testsuite/gcc.target/mips/near-far-1.c (revision 251918) +++ gcc/testsuite/gcc.target/mips/near-far-1.c (working copy) @@ -3,6 +3,7 @@ extern int long_call_func () __attribute__((long_call)); extern int far_func () __attribute__((far)); +extern int short_call_func () __attribute__((short_call)); extern int near_func () __attribute__((near)); extern int normal_func (); @@ -10,6 +11,7 @@ int test () { return (long_call_func () + far_func () + + short_call_func () + near_func () + normal_func ()); } @@ -16,5 +18,6 @@ int test () /* { dg-final { scan-assembler-not "\tjal\tlong_call_func\n" } } */ /* { dg-final { scan-assembler-not "\tjal\tfar_func\n" } } */ +/* { dg-final { scan-assembler "\t(jal(|s)|balc)\tshort_call_func\n" } } */ /* { dg-final { scan-assembler "\t(jal(|s)|balc)\tnear_func\n" } } */ /* { dg-final { scan-assembler-not "\tjal\tnormal_func\n" } } */ Index: gcc/testsuite/gcc.target/mips/near-far-2.c === --- gcc/testsuite/gcc.target/mips/near-far-2.c (revision 251918) +++ gcc/testsuite/gcc.target/mips/near-far-2.c (working copy) @@ -3,6 +3,7 @@ extern int long_call_func () __attribute__((long_call)); extern int far_func () __attribute__((far)); +extern int short_call_func () __at
[PING] [PATCH] Add a -Wcast-align=strict warning
Ping... On 09/04/17 10:07, Bernd Edlinger wrote: > Hi, > > as you know we have a -Wcast-align warning which works only for > STRICT_ALIGNMENT targets. But occasionally it would be nice to be > able to switch this warning on even for other targets. > > Therefore I would like to add a strict version of this option > which can be invoked with -Wcast-align=strict. With the only > difference that it does not depend on STRICT_ALIGNMENT. > > I used the code from check_effective_target_non_strict_align > in target-supports.exp for the first version of the test case, > where we have this: > > return [check_no_compiler_messages non_strict_align assembly { > char *y; > typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c; > c *z; > void foo(void) { z = (c *) y; } > } "-Wcast-align"] > > ... and to my big surprise it did _not_ work for C++ as-is, > because same_type_p considers differently aligned types identical, > and therefore cp_build_c_cast tries the conversion first via a > const_cast which succeeds, but did not emit the cast-align warning > in this case. > > As a work-around I had to check the alignment in build_const_cast_1 > as well. > > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? > > > Thanks > Bernd. >
RE: [PATCH] Add 'short_call' attribute for MIPS targets
Simon Atanasyan writes: > Currently GCC supports 'long_call', 'far', and 'near' attributes. The > 'long_call' and 'far' attributes are synonyms. This patch adds support > for the 'short_call' attribute as a synonym for `near` to make this list > complete, consistent with other targets, and compatible with attributes > supported by the Clang. Sorry for the slow reply. Thanks for keeping GCC and Clang in sync. > Tested on mipsel-linux-gnu. > > 2017-08-22 Simon Atanasyan As you do not have a personal copyright assignment on file please can you resubmit using your @imgtec.com address and use that address for the changelog. There are just a couple of indentation issues below as well. > gcc/ > > * config/mips/mips.c (mips_attribute_table): Add 'short_call' attribute. > (mips_near_type_p): Add 'short_call' attribute as a synonym for 'near'. > * doc/extend.texi (short_call): Document new function attribute. > > gcc/testsuite/ > > * gcc.target/mips/near-far-1.c: Add check for 'short_call' attribute. > * gcc.target/mips/near-far-2.c: Likewise. > * gcc.target/mips/near-far-3.c: Likewise. > * gcc.target/mips/near-far-4.c: Likewise. There should be one tab before the lines in each entry * , lines here should be wrapped at 74 cols. > > Index: gcc/config/mips/mips.c > === > --- gcc/config/mips/mips.c (revision 251219) > +++ gcc/config/mips/mips.c (working copy) > @@ -598,6 +598,7 @@ static const struct attribute_spec mips_attribute_ >/* { name, min_len, max_len, decl_req, type_req, fn_type_req, > handler, > om_diagnostic } */ >{ "long_call", 0, 0, false, true, true, NULL, false }, > + { "short_call", 0, 0, false, true, true, NULL, false }, >{ "far", 0, 0, false, true, true, NULL, false }, >{ "near",0, 0, false, true, true, NULL, false }, >/* We would really like to treat "mips16" and "nomips16" as type > @@ -1171,13 +1172,14 @@ mflip_mips16_use_mips16_p (tree decl) >return *slot; > } > > -/* Predicates to test for presence of "near" and "far"/"long_call" > +/* Predicates to test for presence of "near"/"short_call" and > "far"/"long_call" > attributes on the given TYPE. */ > > static bool > mips_near_type_p (const_tree type) > { > - return lookup_attribute ("near", TYPE_ATTRIBUTES (type)) != NULL; > + return (lookup_attribute ("short_call", TYPE_ATTRIBUTES (type)) != > NULL > + || lookup_attribute ("near", TYPE_ATTRIBUTES (type)) != NULL); The || here should be lined up under the 'l' of lookup_attribute above which will be 1-tab 2-space to save you figuring out the indent rules for GCC again. The space indents in the testcases below are fine as they match the existing lines. If you can repost with your @imgtec address then I'll approve that to commit. Thanks, Matthew
[Ada] Another freezing issue on expression function in nested package
This patch totally disables the freezing of an expression function at the point its body is analyzed, as well the freezing of all the types that are not yet frozen, in order to support more cases where the profile contains a type which depends on a private type that is declared in an open scope and does not yet have a completion. The following package must compile quietly: package P is type Forward_Cursor is private; package Nested is type Cursor is access Forward_Cursor; type Rec is record C : Forward_Cursor; end record; function Element (R : Rec; Current : Cursor) return Cursor is (Current); end Nested; private type Forward_Cursor is null record; end P; Tested on x86_64-pc-linux-gnu, committed on trunk 2017-09-11 Eric Botcazou * freeze.adb (Has_Incomplete_Compoent): Delete. (Freeze_Profile): Do not inhibit the freezing of the profile of an expression function here. (Freeze_Subprogram): Do not re-create extra formals. * sem_ch6.adb (Analyze_Expression_Function): Always pre-analyze the expression if the function is not a completion. (Analyze_Subprogram_Body_Helper): For the body generated from an expression function that is not a completion, do not freeze the profile and temporary mask the types declared outside the expression that are not yet frozen. * sem_res.adb (Rewrite_Renamed_Operator): Also bail out if invoked during the pre-analysis of an expression function. Index: freeze.adb === --- freeze.adb (revision 251956) +++ freeze.adb (working copy) @@ -3423,72 +3423,10 @@ function Freeze_Profile (E : Entity_Id) return Boolean is - function Has_Incomplete_Component (T : Entity_Id) return Boolean; - -- If a type includes a private component from an enclosing scope it - -- cannot be frozen yet. This can happen in a package nested within - -- another, when freezing an expression function whose profile - -- depends on a type in some outer scope. Those types will be frozen - -- at a later time in the enclosing unit. - - -- - -- Has_Incomplete_Component -- - -- - - function Has_Incomplete_Component (T : Entity_Id) return Boolean is -Comp : Entity_Id; -Comp_Typ : Entity_Id; - - begin -if Nkind (N) /= N_Subprogram_Body - or else not Was_Expression_Function (N) -then - return False; - -elsif In_Instance then - return False; - -elsif Is_Record_Type (T) then - Comp := First_Entity (T); - - while Present (Comp) loop - Comp_Typ := Etype (Comp); - - if Ekind_In (Comp, E_Component, E_Discriminant) -and then Is_Private_Type (Comp_Typ) -and then No (Full_View (Comp_Typ)) -and then In_Open_Scopes (Scope (Comp_Typ)) -and then Scope (Comp_Typ) /= Current_Scope - then - return True; - end if; - - Comp := Next_Entity (Comp); - end loop; - - return False; - -elsif Is_Array_Type (T) then - Comp_Typ := Component_Type (T); - - return - Is_Private_Type (Comp_Typ) - and then No (Full_View (Comp_Typ)) - and then In_Open_Scopes (Scope (Comp_Typ)) - and then Scope (Comp_Typ) /= Current_Scope; - -else - return False; -end if; - end Has_Incomplete_Component; - - -- Local variables - F_Type: Entity_Id; R_Type: Entity_Id; Warn_Node : Node_Id; - -- Start of processing for Freeze_Profile - begin -- Loop through formals @@ -3508,12 +3446,6 @@ Set_Etype (Formal, F_Type); end if; -if Has_Incomplete_Component (F_Type) then - Set_Is_Frozen (E, False); - Result := No_List; - return False; -end if; - if not From_Limited_With (F_Type) then Freeze_And_Append (F_Type, N, Result); end if; @@ -8302,7 +8234,9 @@ -- that we know the convention. if not Has_Foreign_Convention (E) then - Create_Extra_Formals (E); + if No (Extra_Formals (E)) then +Create_Extra_Formals (E); + end if; Set_Mechanisms (E); -- If this is convention Ada and a Valued_Procedure, that's odd Index: sem_ch6.adb === --- sem_c
Re: [PATCH]: PR target/80204 (Darwin macosx-version-min problem)
> On 4 Sep 2017, at 21:48, Jakub Jelinek wrote: > > On Mon, Sep 04, 2017 at 08:47:07PM +0100, Simon Wright wrote: >> On 1 Sep 2017, at 23:05, Simon Wright wrote: >>> >>> 2017-09-01 Simon Wright >>> >>> PR target/80204 >>> * config/darwin-driver.c (darwin_find_version_from_kernel): eliminate >>> calculation of the >>> minor version, always output as 0. >> >> Like this? >> >> Do you need the patch to be resubmitted as well? >> >> gcc/Changelog >> >> 2017-09-01 Simon Wright >> >> PR target/80204 >> * config/darwin-driver.c (darwin_find_version_from_kernel): >> Eliminate calculation of the minor version, always output as 0. > > Better > > 2017-09-01 Simon Wright > > PR target/80204 > * config/darwin-driver.c (darwin_find_version_from_kernel): Eliminate > calculation of the minor version, always output as 0. > > Jakub Very sorry that no-one from the Darwin folks has reviewed this to date, and thanks for the patch (and to Jakub and Jeff for taking care of it). In general, I would prefer that a change like this would be made to apply to only versions of Darwin >= to the ones affected (so that the behaviour for earlier versions is unchanged). As I read your patch, it alters things for all versions. Having said that, the risk of bad effects is fairly low, and we can deal with them if they occur, so it’s a reasonable patch (as has been OK’d). Please CC me directly on Darwin patches; in case I miss them in other list traffic. Whilst I cannot approve them - at least I will try to review and make suggestions. Iain Sandoe CodeSourcery / Mentor Embedded / Siemens
Re: std::forward_list optim for always equal allocator
On 11/09/17 07:44 +0200, Daniel Krügler wrote: 2017-09-11 7:12 GMT+02:00 François Dumont : When user declare a container iterator like that: std::forward_list::iterator it; There is no reason to initialize it with a null node pointer. It is just an uninitialized iterator which is invalid to use except to initialize it. While that is correct, for every forward iterator (and std::forward_list::iterator meets these requirements), it is also required that a value-initialized iterator can be compared against other initialized iterators, so this reduces the amount of freedom to define a default constructor for such iterators even when used to default-initialize. This is not meant as a showstopper argument, since I have not fully understood of what you are planning, but just a reminder. Right, which means that std::forward_list::iterator it = {}; must initialize the node pointer to nullptr. If we remove the initialization of _Fwd_list_iterator::_M_node from the default constructor then it would be left uninitialized. But I'm confused, François was talking about removing the initialization of _Fwd_list_node_base::_M_next, what has that got to do with forward_list::iterator? Thee is no node-base in the iterator. So I'm still wondering why the initialization of _M_next should be removed.
Re: [patch] Fix wrong code with small structure return on PowerPC
On September 11, 2017 12:26:09 PM GMT+02:00, Eric Botcazou wrote: >Hi, > >this is a bug originally reported in Ada on 32-bit PowerPC with the >SVR4 ABI >(hence not Linux) and reproducible in C with the attached testcase at >-O1. > >The problem lies in function 'foo': > > struct S ret; > char r, s, c1, c2; > char *p = &r; > > s = bar (&p); > if (s) >c2 = *p; > c1 = 0; > > ret.c1 = c1; > ret.c2 = c2; > return ret; > >Since the call to bar returns 0, c2 is uninitialized at run time (but >this >doesn't matter for correctness since its value is never read). Now >both c1 >and c2 are represented at the RTL level by unsigned promoted subregs, >i.e. >SUBREGs verifying SUBREG_PROMOTED_VAR_P and SUBREG_PROMOTED_UNSIGNED_P > >As a consequence, when store_fixed_bit_field_1 stores the 8-bit values >into >the 'ret' object, it considers that the underlying 32-bit objects have >only 8 >bits set and the rest cleared so it doesn't mask the other 24 bits. >That's >OK for c1 but not for c2, since c2 is uninitialized so the bits are >random. > >This appears to be an inherent weakness of the promoted subregs >mechanism, but >I don't think that we want to go for an upheaval at this point. So the >patch >addresses the problem in an ad-hoc manner directly in >store_fixed_bit_field_1 >and yields the expected 8-bit insertion: > >@@ -26,7 +26,7 @@ >lwz 9,12(1) >lbz 31,0(9) > .L3: >- slwi 3,31,16 >+ rlwinm 3,31,16,8,15 >lwz 0,36(1) >mtlr 0 >lwz 31,28(1) > >Tested on x86-64/Linux and PowerPC64/Linux, OK for the mainline? I think the issue is that we set SUBREG_PROMOTED_* on something that is possibly not so (aka uninitialized in this case). We may only set it if either the ABI or a previous operation forced it to. Maybe this is also the reason why we need this zero init pass in some cases (though that isn't a full solution either). Richard. > >2017-09-11 Eric Botcazou > > * expmed.c (store_fixed_bit_field_1): Force the masking if the value > is an unsigned promoted SUBREG of a sufficiently large object. > > >2017-09-11 Eric Botcazou > > * gcc.c-torture/execute/20170911-1.c: New test.
[testsuite, i386] Fix gcc.target/i386/pr81736-[34].c on 32-bit Solaris/x86 (PR target/81736)
The new gcc.target/i386/pr81736-[34].c tests currently FAIL on 32-bit Solaris x86. Fixed as suggested by HJ in the PR. Tested with the appropriate runtest invocation on i386-pc-solaris2.11, x86_64-pc-linux-gnu, and x86_64-apple-darwin11. Assembler output on Linux and Darwin is unchanged. Ok for mainline? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University 2017-09-11 Rainer Orth PR target/81736 * gcc.target/i386/pr81736-3.c: Add -mno-omit-leaf-frame-pointer. * gcc.target/i386/pr81736-4.c: Likewise. # HG changeset patch # Parent 79870b011f66569412e6da49853b5bd7ee3e7b25 Fix gcc.target/i386/pr81736-[34].c on 32-bit Solaris/x86 (PR target/81736) diff --git a/gcc/testsuite/gcc.target/i386/pr81736-3.c b/gcc/testsuite/gcc.target/i386/pr81736-3.c --- a/gcc/testsuite/gcc.target/i386/pr81736-3.c +++ b/gcc/testsuite/gcc.target/i386/pr81736-3.c @@ -1,5 +1,5 @@ /* { dg-do compile } */ -/* { dg-options "-O2 -fno-omit-frame-pointer" } */ +/* { dg-options "-O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer" } */ void foo (void) diff --git a/gcc/testsuite/gcc.target/i386/pr81736-4.c b/gcc/testsuite/gcc.target/i386/pr81736-4.c --- a/gcc/testsuite/gcc.target/i386/pr81736-4.c +++ b/gcc/testsuite/gcc.target/i386/pr81736-4.c @@ -1,5 +1,5 @@ /* { dg-do compile } */ -/* { dg-options "-O2 -fno-omit-frame-pointer" } */ +/* { dg-options "-O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer" } */ int foo (int i1, int i2, int i3, int i4, int i5, int i6, int i7)
Re: [patch] Fix wrong code with small structure return on PowerPC
> this is a bug originally reported in Ada on 32-bit PowerPC with the SVR4 ABI > (hence not Linux) and reproducible in C with the attached testcase at -O1. With the right C testcase this time... -- Eric Botcazoustruct S { char c1, c2, c3, c4; } __attribute__((aligned(4))); static char bar (char **p) __attribute__((noclone, noinline)); static struct S foo (void) __attribute__((noclone, noinline)); int i; static char bar (char **p) { i = 1; return 0; } static struct S foo (void) { struct S ret; char r, s, c1, c2; char *p = &r; s = bar (&p); if (s) c2 = *p; c1 = 0; ret.c1 = c1; ret.c2 = c2; return ret; } int main (void) { struct S s = foo (); if (s.c1 != 0) __builtin_abort (); return 0; }
[patch] Fix wrong code with small structure return on PowerPC
Hi, this is a bug originally reported in Ada on 32-bit PowerPC with the SVR4 ABI (hence not Linux) and reproducible in C with the attached testcase at -O1. The problem lies in function 'foo': struct S ret; char r, s, c1, c2; char *p = &r; s = bar (&p); if (s) c2 = *p; c1 = 0; ret.c1 = c1; ret.c2 = c2; return ret; Since the call to bar returns 0, c2 is uninitialized at run time (but this doesn't matter for correctness since its value is never read). Now both c1 and c2 are represented at the RTL level by unsigned promoted subregs, i.e. SUBREGs verifying SUBREG_PROMOTED_VAR_P and SUBREG_PROMOTED_UNSIGNED_P As a consequence, when store_fixed_bit_field_1 stores the 8-bit values into the 'ret' object, it considers that the underlying 32-bit objects have only 8 bits set and the rest cleared so it doesn't mask the other 24 bits. That's OK for c1 but not for c2, since c2 is uninitialized so the bits are random. This appears to be an inherent weakness of the promoted subregs mechanism, but I don't think that we want to go for an upheaval at this point. So the patch addresses the problem in an ad-hoc manner directly in store_fixed_bit_field_1 and yields the expected 8-bit insertion: @@ -26,7 +26,7 @@ lwz 9,12(1) lbz 31,0(9) .L3: - slwi 3,31,16 + rlwinm 3,31,16,8,15 lwz 0,36(1) mtlr 0 lwz 31,28(1) Tested on x86-64/Linux and PowerPC64/Linux, OK for the mainline? 2017-09-11 Eric Botcazou * expmed.c (store_fixed_bit_field_1): Force the masking if the value is an unsigned promoted SUBREG of a sufficiently large object. 2017-09-11 Eric Botcazou * gcc.c-torture/execute/20170911-1.c: New test. -- Eric BotcazouIndex: expmed.c === --- expmed.c (revision 251906) +++ expmed.c (working copy) @@ -1213,13 +1213,25 @@ store_fixed_bit_field_1 (rtx op0, scalar } else { - int must_and = (GET_MODE_BITSIZE (value_mode) != bitsize - && bitnum + bitsize != GET_MODE_BITSIZE (mode)); + /* Compute whether we must mask the value in order to make sure that the + bits outside the bitfield are all cleared. Note that, even though the + value has the right size, if it has a mode different from MODE, then + converting it to MODE may unmask uninitialized bits in the case where + it is an unsigned promoted SUBREG of a sufficiently large object. */ + const bool must_mask + = (GET_MODE_BITSIZE (value_mode) != bitsize + || (value_mode != mode + && GET_CODE (value) == SUBREG + && SUBREG_PROMOTED_VAR_P (value) + && SUBREG_PROMOTED_UNSIGNED_P (value) + && GET_MODE_SIZE (GET_MODE (SUBREG_REG (value))) + >= GET_MODE_SIZE (mode))) + && bitnum + bitsize != GET_MODE_BITSIZE (mode); if (value_mode != mode) value = convert_to_mode (mode, value, 1); - if (must_and) + if (must_mask) value = expand_binop (mode, and_optab, value, mask_rtx (mode, 0, bitsize, 0), NULL_RTX, 1, OPTAB_LIB_WIDEN); unsigned long foo (int x) { return x > 0 ? (unsigned long) x : 0; } unsigned long bar (int x, int y) { return x > y ? (unsigned long) x : (unsigned long) y; }
[Ada] Rename runtime variant files under libgnat
Same renaming as just done for libgnarl, under libgnat this time. Tested on x86_64-pc-linux-gnu, committed on trunk 2017-09-11 Jerome Lambourg * libgnat: Rename ?-[a-z]*-* into ?-[a-z]*__* * gcc-interface/Makefile.in, gcc-interface/Make-lang.in: Take this renaming into account. Index: gcc-interface/Makefile.in === --- gcc-interface/Makefile.in (revision 251966) +++ gcc-interface/Makefile.in (working copy) @@ -359,7 +359,7 @@ s-inmaop.adb
Re: [HSA, PR 82119] Make HSA resilient to side-effects of split_edge
On September 11, 2017 11:03:39 AM GMT+02:00, Martin Jambor wrote: >Hi, > >in r251264 the code of split_edge was changed not to reallocate PHI >vectors, but it reorders them along with the order of incoming edges >to the BB. There are two places in the HSA BE where we call >split_edge while iterating over PHI node arguments and those broke, >resulting in a number of libgomp testsuite failures. Ah, interesting. I'll try to change split_edge to not reorder PHI arguments. Richard. >Fixed thusly. I have tested the patch on HSA capable APU and also did >full bootstrap and testing, I will commit in a few moments. > >Martin > > >2017-09-11 Martin Jambor > > PR hsa/82119 > * hsa-gen.c (gen_hsa_phi_from_gimple_phi): Process ADDR_EXPRs in > arguments in advance. > * hsa-regalloc.c (naive_process_phi): New parameter predecessors, > use it to find predecessor edges. > (naive_outof_ssa): Collect vector of predecessors. >--- >gcc/hsa-gen.c | 51 >++- > gcc/hsa-regalloc.c | 14 +++--- > 2 files changed, 49 insertions(+), 16 deletions(-) > >diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c >index bd227626e83..6e054c0ce82 100644 >--- a/gcc/hsa-gen.c >+++ b/gcc/hsa-gen.c >@@ -5657,8 +5657,37 @@ gen_hsa_phi_from_gimple_phi (gimple *phi_stmt, >hsa_bb *hbb) > hphi = new hsa_insn_phi (count, dest); > hphi->m_bb = hbb->m_bb; > >- tree lhs = gimple_phi_result (phi_stmt); >+ auto_vec aexprs; >+ auto_vec aregs; >+ >+ /* Calling split_edge when processing a PHI node messes up with the >order of >+ gimple phi node arguments (it moves the one associated with the >edge to >+ the end). We need to keep the order of edges and arguments of >HSA phi >+ node arguments consistent, so we do all required splitting as the >first >+ step, and in reverse order as to not be affected by the >re-orderings. */ >+ for (unsigned j = count; j != 0; j--) >+{ >+ unsigned i = j - 1; >+ tree op = gimple_phi_arg_def (phi_stmt, i); >+ if (TREE_CODE (op) != ADDR_EXPR) >+ continue; > >+ edge e = gimple_phi_arg_edge (as_a (phi_stmt), i); >+ hsa_bb *hbb_src = hsa_init_new_bb (split_edge (e)); >+ hsa_op_address *addr = gen_hsa_addr (TREE_OPERAND (op, 0), >+ hbb_src); >+ >+ hsa_op_reg *dest >+ = new hsa_op_reg (hsa_get_segment_addr_type (BRIG_SEGMENT_FLAT)); >+ hsa_insn_basic *insn >+ = new hsa_insn_basic (2, BRIG_OPCODE_LDA, BRIG_TYPE_U64, >+dest, addr); >+ hbb_src->append_insn (insn); >+ aexprs.safe_push (op); >+ aregs.safe_push (dest); >+} >+ >+ tree lhs = gimple_phi_result (phi_stmt); > for (unsigned i = 0; i < count; i++) > { > tree op = gimple_phi_arg_def (phi_stmt, i); >@@ -5684,18 +5713,14 @@ gen_hsa_phi_from_gimple_phi (gimple *phi_stmt, >hsa_bb *hbb) > } > else if (TREE_CODE (op) == ADDR_EXPR) > { >-edge e = gimple_phi_arg_edge (as_a (phi_stmt), i); >-hsa_bb *hbb_src = hsa_init_new_bb (split_edge (e)); >-hsa_op_address *addr = gen_hsa_addr (TREE_OPERAND (op, 0), >- hbb_src); >- >-hsa_op_reg *dest >- = new hsa_op_reg (hsa_get_segment_addr_type >(BRIG_SEGMENT_FLAT)); >-hsa_insn_basic *insn >- = new hsa_insn_basic (2, BRIG_OPCODE_LDA, BRIG_TYPE_U64, >-dest, addr); >-hbb_src->append_insn (insn); >- >+hsa_op_reg *dest = NULL; >+for (unsigned a_idx = 0; a_idx < aexprs.length (); a_idx++) >+ if (aexprs[a_idx] == op) >+{ >+ dest = aregs[a_idx]; >+ break; >+} >+gcc_assert (dest); > hphi->set_op (i, dest); > } > else >diff --git a/gcc/hsa-regalloc.c b/gcc/hsa-regalloc.c >index 2a17254c3b2..7fc3a8afa3d 100644 >--- a/gcc/hsa-regalloc.c >+++ b/gcc/hsa-regalloc.c >@@ -42,7 +42,7 @@ along with GCC; see the file COPYING3. If not see >/* Process a PHI node PHI of basic block BB as a part of naive >out-f-ssa. */ > > static void >-naive_process_phi (hsa_insn_phi *phi) >+naive_process_phi (hsa_insn_phi *phi, const vec &predecessors) > { > unsigned count = phi->operand_count (); > for (unsigned i = 0; i < count; i++) >@@ -55,7 +55,7 @@ naive_process_phi (hsa_insn_phi *phi) > if (!op) > break; > >- e = EDGE_PRED (phi->m_bb, i); >+ e = predecessors[i]; > if (single_succ_p (e->src)) > hbb = hsa_bb_for_bb (e->src); > else >@@ -89,10 +89,18 @@ naive_outof_ssa (void) > hsa_bb *hbb = hsa_bb_for_bb (bb); > hsa_insn_phi *phi; > >+/* naive_process_phi can call split_edge on an incoming edge which >order if >+ the incoming edges to the basic block and thus make it >inconsistent with >+
Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace
Thanks for answer. I understood all points which you mentioned, but can't find last one > It seems to work > out the file name a second time, even though the file name must > already be known. Can you please show me where I've missed that, if you have a time for that. Anyway, your patch works for me. Thanks. On 09/11/2017 12:11 AM, Ian Lance Taylor wrote: On Sat, Jul 29, 2017 at 1:42 PM, Denis Khalikov wrote: Hello Ian, thanks for review. I've updated the patch, can you please take a look. Apologies again for the length of time it took to reply. I've had a hard time understanding the patch. It's quite likely that I don't understand how it works, but it seems to pass the same file descriptor to process_elf_header twice. It seems to look for debug files with the buildid in places where they will not be found. It seems to work out the file name a second time, even though the file name must already be known. I eventually just wrote my own implementation. Could you try this patch and see if it works for your cases? The patch is against current mainline. Thanks. Ian
[Ada] Rename runtime variant files under libgnarl
This is the next step in the source file and directory reorg in GNAT sources. This time, we rename all files of the form ?-[a-z]*-* into ?-[a-z]*_*, for example s-tpopsp-posix.adb becomes s-tpopsp__posix.adb. This is done so that it's easier to see which files are platform specific variants (such files will now always contain a double underscore). This change is for the libgnarl directory, the next change will do the same for the libgnat directory. As with the previous changes, there's a small chance that some target got forgotten in Makefile.in, but hopefully not! If this is the case, fixing it is purely mechanical and is preapproved. The diff is huge and mechanical, I'm only including the part in gcc-interface/Makefile.in. Tested on x86_64-pc-linux-gnu, committed on trunk 2017-09-11 Jerome Lambourg * libgnarl: Rename ?-[a-z]*-* into ?-[a-z]*__* * gcc-interface/Makefile.in: Take this renaming into account. Index: gcc-interface/Makefile.in === --- gcc-interface/Makefile.in (revision 251956) +++ gcc-interface/Makefile.in (working copy) @@ -355,13 +355,13 @@ # Non-tasking case: LIBGNAT_TARGET_PAIRS = \ -a-intnam.ads
[HSA, PR 82119] Make HSA resilient to side-effects of split_edge
Hi, in r251264 the code of split_edge was changed not to reallocate PHI vectors, but it reorders them along with the order of incoming edges to the BB. There are two places in the HSA BE where we call split_edge while iterating over PHI node arguments and those broke, resulting in a number of libgomp testsuite failures. Fixed thusly. I have tested the patch on HSA capable APU and also did full bootstrap and testing, I will commit in a few moments. Martin 2017-09-11 Martin Jambor PR hsa/82119 * hsa-gen.c (gen_hsa_phi_from_gimple_phi): Process ADDR_EXPRs in arguments in advance. * hsa-regalloc.c (naive_process_phi): New parameter predecessors, use it to find predecessor edges. (naive_outof_ssa): Collect vector of predecessors. --- gcc/hsa-gen.c | 51 ++- gcc/hsa-regalloc.c | 14 +++--- 2 files changed, 49 insertions(+), 16 deletions(-) diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c index bd227626e83..6e054c0ce82 100644 --- a/gcc/hsa-gen.c +++ b/gcc/hsa-gen.c @@ -5657,8 +5657,37 @@ gen_hsa_phi_from_gimple_phi (gimple *phi_stmt, hsa_bb *hbb) hphi = new hsa_insn_phi (count, dest); hphi->m_bb = hbb->m_bb; - tree lhs = gimple_phi_result (phi_stmt); + auto_vec aexprs; + auto_vec aregs; + + /* Calling split_edge when processing a PHI node messes up with the order of + gimple phi node arguments (it moves the one associated with the edge to + the end). We need to keep the order of edges and arguments of HSA phi + node arguments consistent, so we do all required splitting as the first + step, and in reverse order as to not be affected by the re-orderings. */ + for (unsigned j = count; j != 0; j--) +{ + unsigned i = j - 1; + tree op = gimple_phi_arg_def (phi_stmt, i); + if (TREE_CODE (op) != ADDR_EXPR) + continue; + edge e = gimple_phi_arg_edge (as_a (phi_stmt), i); + hsa_bb *hbb_src = hsa_init_new_bb (split_edge (e)); + hsa_op_address *addr = gen_hsa_addr (TREE_OPERAND (op, 0), + hbb_src); + + hsa_op_reg *dest + = new hsa_op_reg (hsa_get_segment_addr_type (BRIG_SEGMENT_FLAT)); + hsa_insn_basic *insn + = new hsa_insn_basic (2, BRIG_OPCODE_LDA, BRIG_TYPE_U64, + dest, addr); + hbb_src->append_insn (insn); + aexprs.safe_push (op); + aregs.safe_push (dest); +} + + tree lhs = gimple_phi_result (phi_stmt); for (unsigned i = 0; i < count; i++) { tree op = gimple_phi_arg_def (phi_stmt, i); @@ -5684,18 +5713,14 @@ gen_hsa_phi_from_gimple_phi (gimple *phi_stmt, hsa_bb *hbb) } else if (TREE_CODE (op) == ADDR_EXPR) { - edge e = gimple_phi_arg_edge (as_a (phi_stmt), i); - hsa_bb *hbb_src = hsa_init_new_bb (split_edge (e)); - hsa_op_address *addr = gen_hsa_addr (TREE_OPERAND (op, 0), - hbb_src); - - hsa_op_reg *dest - = new hsa_op_reg (hsa_get_segment_addr_type (BRIG_SEGMENT_FLAT)); - hsa_insn_basic *insn - = new hsa_insn_basic (2, BRIG_OPCODE_LDA, BRIG_TYPE_U64, - dest, addr); - hbb_src->append_insn (insn); - + hsa_op_reg *dest = NULL; + for (unsigned a_idx = 0; a_idx < aexprs.length (); a_idx++) + if (aexprs[a_idx] == op) + { + dest = aregs[a_idx]; + break; + } + gcc_assert (dest); hphi->set_op (i, dest); } else diff --git a/gcc/hsa-regalloc.c b/gcc/hsa-regalloc.c index 2a17254c3b2..7fc3a8afa3d 100644 --- a/gcc/hsa-regalloc.c +++ b/gcc/hsa-regalloc.c @@ -42,7 +42,7 @@ along with GCC; see the file COPYING3. If not see /* Process a PHI node PHI of basic block BB as a part of naive out-f-ssa. */ static void -naive_process_phi (hsa_insn_phi *phi) +naive_process_phi (hsa_insn_phi *phi, const vec &predecessors) { unsigned count = phi->operand_count (); for (unsigned i = 0; i < count; i++) @@ -55,7 +55,7 @@ naive_process_phi (hsa_insn_phi *phi) if (!op) break; - e = EDGE_PRED (phi->m_bb, i); + e = predecessors[i]; if (single_succ_p (e->src)) hbb = hsa_bb_for_bb (e->src); else @@ -89,10 +89,18 @@ naive_outof_ssa (void) hsa_bb *hbb = hsa_bb_for_bb (bb); hsa_insn_phi *phi; +/* naive_process_phi can call split_edge on an incoming edge which order if + the incoming edges to the basic block and thus make it inconsistent with + the ordering of PHI arguments, so we collect them in advance. */ +auto_vec predecessors; +unsigned pred_count = EDGE_COUNT (bb->preds); +for (unsigned i = 0; i < pred_count; i++) + predecessors.safe_push (EDGE_PRED (bb, i)); +
Re: backwards threader cleanups
PING. An this time with an actual patch ;-). Aldy On Sat, Sep 2, 2017 at 1:43 PM, Aldy Hernandez wrote: > On Fri, Sep 1, 2017 at 6:11 PM, Jeff Law wrote: >> On 09/01/2017 02:18 PM, Aldy Hernandez wrote: >>> Hi. >>> >>> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends. >>> The main gist of the patch is making the path vectors live in the >>> heap, not GC. But I also cleaned up some comments to reflect reality, >>> and renamed VAR_BB which could use a more meaningful name. Finally, I >>> abstracted some common code to >>> register_jump_thread_path_if_profitable() in preparation for some >>> upcoming work by me :). >>> >>> Tested on x86-64 Linux. >> It looks like you dropped a level of indirection for path in >> profitable_jump_thread_path and perhaps others that push blocks onto the >> path? Does your change from having the vectors in the GC space to the >> heap also change them from embeddable vectors to a space efficient >> vector? It has to for this change to be safe. > > Part of my initial motivation was eliminating the double indirection > as well as removing the out-of-line calls to vec_alloc() and > vec_whatever_push(). > > And yes, the default plain vector<> uses the heap: > > template typename A = va_heap, > typename L = typename A::default_layout> > struct GTY((user)) vec > { > }; > > ...and va_heap defaults to the space efficient vector: > > struct va_heap > { > typedef vl_ptr default_layout; > ... > } > >> >> See the discussion in vec.h >> >> I don't recall any inherent reason we use the embedded vector layout. >> It's the default which is probably why it's used here more than anything. > > Just a wild guess, but this may be why: > >FIXME - Ideally, they would all be vl_ptr to encourage using regular >instances for vectors, but the existing GTY machinery is limited >in that it can only deal with GC objects that are pointers >themselves. > > and: > > /* Use vl_embed as the default layout for GC vectors. Due to GTY > limitations, GC vectors must always be pointers, so it is more > efficient to use a pointer to the vl_embed layout, rather than > using a pointer to a pointer as would be the case with vl_ptr. */ > >> >> Otherwise the change looks good. I think you just to make sure you're >> not using the embedded layout. Which I think is just a different type >> when you declare the vec. > > I have made the vectors auto_vec as Trevor suggested. As auto_vec is > just an inherited plain vec<> with some magic allocation sauce, they > can be passed around interchangeably. > > I also changed the hash sets so they live on the stack as opposed to > allocating memory dynamically, at Trevor's request as well. > > Bootstraps. OK pending another round of tests? > > Aldy curr Description: Binary data
Re: [AArch64], patch] PR71727 fix -mstrict-align
On Tue, Jul 18, 2017 at 5:50 AM, Christophe Lyon wrote: > Hello, > > I've received a complaint that GCC for AArch64 would generate > vectorized code relying on unaligned memory accesses even when using > -mstrict-align. This is a problem for code where such accesses lead to > memory faults. > > A previous patch (r24) introduced > aarch64_builtin_support_vector_misalignment, which rejects such > accesses when the element size is 64 bits, and accept them otherwise, > which I think it shouldn't. The testcase added at that time only used > 64 bits elements, and therefore didn't fully test the patch. > > The report I received is about vectorized accesses to an array of > unsigned chars, whose start address is not aligned on a 128 bits > boundary. > > The attached patch fixes the problem by making > aarch64_builtin_support_vector_misalignment always return false when > the misalignment is not known at compile time. > > I've also added a testcase, which tries to check if the array start > address alignment is checked (using %16, and-ing with #15), so that > loop peeling is performed *before* using vectorized accesses. Without > the patch, vectorized accesses are used at the beginning of the array, > and byte accesses are used for the remainder at the end, and there is > not such 'and wX,wX,15'. > > BTW, I'm not sure about the same hook for arm... it seems to me it has > a similar problem. > > OK? I would keep part of the comment: - /* Misalignment factor is unknown at compile time but we know - it's word aligned. */ Something like: /* Misalignment factor is unknown at compile time. */ Otherwise it is not obvious what -1 means. Other than I think this patch is good (I cannot approve though). Thanks, Andrew > > Thanks, > > Christophe
Re: [AArch64], patch] PR71727 fix -mstrict-align
ping^3 ? https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01063.html On 31 August 2017 at 11:22, Christophe Lyon wrote: > ping^2 ? > > > On 21 August 2017 at 15:04, Christophe Lyon > wrote: >> ping ? >> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01063.html >> >> Christophe >> >> >> On 18 July 2017 at 14:50, Christophe Lyon wrote: >>> Hello, >>> >>> I've received a complaint that GCC for AArch64 would generate >>> vectorized code relying on unaligned memory accesses even when using >>> -mstrict-align. This is a problem for code where such accesses lead to >>> memory faults. >>> >>> A previous patch (r24) introduced >>> aarch64_builtin_support_vector_misalignment, which rejects such >>> accesses when the element size is 64 bits, and accept them otherwise, >>> which I think it shouldn't. The testcase added at that time only used >>> 64 bits elements, and therefore didn't fully test the patch. >>> >>> The report I received is about vectorized accesses to an array of >>> unsigned chars, whose start address is not aligned on a 128 bits >>> boundary. >>> >>> The attached patch fixes the problem by making >>> aarch64_builtin_support_vector_misalignment always return false when >>> the misalignment is not known at compile time. >>> >>> I've also added a testcase, which tries to check if the array start >>> address alignment is checked (using %16, and-ing with #15), so that >>> loop peeling is performed *before* using vectorized accesses. Without >>> the patch, vectorized accesses are used at the beginning of the array, >>> and byte accesses are used for the remainder at the end, and there is >>> not such 'and wX,wX,15'. >>> >>> BTW, I'm not sure about the same hook for arm... it seems to me it has >>> a similar problem. >>> >>> OK? >>> >>> Thanks, >>> >>> Christophe