Re: [patch] implement Cilk Plus simd loops on trunk
On 07/27/13 01:09, Jason Merrill wrote: On 07/26/2013 11:46 AM, Aldy Hernandez wrote: How's this? What branch is this supposed to apply to? trunk, but it depends on the OMP_SIMD patch which is also awaiting review (actually, just the vectorizer bits since Jakub wrote and can pre-approve the actual OMP changes): http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00357.html Both the OMP_SIMD patchset and the present patch being reviewed were based off of trunk at: svn+ssh://gcc.gnu.org/svn/gcc/trunk@200581 (July 1, 2013) I can rebase off a more recent trunk if you prefer, or I can even post a combined OMP_SIMD + Cilk Plus #pragma simd patchset. However you prefer... Aldy
Re: [Patch, Fortran, OOP] PR 57306: ICE on valid with class pointer initialization
Hi Janus, Janus Weil wrote: here is a fix for class pointer initialization. I think the patch looks reasonable. However, as soon as I try to use the variable, I get an ICE in write_global_declarations -> symtab_get_node. It works if one moves the targets into a module. I wonder whether there is an ordering problem of the decl or something else. The dump has: static struct __class_MAIN___C_p cc = &cd; struct c cd; static struct __class_MAIN___C_p dc = ⅆ struct d dd; Additionally, the CLASS are wrongly initialized: You only set "_data" (indirectly as it is the first field/component of the class) but you do not set the _vptr component. Hence, the my example fails at run time Tobias PS: The test case. With module - fails at run time for same_type_as. Without module - one gets an ICE. !module m type :: c end type c type, extends(c) :: d end type d type(c), target :: cd type(d), target :: dd !end module m ! use m class(c), pointer :: cc => cd class(c), pointer :: dc => dd if(.not. associated(cc, cd)) call abort() ! OK if(.not. same_type_as(cc, cd)) call abort() ! Fails if(.not. associated(dc, dd)) call abort() ! OK if(.not. same_type_as(dc, dd)) call abort() ! Fails end
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
Hi Janus, Janus Weil wrote: OK for the trunk? yes, the patch looks basically ok to me. Just one thing I did not quite understand: + /* It can happen that the LHS has BT_DERIVED but it is in reality + a polymorphic variable. */ How exactly can it happen that a polymorphic variable is BT_DERIVED? I don't know. I commented it and it still works with the new test cases - it failed with one of them before. Probably some other change in this patch fixed the issue. As I cannot reproduce it anymore - and as I didn't like it either, I will remove it. OK for the trunk without that bit? Tobias
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
Hi, >>> OK for the trunk? >> >> yes, the patch looks basically ok to me. Just one thing I did not >> quite understand: >> >> + /* It can happen that the LHS has BT_DERIVED but it is in reality >> + a polymorphic variable. */ >> >> How exactly can it happen that a polymorphic variable is BT_DERIVED? > > I don't know. I commented it and it still works with the new test cases - it > failed with one of them before. Probably some other change in this patch > fixed the issue. As I cannot reproduce it anymore - and as I didn't like it > either, I will remove it. To me that sounds like a bug - if the symbol is BT_CLASS, then the expr should be BT_CLASS (unless there is further decoration). By chance I also just noticed one such case when debugging PR 57285. If you happen to find out when this occurs or where the problem originates from, that would be very helpful. > OK for the trunk without that bit? Yes, ok. Thanks for the patch, Janus
Re: [c++-concepts] requires expressions
Committed. On Fri, Jul 26, 2013 at 10:27 PM, Gabriel Dos Reis wrote: > Andrew Sutton writes: > > | Fixed and committed, but I have a small follow-up related to parameter > | packs in requires clauses. The checking for unexpanded parameter packs > | treats the parameter declarations like regular PARM_DECL references > | and gives errors that they are unexpanded packs. > | > | 2013-07-26 Andrew Sutton > | * gcc/cp/tree.c (cp_walk_subtrees): Don't recurse through the > | requires expr parameter list. > | > | Andrew > > Let me know when you commit this so I can merge from trunk. > > -- Gaby -- Andrew Sutton andrew.n.sut...@gmail.com
[Patch, Fortran] PR57991 - add alias warning for intent(out)/intent(out)
Passing the same argument to nonpointer dummy arguments is only
permitted if one does not modify the values.
gfortran was warning for intent(in)/intent(out) and for OUT/IN but not
for OUT/OUT. This patch now also warns for the latter.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-07-27 Tobias Burnus
PR fortran/57991
* interface.c (check_some_aliasing): Also warn for intent OUT/OUT.
2013-07-27 Tobias Burnus
PR fortran/57991
* gfortran.dg/warn_alias.f90: New.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 3c794b2..606cef5 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -3078,7 +3079,8 @@ check_some_aliasing (gfc_formal_arglist *f, gfc_actual_arglist *a)
break;
f2_intent = p[j].f->sym->attr.intent;
if ((f1_intent == INTENT_IN && f2_intent == INTENT_OUT)
- || (f1_intent == INTENT_OUT && f2_intent == INTENT_IN))
+ || (f1_intent == INTENT_OUT && f2_intent == INTENT_IN)
+ || (f1_intent == INTENT_OUT && f2_intent == INTENT_OUT))
{
gfc_warning ("Same actual argument associated with INTENT(%s) "
"argument '%s' and INTENT(%s) argument '%s' at %L",
--- /dev/null 2013-07-27 10:10:46.283765931 +0200
+++ gcc/gcc/testsuite/gfortran.dg/warn_alias.f90 2013-07-27 13:06:05.221802513 +0200
@@ -0,0 +1,33 @@
+! { dg-do compile }
+! { dg-options "-Waliasing" }
+!
+! PR fortran/57991
+!
+! Added check for OUT/OUT. IN/OUT and OUT/IN where already check
+! since GCC 4.0, but not being tested for.
+
+ Program q
+integer :: x
+x = 5
+Call test1(x, x) ! { dg-warning "Same actual argument associated with INTENT.OUT. argument 'a' and INTENT.OUT. argument 'b'" }
+Call test2(x, x) ! { dg-warning "Same actual argument associated with INTENT.IN. argument 'a' and INTENT.OUT. argument 'b'" }
+Call test3(x, x) ! { dg-warning "Same actual argument associated with INTENT.OUT. argument 'a' and INTENT.IN. argument 'b'" }
+ Contains
+Subroutine test1(a,b)
+ Integer, intent(out) :: a
+ Integer, intent(out) :: b
+ b = 5
+ a = 5
+End Subroutine
+Subroutine test2(a,b)
+ Integer, intent(in) :: a
+ Integer, intent(out) :: b
+ b = 5 + a
+End Subroutine
+Subroutine test3(a,b)
+ Integer, intent(out) :: a
+ Integer, intent(in) :: b
+ a = 5 + b
+End Subroutine
+ End Program
+
Re: [Patch, Fortran] PR57991 - add alias warning for intent(out)/intent(out)
Hi Tobias, Passing the same argument to nonpointer dummy arguments is only permitted if one does not modify the values. gfortran was warning for intent(in)/intent(out) and for OUT/IN but not for OUT/OUT. This patch now also warns for the latter. Build and regtested on x86-64-gnu-linux. OK for the trunk? OK (obvious really). Thanks for the patch! Thomas
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
Tobias Burnus wrote: Janus Weil wrote: yes, the patch looks basically ok to me. Just one thing I did not quite understand: + /* It can happen that the LHS has BT_DERIVED but it is in reality + a polymorphic variable. */ How exactly can it happen that a polymorphic variable is BT_DERIVED? I miss remembered (too hot here!) - the problem wasn't for one of my newly added test cases but for an existing one. Without that bit, the following test case is failing: class_array_12.f03 (and class_array_15.f03): It fails via gfc_trans_class_assign -> gfc_trans_pointer_assignment: 1075tmp = gfc_trans_pointer_assignment (expr1, expr2); Namely for the line BGet => self%componentB(1) There: expr1->ts.type == BT_DERIVED expr1->symtree->n.sym->ts.type == BT_CLASS expr1->ref->type == REF_COMPONENT expr1->ref->u.c.component->name == "_data" and expr2->ts.type == BT_CLASS expr2->ref->type == REF_COMPONENT expr2->ref->u.c.component->name == "componentb" expr2->ref->u.c.component->ts.type == BT_CLASS expr2->ref->next->u.ar.type == AR_ELEMENT Both is kind of okay, but inconsistent. My newly added code does: + if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS + && expr2->expr_type != EXPR_FUNCTION) +gfc_add_data_component (expr2); which adds a "_data" ref to expr2 - but expr2->ts.type remains BT_CLASS. Thus, the code later runs into: + if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS + /*&& !gfc_is_class_scalar_expr (expr1)*/) + rse.expr = gfc_class_data_get (rse.expr); which fails without the "gfc_is_class_scalar_expr" as one then adds a "_data" ref to the existing "_data" ref. I think my changed check is bogus (even if it solved the problem) and the real problem is that gfc_add_data_component doesn't update expr->ts.type to BT_DERIVED. - I will try that - and see what else will break. Tobias
Re: [PATCH] Fix illegal cast to rtx (*insn_gen_fn) (rtx, ...)
Hi,
On Fri, 2013-07-26 at 08:51 +0200, Uros Bizjak wrote:
> BTW: I am not c++ expert, but doesn't c++ offer some sort of
> abstraction to get rid of
>
> + union {
> +rtx (*argc0) (void);
> +rtx (*argc1) (rtx);
> +rtx (*argc2) (rtx, rtx);
> +rtx (*argc3) (rtx, rtx, rtx);
> +rtx (*argc4) (rtx, rtx, rtx, rtx);
> +rtx (*argc5) (rtx, rtx, rtx, rtx, rtx);
> +rtx (*argc6) (rtx, rtx, rtx, rtx, rtx, rtx);
> +rtx (*argc7) (rtx, rtx, rtx, rtx, rtx, rtx, rtx);
> +rtx (*argc8) (rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx);
> +rtx (*argc9) (rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx);
> +rtx (*argc10) (rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx);
> +rtx (*argc11) (rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx);
> + } genfun;
>
Variadic templates maybe, but we can't use them since that requires C
++11.
Anyway, I think it's better to turn the insn_gen_fn typedef in recog.h
into a functor. The change is quite transparent to the users, as the
attached patch shows. There really is no need for things like GEN_FCN?,
nor do we need to fixup all the backends etc.
I've tested the attached patch on my SH cross setup with 'make all-gcc'
and it can still produce a valid 'hello world'. Not sure whether it's
sufficient.
Some notes regarding the patch:
* The whole arg list thing could probably be folded with x-macros or
something like that, but I don't think it's worth doing it for this
single case. If we can use C++11 in GCC at some point in time in the
future, the insn_gen_fn implementation can be folded with variadic
templates without touching all the code that uses it.
* I had to extend the number of max. args to 16, otherwise the SH
backend's sync.md code wouldn't compile.
* I don't know whether it's really needed to properly format the code of
class insn_gen_fn. After reading the first two or three overloads
(which do fit into 80 columns) one gets the idea and so I guess nobody
is going to read that stuff completely anyway.
* The class insn_gen_fn is a POD, so it can be passed by value without
any overhead, just like a normal function pointer. Same goes for the
function call through the wrapper class.
* Initially I had overloaded constructors in class insn_gen_fn which
worked and didn't require the cast in genoutput.c. However, it
introduced static initializer functions and defeated the purpose of the
generated const struct insn_data_d insn_data[]. This is worked around
by casting the function pointer to insn_gen_fn::stored_funcptr. (Since
it's C++ and not C it won't implicitly cast to void*).
* The whole thing will fall apart if the stored pointer to a function
'rtx (*)(void)' is different from a stored pointer to e.g. 'rtx
(*)(rtx)'. But I guess this is not likely to happen.
Cheers,
Oleg
gcc/ChangeLog:
* recog.h (rtx (*insn_gen_fn) (rtx, ...)): Replace typedef with
new class insn_gen_fn.
* expr.c (move_by_pieces_1, store_by_pieces_2): Replace
argument rtx (*) (rtx, ...) with insn_gen_fn.
* genoutput.c (output_insn_data): Cast gen_? function pointers
to insn_gen_fn::stored_funcptr. Add initializer braces.
Index: gcc/expr.c
===
--- gcc/expr.c (revision 201282)
+++ gcc/expr.c (working copy)
@@ -119,7 +119,7 @@
int reverse;
};
-static void move_by_pieces_1 (rtx (*) (rtx, ...), enum machine_mode,
+static void move_by_pieces_1 (insn_gen_fn, machine_mode,
struct move_by_pieces_d *);
static bool block_move_libcall_safe_for_call_parm (void);
static bool emit_block_move_via_movmem (rtx, rtx, rtx, unsigned, unsigned, HOST_WIDE_INT);
@@ -128,7 +128,7 @@
static rtx clear_by_pieces_1 (void *, HOST_WIDE_INT, enum machine_mode);
static void clear_by_pieces (rtx, unsigned HOST_WIDE_INT, unsigned int);
static void store_by_pieces_1 (struct store_by_pieces_d *, unsigned int);
-static void store_by_pieces_2 (rtx (*) (rtx, ...), enum machine_mode,
+static void store_by_pieces_2 (insn_gen_fn, machine_mode,
struct store_by_pieces_d *);
static tree clear_storage_libcall_fn (int);
static rtx compress_float_constant (rtx, rtx);
@@ -1043,7 +1043,7 @@
to make a move insn for that mode. DATA has all the other info. */
static void
-move_by_pieces_1 (rtx (*genfun) (rtx, ...), enum machine_mode mode,
+move_by_pieces_1 (insn_gen_fn genfun, machine_mode mode,
struct move_by_pieces_d *data)
{
unsigned int size = GET_MODE_SIZE (mode);
@@ -2657,7 +2657,7 @@
to make a move insn for that mode. DATA has all the other info. */
static void
-store_by_pieces_2 (rtx (*genfun) (rtx, ...), enum machine_mode mode,
+store_by_pieces_2 (insn_gen_fn genfun, machine_mode mode,
struct store_by_pieces_d *data)
{
unsigned int size = GET_MODE_SIZE (mode);
Index: gcc/genoutput.c
===
--- gcc/genoutput.c (revision 201282)
+++ gcc/genoutput.c (working copy)
@@
Re: [PATCH] Fix illegal cast to rtx (*insn_gen_fn) (rtx, ...)
On Sat, 2013-07-27 at 14:52 +0200, Oleg Endo wrote: > * I had to extend the number of max. args to 16, otherwise the SH > backend's sync.md code wouldn't compile. The error message was misleading. It wasn't sync.md but some other SH insn gen func that takes 16 args. Anyway, doesn't change the original fact that 11 args are not enough for all :) Cheers, Oleg
[Patch, Fortran, committed] PR 57285: [OOP] ICE on invalid: "gfc_array_dimen_size(): Bad dimension" due to SIZE intrinsic with invalid dim on CLASS dummy
Hi all, I have just committed an obvious minus-two-line patch to re-enable an error message for CLASS arrays (after a successful regtest): http://gcc.gnu.org/viewcvs?rev=201284&root=gcc&view=rev Cheers, Janus
[c++-concepts] Merge from trunk
Andrew Sutton writes: | Committed. Merge from trunk as of revision 201285. We will have to watch out for Tom's Makefile rewrite work. -- Gaby
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
Tobias Burnus wrote:
Tobias Burnus wrote:
Janus Weil wrote:
yes, the patch looks basically ok to me. Just one thing I did not
quite understand:
+ /* It can happen that the LHS has BT_DERIVED but it is in
reality
+ a polymorphic variable. */
How exactly can it happen that a polymorphic variable is BT_DERIVED?
I miss remembered (too hot here!) - the problem wasn't for one of my
newly added test cases but for an existing one. Without that bit, the
following test case is failing:
When I remove the "if" in class.c's gfc_add_component_ref's
if (!next)
e->ts = (*tail)->u.c.component->ts;
I get several failures, e.g.:
gfortran.dg/finalize_12.f90
gfortran.dg/finalize_13.f90
gfortran.dg/select_type_26.f03
gfortran.dg/select_type_27.f03
gfortran.dg/class_array_1.f03
gfortran.dg/class_array_15.f03
etc.
My newly added code does:
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
+ && expr2->expr_type != EXPR_FUNCTION)
+gfc_add_data_component (expr2);
which adds a "_data" ref to expr2 - but expr2->ts.type remains BT_CLASS.
Giving up on the class.c version, would be the following change okay?
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
+ && expr2->expr_type != EXPR_FUNCTION)
+{
+ gfc_add_data_component (expr2);
+ /* The following is required as gfc_add_data_component doesn't
+update ts.type if there is a tailing REF_ARRAY. */
+ expr2->ts.type = BT_DERIVED;
+}
+
[together with the removal of gfc_is_class_scalar_expr:
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
+ /*&& !gfc_is_class_scalar_expr (expr1)*/)
+ rse.expr = gfc_class_data_get (rse.expr);
]
It still feels a bit like a hack - but it is definitely much cleaner
than my previous band aid.
Built and regtested on x86-64-gnu-linux.
OK?
Tobias
Re: [PATCH v4] MIPS: IEEE 754-2008 features support
"Maciej W. Rozycki" writes: > 2013-07-26 Maciej W. Rozycki > > gcc/ > * config/mips/linux.h (GLIBC_DYNAMIC_LINKER): Handle `-mnan=2008'. > (UCLIBC_DYNAMIC_LINKER): New macro. > * config/mips/linux64.h (GLIBC_DYNAMIC_LINKER32): Handle > `-mnan=2008'. > (GLIBC_DYNAMIC_LINKER64, GLIBC_DYNAMIC_LINKERN32): Likewise. > (UCLIBC_DYNAMIC_LINKER32): Undefine macro first. Handle > `-mnan=2008'. > (UCLIBC_DYNAMIC_LINKER64): Redefine macro. > (UCLIBC_DYNAMIC_LINKERN32): Likewise. > * config/mips/mips-modes.def: Remove RESET_FLOAT_FORMAT calls > for SF and DF modes. Use ieee_quad_format for TF mode. > * config/mips/mips-opts.h (mips_ieee_754_setting): New enum. > * config/mips/mips.c (mips_file_start): Output a `.nan' directive. > (mips_option_override): Handle `-mnan=legacy'. > * config/mips/mips.h (TARGET_CPU_CPP_BUILTINS): Handle > `-mabs=2008' and `-mnan=2008'. > (OPTION_DEFAULT_SPECS): Add "nan" default. > (ASM_SPEC): Handle `-mnan='. > [!HAVE_AS_NAN] (HAVE_AS_NAN): New macro. > * config/mips/mips.md (abs2): Handle `-mabs=2008', update > comment accordingly. > (neg2): Likewise. > * config/mips/mips.opt (mabs, mnan): New options. > * doc/install.texi (Configuration): Document `--with-nan=' option. > * doc/invoke.texi (Option Summary): List MIPS `-mabs=' and > `-mnan=' options. > (MIPS Options): Document them. > * config.gcc : Handle `--with-nan='. > * configure.ac : Check for GAS `-mnan=2008' support. > * configure: Regenerate. > * config.in: Regenerate. > > gcc/testsuite/ > * gcc.target/mips/fabs-2008.c: New test case. > * gcc.target/mips/fabs-legacy.c: New test case. > * gcc.target/mips/fabsf-2008.c: New test case. > * gcc.target/mips/fabsf-legacy.c: New test case. > * gcc.target/mips/fneg-2008.c: New test case. > * gcc.target/mips/fneg-legacy.c: New test case. > * gcc.target/mips/fneg-2008.c: New test case. > * gcc.target/mips/fneg-legacy.c: New test case. > * gcc.target/mips/nan-2008.c: New test case. > * gcc.target/mips/nan-legacy.c: New test case. > * gcc.target/mips/nanf-2008.c: New test case. > * gcc.target/mips/nanf-legacy.c: New test case. > * gcc.target/mips/nans-2008.c: New test case. > * gcc.target/mips/nans-legacy.c: New test case. > * gcc.target/mips/nansf-2008.c: New test case. > * gcc.target/mips/nansf-legacy.c: New test case. > * gcc.target/mips/mips.exp: Handle `-mabs=' and `-mnan='. OK, thanks. Richard
Re: [PATCH 11/11] Make opt_pass and gcc::pipeline be GC-managed
On 26 July 2013 17:04:41 David Malcolm wrote:
diff --git a/gcc/passes.c b/gcc/passes.c
index ce5cdeb..dd1b0ba 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
+
+void gt_pch_nx_pipeline (void *this_obj, void *p,
+gt_pointer_operator op, void *cookie)
+{
+ pipeline *passes = (pipeline *)p;
+ if (p == this_obj)
+passes->gt_pch_nx_with_op (op, cookie);
+}
+
/* Call from anywhere to find out what pass this is. Useful for
printing out debugging information deep inside an service
s/an service/a service/;# separate patch
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index 41d5d92..c3e89d4 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -76,11 +76,22 @@ namespace gcc
/* An instance of a pass. This is also "pass_data" to minimize the
changes in existing code. */
-class opt_pass : public pass_data
+class GTY((user)) opt_pass : public pass_data
{
public:
+ /* Ensure that instances are allocated in the GC-managed heap. */
+ void *operator new (size_t sz);
+
virtual ~opt_pass () { }
+ /* GTY((user)) methods, to be called once per traversal.
+ opt_pass subclasses with additional GC-managed data should overide
s/ overide/ override/
Not a review but sounds goodish.
Sent with AquaMail for Android
http://www.aqua-mail.com
Committed: fix Epiphany UNKNOWN_REGNUM allocation for leaf functions.
2013-07-27 Joern Rennecke
* config/epiphany/epiphany.c (epiphany_compute_frame_size):
Also reserve space for saving UNKNOWN_REGNUM for leaf functions.
Index: config/epiphany/epiphany.c
===
--- config/epiphany/epiphany.c (revision 201267)
+++ config/epiphany/epiphany.c (working copy)
@@ -884,6 +884,11 @@ struct epiphany_frame_info
int stld_sz; /* Current load/store data size for offset
adjustment. */
int need_fp; /* value to override "frame_pointer_needed */
+ /* FIRST_SLOT is the slot that is saved first, at the very start of
+ the frame, with a POST_MODIFY to allocate the frame, if the size fits,
+ or at least the parm and register save areas, otherwise.
+ In the case of a large frame, LAST_SLOT is the slot that is saved last,
+ with a POST_MODIFY to allocate the rest of the frame. */
int first_slot, last_slot, first_slot_offset, last_slot_offset;
int first_slot_size;
int small_threshold;
@@ -1069,7 +1074,10 @@ epiphany_compute_frame_size (int size /*
to be a lot of code complexity for little gain. */
|| (reg_size > 8 && optimize))
reg_size = EPIPHANY_STACK_ALIGN (reg_size);
- if (total_size + reg_size <= (unsigned) epiphany_stack_offset
+ if (((total_size + reg_size
+ /* Reserve space for UNKNOWN_REGNUM. */
+ + EPIPHANY_STACK_ALIGN (4))
+ <= (unsigned) epiphany_stack_offset)
&& !interrupt_p
&& crtl->is_leaf && !frame_pointer_needed)
{
@@ -1108,7 +1116,7 @@ epiphany_compute_frame_size (int size /*
if (total_size + reg_size <= (unsigned) epiphany_stack_offset)
{
gcc_assert (first_slot < 0);
- gcc_assert (reg_size == 0);
+ gcc_assert (reg_size == 0 || reg_size == epiphany_stack_offset);
last_slot_offset = EPIPHANY_STACK_ALIGN (total_size + reg_size);
}
else
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
Tobias Burnus wrote:
Giving up on the class.c version, would be the following change okay?
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
+ && expr2->expr_type != EXPR_FUNCTION)
+{
+ gfc_add_data_component (expr2);
+ /* The following is required as gfc_add_data_component doesn't
+update ts.type if there is a tailing REF_ARRAY. */
+ expr2->ts.type = BT_DERIVED;
+}
It still feels a bit like a hack - but it is definitely much cleaner
than my previous band aid.
Built and regtested on x86-64-gnu-linux.
OK?
Attached is now the patch which does what I wrote above.
OK?
Tobias
2013-07-25 Tobias Burnus
PR fortran/57530
* trans-expr.c (gfc_trans_class_assign): Handle CLASS array
functions.
(gfc_trans_pointer_assign): Ditto and support pointer assignment of
a polymorphic var to a nonpolymorphic var.
2013-07-25 Tobias Burnus
PR fortran/57530
* gfortran.dg/pointer_assign_8.f90: New.
* gfortran.dg/pointer_assign_9.f90: New.
* gfortran.dg/pointer_assign_10.f90: New.
* gfortran.dg/pointer_assign_11.f90: New.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index e0cdd49..ac2fdb0 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1043,7 +1043,7 @@ assign_vptr:
gfc_add_data_component (expr2);
goto assign;
}
- else if (CLASS_DATA (expr2)->attr.dimension)
+ else if (CLASS_DATA (expr2)->attr.dimension && expr2->expr_type != EXPR_FUNCTION)
{
/* Insert an additional assignment which sets the '_vptr' field. */
lhs = gfc_copy_expr (expr1);
@@ -1061,9 +1061,10 @@ assign_vptr:
/* Do the actual CLASS assignment. */
if (expr2->ts.type == BT_CLASS
- && !CLASS_DATA (expr2)->attr.dimension)
+ && !CLASS_DATA (expr2)->attr.dimension)
op = EXEC_ASSIGN;
- else
+ else if (expr2->expr_type != EXPR_FUNCTION || expr2->ts.type != BT_CLASS
+ || !CLASS_DATA (expr2)->attr.dimension)
gfc_add_data_component (expr1);
assign:
@@ -6417,6 +6418,7 @@ gfc_trans_pointer_assign (gfc_code * code)
tree
gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2)
{
+ gfc_expr *expr1_vptr = NULL;
gfc_se lse;
gfc_se rse;
stmtblock_t block;
@@ -6437,6 +6518,15 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2)
if (!scalar)
gfc_free_ss_chain (ss);
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
+ && expr2->expr_type != EXPR_FUNCTION)
+{
+ gfc_add_data_component (expr2);
+ /* The following is required as gfc_add_data_component doesn't
+ update ts.type if there is a tailing REF_ARRAY. */
+ expr2->ts.type = BT_DERIVED;
+}
+
if (scalar)
{
/* Scalar pointers. */
@@ -6485,8 +6575,11 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2)
build_int_cst (gfc_charlen_type_node, 0));
}
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS)
+ rse.expr = gfc_class_data_get (rse.expr);
+
gfc_add_modify (&block, lse.expr,
- fold_convert (TREE_TYPE (lse.expr), rse.expr));
+ fold_convert (TREE_TYPE (lse.expr), rse.expr));
gfc_add_block_to_block (&block, &rse.post);
gfc_add_block_to_block (&block, &lse.post);
@@ -6508,8 +6601,12 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2)
break;
rank_remap = (remap && remap->u.ar.end[0]);
+ gfc_init_se (&lse, NULL);
if (remap)
lse.descriptor_only = 1;
+ if (expr2->expr_type == EXPR_FUNCTION && expr2->ts.type == BT_CLASS
+ && expr1->ts.type == BT_CLASS)
+ expr1_vptr = gfc_copy_expr (expr1);
gfc_conv_expr_descriptor (&lse, expr1);
strlen_lhs = lse.string_length;
desc = lse.expr;
@@ -6526,8 +6623,51 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2)
gfc_init_se (&rse, NULL);
rse.direct_byref = 1;
rse.byref_noassign = 1;
- gfc_conv_expr_descriptor (&rse, expr2);
- strlen_rhs = rse.string_length;
+
+ if (expr2->expr_type == EXPR_FUNCTION && expr2->ts.type == BT_CLASS)
+ {
+ gfc_conv_function_expr (&rse, expr2);
+
+ if (expr1->ts.type != BT_CLASS)
+ rse.expr = gfc_class_data_get (rse.expr);
+ else
+ {
+ tmp = gfc_create_var (TREE_TYPE (rse.expr), "ptrtemp");
+ gfc_add_modify (&lse.pre, tmp, rse.expr);
+
+ gfc_add_vptr_component (expr1_vptr);
+ gfc_init_se (&rse, NULL);
+ rse.want_pointer = 1;
+ gfc_conv_expr (&rse, expr1_vptr);
+ gfc_add_modify (&lse.pre, rse.expr,
+ fold_convert (TREE_TYPE (rse.expr),
+ gfc_class_vptr_get (tmp)));
+ rse.expr = gfc_class_data_get (tmp);
+ }
+ }
+ else if (expr2->expr_type == EXPR_FUNCTION)
+ {
+ tree bound[GFC_MAX_DIMENSIONS];
+ int i;
+
+ for (i = 0; i < expr2->rank; i++)
+ bound[i] = NULL_TREE;
+ tmp = gfc_typenode_for_spec (&expr2->ts);
+ tmp = gfc_get_array_type_bounds (tmp, expr2->rank, 0,
+ bound, bound, 0,
+
Re: [c++-concepts] Merge from trunk
> "Gaby" == Gabriel Dos Reis writes: Gaby> We will have to watch out for Tom's Makefile rewrite work. FWIW, I've found rebasing this series to be very easy. Due to the way it is split up, only one patch (the big manual dependency removal one) only ever has "hard" conflicts, and that patch is 99% deletion of a huge block -- easy to recreate. Tom
[PATCH] Fix PR57993 (ICE in slsr)
PR57993 reports a scenario where a conditional candidate is incorrectly
replaced when its putative "hidden basis" (the basis hidden by one or
more PHI nodes) does not dominate all of the PHI nodes on which the
candidate depends.
This indicates that the hidden basis was incorrectly identified as a
useful basis for the candidate. There are two ways we can fix this.
One would be to add more complexity to the code that determines the
hidden basis. Currently that code does not recursively follow the PHI
definitions backwards to ensure that the basis dominates all the PHIs.
Adding code to do this would ensure we didn't identify an incorrect
basis in the first place, but would duplicate quite a bit of existing
logic in the later analysis phase, and increase compile time.
What I've done here is to instead delay detection of the problem until
the analysis phase. If we detect that we chose an invalid basis, we
assign an "infinite" cost to the replacement so that we won't pursue it
further.
This requires that we know which basic block contains the basis
statement. The basis statement may have itself been replaced by another
statement earlier, so we need to keep the candidate table up to date
with respect to such replacements.
Bootstrapped and tested on powerpc64-linux-gnu with no new regressions.
Ok for trunk?
Thanks,
Bill
gcc:
2013-07-27 Bill Schmidt
* gimple-ssa-strength-reduction.c (replace_mult_candidate): Record
replaced statement in the candidate table.
(phi_add_costs): Return infinite cost when the hidden basis does
not dominate all phis on which the candidate is dependent.
(replace_one_candidate): Record replaced statement in the
candidate table.
gcc/testsuite:
2013-07-27 Bill Schmidt
* gcc.dg/torture/pr57993.c: New test.
Index: gcc/testsuite/gcc.dg/torture/pr57993.c
===
--- gcc/testsuite/gcc.dg/torture/pr57993.c (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr57993.c (revision 0)
@@ -0,0 +1,30 @@
+/* This ICEd prior to fixing PR57993. */
+/* { dg-do compile } */
+
+int a, b, c, d;
+char e;
+unsigned g;
+
+void f(void)
+{
+int h;
+
+for(; d; d++)
+if(d)
+lbl:
+g + a || (d = 0);
+
+b && (a = e);
+
+for(h = 0; h < 1; ++h)
+{
+h = c ? : (d = 0);
+g = a = (e | 0);
+}
+
+if(a)
+goto lbl;
+
+a = e = 0;
+goto lbl;
+}
Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 201267)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -1882,6 +1882,7 @@ replace_mult_candidate (slsr_cand_t c, tree basis_
gimple_stmt_iterator gsi = gsi_for_stmt (c->cand_stmt);
gimple_set_location (copy_stmt, gimple_location (c->cand_stmt));
gsi_replace (&gsi, copy_stmt, false);
+ c->cand_stmt = copy_stmt;
if (dump_file && (dump_flags & TDF_DETAILS))
stmt_to_print = copy_stmt;
}
@@ -2179,6 +2180,18 @@ phi_add_costs (gimple phi, slsr_cand_t c, int one_
int cost = 0;
slsr_cand_t phi_cand = base_cand_from_table (gimple_phi_result (phi));
+ /* If we work our way back to a phi that isn't dominated by the hidden
+ basis, this isn't a candidate for replacement. Indicate this by
+ returning an unreasonably high cost. It's not easy to detect
+ these situations when determining the basis, so we defer the
+ decision until now. */
+ basic_block phi_bb = gimple_bb (phi);
+ slsr_cand_t basis = lookup_cand (c->basis);
+ basic_block basis_bb = gimple_bb (basis->cand_stmt);
+
+ if (phi_bb == basis_bb || !dominated_by_p (CDI_DOMINATORS, phi_bb, basis_bb))
+return COST_INFINITE;
+
for (i = 0; i < gimple_phi_num_args (phi); i++)
{
tree arg = gimple_phi_arg_def (phi, i);
@@ -3226,6 +3239,7 @@ replace_one_candidate (slsr_cand_t c, unsigned i,
gimple_stmt_iterator gsi = gsi_for_stmt (c->cand_stmt);
gimple_set_location (copy_stmt, gimple_location (c->cand_stmt));
gsi_replace (&gsi, copy_stmt, false);
+ c->cand_stmt = copy_stmt;
if (dump_file && (dump_flags & TDF_DETAILS))
stmt_to_print = copy_stmt;
@@ -3238,6 +3252,7 @@ replace_one_candidate (slsr_cand_t c, unsigned i,
NULL_TREE);
gimple_set_location (cast_stmt, gimple_location (c->cand_stmt));
gsi_replace (&gsi, cast_stmt, false);
+ c->cand_stmt = cast_stmt;
if (dump_file && (dump_flags & TDF_DETAILS))
stmt_to_print = cast_stmt;
Re: [c++-concepts] Merge from trunk
Tom Tromey writes: | > "Gaby" == Gabriel Dos Reis writes: | | Gaby> We will have to watch out for Tom's Makefile rewrite work. | | FWIW, I've found rebasing this series to be very easy. | Due to the way it is split up, only one patch (the big manual dependency | removal one) only ever has "hard" conflicts, and that patch is 99% | deletion of a huge block -- easy to recreate. OK, that is good to know. Thanks! -- Gaby
[Patch] Refractor Thompson matcher
Refractor the whole Thompson matcher using the queue-based(BFS) Bellman-Ford algorithm. Fix the grouping problem. The original implementation uses a stack, which possibly runs slower when deduplicating; and cannot handle gourping correctly. The patch may not be very clear, so here's the whole files: https://github.com/innocentim/gcc/tree/tim/regex/libstdc++-v3/include/bits Thanks! -- Tim Shen bfs.patch Description: Binary data
Re: Testsuite tweaks for the SPARC
Eric Botcazou writes:
> Index: gcc.dg/vect/pr57705.c
> ===
> --- gcc.dg/vect/pr57705.c (revision 201177)
> +++ gcc.dg/vect/pr57705.c (working copy)
> @@ -61,5 +61,6 @@ main ()
>return 0;
> }
>
> -/* { dg-final { scan-tree-dump-times "vectorized 1 loop" 3 "vect" } } */
> +/* { dg-final { scan-tree-dump-times "vectorized 1 loop" 3 "vect" { target
> vect_pack_trunc } } } */
> +/* { dg-final { scan-tree-dump-times "vectorized 1 loop" 2 "vect" { target {
> ! vect_pack_trunc } } } } */
> /* { dg-final { cleanup-tree-dump "vect" } } */
That doesn't work on ia64.
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."
