Re: [PATCH 2/3] Add XLP-specific atomic instructions and tweaks.

[Richard Sandiford]

Maxim Kuvyrkov  writes:
> Updated patch attached.  Any further comments?

It's due to my bad explanation, sorry, but this isn't what I meant.
The two main changes I was looking for were:

1) Your pattern uses:

 [(mem:GPR (match_operand:P 1 "register_operand" "d"))]

   Instead, we should define a new memory predicate/constraint pair
   for memories that only accept register addresses.  I.e. there
   should be a new predicate to go alongside things like
   memory_operand and stack_operand, except that the new one would
   be even more restrictive in the set of addresses that it allows.
   mem_reg_operand seems as good a name as any, but I'm not wedded
   to a particular name.

   The new memory constraint would likewise go alongside "m", "W", etc.,
   except that (like the predicate) it too would only allow register
   addresses.  We're running low on constraint latters, so a two-operand
   one like "ZR" might be OK.  We can then use "Z" as a prefix for other
   MIPS-specific memory and address constraints in future.

   The atomic_exchange and atomic_fetch_add expanders should use
   the code I quoted in the earlier message to force the original
   memory_operand into this more restrictive form:

if (!mem_reg_operand (operands[1], mode))
  {
addr = force_reg (Pmode, XEXP (operands[1], 0));
operands[1] = replace_equiv_address (operands[1], addr);
  }

   The reason is that hard-coding (mem ...) in named define_insns
   (i.e. those with a gen_* function) is usually a mistake.  We end
   up discarding the original MEM and losing track of its MEM_ATTRs.

   (Note that this change means we don't need separate Pmode == SImode
   and Pmode == DImode patterns.)

2) Your pattern has:

  (match_operand:GPR 2 "arith_operand" "0")

   to match:

  (match_operand:GPR 0 "register_operand" "=d")

   Operand 2 doesn't accept constants, so it should be a register_operand
   rather than an arith_operand.  Then the atomic_exchange and atomic_fetch_add 
   expanders should use force_reg to turn _their_ arith_operands into
   register_operands before calling gen_atomic_fetch_add_ldadd
   and gen_atomic_fetch_swap.

Your new comment says:

   /* Spill the address to a register upfront to simplify reload's job.  */

But this isn't about making reload's job easier.  Reload can cope just
fine with the arith_operand above and would cope just fine with:

   (match_operand ... "memory_operand" "ZR")

with ZR defined as above.  Instead. we're trying to describe the
instruction as accurately as possible so that the pre-reload passes
(including IRA) are in a position to make good optimisation decisions.
They're less able to do that if patterns claim to accept more things
than they actually do.

I.e. it's the same reason that we don't just use "general_operand"
for all reloadable rvalues and "nonimmediate_operand" for all
reloadable lvalues.  Trying to use accurate predicates is such
standard practice that I think it'd be better to drop the comment here.
Having one gives the impression that we're trying to cope with some
special case, which AFAICT we're not.

Thanks,
Richard

Re: [Patch 4.6] In system.h, wrap include of C++ header in 'extern C++'

[Duncan Sands]

Hi,


If ENABLE_BUILD_WITH_CXX is defined, then GCC itself is built with C++,
and we want a C++ signature for functions.  If it is not defined, then
GCC itself is not built with C++, and we want (and must have) a C
signature.

I suppose we would decide that fancy_abort always uses a C signature,
but that seems odd.

Ian


I guess the issue is when people care only about C plugins, yet fancy_abort
get implicitly exported with a C++ linkage.

I suspect this goes back to the eternal question: what do we consider as
part of the public GCC public API (no, Basile, I am not suggesting to have
the same discussion again.)


if the following are to hold

(1) fancy_abort is declared in system.h
(2) system.h should not be wrapped in extern "C" when included from a plugin,
(3) it should be valid to include it from plugins compiled as C or as C++,
(4) fancy_abort should use the same linkage as GCC, i.e. C when GCC built as C,
C++ when built as C++ (aka ENABLE_BUILD_WITH_CXX).

then something like the following seems inevitable:

#ifdef ENABLE_BUILD_WITH_CXX
#ifdef __cplusplus
extern void fancy_abort(const char *, int, const char *) ATTRIBUTE_NORETURN;
#else
extern void _Z11fancy_abortPKciS0_(const char *, int, const char *) 
ATTRIBUTE_NORETURN;

#endif
#else
#ifdef __cplusplus
extern "C" void fancy_abort(const char *, int, const char *) ATTRIBUTE_NORETURN;
#else
extern void fancy_abort(const char *, int, const char *) ATTRIBUTE_NORETURN;
#endif
#endif

That's pretty nasty.  But to avoid the nastiness one of (1) - (4) needs to be
dropped.  Which one?

Ciao, Duncan.

Re: *ping* [Patch, Fortran] PR53642/45170c24 Deferred-length string fixes

[Tobias Burnus]

Om 13.06.2012 10:00, Tobias Burnus wrote:
This patch fixes issues with deferred length strings, where the new 
string length (= RHS len) is evaluated too late. That's fixed by 
calling gfc_add_block_to_block. I have no idea whether the condition 
makes sense or whether that function could always be called.


Additionally, in the FE optimization, it avoids the removal of trim in 
"lhs = trim(rhs)" if the lhs has a deferred length.


Build and regtested on x86-64-linux.
OK for the trunk?

Tobias

Re: *PING**2 [Patch, Fortran] Reject coarrays in MOVE_ALLOC

[Tobias Burnus]

http://gcc.gnu.org/ml/fortran/2012-05/msg00171.html

On 30.05.2012 13:56, Tobias Burnus wrote:

On 05/30/2012 11:09 AM, Tobias Burnus wrote:
This patch rejects actual arguments to MOVE_ALLOC which are coindexed 
or have a corank.


Updated version (cf. below). Build and regtested on x86-64-linux.
OK for the trunk?

I asked at J3 and John Reid kindly pointed me to the pending 
interpretation request F08/0040 at 
http://j3-fortran.org/doc/year/12/12-006A.txt


According to the IR, coarray arguments are allowed, if the FROM and TO 
have the same corank. (Hence, Damian's example remains invalid.)


Additionally, MOVE_ALLOC becomes an image control statement as TO 
might get deallocated. I filled a PR to track the implications for 
-fcoarray=lib: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526


Tobias

Re: **PING**2 [Patch, Fortran] PR53526 - Fix MOVE_ALLOC for coarrays

[Tobias Burnus]

http://gcc.gnu.org/ml/fortran/2012-05/msg00173.html

On 30.05.2012 18:35, Tobias Burnus wrote:
This patch is related to today's check.c patch, but independent (also 
order wise).


The patch ensures that for scalar coarrays, the array path is taken in 
trans-intrinsic. Thus, "to->data = from->data" gets replaced by "*to = 
*from" such that the array bounds (and with -fcoarray=lib the token) 
gets transferred as well.


While that also affected -fcoarray=single, the main changes are for 
the lib version:

- Call deregister instead of free
- Call sync all if TO is not deregistered. (move_alloc is an image 
control statement and, thus, implies synchronization)


Build and regtested on x86-64-linux.
OK for the trunk?

Tobias

[Patch, Fortran] PR53692 - Fix passing an absent array to an elemental procedure

[Tobias Burnus]

For details, see PR.

Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias
2012-06-16  Tobias Burnus  

	PR fortran/53692
	* trans-array.c (set_loop_bounds): Don't scalarize via absent
	optional arrays.
	* resolve.c (resolve_elemental_actual): Don't stop resolving after printing
	a warning.

2012-06-16  Tobias Burnus  

	PR fortran/53692
	* gfortran.dg/elemental_optional_args_6.f90: New.

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 0e78210..f135af1 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -4337,6 +4337,7 @@ set_loop_bounds (gfc_loopinfo *loop)
   bool dynamic[GFC_MAX_DIMENSIONS];
   mpz_t *cshape;
   mpz_t i;
+  bool nonoptional_arr;
 
   loopspec = loop->specloop;
 
@@ -4345,6 +4346,18 @@ set_loop_bounds (gfc_loopinfo *loop)
 {
   loopspec[n] = NULL;
   dynamic[n] = false;
+
+  /* If there are both optional and nonoptional array arguments, scalarize
+	 over the nonoptional; otherwise, it does not matter as then all
+	 (optional) arrays have to be present per F2008, 125.2.12p3(6).  */
+
+  nonoptional_arr = false;
+
+  for (ss = loop->ss; ss != gfc_ss_terminator; ss = ss->loop_chain)
+	if (ss->info->type != GFC_SS_SCALAR && ss->info->type != GFC_SS_TEMP
+	&& ss->info->type != GFC_SS_REFERENCE && !ss->info->can_be_null_ref)
+	  nonoptional_arr = true;
+
   /* We use one SS term, and use that to determine the bounds of the
 	 loop for this dimension.  We try to pick the simplest term.  */
   for (ss = loop->ss; ss != gfc_ss_terminator; ss = ss->loop_chain)
@@ -4354,7 +4367,8 @@ set_loop_bounds (gfc_loopinfo *loop)
 	  ss_type = ss->info->type;
 	  if (ss_type == GFC_SS_SCALAR
 	  || ss_type == GFC_SS_TEMP
-	  || ss_type == GFC_SS_REFERENCE)
+	  || ss_type == GFC_SS_REFERENCE
+	  || (ss->info->can_be_null_ref && nonoptional_arr))
 	continue;
 
 	  info = &ss->info->data.array;
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 8531318..7d1e281 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1957,7 +1957,6 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code *c)
 		   "ELEMENTAL procedure unless there is a non-optional "
 		   "argument with the same rank (12.4.1.5)",
 		   arg->expr->symtree->n.sym->name, &arg->expr->where);
-	  return FAILURE;
 	}
 }
 
--- /dev/null	2012-06-16 07:44:03.623809858 +0200
+++ gcc/gcc/testsuite/gfortran.dg/elemental_optional_args_6.f90	2012-06-16 12:58:11.0 +0200
@@ -0,0 +1,56 @@
+! { dg-do run }
+!
+! PR fortran/53692
+!
+! Check that the nonabsent arrary is used for scalarization:
+! Either the NONOPTIONAL one or, if there are none, any array.
+!
+! Based on a program by Daniel C Chen
+!
+Program main
+  implicit none
+  integer :: arr1(2), arr2(2)
+  arr1 = [ 1, 2 ]
+  arr2 = [ 1, 2 ]
+  call sub1 (arg2=arr2)
+
+  call two ()
+contains
+   subroutine sub1 (arg1, arg2)
+  integer, optional :: arg1(:)
+  integer :: arg2(:)
+!  print *, fun1 (arg1, arg2)
+  if (size (fun1 (arg1, arg2)) /= 2) call abort() ! { dg-warning "is an array and OPTIONAL" }
+  if (any (fun1 (arg1, arg2) /= [1,2])) call abort() ! { dg-warning "is an array and OPTIONAL" }
+   end subroutine
+
+   elemental function fun1 (arg1, arg2)
+  integer,intent(in), optional :: arg1
+  integer,intent(in)   :: arg2
+  integer  :: fun1
+  fun1 = arg2
+   end function
+end program
+
+subroutine two ()
+  implicit none
+  integer :: arr1(2), arr2(2)
+  arr1 = [ 1, 2 ]
+  arr2 = [ 1, 2 ]
+  call sub2 (arr1, arg2=arr2)
+contains
+   subroutine sub2 (arg1, arg2)
+  integer, optional :: arg1(:)
+  integer, optional :: arg2(:)
+!  print *, fun2 (arg1, arg2)
+  if (size (fun2 (arg1, arg2)) /= 2) call abort() ! { dg-warning "is an array and OPTIONAL" }
+  if (any (fun2 (arg1, arg2) /= [1,2])) call abort() ! { dg-warning "is an array and OPTIONAL" }
+   end subroutine
+
+   elemental function fun2 (arg1,arg2)
+  integer,intent(in), optional :: arg1
+  integer,intent(in), optional :: arg2
+  integer  :: fun2
+  fun2 = arg2
+   end function
+end subroutine two

[Patch, Fortran] Implement RANK

[Tobias Burnus]

This patch adds run-time support for the RANK intrinsic. That's 
currently a bit pointless as the rank is known at compile time and, 
thus, the new code is unreachable as simplify.c handles it.


However, it becomes useful for assumed-rank arrays ("dimension(..)") of 
TS 29113. I tested it by disabling the simplify.c's version and with my 
incomplete draft patch for "(..)".


Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias
2012-06-16  Tobias Burnus  

	* intrinsic.h (gfc_resolve_rank): New prototype.
	* intrinsic.c (add_functions): Use gfc_resolve_rank.
	* iresolve.c (add_functions): New function.
	* trans-intrinsic.c (gfc_conv_intrinsic_rank): New function.
	(gfc_conv_intrinsic_function): Call it.

diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index 38bcb27..88d4636 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -2434,7 +2434,7 @@ add_functions (void)
   make_generic ("range", GFC_ISYM_RANGE, GFC_STD_F95);
 
   add_sym_1 ("rank", GFC_ISYM_RANK, CLASS_INQUIRY, ACTUAL_NO, BT_INTEGER, di,
-	 GFC_STD_F2008_TS, gfc_check_rank, gfc_simplify_rank, NULL,
+	 GFC_STD_F2008_TS, gfc_check_rank, gfc_simplify_rank, gfc_resolve_rank,
 	 a, BT_REAL, dr, REQUIRED);
   make_generic ("rank", GFC_ISYM_RANK, GFC_STD_F2008_TS);
 
diff --git a/gcc/fortran/intrinsic.h b/gcc/fortran/intrinsic.h
index bfc2455..2635ba6 100644
--- a/gcc/fortran/intrinsic.h
+++ b/gcc/fortran/intrinsic.h
@@ -486,6 +486,7 @@ void gfc_resolve_long (gfc_expr *, gfc_expr *);
 void gfc_resolve_ior (gfc_expr *, gfc_expr *, gfc_expr *);
 void gfc_resolve_iparity (gfc_expr *, gfc_expr *, gfc_expr *, gfc_expr *);
 void gfc_resolve_isatty (gfc_expr *, gfc_expr *);
+void gfc_resolve_rank (gfc_expr *, gfc_expr *);
 void gfc_resolve_rshift (gfc_expr *, gfc_expr *, gfc_expr *);
 void gfc_resolve_lshift (gfc_expr *, gfc_expr *, gfc_expr *);
 void gfc_resolve_ishft (gfc_expr *, gfc_expr *, gfc_expr *);
diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index 9d94e3b..2a49455 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -2006,6 +2006,15 @@ gfc_resolve_product (gfc_expr *f, gfc_expr *array, gfc_expr *dim,
 
 
 void
+gfc_resolve_rank (gfc_expr *f, gfc_expr *array ATTRIBUTE_UNUSED)
+{
+  f->ts.type = BT_INTEGER;
+  f->ts.kind = gfc_default_integer_kind;
+  f->value.function.name = gfc_get_string ("__rank");
+}
+
+
+void
 gfc_resolve_real (gfc_expr *f, gfc_expr *a, gfc_expr *kind)
 {
   f->ts.type = BT_REAL;
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 04d6caa..bd6f600 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1663,6 +1663,32 @@ conv_intrinsic_cobound (gfc_se * se, gfc_expr * expr)
 
 
 static void
+gfc_conv_intrinsic_rank (gfc_se *se, gfc_expr *expr)
+{
+  gfc_se argse;
+  gfc_ss *ss;
+  tree dtype, tmp;
+
+  ss = gfc_walk_expr (expr->value.function.actual->expr);
+  gcc_assert (ss != gfc_ss_terminator);
+  gfc_init_se (&argse, NULL);
+  argse.data_not_needed = 1;
+  argse.want_pointer = 1;
+
+  gfc_conv_expr_descriptor (&argse, expr->value.function.actual->expr, ss);
+  gfc_add_block_to_block (&se->pre, &argse.pre);
+  gfc_add_block_to_block (&se->post, &argse.post);
+  argse.expr = build_fold_indirect_ref_loc (input_location, argse.expr);
+  argse.expr = build_fold_indirect_ref_loc (input_location, argse.expr);
+  dtype = gfc_conv_descriptor_dtype (argse.expr);
+  tmp = build_int_cst (TREE_TYPE (dtype), GFC_DTYPE_RANK_MASK);
+  tmp = fold_build2_loc (input_location, BIT_AND_EXPR, TREE_TYPE (dtype),
+			 dtype, tmp);
+  se->expr = fold_convert (gfc_get_int_type (gfc_default_integer_kind), tmp);
+}
+
+
+static void
 gfc_conv_intrinsic_abs (gfc_se * se, gfc_expr * expr)
 {
   tree arg, cabs;
@@ -6710,6 +6736,10 @@ gfc_conv_intrinsic_function (gfc_se * se, gfc_expr * expr)
   gfc_conv_intrinsic_arith (se, expr, MULT_EXPR, false);
   break;
 
+case GFC_ISYM_RANK:
+  gfc_conv_intrinsic_rank (se, expr);
+  break;
+
 case GFC_ISYM_RRSPACING:
   gfc_conv_intrinsic_rrspacing (se, expr);
   break;

Re: [PATCH 2/3] Use synth_mult for vector multiplies vs scalar constant

[Eric Botcazou]

> @@ -179,7 +179,11 @@ extern const unsigned char
> mode_class[NUM_MACHINE_MODES];
>
>  extern CONST_MODE_SIZE unsigned char mode_size[NUM_MACHINE_MODES];
>  #define GET_MODE_SIZE(MODE)((unsigned short) mode_size[MODE])
> -#define GET_MODE_BITSIZE(MODE) ((unsigned short) (GET_MODE_SIZE (MODE) *
> BITS_PER_UNIT)) +
> +#define GET_MODE_BITSIZE(MODE) \
> +  ((unsigned short) (GET_MODE_SIZE (MODE) * BITS_PER_UNIT))
> +#define GET_MODE_UNIT_BITSIZE(MODE) \
> +  ((unsigned short) (GET_MODE_UNIT_SIZE (MODE) * BITS_PER_UNIT))
>
>  /* Get the number of value bits of an object of mode MODE.  */
>  extern const unsigned short mode_precision[NUM_MACHINE_MODES];

Can you move GET_MODE_UNIT_BITSIZE to after GET_MODE_UNIT_SIZE, changing "size 
in bytes" to "size in bytes and bits" in the comment just above?  Because the 
overloading of UNIT in the macro makes the whole thing slightly confusing. :-)

-- 
Eric Botcazou

[Patch, Fortran] PRs - fix TRANSFER checks

[Tobias Burnus]

Two rather simple patches.

Build and regtested on x86-64-linux.
As one of the issues is a 4.7/4.8 regression:
OK for the trunk and 4.7?

Tobias
2012-06-16  Tobias Burnus  

	PR fortran/53691
	PR fortran/53685
	* check.c (gfc_calculate_transfer_sizes): Return if
	SIZE= is not constant or source-size cannot be determined.

2012-06-16  Tobias Burnus  

	PR fortran/53691
	PR fortran/53685
	* gfortran.dg/transfer_check_3.f90: New.

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 9926f05..9be8f66 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3986,7 +3986,6 @@ gfc_try
 gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr *mold, gfc_expr *size,
 			  size_t *source_size, size_t *result_size,
 			  size_t *result_length_p)
-
 {
   size_t result_elt_size;
   mpz_t tmp;
@@ -3995,12 +3994,17 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr *mold, gfc_expr *size,
   if (source->expr_type == EXPR_FUNCTION)
 return FAILURE;
 
-/* Calculate the size of the source.  */
+  if (size && size->expr_type != EXPR_CONSTANT)
+return FAILURE;
+
+  /* Calculate the size of the source.  */
   if (source->expr_type == EXPR_ARRAY
   && gfc_array_size (source, &tmp) == FAILURE)
 return FAILURE;
 
   *source_size = gfc_target_expr_size (source);
+  if (*source_size == 0)
+return FAILURE;
 
   mold_element = mold->expr_type == EXPR_ARRAY
 		 ? gfc_constructor_first (mold->value.constructor)->expr
--- /dev/null	2012-06-16 07:44:03.623809858 +0200
+++ gcc/gcc/testsuite/gfortran.dg/transfer_check_3.f90	2012-06-16 13:28:12.0 +0200
@@ -0,0 +1,33 @@
+! { dg-do compile }
+! { dg-options "-Wsurprising" }
+!
+! PR fortran/53691
+! PR fortran/53685
+!
+! TRANSFER checks
+
+
+! (a) PR 53691
+! Failed for -Wsurprising with an ICE as SIZE was assumed to be constant
+
+   SUBROUTINE CGBRFSX(N, RWORK)
+ INTEGER N
+ REAL RWORK(*)
+ REAL ZERO
+ PARAMETER (ZERO = 0.0E+0)
+ call foo(TRANSFER (RWORK(1:2*N), (/ (ZERO, ZERO) /), N))
+   end
+
+! (b) PR 53685
+! Failed with a bogus size warning if the source's size is not known at compile
+! time (for substrings, the length wasn't set)
+
+  subroutine test(j)
+implicit none
+character(len=4) :: record_type
+integer  :: i, j
+
+i = transfer (record_type, i)  ! no warning
+i = transfer (record_type(1:4), i) ! gave a warning
+i = transfer (record_type(1:j), i) ! gave a warning
+  end

[Patch, Fortran] Add parsing support for assumed-rank array

[Tobias Burnus]

To cleanup my local trees; I had the patch lingering there for a many weeks.

User visible, it only adds parsing support for "dimension(..)" and a 
sorry message.


Internally, it implements a basic support for assumed-shape arrays. 
There are still many constraint checks missing, scalar actual arguments 
to assumed-rank dummies have issues, and many intrinsics do not yet 
handle assumed-rank arguments.


In order to be more useful, some C binding changes and the 
implementation of IS_CONTIGUOUS is required. However, the big stumbling 
block for practical usage is the array descriptor: Instead of using the 
TS29113 one, gfortran's internal one is passed. [Cf. array descriptor 
reform.*]


Build on x86-64-linux.
OK for the trunk?

Tobias

* Talking about the new array descriptor, we really should find out why 
the following patch fails: 
http://gcc.gnu.org/ml/fortran/2012-04/msg00115.html
2012-06-12  Tobias Burnus  

	* array.c (gfc_match_array_spec, gfc_match_array_spec): Add support
	for assumed-rank arrays.
	* check.c (dim_rank_check): Ditto.
	* dump-parse-tree.c (show_array_spec): Ditto.
	* gfortran.h (array_type): Ditto.
	* interface.c (compare_type_rank, compare_parameter): Ditto.
	* resolve.c (resolve_formal_arglist, resolve_global_procedure,
	expression_shape, resolve_variable, resolve_symbol): Ditto.
	* simplify.c (simplify_bound, gfc_simplify_range): Ditto.
	* trans-array.c (gfc_conv_array_parameter): Ditto.
	* trans-decl. (gfc_build_dummy_array_decl,
	gfc_trans_deferred_vars): Ditto.
	* trans-types.c (gfc_is_nodesc_array, gfc_build_array_type,
	gfc_get_array_descriptor_base): Ditto.

diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index b36d517..5b412dc 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -457,6 +457,24 @@ gfc_match_array_spec (gfc_array_spec **asp, bool match_dim, bool match_codim)
   goto coarray;
 }
 
+  if (gfc_match (" .. )") == MATCH_YES)
+{
+  as->type = AS_ASSUMED_RANK;
+  as->rank = -1;
+
+  if (gfc_notify_std (GFC_STD_F2008_TS, "TS 29113: Assumed-rank array "
+			  "at %C") == FAILURE)
+	goto cleanup;
+
+  gfc_error ("Sorry, support for assumed-rank array at %C is not yet "
+		 "implemented");
+  goto cleanup;
+
+  if (!match_codim)
+	goto done;
+  goto coarray;
+}
+
   for (;;)
 {
   as->rank++;
@@ -535,6 +553,9 @@ gfc_match_array_spec (gfc_array_spec **asp, bool match_dim, bool match_codim)
 
 	gfc_error ("Bad specification for assumed size array at %C");
 	goto cleanup;
+
+	  case AS_ASSUMED_RANK:
+	gcc_unreachable (); 
 	  }
 
   if (gfc_match_char (')') == MATCH_YES)
@@ -641,6 +662,9 @@ coarray:
 	case AS_ASSUMED_SIZE:
 	  gfc_error ("Bad specification for assumed size array at %C");
 	  goto cleanup;
+
+	case AS_ASSUMED_RANK:
+	  gcc_unreachable (); 
 	  }
 
   if (gfc_match_char (']') == MATCH_YES)
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 9926f05..ff71ff5 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -618,6 +618,10 @@ dim_rank_check (gfc_expr *dim, gfc_expr *array, int allow_assumed)
   else
 rank = array->rank;
 
+  /* Assumed-rank array.  */
+  if (rank == -1)
+rank = GFC_MAX_DIMENSIONS;
+
   if (array->expr_type == EXPR_VARIABLE)
 {
   ar = gfc_find_array_ref (array);
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 7f1d28f..14909f4 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -173,6 +173,7 @@ show_array_spec (gfc_array_spec *as)
 	case AS_DEFERRED:  c = "AS_DEFERRED";  break;
 	case AS_ASSUMED_SIZE:  c = "AS_ASSUMED_SIZE";  break;
 	case AS_ASSUMED_SHAPE: c = "AS_ASSUMED_SHAPE"; break;
+	case AS_ASSUMED_RANK:  c = "AS_ASSUMED_RANK";  break;
 	default:
 	  gfc_internal_error ("show_array_spec(): Unhandled array shape "
 			  "type.");
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 759074a..454d873 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -132,7 +132,8 @@ expr_t;
 /* Array types.  */
 typedef enum
 { AS_EXPLICIT = 1, AS_ASSUMED_SHAPE, AS_DEFERRED,
-  AS_ASSUMED_SIZE, AS_IMPLIED_SHAPE, AS_UNKNOWN
+  AS_ASSUMED_SIZE, AS_IMPLIED_SHAPE, AS_ASSUMED_RANK,
+  AS_UNKNOWN
 }
 array_type;
 
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 95439c1..13f3ee8 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -511,7 +511,9 @@ compare_type_rank (gfc_symbol *s1, gfc_symbol *s2)
   r1 = (s1->as != NULL) ? s1->as->rank : 0;
   r2 = (s2->as != NULL) ? s2->as->rank : 0;
 
-  if (r1 != r2)
+  if (r1 != r2
+  && (!s1->as || s1->as->type != AS_ASSUMED_RANK)
+  && (!s2->as || s2->as->type != AS_ASSUMED_RANK))
 return 0;			/* Ranks differ.  */
 
   return gfc_compare_types (&s1->ts, &s2->ts)
@@ -1842,7 +1844,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
 		 " is modified",  &actual->where, formal->name);
 }
 
-  if (symbol_rank 

Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore

[Richard Sandiford]

Roland McGrath  writes:
> On Thu, Jun 14, 2012 at 1:13 PM, Mike Stump  wrote:
>> On Jun 14, 2012, at 10:16 AM, Roland McGrath wrote:
>>> But if e.g. I use -ffixed-r9 then I think it's a reasonable expectation
>>> that no code is generated that touches r9 in any way, shape, or form.
>>
>> Also, I can't help but wonder if global_regs is respected.
>
> It's clearly not.  Making the added condition !fixed_regs[i] &&
> !global_regs[i] seems sensible to me.

All global registers have to be fixed though.  The original seemed
fine to me FWIW.

Richard

Re: Ping: always supply a mode to plus_constant

[H.J. Lu]

On Sat, May 5, 2012 at 3:23 PM, H.J. Lu  wrote:
> On Thu, May 3, 2012 at 11:15 AM, Richard Sandiford
>  wrote:
>> Ping for this patch to always supply a mode to plus_constant:
>>
>>    http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00892.html
>>
>> I've done a diff of the changes since the original test revision
>> (which was r186448 FWIW) and there's only been one plus_constant-
>> related change since then: Alan's rs6000 prologue/epilogue fixes.
>> I'd repeat the original testing before committing.
>>
>
> This caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249
>
>

It also caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53698

-- 
H.J.

[PATCH] Decimal Floating-Point (libbid) for GNU/Hurd

[Thomas Schwinge]

Hi!

Intel folks, the bid_functions.h change is for you, that one plus the
other changes are for GCC.

libgcc/config/libbid/
* bid_functions.h: Check for __GLIBC__ additionally to LINUX when
defining format specifiers.

config/
* dfp.m4 (enable_decimal_float): Enable for i?86*-*-gnu*.

gcc/
* configure: Regenerate.

libdecnumber/
* configure: Regenerate.

libgcc/
* configure: Regenerate.

OK to check in?


Grüße,
 Thomas

---
 config/dfp.m4|1 +
 gcc/configure|5 +++--
 libdecnumber/configure   |1 +
 libgcc/config/libbid/bid_functions.h |4 ++--
 libgcc/configure |1 +
 5 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/config/dfp.m4 b/config/dfp.m4
index cc778b1..e971db4 100644
--- a/config/dfp.m4
+++ b/config/dfp.m4
@@ -21,6 +21,7 @@ Valid choices are 'yes', 'bid', 'dpd', and 'no'.]) ;;
 [
   case $1 in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
+i?86*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/gcc/configure b/gcc/configure
index 1fdf0af..3fea751 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -7053,6 +7053,7 @@ else
 
   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
+i?86*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin*)
   enable_decimal_float=yes
@@ -17971,7 +17972,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17974 "configure"
+#line 17975 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -18077,7 +18078,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18080 "configure"
+#line 18081 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/libdecnumber/configure b/libdecnumber/configure
index 2b58684..0466371 100755
--- a/libdecnumber/configure
+++ b/libdecnumber/configure
@@ -4611,6 +4611,7 @@ else
 
   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
+i?86*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/libgcc/config/libbid/bid_functions.h 
b/libgcc/config/libbid/bid_functions.h
index 579370a..abb27b9 100644
--- a/libgcc/config/libbid/bid_functions.h
+++ b/libgcc/config/libbid/bid_functions.h
@@ -1,4 +1,4 @@
-/* Copyright (C) 2007, 2009  Free Software Foundation, Inc.
+/* Copyright (C) 2007, 2009, 2011 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -124,7 +124,7 @@ ALIGN (16)
 #define DENORMAL_MODE   0x0100
 #define INVALID_MODE0x0080
 
-#if defined LINUX || defined SUNOS
+#if defined LINUX || defined __GLIBC__ || defined SUNOS
 #define LX16  "%016llx"
 #define LX"%llx"
 #define LD4   "%4llu"
diff --git a/libgcc/configure b/libgcc/configure
index a226f81..e645378 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -4075,6 +4075,7 @@ else
 
   case $host in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
+i?86*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin*)
   enable_decimal_float=yes
-- 
tg: (c5acd2b..) hurd/decimal_floating_point (depends on: baseline)

Re: [PATCH] Decimal Floating-Point (libbid) for GNU/Hurd

[H.J. Lu]

On Sat, Jun 16, 2012 at 7:32 AM, Thomas Schwinge
 wrote:
> Hi!
>
> Intel folks, the bid_functions.h change is for you, that one plus the
> other changes are for GCC.
>
> libgcc/config/libbid/
>        * bid_functions.h: Check for __GLIBC__ additionally to LINUX when
>        defining format specifiers.
>

Looks OK to me.

Thanks.

-- 
H.J.

[PATCH] boehm-gc configuration support for GNU/Hurd

[Thomas Schwinge]

Hello!

This is a backport of upstream boehm-gc configuration support for
GNU/Hurd.  The equivalent thing has been used in Debian's GCC packages
since GCC 4.2 already, and I decided that *NOW* ought to be the time to
put it into the GCC tree.

That patch has mostly be done by Samuel Thibault .

boehm-gc/
* configure.ac: Add stanza for *-*-gnu* threads configuration.
* configure: Regenerate.
* include/gc_config.h.in: Likewise.
* dyn_load.c (_GNU_SOURCE): Define for __GNU__.
* include/gc_config_macros.h (_REENTRANT, GC_PTHREADS): Define for
GC_GNU_THREADS.
* include/private/gcconfig.h (DATASTART): Don't define for I386 &&
HURD.
(SIG_SUSPEND, SIG_THR_RESTART, SEARCH_FOR_DATA_START): Define for I386
&& HURD.
(UNIX_LIKE, REGISTER_LIBRARIES_EARLY): Define for HURD.
* os_dep.c (GC_init_linux_data_start): Handle for HURD.
* pthread_support.c (GC_thr_init): Add case for GC_GNU_THREADS.
* specific.c: Use for GC_GNU_THREADS.
* threadlibs.c: Add case for GC_GNU_THREADS.

OK to commit?


Grüße,
 Thomas

---
 boehm-gc/configure  |9 +
 boehm-gc/configure.ac   |5 +
 boehm-gc/dyn_load.c |3 ++-
 boehm-gc/include/gc_config.h.in |3 +++
 boehm-gc/include/gc_config_macros.h |4 +++-
 boehm-gc/include/private/gcconfig.h |   13 +
 boehm-gc/os_dep.c   |4 ++--
 boehm-gc/pthread_support.c  |2 +-
 boehm-gc/specific.c |2 +-
 boehm-gc/threadlibs.c   |3 ++-
 10 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/boehm-gc/configure b/boehm-gc/configure
index aa61053..0eeab69 100755
--- a/boehm-gc/configure
+++ b/boehm-gc/configure
@@ -14794,6 +14794,15 @@ $as_echo "$as_me: WARNING: \"Only HP-UX 11 POSIX 
threads are supported.\"" >&2;}
 $as_echo "#define USE_COMPILER_TLS 1" >>confdefs.h
 
;;
+ *-*-gnu*)
+
+$as_echo "#define GC_GNU_THREADS 1" >>confdefs.h
+
+   $as_echo "#define _REENTRANT 1" >>confdefs.h
+
+   $as_echo "#define THREAD_LOCAL_ALLOC 1" >>confdefs.h
+
+   ;;
  *-*-freebsd*)
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: \"FreeBSD does not 
yet fully support threads with Boehm GC.\"" >&5
 $as_echo "$as_me: WARNING: \"FreeBSD does not yet fully support threads with 
Boehm GC.\"" >&2;}
diff --git a/boehm-gc/configure.ac b/boehm-gc/configure.ac
index 2eddc9f..1ccfe37 100644
--- a/boehm-gc/configure.ac
+++ b/boehm-gc/configure.ac
@@ -175,6 +175,11 @@ case "$THREADS" in
AC_DEFINE(THREAD_LOCAL_ALLOC)
AC_DEFINE(USE_COMPILER_TLS, 1,[use tls for boehm])
;;
+ *-*-gnu*)
+   AC_DEFINE(GC_GNU_THREADS,1,[support GNU threads])
+   AC_DEFINE(_REENTRANT)
+   AC_DEFINE(THREAD_LOCAL_ALLOC)
+   ;;
  *-*-freebsd*)
AC_MSG_WARN("FreeBSD does not yet fully support threads with Boehm GC.")
AC_DEFINE(GC_FREEBSD_THREADS,1,[support FreeBSD threads])
diff --git a/boehm-gc/dyn_load.c b/boehm-gc/dyn_load.c
index f1e3e8e..eac2e71 100644
--- a/boehm-gc/dyn_load.c
+++ b/boehm-gc/dyn_load.c
@@ -26,7 +26,8 @@
  * None of this is safe with dlclose and incremental collection.
  * But then not much of anything is safe in the presence of dlclose.
  */
-#if (defined(__linux__) || defined(__GLIBC__)) && !defined(_GNU_SOURCE)
+#if (defined(__linux__) || defined(__GLIBC__) || defined(__GNU__)) \
+&& !defined(_GNU_SOURCE)
 /* Can't test LINUX, since this must be define before other includes */
 #   define _GNU_SOURCE
 #endif
diff --git a/boehm-gc/include/gc_config.h.in b/boehm-gc/include/gc_config.h.in
index 6bdd807..d1ae47d 100644
--- a/boehm-gc/include/gc_config.h.in
+++ b/boehm-gc/include/gc_config.h.in
@@ -33,6 +33,9 @@
 /* include support for gcj */
 #undef GC_GCJ_SUPPORT
 
+/* support GNU threads */
+#undef GC_GNU_THREADS
+
 /* enables support for HP/UX 11 pthreads */
 #undef GC_HPUX_THREADS
 
diff --git a/boehm-gc/include/gc_config_macros.h 
b/boehm-gc/include/gc_config_macros.h
index 12e91e2..fd3006c 100644
--- a/boehm-gc/include/gc_config_macros.h
+++ b/boehm-gc/include/gc_config_macros.h
@@ -6,7 +6,8 @@
 || defined(GC_SOLARIS_PTHREADS) \
 || defined(GC_HPUX_THREADS) \
 || defined(GC_AIX_THREADS) \
-|| defined(GC_LINUX_THREADS))
+|| defined(GC_LINUX_THREADS) \
+|| defined(GC_GNU_THREADS))
 # define _REENTRANT
/* Better late than never.  This fails if system headers that   */
/* depend on this were previously included. */
@@ -18,6 +19,7 @@
 
 # if defined(GC_SOLARIS_PTHREADS) || defined(GC_FREEBSD_THREADS) || \
defined(GC_IRIX_THREADS) || defined(GC_LINUX_THREADS) || \
+   defined(GC_GNU_THREADS) || \
defined(GC_HPUX_THREADS) || defined(GC_OSF1_THRE

Re: [patch] Reduce over-promotion of vector operations

[H.J. Lu]

On Thu, Aug 4, 2011 at 9:47 AM, Ira Rosen  wrote:
> On 19 July 2011 09:44, Ira Rosen  wrote:
>> Hi,
>>
>> This patch tries to reduce over-promotion of vector operations that
>> could be done with narrower elements, e.g., for
>>
>> char a;
>> int b, c;
>> short d;
>>
>> b = (int) a;
>> c = b << 2;
>> d = (short) c;
>>
>> we currently produce six vec_unpack_lo/hi_expr statements for
>> char->int conversion and then two vec_pack_trunc_expr for short->int.
>> While the shift can be performed on short, using only two
>> vec_unpack_lo/hi_expr operations for char->short conversion in this
>> example.
>>
>> With this patch we detect such over-promoted sequences that start with
>> a type promotion operation and end with a type demotion operation. The
>> statements in between are checked if they can be performed using
>> smaller type (this patch only adds a support for shifts and bit
>> operations with a constant). If a sequence is detected we create a
>> sequence of scalar pattern statements to be vectorized instead the
>> original one.  Since there may be two pattern statements created for
>> the same original statement - the operation itself (on an intermediate
>> type) and a type promotion (from a smaller type to the intermediate
>> type) for the non-constant operand - this patch adds a new field to
>> struct _stmt_vec_info to keep that pattern def statement.
>>
>> Bootstrapped and tested on powerpc64-suse-linux.
>> Comments are welcome.
>
> I committed the attached version which incorporates Richard's comments
> from here http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00144.html.
>
> Thanks,
> Ira
>
>>
>> Thanks,
>> Ira
>>
>> ChangeLog:
>>
>>   * tree-vectorizer.h (struct _stmt_vec_info): Add new field for
>>   pattern def statement, and its access macro.
>>   (NUM_PATTERNS): Set to 5.
>>   * tree-vect-loop.c (vect_determine_vectorization_factor): Handle
>>   pattern def statement.
>>   (vect_transform_loop): Likewise.
>>   * tree-vect-patterns.c (vect_vect_recog_func_ptrs): Add new
>>   function vect_recog_over_widening_pattern ().
>>   (vect_operation_fits_smaller_type): New function.
>>   (vect_recog_over_widening_pattern, vect_mark_pattern_stmts):
>>   Likewise.
>>   (vect_pattern_recog_1): Move the code that marks pattern
>>   statements to vect_mark_pattern_stmts (), and call it.  Update
>>   documentation.
>>   * tree-vect-stmts.c (vect_supportable_shift): New function.
>>   (vect_analyze_stmt): Handle pattern def statement.
>>   (new_stmt_vec_info): Initialize pattern def statement.

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53693

-- 
H.J.

Re: [PATCH] Preserve loops from tree to RTL loop optimizers

[H.J. Lu]

On Sun, Apr 1, 2012 at 11:51 PM, Ramana Radhakrishnan
 wrote:
> On 1 April 2012 23:55, David Edelsohn  wrote:
>>> If there are no further comments I am inclined to commit this
>>> patch early next week (possibly causing quite some fallout ...).
>>
>> I am glad there was not more fallout.  Unfortunately powerpc-aix was
>> not so lucky:
>>
>> /farm/dje/src/src/libstdc++-v3/src/c++98/streambuf.cc: In function
>> 'std::streamsize
>> std::__copy_streambufs_eof(std::basic_streambuf<_CharT, _Traits>*,
>> std::basic_streambuf<_CharT, _Traits>*, bool&) [with _CharT = wchar_t;
>> _Traits = std::char_traits; std::streamsize = long int]':
>> /farm/dje/src/src/libstdc++-v3/src/c++98/streambuf.cc:113:5: internal
>> compiler error: in get_loop_body, at cfgloop.c:831
>
>
> This looks similar to  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800
>

This also caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695


-- 
H.J.

Re: *ping* [Patch, Fortran] PR53642/45170c24 Deferred-length string fixes

[Thomas Koenig]

Hi Tobias,


Build and regtested on x86-64-linux.
OK for the trunk?

Tobias


OK.

Thanks a lot for the patch!

Thomas

[PATCH] C++11, grammar fix for late-specified return types and virt-specifiers

[Ville Voutilainen]

2012-06-16 Ville Voutilainen 
  Parse virt-specifiers after late-specified return types.
  * parser.c (cp_parser_direct_declarator): Move virt-specifier parsing 
after late-specified return type parsing
  * override4.C: new

Git is doing weird things with my test, its diff shows
a stale file version. Attached here inline:
--snip--
// { dg-do compile }
// { dg-options "--std=c++11" }


struct B
{
virtual auto f() -> void final;
virtual auto g() -> void;
};

struct B2
{
virtual auto f() -> void final {}
};

struct B3
{
virtual auto f() -> final void; // { dg-error "expected type-specifier 
before 'final'||expected ';'||declaration doesn't declare anything" } 
};

struct B4
{
virtual auto f() -> final void {} // { dg-error "expected 
type-specifier before 'final'||expected ';'||declaration doesn't declare 
anything" } 
};

struct D : B
{
virtual auto g() -> void override;
};

struct D2 : B
{
virtual auto g() -> void override {}
};

struct D3 : B
{
virtual auto g() -> override void; // { dg-error "expected 
type-specifier before 'override'||expected ';'||declaration doesn't declare 
anything" }
};

struct D4 : B
{
virtual auto g() -> override void {} // { dg-error "expected 
type-specifier before 'override'||expected ';'||declaration doesn't declare 
anything" }
};

int main()
{
}
--snap--

And the patch:

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 1691f81..6bc6877 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -16102,12 +16102,13 @@ cp_parser_direct_declarator (cp_parser* parser,
  /* And the exception-specification.  */
  exception_specification
= cp_parser_exception_specification_opt (parser);
- /* Parse the virt-specifier-seq.  */
- virt_specifiers = cp_parser_virt_specifier_seq_opt (parser);
 
  late_return = (cp_parser_late_return_type_opt
 (parser, member_p ? cv_quals : -1));
 
+ /* Parse the virt-specifier-seq.  */
+ virt_specifiers = cp_parser_virt_specifier_seq_opt (parser);
+
  /* Create the function-declarator.  */
  declarator = make_call_declarator (declarator,
 params,

Re: [Patch 4.6] In system.h, wrap include of C++ header in 'extern C++'

[Gabriel Dos Reis]

On Sat, Jun 16, 2012 at 3:54 AM, Duncan Sands  wrote:
> Hi,
>
>
>>> If ENABLE_BUILD_WITH_CXX is defined, then GCC itself is built with C++,
>>> and we want a C++ signature for functions.  If it is not defined, then
>>> GCC itself is not built with C++, and we want (and must have) a C
>>> signature.
>>>
>>> I suppose we would decide that fancy_abort always uses a C signature,
>>> but that seems odd.
>>>
>>> Ian
>>
>>
>> I guess the issue is when people care only about C plugins, yet
>> fancy_abort
>> get implicitly exported with a C++ linkage.
>>
>> I suspect this goes back to the eternal question: what do we consider as
>> part of the public GCC public API (no, Basile, I am not suggesting to have
>> the same discussion again.)
>
>
> if the following are to hold
>
> (1) fancy_abort is declared in system.h
> (2) system.h should not be wrapped in extern "C" when included from a
> plugin,
> (3) it should be valid to include it from plugins compiled as C or as C++,
> (4) fancy_abort should use the same linkage as GCC, i.e. C when GCC built as
> C,
> C++ when built as C++ (aka ENABLE_BUILD_WITH_CXX).
>
> then something like the following seems inevitable:
>
> #ifdef ENABLE_BUILD_WITH_CXX
> #ifdef __cplusplus
> extern void fancy_abort(const char *, int, const char *) ATTRIBUTE_NORETURN;
> #else
> extern void _Z11fancy_abortPKciS0_(const char *, int, const char *)
> ATTRIBUTE_NORETURN;
> #endif
> #else
> #ifdef __cplusplus
> extern "C" void fancy_abort(const char *, int, const char *)
> ATTRIBUTE_NORETURN;
> #else
> extern void fancy_abort(const char *, int, const char *) ATTRIBUTE_NORETURN;
> #endif
> #endif
>
> That's pretty nasty.  But to avoid the nastiness one of (1) - (4) needs to
> be
> dropped.  Which one?
>
> Ciao, Duncan.

It is not just nasty; it is fragile.
I think we should just give fancy_abort a C language specification.

Re: [PR49888, VTA] don't keep VALUEs bound to modified MEMs

[H.J. Lu]

On Fri, Jun 15, 2012 at 3:21 PM, Alexandre Oliva  wrote:
> On Jun 14, 2012, "H.J. Lu"  wrote:
>
>> On Tue, Jun 12, 2012 at 1:42 PM, Richard Henderson  wrote:
>>> On 2012-06-05 12:33, Alexandre Oliva wrote:
 for  gcc/ChangeLog
 from  Alexandre Oliva  

       PR debug/49888
       * var-tracking.c: Include alias.h.
       (overlapping_mems): New struct.
       (drop_overlapping_mem_locs): New.
       (clobber_overlapping_mems): New.
       (var_mem_delete_and_set, var_mem_delete): Call it.
       (val_bind): Likewise, but only if modified.
       (compute_bb_dataflow, emit_notes_in_bb): Call it on MEMs.
       * Makefile.in (var-tracking.o): Depend in $(ALIAS_H).

 for  gcc/testsuite/ChangeLog
 from  Alexandre Oliva  

       PR debug/49888
       * gcc.dg/guality/pr49888.c: New.
>>>
>>> Ok.
>
>> It caused:
>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671
>
> I see a few of these failures myself.  They're in my test results.  I
> guess I was so caught up in assessing the debug info quality changes
> with this patch that I completely failed to look at the test results,
> because they've been around for a while, and I have a few pristine-build
> baselines in between.  Apologies for this mistake.
>
> Anyway...  The problem is not too hard to understand, but it may be
> somewhat hard to fix.  Basically, pushing registers to save them on the
> stack implies writes that are currently thought to conflict with the
> MEMs holding incoming arguments, and apparently there isn't enough
> information in the cselib static table for us to realize the write
> doesn't alias with any of the incoming arguments.
>
> Using the dynamic tables during alias testing is one possibility I'm
> looking into, but this won't be trivial and it could get expensive;
> another, that has just occurred to me while composing this message, is
> to use the cselib static table itself, for it *should* have enough info
> for us to realize that argp and sp offset are related and, given proper
> offsets, non-overlapping.
>
> Now, neither approach is going to be an immediate fix.  Should I revert
> the patch, or can we live with some debug info completeness regressions
> for a bit?  I wouldn't mind reverting it, but I won't unless the broken
> patch is actually causing trouble to any of us.
>

If I understand it correctly, the new approach fails to handle push
properly.  If it is true, I think the patch should be reverted.

Thanks.


-- 
H.J.