[c++] typeinfo for target types

2014-04-13 Thread Marc Glisse

Hello,

this patch generates typeinfo for target types. On x86_64, it adds these 6 
lines to nm -C libsupc++.a. A follow-up patch will be needed to export and 
version those in the shared library.


+ V typeinfo for __float128
+ V typeinfo for __float128 const*
+ V typeinfo for __float128*
+ V typeinfo name for __float128
+ V typeinfo name for __float128 const*
+ V typeinfo name for __float128*

Bootstrap and testsuite on x86_64-linux-gnu (a bit of noise in 
tsan/tls_race.c).


2014-04-13  Marc Glisse  marc.gli...@inria.fr

PR libstdc++/43622
gcc/c-family/
* c-common.c (registered_builtin_types): Make non-static.
* c-common.h (registered_builtin_types): Declare.
gcc/cp/
* rtti.c (emit_support_tinfo_1): New function, extracted from
emit_support_tinfos.
(emit_support_tinfos): Call it and iterate on registered_builtin_types.

--
Marc GlisseIndex: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 209345)
+++ gcc/c-family/c-common.c (working copy)
@@ -3462,21 +3462,21 @@ c_common_fixed_point_type_for_size (unsi
 fixed-point types that have too many integral and 
 fractional bits together);
   return 0;
 }
 
   return c_common_type_for_mode (mode, satp);
 }
 
 /* Used for communication between c_common_type_for_mode and
c_register_builtin_type.  */
-static GTY(()) tree registered_builtin_types;
+tree registered_builtin_types;
 
 /* Return a data type that has machine mode MODE.
If the mode is an integer,
then UNSIGNEDP selects between signed and unsigned types.
If the mode is a fixed-point mode,
then UNSIGNEDP selects between saturating and nonsaturating types.  */
 
 tree
 c_common_type_for_mode (enum machine_mode mode, int unsignedp)
 {
Index: gcc/c-family/c-common.h
===
--- gcc/c-family/c-common.h (revision 209345)
+++ gcc/c-family/c-common.h (working copy)
@@ -1006,20 +1006,24 @@ extern void do_warn_double_promotion (tr
 extern void set_underlying_type (tree);
 extern void record_locally_defined_typedef (tree);
 extern void maybe_record_typedef_use (tree);
 extern void maybe_warn_unused_local_typedefs (void);
 extern vectree, va_gc *make_tree_vector (void);
 extern void release_tree_vector (vectree, va_gc *);
 extern vectree, va_gc *make_tree_vector_single (tree);
 extern vectree, va_gc *make_tree_vector_from_list (tree);
 extern vectree, va_gc *make_tree_vector_copy (const vectree, va_gc *);
 
+/* Used for communication between c_common_type_for_mode and
+   c_register_builtin_type.  */
+extern GTY(()) tree registered_builtin_types;
+
 /* In c-gimplify.c  */
 extern void c_genericize (tree);
 extern int c_gimplify_expr (tree *, gimple_seq *, gimple_seq *);
 extern tree c_build_bind_expr (location_t, tree, tree);
 
 /* In c-pch.c  */
 extern void pch_init (void);
 extern void pch_cpp_save_state (void);
 extern int c_common_valid_pch (cpp_reader *pfile, const char *name, int fd);
 extern void c_common_read_pch (cpp_reader *pfile, const char *name, int fd,
Index: gcc/cp/rtti.c
===
--- gcc/cp/rtti.c   (revision 209345)
+++ gcc/cp/rtti.c   (working copy)
@@ -1458,20 +1458,58 @@ create_tinfo_types (void)
FIELD_DECL, NULL_TREE, integer_type_node),
build_decl (BUILTINS_LOCATION,
FIELD_DECL, NULL_TREE, type_info_ptr_type),
build_decl (BUILTINS_LOCATION,
FIELD_DECL, NULL_TREE, type_info_ptr_type),
NULL);
 
   pop_abi_namespace ();
 }
 
+/* Helper for emit_support_tinfos. Emits the type_info descriptor of
+   a single type.  */
+
+void
+emit_support_tinfo_1 (tree bltn)
+{
+  tree types[3];
+
+  if (bltn == NULL_TREE)
+return;
+  types[0] = bltn;
+  types[1] = build_pointer_type (bltn);
+  types[2] = build_pointer_type (cp_build_qualified_type (bltn,
+ TYPE_QUAL_CONST));
+
+  for (int i = 0; i  3; ++i)
+{
+  tree tinfo = get_tinfo_decl (types[i]);
+  TREE_USED (tinfo) = 1;
+  mark_needed (tinfo);
+  /* The C++ ABI requires that these objects be COMDAT.  But,
+On systems without weak symbols, initialized COMDAT
+objects are emitted with internal linkage.  (See
+comdat_linkage for details.)  Since we want these objects
+to have external linkage so that copies do not have to be
+emitted in code outside the runtime library, we make them
+non-COMDAT here.  
+
+It might also not be necessary to follow this detail of the
+ABI.  */
+  if (!flag_weak || ! targetm.cxx.library_rtti_comdat ())
+   {
+ gcc_assert (TREE_PUBLIC (tinfo)  !DECL_COMDAT (tinfo));
+ 

Re: [DOC PATCH] Rewrite docs for inline asm

2014-04-13 Thread dw



No, it does seem deleted, I can't find it.  I can only find its
deletion in the patch, not any re-insert or rewrite and I can't
find this information in the web-pages at limegreensocks.  To
wit: where's the corresponding information; the replacement for
the section which started with Sometimes you need to make an
@code{asm} operand be a specific register, but there's no
matching constraint letter for that register and had the two
sysint examples?  Maybe best placed in a separate subsection
cross-referenced from the top Extended-Asm Remarks section or
when first discussing constraints, in the Output Operands
subsection.


You are correct, I should not have removed this information.  After 
re-reading the original text several times to try to puzzle out exactly 
what it was trying to say, I did feel the need to rephrase it however.


Then there's the question of where this text goes.  Like you, I looked 
at the idea of a new section, but it doesn't seem like it really merits 
its own section.  Putting it in the Output section sounds good, but it's 
pretty big for that and kinda off-topic.  And it would really have to be 
repeated in the Inputs section as well. Yuck.


So, how about this:

1) I put the (rephrased) text and examples at the end of Local Reg 
Vars page (starts with Sometimes): 
http://www.LimeGreenSocks.com/gcc/Local-Reg-Vars.html
2) In the constraint paragraph for both Input and Output, I added this: 
If you must use a specific register, but your Machine Constraints do 
not provide sufficient control to select the specific register you want, 
Local Reg Vars may provide a solution (@pxref{Local Reg Vars}).


Acceptable?  To see the changes in patch form, check out 
http://www.LimeGreenSocks.com/gcc/extend06.zip


Anything else?  Or time to re-post the patch to the list?


But, speaking of that, I
can't find anyone mentioning the copyright issue.  Maybe people
didn't want to scare you away...  Someone has said that FSF were
moving towards it sometimes wouldn't be required anymore, but
that comment was made about a year ago and I don't know if
anything has actually changed, so: assuming this is still
required, are copyright assignment papers in place with the FSF
for these changes?  I can't find any dw (or maybe too many) in
the canonical copyright.list just refreshed so I can't tell.


It would be a bummer to just find out about this now, but fortunately 
Jonathan Wakely and Ian Lance Taylor already helped walk me thru all 
this copyright stuff.


I can't see the copyright.list to which you are referring, but the email 
I received from Donald Robertson at FSF on August 7, 2013 stated Your 
assignment/disclaimer process with the FSF is currently complete.


My name is David Wohlferd (it was in the changelog).  If I'm not on the 
official list, please let me know how to proceed.


Thanks again for your time,
dw


[i386] define __SIZEOF_FLOAT128__

2014-04-13 Thread Marc Glisse

Hello,

some people like having a macro to test if a type is available 
(__SIZEOF_INT128__ for instance). This adds macros for __float80 and 
__float128. The types seem to be always available, so I didn't add any 
condition.


If you think this is a bad idea, please close the PR.

Bootstrap+testsuite on x86_64-linux-gnu.

2014-04-13  Marc Glisse  marc.gli...@inria.fr

PR preprocessor/56540
* config/i386/i386-c.c (ix86_target_macros): Define
__SIZEOF_FLOAT80__ and __SIZEOF_FLOAT128__.

--
Marc GlisseIndex: gcc/config/i386/i386-c.c
===
--- gcc/config/i386/i386-c.c(revision 209345)
+++ gcc/config/i386/i386-c.c(working copy)
@@ -511,20 +511,27 @@ ix86_target_macros (void)
 
   if (!TARGET_80387)
 cpp_define (parse_in, _SOFT_FLOAT);
 
   if (TARGET_LONG_DOUBLE_64)
 cpp_define (parse_in, __LONG_DOUBLE_64__);
 
   if (TARGET_LONG_DOUBLE_128)
 cpp_define (parse_in, __LONG_DOUBLE_128__);
 
+  if (TARGET_64BIT)
+cpp_define (parse_in, __SIZEOF_FLOAT80__=16);
+  else
+cpp_define (parse_in, __SIZEOF_FLOAT80__=12);
+
+  cpp_define (parse_in, __SIZEOF_FLOAT128__=16);
+
   cpp_define_formatted (parse_in, __ATOMIC_HLE_ACQUIRE=%d, IX86_HLE_ACQUIRE);
   cpp_define_formatted (parse_in, __ATOMIC_HLE_RELEASE=%d, IX86_HLE_RELEASE);
 
   ix86_target_macros_internal (ix86_isa_flags,
   ix86_arch,
   ix86_tune,
   ix86_fpmath,
   cpp_define);
 }
 


Re: gcc/doc/*texi patch ping

2014-04-13 Thread Gerald Pfeifer
On Thu, 10 Apr 2014, Tobias Burnus wrote:
 I would like to ping the patch:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01673.html
 
 It's a syntax issue: It simply makes no sense to have a @menu item
 which points to @nodes which are at the same or higher level
 than the section in which the @menu is.

Looks fine to me. 

And probably a good idea for the 4.9 branch as well.

Thanks,
Gerald


Re: [PING] [PATCH, DOC] Mention -free enabled by default for -O2 and above on AArch64

2014-04-13 Thread Gerald Pfeifer
On Fri, 11 Apr 2014, Yufeng Zhang wrote:
 Ping~
 
 Originally posted here:
 http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01282.html

Looks okay to me, that I'd prefer it to be approved by a target
maintainer -- AArch64 here.

Gerald


[C PATCH] Quash spurious warnings (PR c/60784)

2014-04-13 Thread Marek Polacek
This PR is about spurious warnings with -Wmissing-field-initializers
that can be seen when using multi-level designated initializers.
The warning should not be output for designated initializers [*],
pop_init_level checks for constructor_designated.  But push_init_level
clears this variable, so we need to set it back if needed.  In other
words, if we have .a.i, then both a and i should be marked as
designated.  For a we set constructor_designated correctly, but then
when processing i we push a and thus for i it's not set properly.

[*] At least right now.  There's a PR about -Wmissing-field-initializers=2
that should warn even for designated initializers.

Regtested/bootstrapped on x86_64-linux, ok for trunk?

2014-04-13  Marek Polacek  pola...@redhat.com

PR c/60784
* c-typeck.c (push_init_level): Set constructor_designated to
p-designated for structures.

* gcc.dg/pr60784.c: New test.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 65aad45..2b6c378 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -7266,6 +7266,9 @@ push_init_level (int implicit, struct obstack * 
braced_init_obstack)
  push_member_name (constructor_fields);
  constructor_depth++;
}
+  /* If upper initializer is designated, then mark this as
+designated too to prevent bogus warnings.  */
+  constructor_designated = p-designated;
 }
   else if (TREE_CODE (constructor_type) == ARRAY_TYPE)
 {
diff --git gcc/testsuite/gcc.dg/pr60784.c gcc/testsuite/gcc.dg/pr60784.c
index e69de29..82b512f 100644
--- gcc/testsuite/gcc.dg/pr60784.c
+++ gcc/testsuite/gcc.dg/pr60784.c
@@ -0,0 +1,25 @@
+/* PR c/60784 */
+/* { dg-do compile } */
+/* { dg-options -Wextra -std=c99 } */
+
+struct A { int i, j; };
+struct B { struct A a; } b1 = { .a.i = 1, .a.j = 1 };
+struct B b2 = { .a.i = 1 };
+
+struct C { struct { int a, b; }; } c1 = { .a = 4, .b = 2 };
+struct C c2 = { .a = 4, .b = 2 };
+
+struct D { struct A a; };
+struct E { struct D d; };
+struct F { struct E e; } f1 = { .e.d.a.i = 8 };
+struct F f2 = { .e.d.a.i = 8, .e.d.a.j = 3 };
+
+struct G {
+  struct {
+struct {
+  struct {
+int a, b, c, d, e, f;
+  };
+};
+  };
+} g = { .b = 2 };

Marek


Re: gcc/doc/*texi patch ping

2014-04-13 Thread Tobias Burnus

Gerald Pfeifer wrote:

Looks fine to me. And probably a good idea for the 4.9 branch as well.


Thanks for the review! However, Jakub has already approved and committed 
it for me, just before he has branched 4.9 :-)


Tobias



[Patch] Add TYPE_NAME_IDENTIFIER

2014-04-13 Thread Paolo Carlini

Hi,

this is a small clean-up discussed some time ago with Jason. The basic 
idea seems pretty straightforward to me. However, at variance with that 
discussion, I'm not proposing replacing the C++ front-end 
TYPE_IDENTIFIER with the new TYPE_NAME_IDENTIFIER because, as far as I 
can see, that front-end really needs DECL_NAME (TYPE_NAME 
unconditionally. Eg, code like (in error.c):


case TEMPLATE_TEMPLATE_PARM:
  /* For parameters inside template signature.  */
  if (TYPE_IDENTIFIER (t))
pp_cxx_tree_identifier (pp, TYPE_IDENTIFIER (t));
  else
pp_cxx_canonical_template_parameter (pp, t);
  break;

assumes that TYPE_IDENTIFIER is indeed an identifier and that would not 
be necessarily the case in C++ when TYPE_NAME_IDENTIFIER boils down to 
TYPE_NAME itself (in practice, fails like eg, abi/mangle12.C, where 
TYPE_NAME is a TEMPLATE_DECL).


Tested x86_64-linux without Ada (I'm asking the help of the maintainers 
about testing those simple bits)


Thanks!
Paolo.

///
2014-04-13  Paolo Carlini  paolo.carl...@oracle.com

* tree.h (TYPE_NAME_IDENTIFIER): Declare.
* tree.c (subrange_type_for_debug_p): Use it.
* godump.c (go_format_type): Likewise.
* dwarf2out.c (is_cxx_auto, modified_type_die,
gen_type_die_with_usage, gen_type_die_with_usage): Likewise.
* dbxout.c (dbxout_type, dbxout_symbol): Likewise.

/objcp
2014-04-13  Paolo Carlini  paolo.carl...@oracle.com

* objcp-decl.h (OBJC_TYPE_NAME, OBJC_SET_TYPE_NAME): Use
TYPE_NAME_IDENTIFIER.

/ada
2014-04-13  Paolo Carlini  paolo.carl...@oracle.com

* gcc-interface/decl.c (gnat_to_gnu_entity, components_to_record,
make_aligning_type, maybe_pad_type, finish_record_type,
rest_of_record_type_compilation): Use TYPE_NAME_IDENTIFIER.
Index: ada/gcc-interface/decl.c
===
--- ada/gcc-interface/decl.c(revision 209339)
+++ ada/gcc-interface/decl.c(working copy)
@@ -2671,11 +2671,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gn
  for (index = ndim - 1; index = 0; index--)
{
  tree gnu_index = TYPE_INDEX_TYPE (gnu_index_types[index]);
- tree gnu_index_name = TYPE_NAME (gnu_index);
+ tree gnu_index_name = TYPE_NAME_IDENTIFIER (gnu_index);
 
- if (TREE_CODE (gnu_index_name) == TYPE_DECL)
-   gnu_index_name = DECL_NAME (gnu_index_name);
-
  /* Make sure to reference the types themselves, and not just
 their names, as the debugger may fall back on them.  */
  gnu_field = create_field_decl (gnu_index_name, gnu_index,
@@ -3652,12 +3649,10 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gn
  if (debug_info_p)
{
  tree gnu_subtype_marker = make_node (RECORD_TYPE);
- tree gnu_unpad_base_name = TYPE_NAME (gnu_unpad_base_type);
+ tree gnu_unpad_base_name
+   = TYPE_NAME_IDENTIFIER (gnu_unpad_base_type);
  tree gnu_size_unit = TYPE_SIZE_UNIT (gnu_type);
 
- if (TREE_CODE (gnu_unpad_base_name) == TYPE_DECL)
-   gnu_unpad_base_name = DECL_NAME (gnu_unpad_base_name);
-
  TYPE_NAME (gnu_subtype_marker)
= create_concat_name (gnat_entity, XVS);
  finish_record_type (gnu_subtype_marker,
@@ -4976,11 +4971,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gn
   false, !gnu_decl, definition, false);
 
   if (TYPE_IS_PADDING_P (gnu_type))
-   {
- gnu_entity_name = TYPE_NAME (gnu_type);
- if (TREE_CODE (gnu_entity_name) == TYPE_DECL)
-   gnu_entity_name = DECL_NAME (gnu_entity_name);
-   }
+   gnu_entity_name = TYPE_NAME_IDENTIFIER (gnu_type);
 
   /* Now set the RM size of the type.  We cannot do it before padding
 because we need to accept arbitrary RM sizes on integral types.  */
@@ -7035,7 +7026,7 @@ components_to_record (tree gnu_record_type, Node_I
 {
   Node_Id gnat_discr = Name (variant_part), variant;
   tree gnu_discr = gnat_to_gnu (gnat_discr);
-  tree gnu_name = TYPE_NAME (gnu_record_type);
+  tree gnu_name = TYPE_NAME_IDENTIFIER (gnu_record_type);
   tree gnu_var_name
= concat_name (get_identifier (Get_Name_String (Chars (gnat_discr))),
   XVN);
@@ -7047,9 +7038,6 @@ components_to_record (tree gnu_record_type, Node_I
   unsigned int variants_align = 0;
   unsigned int i;
 
-  if (TREE_CODE (gnu_name) == TYPE_DECL)
-   gnu_name = DECL_NAME (gnu_name);
-
   gnu_union_name
= concat_name (gnu_name, IDENTIFIER_POINTER (gnu_var_name));
 
Index: ada/gcc-interface/utils.c
===
--- 

[C++ Patch] Mini pt.c tweak

2014-04-13 Thread Paolo Carlini

Hi,

tested x86_64-linux.

Thanks,
Paolo.

/
2014-04-13  Paolo Carlini  paolo.carl...@oracle.com

* pt.c (mark_template_parm): Use template_parm_level_and_index.
Index: pt.c
===
--- pt.c(revision 209339)
+++ pt.c(working copy)
@@ -4028,16 +4028,7 @@ mark_template_parm (tree t, void* data)
   int idx;
   struct template_parm_data* tpd = (struct template_parm_data*) data;
 
-  if (TREE_CODE (t) == TEMPLATE_PARM_INDEX)
-{
-  level = TEMPLATE_PARM_LEVEL (t);
-  idx = TEMPLATE_PARM_IDX (t);
-}
-  else
-{
-  level = TEMPLATE_TYPE_LEVEL (t);
-  idx = TEMPLATE_TYPE_IDX (t);
-}
+  template_parm_level_and_index (t, level, idx);
 
   if (level == tpd-level)
 {


Re: [patch, libgfortran] Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

2014-04-13 Thread Jerry DeLisle
Ping! This is PR52539

On 03/29/2014 09:58 PM, Jerry DeLisle wrote:
 Hi all,
 
 The attached patch fixes namelist read/write and list directed read/write to
 support UTF-8.
 
 I have attached a preliminary test case to use to experiment with this.  I 
 will
 need to set it up for the testsuite still.
 
 Regression tested on x86-64-linux-gnu.
 
 OK for trunk or wait?
 
 Regards,
 
 Jerry
 
 2014-03-29  Jerry DeLisle  jvdeli...@gcc.gnu
 
   PR libfortran/52539
   * io/list_read.c: Add uchar typedef. (push_char4): New function
   to save kind=4 character. (next_char_utf8): New function to read
   a single UTF-8 encoded character value. (read_chracter): Update
   to use the new functions for reading UTF-8 strings.
   (list_formatted_read_scalar): Update to handle list directed
   reads of UTF-8 strings. (nml_read_obj): Likewise update for
   UTF-8 strings in namelists.
   * io/write.c (nml_write_obj): Add kind=4 character support for
   namelist writes.
 


[fortran-caf, patch, committed] Fix bugs, prepare for GET/PULL support

2014-04-13 Thread Tobias Burnus

Hi all,

the attached and committed (Rev. 209348) patch fixes two issues and 
prepares for pulling (getting) data from remote hosts by inserting an 
intrinsic function (inaccessible from the outside) when a coindexed 
expression is used. The code is a bit eager as it also adds it to the 
LHS of an assignment and in an allocate/deallocate statement - hence, I 
remove the intrinsic. I have a draft patch for trans-intrinsic.c, but I 
still need to clean it up.


The two issues, which the patch fixes were:

* When one has a coarray which is a component of a derived type, one 
also needs to include the variable when accessing it, not only the the 
tree decl of the component. And also polymorphic types have to be handled.


* For automatic arrays, the whole initialization got lost, leading to 
zero-sized arrays which shouldn't be zero sized. Let's hope that there 
are not too many similar bugs still lurking in the code.


Tobias
Index: ChangeLog.fortran-caf
===
--- ChangeLog.fortran-caf	(Revision 209347)
+++ ChangeLog.fortran-caf	(Arbeitskopie)
@@ -1,3 +1,15 @@
+2014-04-13  Tobias Burnus  bur...@net-b.de
+
+	* trans-decl.c (gfc_trans_deferred_vars): Fix bug in
+	condition.
+	* trans-expr.c (gfc_get_tree_for_caf_expr): Handle polymorphism
+	and coarray components of derived types.
+	* resolve.c (add_caf_get_intrinsic, remove_caf_get_intrinsic): New.
+	(resolve_variable, resolve_allocate_expr, resolve_code): Use it;
+	currently disabled.
+	(gfc_resolve_expr): Moved expression_rank call into
+	resolve_variable.
+
 2014-04-10  Tobias Burnus  bur...@net-b.de
 
 	* trans-intrinsic.c (caf_get_image_index, conv_caf_send):
Index: trans-decl.c
===
--- trans-decl.c	(Revision 209347)
+++ trans-decl.c	(Arbeitskopie)
@@ -3798,7 +3798,8 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gf
 	NULL_TREE);
 		  continue;
 		}
-	  else if (gfc_option.coarray != GFC_FCOARRAY_LIB)
+	  else if (gfc_option.coarray != GFC_FCOARRAY_LIB
+		   || !sym-attr.codimension)
 		{
 		  gfc_save_backend_locus (loc);
 		  gfc_set_backend_locus (sym-declared_at);
Index: resolve.c
===
--- resolve.c	(Revision 209347)
+++ resolve.c	(Arbeitskopie)
@@ -4728,6 +4728,40 @@ done:
 }
 
 
+static void
+add_caf_get_intrinsic (gfc_expr *e)
+{
+  gfc_expr *wrapper, *tmp_expr;
+  gfc_expr *async = gfc_get_logical_expr (gfc_default_logical_kind, NULL,
+	  false);
+  tmp_expr = XCNEW (gfc_expr);
+  *tmp_expr = *e;
+  wrapper = gfc_build_intrinsic_call (gfc_current_ns, GFC_ISYM_CAF_GET,
+  caf_get, tmp_expr-where, 2,
+  tmp_expr, async);
+  wrapper-ts = e-ts;
+  wrapper-rank = e-rank;
+  if (e-rank)
+wrapper-shape = gfc_copy_shape (e-shape, e-rank);
+  *e = *wrapper;
+  free (wrapper);
+}
+
+
+static void
+remove_caf_get_intrinsic (gfc_expr *e)
+{
+  gcc_assert (e-expr_type == EXPR_FUNCTION  e-value.function.isym
+	   e-value.function.isym-id == GFC_ISYM_CAF_GET);
+  gfc_expr *e2 = e-value.function.actual-expr;
+  e-value.function.actual-expr =NULL;
+  gfc_free_actual_arglist (e-value.function.actual);
+  gfc_free_shape (e-shape, e-rank);
+  *e = *e2;
+  free (e2);
+}
+
+
 /* Resolve a variable expression.  */
 
 static bool
@@ -5007,6 +5041,12 @@ resolve_procedure:
 	}
 }
 
+  if (t)
+expression_rank (e);
+
+  if (0  t  gfc_option.coarray == GFC_FCOARRAY_LIB  gfc_is_coindexed (e))
+add_caf_get_intrinsic(e);
+
   return t;
 }
 
@@ -6090,11 +6130,7 @@ gfc_resolve_expr (gfc_expr *e)
   if (check_host_association (e))
 	t = resolve_function (e);
   else
-	{
-	  t = resolve_variable (e);
-	  if (t)
-	expression_rank (e);
-	}
+	t = resolve_variable (e);
 
   if (e-ts.type == BT_CHARACTER  e-ts.u.cl == NULL  e-ref
 	   e-ref-type != REF_SUBSTRING)
@@ -6673,6 +6709,10 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code
   if (!gfc_resolve_expr (e))
 goto failure;
 
+  if (e-expr_type == EXPR_FUNCTION  e-value.function.isym
+   e-value.function.isym-id == GFC_ISYM_CAF_GET)
+remove_caf_get_intrinsic (e);
+
   /* Make sure the expression is allocatable or a pointer.  If it is
  pointer, the next-to-last reference must be a pointer.  */
 
@@ -9867,6 +9907,11 @@ resolve_code (gfc_code *code, gfc_namespace *ns)
 	  if (!t)
 	break;
 
+	  if (code-expr1-expr_type == EXPR_FUNCTION
+	   code-expr1-value.function.isym
+	   code-expr1-value.function.isym-id == GFC_ISYM_CAF_GET)
+	remove_caf_get_intrinsic (code-expr1);
+
 	  if (!gfc_check_vardef_context (code-expr1, false, false, false, 
 	 _(assignment)))
 	break;
Index: trans-expr.c
===
--- trans-expr.c	(Revision 209347)
+++ trans-expr.c	(Arbeitskopie)
@@ -1386,25 +1386,42 @@ gfc_get_expr_charlen (gfc_expr *e)
 tree
 gfc_get_tree_for_caf_expr (gfc_expr *expr)
 {
-   

Re: Optimize n?rotate(x,n):x

2014-04-13 Thread Marc Glisse

On Mon, 3 Mar 2014, Richard Biener wrote:


On Sat, Mar 1, 2014 at 3:33 PM, Marc Glisse marc.gli...@inria.fr wrote:

Hello,

again, a stage 1 patch that I will ping then, but early comments are
welcome.

PR 59100 was asking to transform n?rotate(x,n):x to rotate(x,n) (because it
can be hard to write a strictly valid rotate in plain C). The operation is
really:
(x != neutral) ? x op y : y
where neutral is such that (neutral op y) is always y, so that's what I
implemented (and absorbing elements while I was at it).

For some operations on some platforms, the transformation may not be such a
good idea, in particular if division is very slow and b is 1 most of the
time, then computing a/b may be slower than (b!=1)?a/b:a. The easiest might
be to comment out those operations in the switch for now. I think divisions
are the only ones slow enough to deserve this, though there certainly are
CPUs where multiplication is not so fast, and even for rotate it may not
always be a win if the processor doesn't have a rotate instruction and the
shift amount is almost always 0.


You only handle integer operations, so checking for INTEGER_TYPE_P
early on would make sense.


Ah, I wasn't planning on restricting this to integers but yes, indeed, 
since it ended up that way...



Note that some archs may dispatch to libgcc for integer operations
so it may make sense to check whether that is the case (you can
query optabs to check that) - if the comparison also dispatches to
libgcc then of course the transform would be a win again.


Ok. I am not sure about using cbranch_optab, other ideas for the 
comparison?



Even on x86 TImode division uses libgcc.


This reminds me of PR 58897 (unrelated).

Note also that value-profiling may have created this special case in the 
first place! (gimple_divmod_fixed_value_transform)


Test coverage must be limited if I didn't break the testsuite :-(

value-profiling seems to set edge probabilities when it does the 
transformation, so I am checking only that.



Otherwise I think this is a good transform.  Did you check if it triggers
during GCC bootstrap?


It does, a few times. Java has the obvious:

int padLength = blockSize;
if (length % blockSize != 0)
  padLength = blockSize - length % blockSize;

sched-deps.c has (I didn't check if it was actually this piece of code 
that triggered or another one in the same file):


  if ((ds1  t)  !(ds2  t))
ds |= ds1  t;
  else if (!(ds1  t)  (ds2  t))
ds |= ds2  t;

and we end up seeing (phiopt3) if(a!=0)ds|=a.

And mostly bitmap.h where we see quite a bit of:

  if (_867 != 0)
goto bb 55;
  else
goto bb 56;

  bb 55:
  start_bit_869 = _867 * 128;

  bb 56:
  # start_bit_870 = PHI 0(54), start_bit_869(55)


Bootstrap+testsuite on x86_64-linux-gnu (modulo a minor reformatting, I'm 
retesting anyway).


2014-04-14  Marc Glisse  marc.gli...@inria.fr

PR tree-optimization/59100
gcc/
* tree-ssa-phiopt.c (neutral_element_p, absorbing_element_p,
is_cheap_stmt): New functions.
(value_replacement): Handle conditional binary operations with a
neutral or absorbing element.
gcc/testsuite/
* gcc.dg/tree-ssa/phi-opt-12.c: New file.
* gcc.dg/tree-ssa/phi-opt-13.c: Likewise.

--
Marc GlisseIndex: gcc/testsuite/gcc.dg/tree-ssa/phi-opt-12.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/phi-opt-12.c  (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/phi-opt-12.c  (working copy)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options -O -fdump-tree-phiopt1 } */
+
+int f(int a, int b, int c) {
+  if (c  5) return c;
+  if (a == 0) return b;
+  return a + b;
+}
+
+unsigned rot(unsigned x, int n) {
+  const int bits = __CHAR_BIT__ * __SIZEOF_INT__;
+  return (n == 0) ? x : ((x  n) | (x  (bits - n)));
+}
+
+unsigned m(unsigned a, unsigned b) {
+  if (a == 0)
+return 0;
+  else
+return a  b;
+}
+
+/* { dg-final { scan-tree-dump-times goto 2 phiopt1 } } */
+/* { dg-final { cleanup-tree-dump phiopt1 } } */

Property changes on: gcc/testsuite/gcc.dg/tree-ssa/phi-opt-12.c
___
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index: gcc/testsuite/gcc.dg/tree-ssa/phi-opt-13.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/phi-opt-13.c  (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/phi-opt-13.c  (working copy)
@@ -0,0 +1,19 @@
+/* { dg-do compile { target x86_64-*-* } } */
+/* { dg-options -O2 -fdump-tree-optimized } */
+
+int f(int a, int b) {
+  if (__builtin_expect(a == 0, 1)) return b;
+  return a + b;
+}
+
+// optab_handler can handle if(b==1) but not a/b
+// so we consider a/b too expensive.
+unsigned __int128 g(unsigned __int128 a, unsigned __int128 b) {
+  if (b == 1)
+

Re: [DOC PATCH] Rewrite docs for inline asm

2014-04-13 Thread Hans-Peter Nilsson
On Sun, 13 Apr 2014, dw wrote:
 So, how about this:

 1) I put the (rephrased) text and examples at the end of Local Reg Vars page
 (starts with Sometimes):
 http://www.LimeGreenSocks.com/gcc/Local-Reg-Vars.html
 2) In the constraint paragraph for both Input and Output, I added this: If
 you must use a specific register, but your Machine Constraints do not provide
 sufficient control to select the specific register you want, Local Reg Vars
 may provide a solution (@pxref{Local Reg Vars}).

 Acceptable?

Yes, nice, thank you!

 Anything else?  Or time to re-post the patch to the list?

Better re-post the updated patch.

  But, speaking of that, I
  can't find anyone mentioning the copyright issue.

 It would be a bummer to just find out about this now, but fortunately Jonathan
 Wakely and Ian Lance Taylor already helped walk me thru all this copyright
 stuff.

Congratulations for having been through that!

 I can't see the copyright.list to which you are referring, but the email I
 received from Donald Robertson at FSF on August 7, 2013 stated Your
 assignment/disclaimer process with the FSF is currently complete.

 My name is David Wohlferd (it was in the changelog).  If I'm not on the
 official list, please let me know how to proceed.

No worries, you are there.

brgds, H-P


Re: RFA: Testsuite PATCH to add support for dlopen tests

2014-04-13 Thread Hans-Peter Nilsson
On Fri, 11 Apr 2014, Jakub Jelinek wrote:

 On Thu, Apr 10, 2014 at 02:18:26PM +0100, Ramana Radhakrishnan wrote:
  I see failures from last night on aarch64-none-elf and arm-none-eabi
  (both bare-metal) configurations even after moving up to dejagnu
  1.5.1. If this can't be fixed easily should we consider reverting this
  patch in the interest of getting sane test results on bare-metal
  targets before the release ?
 
  Should we also update the prereqs page to say dejagnu 1.5.1 ?
  (http://gcc.gnu.org/install/prerequisites.html)

 Jason has disabled the problematic test temporarily last night, can you
 please verify bare-metal cross-testing now works?

I just noticed that I see this error, so the problem still
exists at r209347 (seen for cris-elf).

(The FAILs are old and provided only for context; the ERRORs are
fatal.)

...
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/dg.exp ...
FAIL: g++.dg/abi/vbase10.C -std=gnu++98  (test for warnings, line 13)
FAIL: g++.dg/abi/vbase10.C -std=gnu++11  (test for warnings, line 13)
FAIL: g++.dg/abi/vbase10.C -std=gnu++1y  (test for warnings, line 13)
FAIL: g++.dg/cpp0x/gen-attrs-17.2.C -std=c++11  (test for errors, line 19)
FAIL: g++.dg/cpp0x/gen-attrs-17.2.C -std=c++1y  (test for errors, line 19)
FAIL: g++.dg/cpp0x/gen-attrs-21.C -std=c++11 (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-21.C -std=c++1y (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-39.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-39.C -std=gnu++1y (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-51.C -std=c++11 (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-51.C -std=c++1y (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-52.C -std=c++11 (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-52.C -std=c++1y (test for excess errors)
FAIL: g++.dg/dso/dlclose1-dso.cc (test for excess errors)
ERROR: tcl error sourcing /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/dg.exp.
ERROR: can't rename dg-save-unknown: command doesn't exist
while executing
rename dg-save-unknown unknown
(procedure saved-dg-test line 96)
invoked from within
saved-dg-test /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/dso/dlclose1.C 
-std=c++98 { -pedantic-errors -Wno-long-long}
(eval body line 1)
invoked from within
eval saved-dg-test $args 
(procedure dg-test line 11)
invoked from within
dg-test $test $flags ${default-extra-flags}
(procedure g++-dg-runtest line 27)
invoked from within
g++-dg-runtest $tests $DEFAULT_CXXFLAGS
(file /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/dg.exp line 60)
invoked from within
source /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/dg.exp
(uplevel body line 1)
invoked from within
uplevel #0 source /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/dg.exp
invoked from within
catch uplevel #0 source $test_file_name
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/gcov/gcov.exp ...
ERROR: tcl error sourcing 
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/gcov/gcov.exp.
ERROR: can't rename unknown: command doesn't exist
while executing
rename unknown dg-save-unknown
(procedure saved-dg-test line 69)
invoked from within
saved-dg-test /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/gcov/gcov-1.C 
-std=gnu++98 {}
(eval body line 1)
invoked from within
eval saved-dg-test $args 
(procedure dg-test line 11)
invoked from within
dg-test $test $flags ${default-extra-flags}
(procedure g++-dg-runtest line 27)
invoked from within
g++-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.C]] 
(file /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/gcov/gcov.exp line 42)
invoked from within
source /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/gcov/gcov.exp
(uplevel body line 1)
invoked from within
uplevel #0 source /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/gcov/gcov.exp
invoked from within
catch uplevel #0 source $test_file_name
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/gomp/gomp.exp ...

So, I've lost track of regression state since this error was
introduced.  (I had a grep supposed to watch for errors like
this to treat it as a build error, but unfortunately the pattern
was too narrow.)

Can this please be reverted and a patch circulated for testing
instead?

brgds, H-P


Re: [PATCH v7] PR middle-end/60281

2014-04-13 Thread lin zuojian
Hi,
GCC changes(http://gcc.gnu.org/gcc-4.9/changes.html) says:

AddressSanitizer, a fast memory error detector, is now available on
ARM.

But I test it,and find PR60281 is still there!That means the wrong
shadow bytes will still populate using stm instructions.

So,I don't think asan is available on ARM.
Anyway I have signed the FSF copyright form.I hope my patch will be
apply on newer GCC.
--
Regards
lin zuojian


Re: [PATCH, PR60189, Cilk+] Fix for ICE with incorrect Cilk_sync usage

2014-04-13 Thread Jason Merrill

On 04/11/2014 03:08 PM, Zamyatin, Igor wrote:

I remembered - I haven't used cp_parser_require since it calls 
cp_lexer_consume_token which is not needed at this point. It is already called 
a bit earlier.


So the call to cp_parser_require can replace that call as well.

Jason




Re: [C++ Patch] Mini pt.c tweak

2014-04-13 Thread Jason Merrill

OK.

Jason


Re: [c++] typeinfo for target types

2014-04-13 Thread Jason Merrill

On 04/13/2014 04:41 AM, Marc Glisse wrote:

this patch generates typeinfo for target types. On x86_64, it adds these
6 lines to nm -C libsupc++.a. A follow-up patch will be needed to export
and version those in the shared library.


This looks fine, but shouldn't be checked in without that other patch.

Jason




Re: RFA: Testsuite PATCH to add support for dlopen tests

2014-04-13 Thread Jason Merrill

On 04/13/2014 09:24 PM, Hans-Peter Nilsson wrote:

Can this please be reverted and a patch circulated for testing
instead?


Done, sorry.

Jason



Re: [Patch] Add TYPE_NAME_IDENTIFIER

2014-04-13 Thread Jason Merrill

On 04/13/2014 12:20 PM, Paolo Carlini wrote:

this is a small clean-up discussed some time ago with Jason. The basic
idea seems pretty straightforward to me. However, at variance with that
discussion, I'm not proposing replacing the C++ front-end
TYPE_IDENTIFIER with the new TYPE_NAME_IDENTIFIER because, as far as I
can see, that front-end really needs DECL_NAME (TYPE_NAME
unconditionally. Eg, code like (in error.c):

 case TEMPLATE_TEMPLATE_PARM:
   /* For parameters inside template signature.  */
   if (TYPE_IDENTIFIER (t))
 pp_cxx_tree_identifier (pp, TYPE_IDENTIFIER (t));
   else
 pp_cxx_canonical_template_parameter (pp, t);
   break;

assumes that TYPE_IDENTIFIER is indeed an identifier and that would not
be necessarily the case in C++ when TYPE_NAME_IDENTIFIER boils down to
TYPE_NAME itself (in practice, fails like eg, abi/mangle12.C, where
TYPE_NAME is a TEMPLATE_DECL).


You could avoid that issue if TYPE_NAME_IDENTIFIER checked for 
IDENTIFIER_NODE rather than TYPE_DECL.


Jason