Re: wide-int branch now up for public comment and review

[Richard Sandiford]

Thanks for doing this.  I haven't had chance to look at the branch yet
(hope to soon), but the results on mips64-linux-gnu look pretty good:

  http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg02033.html

The only failures that stand out as being possibly wide-int-related are:

  FAIL: gcc.dg/fixed-point/int-warning.c  (test for warnings, line ...)

which isn't something that x86_64-linux-gnu or powerpc64-linux-gnu
would test AFAIK.  Haven't had chance to look into why it's failing yet,
but FWIW it's a compile-only test so should be reproducable with a cc1 cross.

I'll run a test with the corresponding trunk version too.

Thanks,
Richard

Re: [PATCH] Enable non-complex math builtins from C99 for Bionic

[Andreas Krebbel]

On Wed, Aug 21, 2013 at 11:21:32PM +0400, Alexander Ivchenko wrote:
> I'm sorry for that. The following patch cured my build of those
> targets; it is also preserving the initial presence of c99. There were
> plenty of targets that were changed by my patch, I hope this time I
> didn't miss anything.

S/390 bootstrap still fails. The reason is that when we set
tm_file/tm_p_file in config.gcc we do not append to the existing
content so your adjustments done before are ignored and gcc complains
about unknown linux_android_libc_has_function.

However, since with s390 Linux and TPF we only target GNU Linux
systems with Glibc we can default to gnu_libc_has_functions anyway:

Index: gcc/config/s390/linux.h
===
*** gcc/config/s390/linux.h.orig2013-01-14 07:48:06.0 +
--- gcc/config/s390/linux.h 2013-08-22 07:57:46.006014197 +
*** along with GCC; see the file COPYING3.
*** 87,90 
--- 87,93 
  /* Define if long doubles should be mangled as 'g'.  */
  #define TARGET_ALTERNATE_LONG_DOUBLE_MANGLING
  
+ #undef TARGET_LIBC_HAS_FUNCTION
+ #define TARGET_LIBC_HAS_FUNCTION gnu_libc_has_function
+ 
  #endif
Index: gcc/config/s390/tpf.h
===
*** gcc/config/s390/tpf.h.orig  2013-08-22 07:01:48.0 +
--- gcc/config/s390/tpf.h   2013-08-22 07:57:27.706013534 +
*** along with GCC; see the file COPYING3.
*** 111,118 
  /* IBM copies these libraries over with these names.  */
  #define MATH_LIBRARY "CLBM"
  #define LIBSTDCXX "CPP2"
- #endif /* ! _TPF_H */
  
- /* We redefine this hook so the version from elfos.h header won't be used.  */
  #undef TARGET_LIBC_HAS_FUNCTION
! #define TARGET_LIBC_HAS_FUNCTION default_libc_has_function
--- 111,118 
  /* IBM copies these libraries over with these names.  */
  #define MATH_LIBRARY "CLBM"
  #define LIBSTDCXX "CPP2"
  
  #undef TARGET_LIBC_HAS_FUNCTION
! #define TARGET_LIBC_HAS_FUNCTION gnu_libc_has_function
! 
! #endif /* ! _TPF_H */

Re: [Patch] Replace spaces with tabs in regex files

[Paolo Carlini]

On 08/22/2013 05:55 AM, Tim Shen wrote:

I simply replace 8 spaces in indentation with a tab.

Bootstrap passed.

Ok, thanks!

Paolo.

Re: [Patch] Replace spaces with tabs in regex files

[Tim Shen]

On Thu, Aug 22, 2013 at 4:56 PM, Paolo Carlini  wrote:
> Ok, thanks!

Committed.


-- 
Tim Shen

Re: [PATCH i386 2/8] [AVX512] Add mask registers.

[Kirill Yukhin]

Hello Richard,

On 19 Aug 14:17, Richard Henderson wrote:
> On 08/14/2013 12:23 AM, Kirill Yukhin wrote:
> > +  ;; For AVX512F mask support
> > +  UNSPEC_KIOR
> > +  UNSPEC_KXOR
> > +  UNSPEC_KAND
> > +  UNSPEC_KANDN
> 
> I thought we determined that you didn't need these,
> that "*Yk" as a constraint was sufficient.

As far as I understood, we're talking about incorporating
of mask logic instructions into existing patterns + making 
mask constraints disparage.

E.g. for OR we have:
  (define_insn "*_1"
[(set (match_operand:SWI248 0 "nonimmediate_operand" "=r,rm")
  (any_or:SWI248
   (match_operand:SWI248 1 "nonimmediate_operand" "%0,0")
   (match_operand:SWI248 2 "" ",r")))
 (clobber (reg:CC FLAGS_REG))]
"ix86_binary_operator_ok (, mode, operands)"
"{}\t{%2, %0|%0, %2}"

Despite of generic OR, mask version of OR do not clobber FLAGS_REG.
Of course, we may conservatively think that it is, but I believe
this is not good idea.
Making single constraint in new pattern disparage have no sense
as far as I understad, since this is relative notion.
So, what should I do?

--
Thanks, K

Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic

[Janus Weil]

Hi Mikael,

thanks for the review!

>> +  else if (selector->ts.u.derived)
>
> Hum, accessing ts.u.derived is correct only if selector->ts.type is
> BT_DERIVED or BT_CLASS, isn't it?

yes.


> Thus the condition should probably be
> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled
> before?  OK with that change (if it works).

Good point. And yes, it works.

However, on second thought, I wonder why we need to treat the case
"selector->ts.type == BT_DERIVED" at all, since the selector in a
SELECT TYPE statement is required to be polymorphic (which is being
checked later in resolve_select_type). I.e. we weill get an error on
the BT_DERIVED case anyway, so I don't see why we need to build a
class container at all here (the only reason I could imagine would be
something like error recovery).

The attached new version is what I'm regtesting right now (with the
whole BT_DERIVED branch removed, since it should not be needed). Ok if
it succeeds?

Cheers,
Janus


pr58185_v3.diff
Description: Binary data

[C++ patch] Move FINAL flag to middle-end trees.

[Jan Hubicka]

Hi,
this patch moves CLASSTYPE_FINAL and DECL_FINAL_P to middle end trees,
so I can use them in my type inheritance analysis.
Incrementally I would like to introduce DECL_CPP_CONSTURCTOR_P/DESTRUCTOR,
too, since we need to know about their C++ specific semantics.  However
I failed to follow the same patch, since these predicates are often called
on TEMPLATE_DECL.  I wonder if those can ever be ctors/dtors?

Bootstrapped/regtested x86_64-linux, OK?

* cp-tree.h (CLASSTYPE_FINAL): Define using TYPE_FINAL_P.
(DECL_FINAL_P): Remove.
* pt.c (instantiate_class_template_1): Guard that CLASSTYPE_FINAL
is called on CLASS_TYPE_P.
* tree.h (TYPE_FINAL_P, DECL_FINAL_P): New macros.
(tree_decl_with_vis): Add FINAL field.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 201910)
+++ cp/cp-tree.h(working copy)
@@ -1535,7 +1535,7 @@ struct GTY((variable_size)) lang_type {
 
 /* Nonzero means that NODE (a class type) is final */
 #define CLASSTYPE_FINAL(NODE) \
-  (LANG_TYPE_CLASS_CHECK (NODE)->is_final)
+  TYPE_FINAL_P (NODE)
 
 
 /* Nonzero means that this _CLASSTYPE node overloads operator=(X&).  */
@@ -2400,10 +2400,6 @@ struct GTY((variable_size)) lang_decl {
an override virt-specifier */
 #define DECL_OVERRIDE_P(NODE) (TREE_LANG_FLAG_0 (NODE))
 
-/* True (in a FUNCTION_DECL) if NODE is a function declared with
-   a final virt-specifier */
-#define DECL_FINAL_P(NODE) (TREE_LANG_FLAG_1 (NODE))
-
 /* The thunks associated with NODE, a FUNCTION_DECL.  */
 #define DECL_THUNKS(NODE) \
   (DECL_VIRTUAL_P (NODE) ? LANG_DECL_FN_CHECK (NODE)->context : NULL_TREE)
Index: cp/pt.c
===
--- cp/pt.c (revision 201910)
+++ cp/pt.c (working copy)
@@ -8730,7 +8730,8 @@ instantiate_class_template_1 (tree type)
   /* Adjust visibility for template arguments.  */
   determine_visibility (TYPE_MAIN_DECL (type));
 }
-  CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern);
+  if (CLASS_TYPE_P (type))
+CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern);
 
   pbinfo = TYPE_BINFO (pattern);
 
Index: tree.h
===
--- tree.h  (revision 201910)
+++ tree.h  (working copy)
@@ -715,6 +715,9 @@ struct GTY(()) tree_base {
 
DECL_NONLOCAL_FRAME in
   VAR_DECL
+
+   TYPE_FINAL_P in
+  RECORD_TYPE, UNION_TYPE and QUAL_UNION_TYPE
 */
 
 struct GTY(()) tree_typed {
@@ -2314,6 +2317,10 @@ enum cv_qualifier
 #define TYPE_CONTAINS_PLACEHOLDER_INTERNAL(NODE) \
   (TYPE_CHECK (NODE)->type_common.contains_placeholder_bits)
 
+/* Nonzero if RECORD_TYPE represents a final derivation of class.  */
+#define TYPE_FINAL_P(NODE) \
+  (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)
+
 /* The debug output functions use the symtab union field to store
information specific to the debugging format.  The different debug
output hooks store different types in the union field.  These three
@@ -3224,7 +3231,9 @@ struct GTY(()) tree_decl_with_vis {
  unsigned init_priority_p : 1;
  /* Used by C++ only.  Might become a generic decl flag.  */
  unsigned shadowed_for_var_p : 1;
- /* 14 unused bits. */
+ /* Belong to FUNCTION_DECL exclusively.  */
+ unsigned final : 1;
+ /* 13 unused bits. */
 };
 
 extern tree decl_debug_expr_lookup (tree);
@@ -3474,6 +3483,11 @@ extern vec **decl_debug_arg
 #define DECL_FUNCTION_VERSIONED(NODE)\
(FUNCTION_DECL_CHECK (NODE)->function_decl.versioned_function)
 
+/* In FUNCTION_DECL that represent an virtual method this is set when
+   the method is final.  */
+#define DECL_FINAL_P(NODE)\
+   (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.final)
+
 /* FUNCTION_DECL inherits from DECL_NON_COMMON because of the use of the
arguments/result/saved_tree fields by front ends.   It was either inherit
FUNCTION_DECL from non_common, or inherit non_common from FUNCTION_DECL,

Clean up pretty printers [10/n]

[Gabriel Dos Reis]

This patch consolidates initialization routines of various pretty
printers -- at the moment, we have unfortunately very few (basic, C, C++).
It adds a default constructor to pretty_printer (which in turn made
obvious we needed one for output_buffer), c_pretty_printer, and
cxx_pretty_printer.   The rest of the patch is just propagating these
things by removing direct calls to pp_construct,
pp_c_pretty_printer_init, and pp_cxx_pretty_printer_init.  Now, we are
guaranteed that initialization of any pretty printer derived from
pretty_printer will initialize the base subobjects (good!)

Our existing XNEW placebo doesn't do what is expected by a C++
programmer, which is to call the constructor to initialize the object.
So, I use placement-new at select places to ensure the Right Thing is done.
As you know, placement-new doesn't allocate memory; its only effect is
to "call" the right constructor.

We need to revisit our design and policy with regard to XNEW and friends.
But that is a debate for a separate thread.

Finally, we really need to get rid of pretty printers with static
storage duration.  I removed almost all of them in previous patches
except two: one is left in tree-pretty-printer.c , and one in cp/error.c.

Tested on an x86_64-suse-linux.  Applied to trunk.

-- Gaby

2013-08-22  Gabriel Dos Reis  

* pretty-print.h (output_buffer::output_buffer): Declare.
(pretty_printer::pretty_printer): Likewise.
(pp_construct): Remove.
* pretty-print.c (output_buffer::output_buffer): Define.
(pretty_printer::pretty_printer): Rename from pp_construct.  Simplify.
* gimple-pretty-print.c (print_gimple_stmt): Do not call pp_construct.
(print_gimple_expr): Likewise.
(print_gimple_seq): Likewise.
(gimple_dump_bb): Likewise.
* sched-vis.c (dump_value_slim): Likewise.
(dump_insn_slim): Likewise.
(dump_rtl_slim): Likewise.
(str_pattern_slim): Likewise.
* tree-mudflap.c (mf_varname_tree): Likewise.
* graph.c (print_graph_cfg): Likewise.
(start_graph_dump): Likewise.
* tree-pretty-print.c (maybe_init_pretty_print): Likewise.  Use
placement-new.
* diagnostic.c (diagnostic_initialize): Simplify early diagnostic
pretty printer initialization.
* coretypes.h (diagnostic_context): Remove superflous type alias
declaration.
(pretty_printer): Likewise.  Declare directly as a class.
(pretty_print_info): Remove declaration as class.
* asan.c (asan_emit_stack_protection): Remove call to pp_construct
and pp_clear_output_area.
(asan_add_global): Likewise.

c/
* c-objc-common.c (c_initialize_diagnostics): Simplify C pretty
printer initialization.

c-family/
* c-pretty-print.h (pp_c_pretty_printer_init): Remove.
(c_pretty_printer::c_pretty_printer): Declare.
* c-pretty-print.c (pretty_printer::c_pretty_printer): Rename from
c_pretty_printer_init.  Adjust.
(print_c_tree): Do not call c_pretty_printer_init.
* c-ada-spec.c (dump_ads): Remove call to pp_construct.

cp/
* error.c (init_error): Remove calls to pp_construct and
pp_cxx_pretty_printer_init.  Initialize cxx_pp with placement-new.
* cxx-pretty-print.h (cxx_pretty_printer::cxx_pretty_printer): Declare.
(cxx_pretty_printer_init): Remove.
* cxx-pretty-print.c (cxx_pretty_printer::cxx_pretty_printer):
Rename from cxx_pretty_printer_init.  Adjust.
* cp-objcp-common.c (cxx_initialize_diagnostics): Simplify
initialization of C++ diagnostics pretty printer.

Index: asan.c
===
--- asan.c  (revision 201904)
+++ asan.c  (working copy)
@@ -938,9 +938,7 @@
 
   /* First of all, prepare the description string.  */
   pretty_printer asan_pp;
-  pp_construct (&asan_pp, /* prefix */NULL, /* line-width */0);
-  
-  pp_clear_output_area (&asan_pp);
+
   if (DECL_NAME (current_function_decl))
 pp_tree_identifier (&asan_pp, DECL_NAME (current_function_decl));
   else
@@ -1963,9 +1961,7 @@
   vec *vinner = NULL;
 
   pretty_printer asan_pp;
-  pp_construct (&asan_pp, /* prefix */NULL, /* line-width */0);
 
-  pp_clear_output_area (&asan_pp);
   if (DECL_NAME (decl))
 pp_tree_identifier (&asan_pp, DECL_NAME (decl));
   else
Index: c/c-objc-common.c
===
--- c/c-objc-common.c   (revision 201904)
+++ c/c-objc-common.c   (working copy)
@@ -30,6 +30,8 @@
 #include "langhooks.h"
 #include "c-objc-common.h"
 
+#include   // For placement new.
+
 static bool c_tree_printer (pretty_printer *, text_info *, const char *,
int, bool, bool, bool);
 
@@ -183,16 +185,11 @@
 void
 c_initialize_diagnostics (diagnostic_context *context)
 {
-  pretty_printer *base;
-  c_pretty_printer *pp;
-
   c_

Re: [PATCH] Do not mark pseudo-copies decomposable during first lower-subreg pass

[Jay Foad]

On 26 September 2012 13:11, Ulrich Weigand  wrote:
> ChangeLog:
>
> * lower-subreg.c (enum classify_move_insn): Rename
> SIMPLE_PSEUDO_REG_MOVE to DECOMPOSABLE_SIMPLE_MOVE.
> (find_decomposable_subregs): Update.
> (decompose_multiword_subregs): Add DECOMPOSE_COPIES parameter.
> Only mark pseudo-to-pseudo copies as DECOMPOSABLE_SIMPLE_MOVE
> if that parameter is true.
> (rest_of_handle_lower_subreg): Call decompose_multiword_subregs
> with DECOMPOSE_COPIES false.
> (rest_of_handle_lower_subreg2): Call decompose_multiword_subregs
> with DECOMPOSE_COPIES true.

This patch seems to have caused a slight regression in ARM register allocation:

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

Jay.

Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic

[Janus Weil]

Hi,

>> Thus the condition should probably be
>> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled
>> before?  OK with that change (if it works).
>
> Good point. And yes, it works.
>
> However, on second thought, I wonder why we need to treat the case
> "selector->ts.type == BT_DERIVED" at all, since the selector in a
> SELECT TYPE statement is required to be polymorphic (which is being
> checked later in resolve_select_type). I.e. we weill get an error on
> the BT_DERIVED case anyway, so I don't see why we need to build a
> class container at all here (the only reason I could imagine would be
> something like error recovery).
>
> The attached new version is what I'm regtesting right now (with the
> whole BT_DERIVED branch removed, since it should not be needed). Ok if
> it succeeds?

It does regtest cleanly. Ok for trunk and 4.8?

Cheers,
Janus

Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic

[Mikael Morin]

Le 22/08/2013 12:49, Janus Weil a écrit :
> Hi,
> 
>>> Thus the condition should probably be
>>> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled
>>> before?  OK with that change (if it works).
>>
>> Good point. And yes, it works.
>>
>> However, on second thought, I wonder why we need to treat the case
>> "selector->ts.type == BT_DERIVED" at all, since the selector in a
>> SELECT TYPE statement is required to be polymorphic (which is being
>> checked later in resolve_select_type). I.e. we weill get an error on
>> the BT_DERIVED case anyway, so I don't see why we need to build a
>> class container at all here (the only reason I could imagine would be
>> something like error recovery).
>>
>> The attached new version is what I'm regtesting right now (with the
>> whole BT_DERIVED branch removed, since it should not be needed). Ok if
>> it succeeds?
> 
> It does regtest cleanly. Ok for trunk and 4.8?
> 
Yes.

Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic

[Janus Weil]

>>> The attached new version is what I'm regtesting right now (with the
>>> whole BT_DERIVED branch removed, since it should not be needed). Ok if
>>> it succeeds?
>>
>> It does regtest cleanly. Ok for trunk and 4.8?
>>
> Yes.

Thanks, committed to trunk as r201919. Will backport to 4.8 soon.

Cheers,
Janus

[C++ Patch] PR 56380

[Paolo Carlini]

Hi,

we fail to diagnose such illegal declarations when they occur at 
instantiation time.


Patch should be rather straightforward, possibly modulo exact wording; 
permerror vs error; something error recovery related (not touching the 
CLASSTYPE_HAS_MUTABLE setting seems ok to me).


Booted and tested x86_64-linux.

Thanks,
Paolo.

//
/cp
2013-08-22  Paolo Carlini  

PR c++/56380
* class.c (check_field_decls): Check for const mutable and const
reference data members.

/testsuite
2013-08-22  Paolo Carlini  

PR c++/56380
* g++.dg/template/error54.C: New.
Index: cp/class.c
===
--- cp/class.c  (revision 201917)
+++ cp/class.c  (working copy)
@@ -3500,6 +3500,22 @@ check_field_decls (tree t, tree *access_decls,
   if (DECL_MUTABLE_P (x) || TYPE_HAS_MUTABLE_P (type))
CLASSTYPE_HAS_MUTABLE (t) = 1;
 
+  if (DECL_MUTABLE_P (x))
+   {
+ if (CP_TYPE_CONST_P (type))
+   {
+ error ("member %q+D cannot be declared both % "
+"and %", x);
+ continue;
+   }
+ if (TREE_CODE (type) == REFERENCE_TYPE)
+   {
+ error ("member %q+D cannot be declared as a % "
+"reference", x);
+ continue;
+   }
+   }
+
   if (! layout_pod_type_p (type))
/* DR 148 now allows pointers to members (which are POD themselves),
   to be allowed in POD structs.  */
Index: testsuite/g++.dg/template/error54.C
===
--- testsuite/g++.dg/template/error54.C (revision 0)
+++ testsuite/g++.dg/template/error54.C (working copy)
@@ -0,0 +1,10 @@
+// PR c++/56380
+
+template 
+struct X {
+  X();
+  mutable T x;  // { dg-error "cannot be declared" }
+};
+
+X a; // { dg-message "required from here" }
+X b;  // { dg-message "required from here" }

Re: ipa-devirt.c TLC

[Richard Biener]

Jan Hubicka  wrote:
>Hi,
>this patch fixes some issues with ipa-devirt I noticed since the
>initial
>commit.
>
> 1) I added fixes and comments Doji suggested (thanks!)
>
>2) During the callgraph construction new external nodes may be created
>that
>needs to be added into the inheritance graph get more complette andwers
>from possible_polymorphic_call_targets.
>
>While the answer is never complette for external functions, it is
>better
>   to have more of them than fewer so speculation is not trying to work
>too hard.
>
>I added function that collects all new nodes into the graph.
>
>3) I merged in flag for anonymous_namespace types, but forgot to
>initialize
>   it (it is used to decide if set of targets is complette and I am not
>using that flag in mainline ATM)
>
>4) Added possible_polymorphic_call_target_p that can be used for sanity
>checking
>of devirtualization machinery.  The testing now passes firefox and
>couple
>other testcases, but I will submit the verification bits separately of
>this
>change.
>
>5) -fdump-ipa-type-inheritance ICEs when there are no polynmorphic
>types.
>
>6) I managed to get call target cache wrong in a way that is is never
>freed
>on node removal as it is supposed to.
>
>Bootstrapped/regtested ppc64-linux, will commit it tomorrow if there
>are no
>complains and x86_64-linux testing completes.

Btw, how does this all scale with the worst testcase?  That is, a very deep 
inheritance hierarchy with each level virtually overriding all methods and very 
many duplicate input files? Is that really the worst case? We should make sure 
not to introduce quadratic or worse algorithms. (I didn't see you limiting the 
number of possible call targets)

Richard.

>Honza
>
>   * cgraphunit.c (analyze_functions) Use update_type_inheritance_graph.
>   * ipa-utils.h (update_type_inheritance_graph): Declare.
>   (possible_polymorphic_call_target_p): Declare.
>   (possible_polymorphic_call_target_p): New.
>   * ipa-devirt.c: Update toplevel comments.
>   (cached_polymorphic_call_targets): Move up.
>   (odr_type_d): Move ID down.
>   (polymorphic_type_binfo_p): Update comment.
>   (odr_hasher::remove): Likewise;
>   (get_odr_type): Set anonymous_namespace.
>   (dump_odr_type): Dump it.
>   (dump_type_inheritance_graph): Do not ICE when there are no ODR types.
>   (maybe_record_node): Record node in cached_polymorphic_call_targets.
>   (record_binfo): Add comment.
>   (free_polymorphic_call_targets_hash): Do not ICE when cache is not
>built.
>   (devirt_node_removal_hook): Do not iCE when cache is freed.
>   (possible_polymorphic_call_target_p): New predicate.
>   (update_type_inheritance_graph): New function.
>Index: cgraphunit.c
>===
>--- cgraphunit.c   (revision 201899)
>+++ cgraphunit.c   (working copy)
>@@ -976,6 +976,8 @@ analyze_functions (void)
>   cgraph_process_new_functions ();
>   }
> }
>+  if (optimize && flag_devirtualize)
>+update_type_inheritance_graph ();
> 
>   /* Collect entry points to the unit.  */
>   if (cgraph_dump_file)
>Index: ipa-utils.h
>===
>--- ipa-utils.h(revision 201899)
>+++ ipa-utils.h(working copy)
>@@ -50,12 +50,15 @@ tree get_base_var (tree);
> struct odr_type_d;
> typedef odr_type_d *odr_type;
> void build_type_inheritance_graph (void);
>+void update_type_inheritance_graph (void);
> vec 
> possible_polymorphic_call_targets (tree, HOST_WIDE_INT,
>  bool *final = NULL,
>  void **cache_token = NULL);
> odr_type get_odr_type (tree, bool insert = false);
>void dump_possible_polymorphic_call_targets (FILE *, tree,
>HOST_WIDE_INT);
>+bool possible_polymorphic_call_target_p (tree, HOST_WIDE_INT,
>+   struct cgraph_node *n);
> 
> /* Return vector containing possible targets of polymorphic call E.
>If FINALP is non-NULL, store true if the list is complette. 
>@@ -87,6 +90,17 @@ dump_possible_polymorphic_call_targets (
> dump_possible_polymorphic_call_targets (f, e->indirect_info->otr_type,
> e->indirect_info->otr_token);
> }
>+
>+/* Return true if N can be possibly target of a polymorphic call of
>+   E.  */
>+
>+inline bool
>+possible_polymorphic_call_target_p (struct cgraph_edge *e,
>+  struct cgraph_node *n)
>+{
>+  return possible_polymorphic_call_target_p
>(e->indirect_info->otr_type,
>+   e->indirect_info->otr_token, n);
>+}
> #endif  /* GCC_IPA_UTILS_H  */
> 
> 
>Index: ipa-devirt.c
>===
>--- ipa-devirt.c   (revision 201899)
>+++ ipa-devirt.c   (working copy)
>@@ -37,10 +37,10 @@ along with GCC; see the file COPYING3.

Re: [PATCH] Enable non-complex math builtins from C99 for Bionic

[Alexander Ivchenko]

Ugh.. thanks, you are right. That points to another problem that I
didn't see before:

3) *linux* targets that do not append to tm_p_file (s390x-*-linux* and
s390x-ibm-tpf* - your patch addresses that problem correctly) OR
tmake_file (bfin*-linux-uclibc* or crisv32-*-linux* | cris-*-linux*)

(btw bfin*-linux-uclibc* or crisv32-*-linux* | cris-*-linux* are
broken now anyways:

opening glibc-c.o: No such file or directory
make[1]: *** [cc1-checksum.c] Error 1
make[1]: *** Waiting for unfinished jobs...)

Sorry again for the inconvenience, here is the updated patch that now,
hopefully, fixes the issues with my initial patch.
(Andreas patch still needs to be applied)

Is it OK?

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6e27be2..2d15fb1 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,17 @@
+2013-08-21  Alexander Ivchenko  
+
+ * config/linux-android.c (linux_android_libc_has_function): Fix
+ checks for libc.
+ * config/bfin/uclinux.h: Define TARGET_LIBC_HAS_FUNCTION as
+ no_c99_libc_has_function.
+ * config/c6x/uclinux-elf.h: Ditto.
+ * config/lm32/uclinux-elf.h: Ditto.
+ * config/m68k/uclinux.h: Ditto.
+ * config/moxie/uclinux.h: Ditto.
+ * config.gcc (bfin*-linux-uclibc*): Add t-linux-android to tmake_file.
+ (crisv32-*-linux*, cris-*-linux*): Ditto.
+ * config/bfin/bfin.c: Include "tm_p.h".
+
 2013-08-21  Joern Rennecke  

  * reload.h (struct reg_equivs): Rename to ..
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7e1d529..89cf30a 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1018,7 +1018,7 @@ bfin*-uclinux*)
  ;;
 bfin*-linux-uclibc*)
  tm_file="${tm_file} dbxelf.h elfos.h bfin/elf.h gnu-user.h linux.h
glibc-stdint.h bfin/linux.h ./linux-sysroot-suffix.h"
- tmake_file="bfin/t-bfin-linux t-slibgcc"
+ tmake_file="bfin/t-bfin-linux t-slibgcc t-linux-android"
  use_collect2=no
  ;;
 bfin*-rtems*)
@@ -1053,7 +1053,7 @@ cris-*-elf | cris-*-none)
 crisv32-*-linux* | cris-*-linux*)
  tm_file="dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h
glibc-stdint.h cris/linux.h"
  # We need to avoid using t-linux, so override default tmake_file
- tmake_file="cris/t-cris cris/t-linux t-slibgcc"
+ tmake_file="cris/t-cris cris/t-linux t-slibgcc t-linux-android"
  extra_options="${extra_options} cris/linux.opt"
  case $target in
   cris-*-*)
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index 7fab975..18457f8 100644
--- a/gcc/config/bfin/bfin.c
+++ b/gcc/config/bfin/bfin.c
@@ -46,6 +46,7 @@
 #include "cgraph.h"
 #include "langhooks.h"
 #include "bfin-protos.h"
+#include "tm_p.h"
 #include "tm-preds.h"
 #include "tm-constrs.h"
 #include "gt-bfin.h"
diff --git a/gcc/config/bfin/uclinux.h b/gcc/config/bfin/uclinux.h
index ca0f4ee..63cba99 100644
--- a/gcc/config/bfin/uclinux.h
+++ b/gcc/config/bfin/uclinux.h
@@ -44,3 +44,6 @@ see the files COPYING3 and COPYING.RUNTIME
respectively.  If not, see
 #define TARGET_SUPPORTS_SYNC_CALLS 1

 #define SUBTARGET_FDPIC_NOT_SUPPORTED
+
+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/c6x/uclinux-elf.h b/gcc/config/c6x/uclinux-elf.h
index 5d61f4d..fa0937e 100644
--- a/gcc/config/c6x/uclinux-elf.h
+++ b/gcc/config/c6x/uclinux-elf.h
@@ -62,3 +62,5 @@
 : "0" (_beg), "b" (_end), "b" (_scno)); \
 }

+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
index 4a4b48d..e9d9e9a 100644
--- a/gcc/config/linux-android.c
+++ b/gcc/config/linux-android.c
@@ -35,9 +35,9 @@ linux_android_has_ifunc_p (void)
 bool
 linux_android_libc_has_function (enum function_class fn_class)
 {
-  if (OPTION_GLIBC)
+  if (linux_libc == LIBC_GLIBC)
 return true;
-  if (OPTION_BIONIC)
+  if (linux_libc == LIBC_BIONIC)
 if (fn_class == function_c94
  || fn_class == function_c99_misc
  || fn_class == function_sincos)
diff --git a/gcc/config/lm32/uclinux-elf.h b/gcc/config/lm32/uclinux-elf.h
index 3a556d7..a5e8163 100644
--- a/gcc/config/lm32/uclinux-elf.h
+++ b/gcc/config/lm32/uclinux-elf.h
@@ -77,3 +77,5 @@
 #undef  CC1_SPEC
 #define CC1_SPEC "%{G*} %{!fno-PIC:-fPIC}"

+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/m68k/uclinux.h b/gcc/config/m68k/uclinux.h
index 8d74312..b1af7d2 100644
--- a/gcc/config/m68k/uclinux.h
+++ b/gcc/config/m68k/uclinux.h
@@ -67,3 +67,6 @@ along with GCC; see the file COPYING3.  If not see
sections.  */
 #undef M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
 #define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P 1
+
+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/moxie/uclinux.h b/gcc/config/moxie/uclinux.h
index 498037e..85c65f2 100644
--- a/gcc/config/moxie/uclinux.h
+++ b/gcc/config/moxie/uclinux.h
@@ -37,3 +37,6 @@ see the files COPYING3 and COPYING.RUNTIME
respectively.  If not, see
  --wrap=mmap --wrap=munmap --wrap=alloca\
  %{fmudflapth: --wrap=pt

[C++ patch] Set attributes for C++ runtime library calls

[Jan Hubicka]

Hi,
this patch started as a work to make cxa_pure_virtual as noreturn.  This
is good for middle-end to figure out that it should not care about
devirtualizing to it and it should devirtualize speculative where there
is only one variant.  I ended up switching the function building
stuff to use ecf_flags that is handy to set other attributes, too.

I tried to go across all functions build and assign them correct attributes.
I expecitely listed them all in changelog to make it easier to double
check: I am not expert on C++ runtime.

I have three questions:

 - I tried to track functions that lead to terminate() and not mark them
   as ECF_LEAF.  This is because user can set handler.  If the handler
   can resonably expect the static vars defined in its unit to be
   in the final form, we can not consider it ECF_LEAF.
   Perhaps there are cases where terminate() is called only for programs
   already after undefined effect?
 - I would like to recall issue if we can make NEW_EXPR annotated with
   MALLOC attribute.  Without it, it is basically impossible to track
   any dynamically allocated objects in the middle-end
 - Is do_end_catch nothrow? It does not seem to be declared so in libsupc++

Bootstrapped/regtested x86_64-linux, OK?

* class.c (build_vtbl_initializer): Make __cxa_deleted_virtual
ECF_NORETURN
* cp-tree.h (build_library_fn_ptr, build_cp_library_fn_ptr,
push_library_fn, push_void_library_fn): Update prototype.
* decl.c (build_library_fn_1): Remove.
(push_cp_library_fn, build_cp_library_fn): Update to take ECF flags.
(cxx_init_decl_processing): Update; global_delete_fndecl is ECF_NOTROW;
__cxa_pure_virtual is ECF_NORETURN | ECF_NORETURN.
(build_library_fn_1): Add ecf_flags argument; rename to ...
(build_library_fn): ... this one.
(build_cp_library_fn): Take ecf_flags; do not copy NOTHROW flag.
(build_library_fn_ptr): Take ecf_flags.
(build_cp_library_fn_ptr): Likewise.
(push_library_fn): Likewise.
(push_cp_library_fn): Likewise.
(push_void_library_fn): Likewise.
(push_throw_library_fn): All throws are ECF_NORETURN.
(__cxa_atexit, __cxa_thread_atexit): Add ECF_LEAF | ECF_NOTHROW 
attributes.
(expand_static_init): __cxa_guard_acquire, __cxa_guard_release,
__cxa_guard_abort are ECF_NOTHROW | ECF_LEAF.
* except.c (init_exception_processing): terminate is
ECF_NOTHROW | ECF_NORETURN.
(declare_nothrow_library_fn): Add ecf_flags parameter.
(__cxa_get_exception_ptr): Is ECF_NOTHROW | ECF_PURE | ECF_LEAF |
ECF_TM_PURE.
(do_begin_catch): cxa_begin_catch and _ITM_cxa_begin_catch
are ECF_NOTHROW.
(do_end_catch): __cxa_end_catch and _ITM_cxa_end_catch is
nothing.
(do_allocate_exception): _cxa_allocate_exception
and _ITM_cxa_allocate_exception are ECF_NOTHROW | ECF_MALLOC
(do_free_exception): __cxa_free_exception is
ECF_NOTHROW | ECF_LEAF.
* rtti.c (build_dynamic_cast_1): __dynamic_cast
is ECF_LEAF | ECF_PURE | ECF_NOTHROW.

Index: cp/class.c
===
*** cp/class.c  (revision 201910)
--- cp/class.c  (working copy)
*** build_vtbl_initializer (tree binfo,
*** 8857,8863 
  if (!get_global_value_if_present (fn, &fn))
fn = push_library_fn (fn, (build_function_type_list
   (void_type_node, NULL_TREE)),
! NULL_TREE);
  if (!TARGET_VTABLE_USES_DESCRIPTORS)
init = fold_convert (vfunc_ptr_type_node,
 build_fold_addr_expr (fn));
--- 8857,8863 
  if (!get_global_value_if_present (fn, &fn))
fn = push_library_fn (fn, (build_function_type_list
   (void_type_node, NULL_TREE)),
! NULL_TREE, ECF_NORETURN);
  if (!TARGET_VTABLE_USES_DESCRIPTORS)
init = fold_convert (vfunc_ptr_type_node,
 build_fold_addr_expr (fn));
Index: cp/cp-tree.h
===
*** cp/cp-tree.h(revision 201910)
--- cp/cp-tree.h(working copy)
*** extern void check_goto  (tree);
*** 5173,5182 
  extern bool check_omp_return  (void);
  extern tree make_typename_type(tree, tree, enum 
tag_types, tsubst_flags_t);
  extern tree make_unbound_class_template   (tree, tree, tree, 
tsubst_flags_t);
! extern tree build_library_fn_ptr  (const char *, tree);
! extern tree build_cp_library_fn_ptr   (const char *, tree);
! extern tree push_library_fn   (tree, tree, tree);
! extern tree push_void_lib

[Patch, Fortran, OOP] PR 57305: ICE when calling SIZEOF on an unlimited polymorphic variable

[Janus Weil]

Hi all,

the SIZEOF intrinsic currently returns the size according to the
*declared* type for polymorphic variables. I think this doesn't really
make much sense and it also causes ICEs when SIZEOF is called on
CLASS(*) variables (which don't really have a declared type).
Therefore I'm proposing to make SIZEOF return the size according to
the *dynamic* type instead. The same is done by STORAGE_SIZE (F08),
which however gives the size in bits. SIZEOF is a GNU extension, so we
are free to decide on its behavior. I don't remember why the declared
type was chosen in the first place, and I hope that no one seriously
depends on the current behavior (the size of the declared type is
probably not really useful after all).

The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2013-08-22  Janus Weil  

PR fortran/57305
* intrinsic.texi (SIZEOF): Update documentation.
* trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Make SIZEOF return the
size of the dynamic type for polymorphic variables.


2013-08-22  Janus Weil  

PR fortran/57305
* gfortran.dg/storage_size_1.f08: Modified.
* gfortran.dg/sizeof_4.f90: New.


pr57305.diff
Description: Binary data


sizeof_4.f90
Description: Binary data

Re: RFC - Refactor tree.h

[Andrew MacLeod]

On 08/21/2013 05:13 PM, Mike Stump wrote:

O

that should include the tree-core.h file as well as the tree-api.h file.

No…  I don't see a client for tree-api.  Logically, you can segregate them down 
at the bottom of tree-core.h.


We are then left with this tree-api.h file which will be included from 2 
places.. tree.h and gimple.h.   As files are converted to the new gimple form, 
any functions which use to have 'tree' in the prototype are going to be 
converted to GimpleType or whatever, and the tree prototype(s) will be removed 
from tree-api.h.  At that point, the prototype(s) will be put in an appropriate 
header file, creating one if need be, and included as needed.

One can move them from tree-core.h or to any other home as appropriate.

OK, I see what you are saying, and it makes sense.

I was thinking there would be other uses for the tree-api.h file and 
didn't want to pollute tree-core.h... for instance, the tree-builder 
inline functions are going to need to be accessible in files which have 
been converted as well, but I'll worry about that when I get to it... I 
will likely create gimple object routines to do the equivalent anyway.  
And I'll deal with anything else as it arises.


so we would have:
- tree-core.h which has the tree structure's first, then all the 
prototypes at the end of that file which would have been in 
tree-api.hIn theory, these eventually all find better homes.

- tree.h  which includes tree-core.h, then all the macros and such.

I can live with that, it enables what I need to do and has minimal impact.

Andrew

Re: powerpc64le multilibs and multiarch dir

[David Edelsohn]

On Wed, Aug 21, 2013 at 11:57 PM, Alan Modra  wrote:

> Index: gcc/config/rs6000/t-linux64
> ===
> --- gcc/config/rs6000/t-linux64 (revision 201834)
> +++ gcc/config/rs6000/t-linux64 (working copy)
> @@ -25,8 +25,8 @@
>  # it doesn't tell anything about the 32bit libraries on those systems.  Set
>  # MULTILIB_OSDIRNAMES according to what is found on the target.
>
> -MULTILIB_OPTIONS= m64/m32
> -MULTILIB_DIRNAMES   = 64 32
> -MULTILIB_EXTRA_OPTS = fPIC
> -MULTILIB_OSDIRNAMES= ../lib64$(call if_multiarch,:powerpc64-linux-gnu)
> -MULTILIB_OSDIRNAMES+= $(if $(wildcard $(shell echo 
> $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
> if_multiarch,:powerpc-linux-gnu)
> +MULTILIB_OPTIONS:= m64/m32
> +MULTILIB_DIRNAMES   := 64 32
> +MULTILIB_EXTRA_OPTS :=
> +MULTILIB_OSDIRNAMES := m64=../lib64$(call if_multiarch,:powerpc64-linux-gnu)
> +MULTILIB_OSDIRNAMES += m32=$(if $(wildcard $(shell echo 
> $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
> if_multiarch,:powerpc-linux-gnu)

What is the purpose of the change to MULTILIB_OSDIRNAMES? Why the
addition of m64= and m32=? A secondary tmake file is not always set to
post-process those macros, AFAICT.

Thanks, David

Re: [PATCH i386 4/8] [AVX512] Add substed patterns.

[Kirill Yukhin]

On 14 Aug 11:44, Kirill Yukhin wrote:
PING?

Thanks, K

Re: [Patch] Fix empty grouping problem in regex

[Tim Shen]

On Thu, Aug 22, 2013 at 9:08 AM, Tim Shen  wrote:
> Booted and tested with -m32, -m64 and -m64 debug-mode under x86_64
> GNU/Linux and committed(r201914).

...and here's the patch committed.


-- 
Tim Shen


emptygroup.patch
Description: Binary data

[PATCH, AArch64] Fix configure test for AArch64 dwarf2 debug_line

[Julian Brown]

Hi,

This patch fixes what I assume to be a simple omission from the
configure test for debug_line assembler support in gcc/configure. This
tripped an obscure corner-case test in our build infrastructure, which
is fixed by the attached patch, but I don't otherwise have a way of
testing the patch at present.

OK to apply?

Thanks,

Julian

ChangeLog

gcc/
* configure.ac: Add aarch64 to list of arches which use "nop" in
debug_line test.
* configure: Regenerate.Index: gcc/configure.ac
===
--- gcc/configure.ac	(revision 201919)
+++ gcc/configure.ac	(working copy)
@@ -4219,8 +4219,9 @@ esac
 # ??? Once 2.11 is released, probably need to add first known working
 # version to the per-target configury.
 case "$cpu_type" in
-  alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze | mips \
-  | pa | rs6000 | score | sparc | spu | tilegx | tilepro | xstormy16 | xtensa)
+  aarch64 | alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze
+  | mips | pa | rs6000 | score | sparc | spu | tilegx | tilepro | xstormy16
+  | xtensa)
 insn="nop"
 ;;
   ia64 | s390)

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 8:19 AM, Jan Hubicka  wrote:
>
> Hi,
> this patch started as a work to make cxa_pure_virtual as noreturn.  This
> is good for middle-end to figure out that it should not care about
> devirtualizing to it and it should devirtualize speculative where there
> is only one variant.  I ended up switching the function building
> stuff to use ecf_flags that is handy to set other attributes, too.
>
> I tried to go across all functions build and assign them correct attributes.
> I expecitely listed them all in changelog to make it easier to double
> check: I am not expert on C++ runtime.
>
> I have three questions:
>
>  - I tried to track functions that lead to terminate() and not mark them
>as ECF_LEAF.  This is because user can set handler.  If the handler
>can resonably expect the static vars defined in its unit to be
>in the final form, we can not consider it ECF_LEAF.
>Perhaps there are cases where terminate() is called only for programs
>already after undefined effect?
>  - I would like to recall issue if we can make NEW_EXPR annotated with
>MALLOC attribute.  Without it, it is basically impossible to track
>any dynamically allocated objects in the middle-end

operator new is replaceable by user program.

>  - Is do_end_catch nothrow? It does not seem to be declared so in libsupc++
>
> Bootstrapped/regtested x86_64-linux, OK?
>
> * class.c (build_vtbl_initializer): Make __cxa_deleted_virtual
> ECF_NORETURN
> * cp-tree.h (build_library_fn_ptr, build_cp_library_fn_ptr,
> push_library_fn, push_void_library_fn): Update prototype.
> * decl.c (build_library_fn_1): Remove.
> (push_cp_library_fn, build_cp_library_fn): Update to take ECF flags.
> (cxx_init_decl_processing): Update; global_delete_fndecl is 
> ECF_NOTROW;
> __cxa_pure_virtual is ECF_NORETURN | ECF_NORETURN.
> (build_library_fn_1): Add ecf_flags argument; rename to ...
> (build_library_fn): ... this one.
> (build_cp_library_fn): Take ecf_flags; do not copy NOTHROW flag.
> (build_library_fn_ptr): Take ecf_flags.
> (build_cp_library_fn_ptr): Likewise.
> (push_library_fn): Likewise.
> (push_cp_library_fn): Likewise.
> (push_void_library_fn): Likewise.
> (push_throw_library_fn): All throws are ECF_NORETURN.
> (__cxa_atexit, __cxa_thread_atexit): Add ECF_LEAF | ECF_NOTHROW 
> attributes.
> (expand_static_init): __cxa_guard_acquire, __cxa_guard_release,
> __cxa_guard_abort are ECF_NOTHROW | ECF_LEAF.
> * except.c (init_exception_processing): terminate is
> ECF_NOTHROW | ECF_NORETURN.
> (declare_nothrow_library_fn): Add ecf_flags parameter.
> (__cxa_get_exception_ptr): Is ECF_NOTHROW | ECF_PURE | ECF_LEAF |
> ECF_TM_PURE.
> (do_begin_catch): cxa_begin_catch and _ITM_cxa_begin_catch
> are ECF_NOTHROW.
> (do_end_catch): __cxa_end_catch and _ITM_cxa_end_catch is
> nothing.
> (do_allocate_exception): _cxa_allocate_exception
> and _ITM_cxa_allocate_exception are ECF_NOTHROW | ECF_MALLOC
> (do_free_exception): __cxa_free_exception is
> ECF_NOTHROW | ECF_LEAF.
> * rtti.c (build_dynamic_cast_1): __dynamic_cast
> is ECF_LEAF | ECF_PURE | ECF_NOTHROW.
>
> Index: cp/class.c
> ===
> *** cp/class.c  (revision 201910)
> --- cp/class.c  (working copy)
> *** build_vtbl_initializer (tree binfo,
> *** 8857,8863 
>   if (!get_global_value_if_present (fn, &fn))
> fn = push_library_fn (fn, (build_function_type_list
>(void_type_node, NULL_TREE)),
> ! NULL_TREE);
>   if (!TARGET_VTABLE_USES_DESCRIPTORS)
> init = fold_convert (vfunc_ptr_type_node,
>  build_fold_addr_expr (fn));
> --- 8857,8863 
>   if (!get_global_value_if_present (fn, &fn))
> fn = push_library_fn (fn, (build_function_type_list
>(void_type_node, NULL_TREE)),
> ! NULL_TREE, ECF_NORETURN);
>   if (!TARGET_VTABLE_USES_DESCRIPTORS)
> init = fold_convert (vfunc_ptr_type_node,
>  build_fold_addr_expr (fn));
> Index: cp/cp-tree.h
> ===
> *** cp/cp-tree.h(revision 201910)
> --- cp/cp-tree.h(working copy)
> *** extern void check_goto  (tree);
> *** 5173,5182 
>   extern bool check_omp_return  (void);
>   extern tree make_typename_type(tree, tree, enum 
> tag_types, tsubst_flags_t);
>   extern tree make_unbound_class_template 

Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

[Bill Schmidt]

Hi Christian and Jakub,

I'm curious whether there was ever any resolution for:
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.

We've encountered what appears to be the same issue internally when
building a cross for powerpc64le-linux-gnu:

/scratch/tmp/anton/toolchain/build/src/gcc/libgcc/unwind-dw2.c:41:21:
fatal error: sys/sdt.h: No such file or directory
 #include 

The gcc configure is looking at the build machine header files, instead
of the installed headers for the host we're building.  We can work
around this with a build-sysroot, but it seems that shouldn't be
necessary.  Thoughts?

Re: [C++ patch] Set attributes for C++ runtime library calls

[Alexander Monakov]

On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> >  - I would like to recall issue if we can make NEW_EXPR annotated with
> >MALLOC attribute.  Without it, it is basically impossible to track
> >any dynamically allocated objects in the middle-end
> 
> operator new is replaceable by user program.

But so is malloc?  As I understand, the reason why "malloc" attribute is not
applicable to operator new is "placement new", which returns aliased memory.

Alexander

Re: ipa-devirt.c TLC

[Jan Hubicka]

> 
> Btw, how does this all scale with the worst testcase?  That is, a very deep
> inheritance hierarchy with each level virtually overriding all methods and
> very many duplicate input files? Is that really the worst case? We should
> make sure not to introduce quadratic or worse algorithms. (I didn't see you
> limiting the number of possible call targets)

Very many duplicate input files are not an issue, since I identify the ODR
types and handle them only by leaders.  

To get things working well in practice (not in worst case) I use the query
cache.  The purpose of query cache is to re-use the target lists when same
virutal call appears in program many times.  The cache tokens passed to users
allows them to not walk the same list many times when the work depends only on
callees (as it does for dead code removal).

So to trigger the qudaratic case you need to introduce something like 1000
classes inheriting each other and each overwriting the method and then call
with type of each of them (so you have 1000 different calls). Then the
call target query cache will have 1+2+..1000 entries.
Worse yet, make the first baseclass to have 1000 methods and you can trigger
linear walks in the gimple_get_virt_method_for_binfo linear slowness. Of course
here you will generate quadratically sized vtables into the binary.

I made simple script constructing this and we died in FE (binfos are quadratic
already and we have non-linear walks on them). So I declared it premature
optimization and decided to get things correct first.

The simple way around is to start returning empty list once call target cache
is, say 100*number of virtual methods in unit.

The mainline version with patch enabling it on LTO (I wait for approval of the
ODR patch that makes use of VTABLE manglings) I get the overall overhead of
call target analysis and walks in unreachable code removal on Firefox under 2%.
Vast majority goes to constructor folding that is called from
gimple_get_virt_method_for_binfo.  Sensible speedup would be to reconstruct
vectors of virtual methods from vtables instead of walking the vtables
everywhere, but for that I would like to change all the binfo walks we have in
middle-end, so I would like to cleanup and fix existing code a bit first.

Finally the cache can be made smaller (linear to vtable size in case of single)
inheritance by simply making it to return partial vectors and have list of
outer type to contain the list of inner type.  It means that I will need to
invent my own type for return value of possible_polymorphic_call_targets and
iterators on that + some smarter way to tell passes calling me when they
do redundant work.

If you preffer to have the limit on cache size now, I can push out a patch.

Honza

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov  wrote:
> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> >  - I would like to recall issue if we can make NEW_EXPR annotated with
>> >MALLOC attribute.  Without it, it is basically impossible to track
>> >any dynamically allocated objects in the middle-end
>>
>> operator new is replaceable by user program.
>
> But so is malloc?

no, malloc isn't replaceable.

>  As I understand, the reason why "malloc" attribute is not
> applicable to operator new is "placement new", which returns aliased memory.

whether 'operator new' returns aliases memory depends on the user's
implementation, but then user has to be careful so that all other
aliasing assumptions still holds.  It is not obvious it is *exactly*
like malloc, which is why we need to exercise caution.

-- Gaby

Re: [PATCH, AArch64] Fix configure test for AArch64 dwarf2 debug_line

[Richard Earnshaw]

On 22/08/13 15:26, Julian Brown wrote:
> Hi,
> 
> This patch fixes what I assume to be a simple omission from the
> configure test for debug_line assembler support in gcc/configure. This
> tripped an obscure corner-case test in our build infrastructure, which
> is fixed by the attached patch, but I don't otherwise have a way of
> testing the patch at present.
> 
> OK to apply?
> 
> Thanks,
> 
> Julian
> 
> ChangeLog
> 
> gcc/
> * configure.ac: Add aarch64 to list of arches which use "nop" in
> debug_line test.
> * configure: Regenerate.
> 
> 

This is OK, though it seems to me that, given how old gas 2.11 is now,
it might be better to have a 'default' for this test and then catch the
systems that are different.

R.

> aarch64-debug-linux-configure-fix-1.diff
> 
> 
> Index: gcc/configure.ac
> ===
> --- gcc/configure.ac  (revision 201919)
> +++ gcc/configure.ac  (working copy)
> @@ -4219,8 +4219,9 @@ esac
>  # ??? Once 2.11 is released, probably need to add first known working
>  # version to the per-target configury.
>  case "$cpu_type" in
> -  alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze | mips \
> -  | pa | rs6000 | score | sparc | spu | tilegx | tilepro | xstormy16 | 
> xtensa)
> +  aarch64 | alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze
> +  | mips | pa | rs6000 | score | sparc | spu | tilegx | tilepro | xstormy16
> +  | xtensa)
>  insn="nop"
>  ;;
>ia64 | s390)
> 

Fix overflows in -ftime-report

[Jan Hubicka]

Hi,
this patch fixes overflow happening in -ftime-report when printing memory usage
of bigger WPA compilations.

Honza

* timevar.c (validate_phases): Use size_t for memory.
* timevar.h (struct timevar_time_def): Use size_t for ggc_mem.
Index: timevar.c
===
--- timevar.c   (revision 201919)
+++ timevar.c   (working copy)
@@ -430,7 +430,7 @@ validate_phases (FILE *fp)
   double phase_user = 0.0;
   double phase_sys = 0.0;
   double phase_wall = 0.0;
-  unsigned phase_ggc_mem = 0;
+  size_t phase_ggc_mem = 0;
   static char phase_prefix[] = "phase ";
   const double tolerance = 1.01;  /* One part in a million.  */
 
@@ -465,7 +465,7 @@ validate_phases (FILE *fp)
   if (phase_wall > total->wall)
fprintf (fp, "wall%24.18e > %24.18e\n", phase_wall, total->wall);
   if (phase_ggc_mem > total->ggc_mem)
-   fprintf (fp, "ggc_mem %24u > %24u\n", phase_ggc_mem, total->ggc_mem);
+   fprintf (fp, "ggc_mem %24lu > %24lu\n", phase_ggc_mem, total->ggc_mem);
   gcc_unreachable ();
 }
 }
Index: timevar.h
===
--- timevar.h   (revision 201919)
+++ timevar.h   (working copy)
@@ -62,7 +62,7 @@ struct timevar_time_def
   double wall;
 
   /* Garbage collector memory.  */
-  unsigned ggc_mem;
+  size_t ggc_mem;
 };
 
 /* An enumeration of timing variable identifiers.  Constructed from

Re: [C++ patch] Set attributes for C++ runtime library calls

[Jakub Jelinek]

On Thu, Aug 22, 2013 at 09:53:35AM -0500, Gabriel Dos Reis wrote:
> On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov  wrote:
> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> >> >  - I would like to recall issue if we can make NEW_EXPR annotated with
> >> >MALLOC attribute.  Without it, it is basically impossible to track
> >> >any dynamically allocated objects in the middle-end
> >>
> >> operator new is replaceable by user program.
> >
> > But so is malloc?
> 
> no, malloc isn't replaceable.

Is it such a good idea to replace something gcc during bootstrap can
optimize well (malloc/xmalloc etc.) with something that it can't (operator new)?

Jakub

Fix variable symbol renaming

[Jan Hubicka]

Hi,
this was noticed by the ODR verifier.  For variables we get unique_name wrong
because we first bring it local and then test if it is global.
This makes the ODR unification based on aassembler name to go wrong.

Bootstrapped/regtested x86_64-linux, will commit it shortly.

* ipa.c (function_and_variable_visibility): First remember function was 
global
and then make it local.
Index: ipa.c
===
--- ipa.c   (revision 201919)
+++ ipa.c   (working copy)
@@ -968,10 +968,10 @@ function_and_variable_visibility (bool w
  && !vnode->symbol.weakref)
{
  gcc_assert (in_lto_p || whole_program || !TREE_PUBLIC 
(vnode->symbol.decl));
- symtab_make_decl_local (vnode->symbol.decl);
  vnode->symbol.unique_name = ((vnode->symbol.resolution == 
LDPR_PREVAILING_DEF_IRONLY
   || vnode->symbol.resolution == 
LDPR_PREVAILING_DEF_IRONLY_EXP)
   && TREE_PUBLIC (vnode->symbol.decl));
+ symtab_make_decl_local (vnode->symbol.decl);
  if (vnode->symbol.same_comdat_group)
symtab_dissolve_same_comdat_group_list ((symtab_node) vnode);
  vnode->symbol.resolution = LDPR_PREVAILING_DEF_IRONLY;

Re: Fix overflows in -ftime-report

[Richard Earnshaw]

On 22/08/13 16:03, Jan Hubicka wrote:
> Hi,
> this patch fixes overflow happening in -ftime-report when printing memory 
> usage
> of bigger WPA compilations.
> 
> Honza
> 
>   * timevar.c (validate_phases): Use size_t for memory.
>   * timevar.h (struct timevar_time_def): Use size_t for ggc_mem.
> Index: timevar.c
> ===
> --- timevar.c (revision 201919)
> +++ timevar.c (working copy)
> @@ -430,7 +430,7 @@ validate_phases (FILE *fp)
>double phase_user = 0.0;
>double phase_sys = 0.0;
>double phase_wall = 0.0;
> -  unsigned phase_ggc_mem = 0;
> +  size_t phase_ggc_mem = 0;
>static char phase_prefix[] = "phase ";
>const double tolerance = 1.01;  /* One part in a million.  */
>  
> @@ -465,7 +465,7 @@ validate_phases (FILE *fp)
>if (phase_wall > total->wall)
>   fprintf (fp, "wall%24.18e > %24.18e\n", phase_wall, total->wall);
>if (phase_ggc_mem > total->ggc_mem)
> - fprintf (fp, "ggc_mem %24u > %24u\n", phase_ggc_mem, total->ggc_mem);
> + fprintf (fp, "ggc_mem %24lu > %24lu\n", phase_ggc_mem, total->ggc_mem);
>gcc_unreachable ();
>

Won't that cause compilation errors on platforms where size_t is not
unsigned long?

R.

Re: Fix overflows in -ftime-report

[Jan Hubicka]

> >if (phase_wall > total->wall)
> > fprintf (fp, "wall%24.18e > %24.18e\n", phase_wall, total->wall);
> >if (phase_ggc_mem > total->ggc_mem)
> > -   fprintf (fp, "ggc_mem %24u > %24u\n", phase_ggc_mem, total->ggc_mem);
> > +   fprintf (fp, "ggc_mem %24lu > %24lu\n", phase_ggc_mem, total->ggc_mem);
> >gcc_unreachable ();
> >
> 
> Won't that cause compilation errors on platforms where size_t is not
> unsigned long?

You are probably right.  I will add the cast shortly.
Thanks,
Honza
> 
> R.

Re: [C++ patch] Move FINAL flag to middle-end trees.

[Jason Merrill]

On 08/22/2013 05:59 AM, Jan Hubicka wrote:

+/* Nonzero if RECORD_TYPE represents a final derivation of class.  */
+#define TYPE_FINAL_P(NODE) \
+  (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)


How about if we put this flag on the BINFO rather than the type itself?

Jason

Re: [C++ patch] Set attributes for C++ runtime library calls

[Jan Hubicka]

> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > >  - I would like to recall issue if we can make NEW_EXPR annotated with
> > >MALLOC attribute.  Without it, it is basically impossible to track
> > >any dynamically allocated objects in the middle-end
> > 
> > operator new is replaceable by user program.
> 
> But so is malloc?  As I understand, the reason why "malloc" attribute is not
> applicable to operator new is "placement new", which returns aliased memory.

placement new is optimized to nothing, so it should not affect anything here.

MALLOC attribute makes the assumtion that you can not get to the return value of
the function from something that you had previously (i.e. you can not have
existing pointer to that block of memory).  So you can not really implement
malloc in the same compilation unit you are using it.

So the existing program needs to overwrite libsup++ symbol like we do with 
malloc?
Of course with user defineed malloc function we should not propagate the 
attribute,
but I think we could have it when we end up calling the runtime.

Honza
> 
> Alexander

Re: [C++ patch] Move FINAL flag to middle-end trees.

[Jan Hubicka]

> On 08/22/2013 05:59 AM, Jan Hubicka wrote:
> >+/* Nonzero if RECORD_TYPE represents a final derivation of class.  */
> >+#define TYPE_FINAL_P(NODE) \
> >+  (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)
> 
> How about if we put this flag on the BINFO rather than the type itself?
No problem for me.  There is space in type flags and binfo flags, so whatever
seems more suitable.
This option did not occured to me and of course I would be bit fearing of C++ FE
not having binfos ready all the time it wants to touch the type.  But probably
you know if that can happen ;)

Honza
> 
> Jason

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 9:56 AM, Jakub Jelinek  wrote:
> On Thu, Aug 22, 2013 at 09:53:35AM -0500, Gabriel Dos Reis wrote:
>> On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov  
>> wrote:
>> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> >> >  - I would like to recall issue if we can make NEW_EXPR annotated with
>> >> >MALLOC attribute.  Without it, it is basically impossible to track
>> >> >any dynamically allocated objects in the middle-end
>> >>
>> >> operator new is replaceable by user program.
>> >
>> > But so is malloc?
>>
>> no, malloc isn't replaceable.
>
> Is it such a good idea to replace something gcc during bootstrap can
> optimize well (malloc/xmalloc etc.) with something that it can't (operator 
> new)?

I think we may have terminology problems here.

A placement-new, like the one I used in my recent patch, is operationally
the identity function (in addition to informing the alias analyzer about
the beginning of a new object lifetime).

'operator new' is an allocator function.  I didn't use it.

-- Gaby

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 10:21 AM, Jan Hubicka  wrote:
>> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > >  - I would like to recall issue if we can make NEW_EXPR annotated with
>> > >MALLOC attribute.  Without it, it is basically impossible to track
>> > >any dynamically allocated objects in the middle-end
>> >
>> > operator new is replaceable by user program.
>>
>> But so is malloc?  As I understand, the reason why "malloc" attribute is not
>> applicable to operator new is "placement new", which returns aliased memory.
>
> placement new is optimized to nothing, so it should not affect anything here.

Yup.

> MALLOC attribute makes the assumtion that you can not get to the return value 
> of
> the function from something that you had previously (i.e. you can not have
> existing pointer to that block of memory).  So you can not really implement
> malloc in the same compilation unit you are using it.

Exactly.  The same goes for any user allocators -- many of which tend
to be inline,
delegating the hard work to an off-line function.

>
> So the existing program needs to overwrite libsup++ symbol like we do with 
> malloc?
> Of course with user defineed malloc function we should not propagate the 
> attribute,
> but I think we could have it when we end up calling the runtime.

I suspect the question is whether our current infrastructure permits
to distinguish
between declaration of 'operator new' we supply, and 'operator new' defined by
user.  The way we currently arrange for user-defined 'operator new' to take
over is that it is something that is done at linktime, (so is LTO
prepared for this?)
and ours is searched last.

>
> Honza
>>
>> Alexander

Fix OBJ_TYPE_REF handling in ipa-cp

[Jan Hubicka]

Hi,
this problem was noticed by my verifier that binfo walks are not across type
hiearchy. ipa_intraprocedural_devirtualization is one remaining place where we
take class of object from OBJ_TYPE_REF_OBJECT instead of
obj_type_ref_class_type.

Unforutnately I noticed that this problem is propagated quite further across 
ipa-prop
design.  We assume that types of pointers taken from gimple call arguments
are types of pointers to classes pass down to the callee.  This is not true
after propagation.

I did not fix the all places, only places needed to get parameter for
ipa_set_jf_known_type and detect_type_change_ssa right. Also I modified
ipa_set_jf_known_type to not record non-polymorphic type. It is a waste
of memory and LTO streaming bandwidth.

Bootstrapped/regtesed x86_64-linux. Martin, please can you review the change?

* ipa-prop.c (ipa_set_jf_known_type): Check that component type
is a record type with BINFO.
(detect_type_change_ssa):  Add comp_type argument.
(compute_complex_assign_jump_func): Add param_type argument; pass
it down to detect_type_change_ssa.
(compute_known_type_jump_func): Add expected_type parameter.
Do not bother tracking a non-polymorphic type.
(ipa_get_callee_param_type): New function.
(ipa_compute_jump_functions_for_edge): Pass down calle parm types.
(ipa_analyze_virtual_call_uses): Use class typee as argument
of detect_type_change_1.
(ipa_intraprocedural_devirtualization): Pass down class type.
Index: ipa-prop.c
===
--- ipa-prop.c  (revision 201919)
+++ ipa-prop.c  (working copy)
@@ -367,6 +367,8 @@ static void
 ipa_set_jf_known_type (struct ipa_jump_func *jfunc, HOST_WIDE_INT offset,
   tree base_type, tree component_type)
 {
+  gcc_assert (TREE_CODE (component_type) == RECORD_TYPE
+ && TYPE_BINFO (component_type));
   jfunc->type = IPA_JF_KNOWN_TYPE;
   jfunc->value.known_type.offset = offset,
   jfunc->value.known_type.base_type = base_type;
@@ -674,20 +676,18 @@ detect_type_change (tree arg, tree base,
 
 /* Like detect_type_change but ARG is supposed to be a non-dereferenced pointer
SSA name (its dereference will become the base and the offset is assumed to
-   be zero).  */
+   be zero).  COMP_TYPE is type of object being tracked.  */
 
 static bool
-detect_type_change_ssa (tree arg, gimple call, struct ipa_jump_func *jfunc)
+detect_type_change_ssa (tree arg, tree comp_type,
+   gimple call, struct ipa_jump_func *jfunc)
 {
-  tree comp_type;
-
   gcc_checking_assert (TREE_CODE (arg) == SSA_NAME);
   if (!flag_devirtualize
   || !POINTER_TYPE_P (TREE_TYPE (arg))
   || TREE_CODE (TREE_TYPE (TREE_TYPE (arg))) != RECORD_TYPE)
 return false;
 
-  comp_type = TREE_TYPE (TREE_TYPE (arg));
   arg = build2 (MEM_REF, ptr_type_node, arg,
build_int_cst (ptr_type_node, 0));
 
@@ -961,13 +961,16 @@ ipa_load_from_parm_agg (struct ipa_node_
 
INFO is the structure describing individual parameters access different
stages of IPA optimizations.  PARMS_AINFO contains the information that is
-   only needed for intraprocedural analysis.  */
+   only needed for intraprocedural analysis. 
+
+   PARAM_TYPE is type of the parameter, NULL if not available.  */
 
 static void
 compute_complex_assign_jump_func (struct ipa_node_params *info,
  struct param_analysis_info *parms_ainfo,
  struct ipa_jump_func *jfunc,
- gimple call, gimple stmt, tree name)
+ gimple call, gimple stmt, tree name,
+ tree param_type)
 {
   HOST_WIDE_INT offset, size, max_size;
   tree op1, tc_ssa, base, ssa;
@@ -1006,7 +1009,10 @@ compute_complex_assign_jump_func (struct
 gimple_assign_rhs_code (stmt));
}
   else if (gimple_assign_single_p (stmt)
-  && !detect_type_change_ssa (tc_ssa, call, jfunc))
+  && param_type
+  && !detect_type_change_ssa (tc_ssa,
+  TREE_TYPE (param_type),
+  call, jfunc))
{
  bool agg_p = parm_ref_data_pass_through_p (&parms_ainfo[index],
 call, tc_ssa);
@@ -1171,18 +1177,25 @@ compute_complex_ancestor_jump_func (stru
 
 /* Given OP which is passed as an actual argument to a called function,
determine if it is possible to construct a KNOWN_TYPE jump function for it
-   and if so, create one and store it to JFUNC.  */
+   and if so, create one and store it to JFUNC.
+   EXPECTED_TYPE represents a type the argument should be in  */
 
 static void
 compute_known_type_jump_func (tree op, struct ipa_jump_func *jfunc,
- gimple call)
+   

Re: [C++ patch] Set attributes for C++ runtime library calls

[Jan Hubicka]

> >
> > So the existing program needs to overwrite libsup++ symbol like we do with 
> > malloc?
> > Of course with user defineed malloc function we should not propagate the 
> > attribute,
> > but I think we could have it when we end up calling the runtime.
> 
> I suspect the question is whether our current infrastructure permits
> to distinguish
> between declaration of 'operator new' we supply, and 'operator new' defined by
> user.  The way we currently arrange for user-defined 'operator new' to take
> over is that it is something that is done at linktime, (so is LTO
> prepared for this?)

I think so (I am not expert though :))
The operator new we supply is called _Znwm and I want the particular decl with
assembler name _Znwm to have malloc attribute.  I get it right, it is the
declaration we build by

newtype = cp_build_type_attribute_variant (ptr_ftype_sizetype, newattrs);
newtype = build_exception_variant (newtype, new_eh_spec);
deltype = cp_build_type_attribute_variant (void_ftype_ptr, extvisattr);
deltype = build_exception_variant (deltype, empty_except_spec);

push_cp_library_fn (NEW_EXPR, newtype);
push_cp_library_fn (VEC_NEW_EXPR, newtype);

User's new will be different declarations with different assembler name. It is
up to user to care about malloc attributes or whatever.

Aren't user allocator also allowed to make their own exceptions in addition to 
throw (std::bad_alloc);?

Honza
> and ours is searched last.
> 
> >
> > Honza
> >>
> >> Alexander

Re: [C++ patch] Set attributes for C++ runtime library calls

[Alexander Monakov]

On Thu, 22 Aug 2013, Jan Hubicka wrote:

> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > > >  - I would like to recall issue if we can make NEW_EXPR annotated with
> > > >MALLOC attribute.  Without it, it is basically impossible to track
> > > >any dynamically allocated objects in the middle-end
> > > 
> > > operator new is replaceable by user program.
> > 
> > But so is malloc?  As I understand, the reason why "malloc" attribute is not
> > applicable to operator new is "placement new", which returns aliased memory.
> 
> placement new is optimized to nothing, so it should not affect anything here.

Which means you cannot annotate NEW_EXPR with attribute malloc when
-fno-inline is in effect, right?  Because then placement new is no longer
optimized out.  Testcase, compile with -O2 -fno-inline -fno-ipa-sra:

#include 
int foo(void *c)
{
  return *(new (c) int);
}

[Patch, Fortran, OOP] PR 57843: Type-bound assignment is resolved to non-polymorphic procedure call

[Janus Weil]

Hi all,

here is a wrong-code fix for type-bound assignments, which makes sure
that these are resolved to polymorphic procedure calls. This was not
always the case, because we used the wrong ordering when checking for
defined-assignment procedures (looking for non-typebound ones first,
and for typebound ones only afterwards). See in particular comment 3 -
5 in the PR.

The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2013-08-22  Janus Weil  

PR fortran/57843
* interface.c (gfc_extend_assign): Look for type-bound assignment
procedure before non-typebound.


2013-08-22  Janus Weil  

PR fortran/57843
* gfortran.dg/typebound_assignment_7.f90: New.


pr57843.diff
Description: Binary data


typebound_assignment_7.f90
Description: Binary data

Re: [C++ Patch] PR 56380

[Jason Merrill]

OK.

Jason

Re: [PATCH i386 2/8] [AVX512] Add mask registers.

[Richard Henderson]

On 08/22/2013 02:35 AM, Kirill Yukhin wrote:
> Despite of generic OR, mask version of OR do not clobber FLAGS_REG.
> Of course, we may conservatively think that it is, but I believe
> this is not good idea.

I believe that having two different patterns is a worse idea.

You can always split away the clobber after reload, as we do for
when add gets implemented with lea.


r~

Re: [C++ patch] Set attributes for C++ runtime library calls

[Jan Hubicka]

> 
> 
> On Thu, 22 Aug 2013, Jan Hubicka wrote:
> 
> > > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > > > >  - I would like to recall issue if we can make NEW_EXPR annotated with
> > > > >MALLOC attribute.  Without it, it is basically impossible to track
> > > > >any dynamically allocated objects in the middle-end
> > > > 
> > > > operator new is replaceable by user program.
> > > 
> > > But so is malloc?  As I understand, the reason why "malloc" attribute is 
> > > not
> > > applicable to operator new is "placement new", which returns aliased 
> > > memory.
> > 
> > placement new is optimized to nothing, so it should not affect anything 
> > here.
> 
> Which means you cannot annotate NEW_EXPR with attribute malloc when
> -fno-inline is in effect, right?  Because then placement new is no longer
> optimized out.  Testcase, compile with -O2 -fno-inline -fno-ipa-sra:
> 
> #include 
> int foo(void *c)
> {
>   return *(new (c) int);
> }

Yes, this is user provided new oprator, not libsupc++ one. We can't 
automatically make
it MALLOC.

As for LTO question mentioned by Gaby, we currently have notion of runtime
library (i.e.  everything that compiler can autogenerate calls to - libgcc,
libgcov, glibc, ...) and we do not support LTOing those into user programs.  I
think libsupc++ counts in the list.

Getting runtime libraries to be reliably ltoable is interesting problem.  We 
will
need to annotate all functions that can possibly be used by compiler and hold
them until we are sure they are not (i.e. bit what externally_visible+used does
but not quite).

LTOing libsupc++ new (and transtiively malloc) is even trickier, since C 
standard
does not really permit to change type of a block of memory that happens with
malloc/free pair. It is easy to construct programs breaking aliasing rules
with inlined malloc/free implementation (as is with wrong use of placement 
news).
If we will ever LTO it, we will need to have some sort of optimization barrier
on those, so malloc implementation code does not mix with other code in a way
we understand.

Honza

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 10:38 AM, Alexander Monakov  wrote:
> On Thu, 22 Aug 2013, Jan Hubicka wrote:
>
>> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > > >  - I would like to recall issue if we can make NEW_EXPR annotated with
>> > > >MALLOC attribute.  Without it, it is basically impossible to track
>> > > >any dynamically allocated objects in the middle-end
>> > >
>> > > operator new is replaceable by user program.
>> >
>> > But so is malloc?  As I understand, the reason why "malloc" attribute is 
>> > not
>> > applicable to operator new is "placement new", which returns aliased 
>> > memory.
>>
>> placement new is optimized to nothing, so it should not affect anything here.
>
> Which means you cannot annotate NEW_EXPR with attribute malloc when
> -fno-inline is in effect, right?  Because then placement new is no longer
> optimized out.  Testcase, compile with -O2 -fno-inline -fno-ipa-sra:
>
> #include 
> int foo(void *c)
> {
>   return *(new (c) int);
> }

This should be a C++ front-end bug.  The specific operator new
from  used in this placement-new should be folded,
even if -fno-inline.  Jason, is this something easily fixable?

After overload resolution, we know exactly which operator new
we are picking, and we know it is the one coming from the
implementation with its definition.  So we should be good to go.

-- Gaby

Re: [C++ patch] Move FINAL flag to middle-end trees.

[Paolo Carlini]

Hi,

On 08/22/2013 05:22 PM, Jan Hubicka wrote:

On 08/22/2013 05:59 AM, Jan Hubicka wrote:

+/* Nonzero if RECORD_TYPE represents a final derivation of class.  */
+#define TYPE_FINAL_P(NODE) \
+  (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)

How about if we put this flag on the BINFO rather than the type itself?

No problem for me.  There is space in type flags and binfo flags, so whatever
seems more suitable.
This option did not occured to me and of course I would be bit fearing of C++ FE
not having binfos ready all the time it wants to touch the type.  But probably
you know if that can happen ;)
Sorry if I'm saying something rather vague: I suppose you mean 
BINFO_FLAG_6? Because it's the last one. I'm saying this because over 
the last week or so I wondered if we need a bit also to fix c++/15272. 
Can we give that a little thought before making the final (pun intended 
;) decision?


Thanks!
Paolo.

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka  wrote:
>> >
>> > So the existing program needs to overwrite libsup++ symbol like we do with 
>> > malloc?
>> > Of course with user defineed malloc function we should not propagate the 
>> > attribute,
>> > but I think we could have it when we end up calling the runtime.
>>
>> I suspect the question is whether our current infrastructure permits
>> to distinguish
>> between declaration of 'operator new' we supply, and 'operator new' defined 
>> by
>> user.  The way we currently arrange for user-defined 'operator new' to take
>> over is that it is something that is done at linktime, (so is LTO
>> prepared for this?)
>
> I think so (I am not expert though :))
> The operator new we supply is called _Znwm and I want the particular decl with
> assembler name _Znwm to have malloc attribute.  I get it right, it is the
> declaration we build by
>
> newtype = cp_build_type_attribute_variant (ptr_ftype_sizetype, newattrs);
> newtype = build_exception_variant (newtype, new_eh_spec);
> deltype = cp_build_type_attribute_variant (void_ftype_ptr, extvisattr);
> deltype = build_exception_variant (deltype, empty_except_spec);
>
> push_cp_library_fn (NEW_EXPR, newtype);
> push_cp_library_fn (VEC_NEW_EXPR, newtype);
>
> User's new will be different declarations with different assembler name. It is
> up to user to care about malloc attributes or whatever.

For functions that are replaceable, what counts is the provenance of the
*definition*, not just of one its declarations.  The sequence of code that you
show is mandated by C++.  Quoting C++11 3.7.4/2

   The library provides default definitions for the global allocation and
   deallocation functions. Some global allocation and deallocation functions
   are replaceable (18.6.1). A C++ program shall provide at most one
   definition of a replaceable allocation or deallocation function. Any such
   function definition replaces the default version provided in the
library (17.6.4.6).
   The following allocation and deallocation functions (18.6) are implicitly
   declared in global scope in each translation unit of a program.

  void* operator new(std::size_t);
  void* operator new[](std::size_t);
  void operator delete(void*);
  void operator delete[](void*);

   These implicit declarations introduce only the function names operator new,
   operator new[], operator delete, and operator delete[].

So, I think we do need to know the definition site of _Znwm.  If it comes from
the implementation, then we are good to go.  Otherwise, we would need
to proceed carefully.

> Aren't user allocator also allowed to make their own exceptions in addition 
> to throw (std::bad_alloc);?

I suspect so, though I don't think the replacement allocation definitions
are allowed to throw arbitrary exceptions.

-- Gaby

Re: [C++ patch] Set attributes for C++ runtime library calls

[Jan Hubicka]

> 
> This should be a C++ front-end bug.  The specific operator new
> from  used in this placement-new should be folded,
> even if -fno-inline.  Jason, is this something easily fixable?
> 
> After overload resolution, we know exactly which operator new
> we are picking, and we know it is the one coming from the
> implementation with its definition.  So we should be good to go.

Great!  I think this is quite important starting point to get some
heap optimizations done in middle-end :)

Honza

Re: powerpc64le multilibs and multiarch dir

[Alan Modra]

On Thu, Aug 22, 2013 at 10:06:48AM -0400, David Edelsohn wrote:
> On Wed, Aug 21, 2013 at 11:57 PM, Alan Modra  wrote:
> 
> > Index: gcc/config/rs6000/t-linux64
> > ===
> > --- gcc/config/rs6000/t-linux64 (revision 201834)
> > +++ gcc/config/rs6000/t-linux64 (working copy)
> > @@ -25,8 +25,8 @@
> >  # it doesn't tell anything about the 32bit libraries on those systems.  Set
> >  # MULTILIB_OSDIRNAMES according to what is found on the target.
> >
> > -MULTILIB_OPTIONS= m64/m32
> > -MULTILIB_DIRNAMES   = 64 32
> > -MULTILIB_EXTRA_OPTS = fPIC
> > -MULTILIB_OSDIRNAMES= ../lib64$(call if_multiarch,:powerpc64-linux-gnu)
> > -MULTILIB_OSDIRNAMES+= $(if $(wildcard $(shell echo 
> > $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
> > if_multiarch,:powerpc-linux-gnu)
> > +MULTILIB_OPTIONS:= m64/m32
> > +MULTILIB_DIRNAMES   := 64 32
> > +MULTILIB_EXTRA_OPTS :=
> > +MULTILIB_OSDIRNAMES := m64=../lib64$(call 
> > if_multiarch,:powerpc64-linux-gnu)
> > +MULTILIB_OSDIRNAMES += m32=$(if $(wildcard $(shell echo 
> > $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
> > if_multiarch,:powerpc-linux-gnu)
> 
> What is the purpose of the change to MULTILIB_OSDIRNAMES? Why the
> addition of m64= and m32=? A secondary tmake file is not always set to
> post-process those macros, AFAICT.

That m64= is the newer syntax that specifies a mapping from a
MUTLILIB_OPTIONS selection.  And, yes, without another tmake file this
gives us exactly the same result as before.

I needed to use the new syntax to specify the correct os dirs when
adding cross-endian multilibs.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [C++ patch] Set attributes for C++ runtime library calls

[Jan Hubicka]

> On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka  wrote:
> >> >
> >> > So the existing program needs to overwrite libsup++ symbol like we do 
> >> > with malloc?
> >> > Of course with user defineed malloc function we should not propagate the 
> >> > attribute,
> >> > but I think we could have it when we end up calling the runtime.
> >>
> >> I suspect the question is whether our current infrastructure permits
> >> to distinguish
> >> between declaration of 'operator new' we supply, and 'operator new' 
> >> defined by
> >> user.  The way we currently arrange for user-defined 'operator new' to take
> >> over is that it is something that is done at linktime, (so is LTO
> >> prepared for this?)
> >
> > I think so (I am not expert though :))
> > The operator new we supply is called _Znwm and I want the particular decl 
> > with
> > assembler name _Znwm to have malloc attribute.  I get it right, it is the
> > declaration we build by
> >
> > newtype = cp_build_type_attribute_variant (ptr_ftype_sizetype, 
> > newattrs);
> > newtype = build_exception_variant (newtype, new_eh_spec);
> > deltype = cp_build_type_attribute_variant (void_ftype_ptr, extvisattr);
> > deltype = build_exception_variant (deltype, empty_except_spec);
> >
> > push_cp_library_fn (NEW_EXPR, newtype);
> > push_cp_library_fn (VEC_NEW_EXPR, newtype);
> >
> > User's new will be different declarations with different assembler name. It 
> > is
> > up to user to care about malloc attributes or whatever.
> 
> For functions that are replaceable, what counts is the provenance of the
> *definition*, not just of one its declarations.  The sequence of code that you
> show is mandated by C++.  Quoting C++11 3.7.4/2
> 
>The library provides default definitions for the global allocation and
>deallocation functions. Some global allocation and deallocation functions
>are replaceable (18.6.1). A C++ program shall provide at most one
>definition of a replaceable allocation or deallocation function. Any such
>function definition replaces the default version provided in the
> library (17.6.4.6).
>The following allocation and deallocation functions (18.6) are implicitly
>declared in global scope in each translation unit of a program.

This is quite unfortunate.   Thre is nothing standard promise about return
value if this default new?  I.e. can I have something like

int a;
test()
{
  int *b=new (int);
}

with custom implementation of new that returns &a?

While compiling given object file we do not know if the user program happens to
define it somewhere else or not.  Even with LTO I do not think we have
mechanism to recognize statically or dynamically linked libsupc++ (we would
have to LTO _Zwnm that will need to stabilize LTO format to start with).

We probably can go with -fno-user-overwritten-new or something similar?

Honza

Re: [PATCH, AArch64] Fix configure test for AArch64 dwarf2 debug_line

[Paolo Carlini]

.. I'm double checking, but I think that this commit broke the 
bootstrap. I'm seeing:


/scratch/Gcc/svn-dirs/trunk/gcc/configure: line 26121: syntax error near 
unexpected token `newline'
/scratch/Gcc/svn-dirs/trunk/gcc/configure: line 26121: `  aarch64 | 
alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze'

make[1]: *** [configure-gcc] Error 1

Paolo.

Re: [PATCH, AArch64] Fix configure test for AArch64 dwarf2 debug_line

[Paolo Carlini]

.. missing backslashes I would say.

Paolo.

Re: RFA: AVR: Support building AVR Linux targets

[Joseph S. Myers]

On Mon, 12 Aug 2013, Nick Clifton wrote:

> Hi Dennis, Hi Anatoly, Hi Eric,
> 
>   I have run into a small problem building GCC for an AVR Linux target -
>   glibc-c.o is not being built.  It turns out that the section handling
>   "avr-*-*" in the config.gcc file is redefining tmake_file without
>   allowing for the fact that t-glibc has already been added to it.

Your patch itself makes sense on general principles, but the concept of an 
AVR Linux target doesn't - this is an 8-bit processor  Really, the bug 
you've found is that there's an avr-*-* case that is too general, matching 
nonsensical targets such as AVR Linux rather than just avr-*-none / 
avr-*-elf.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 11:16 AM, Jan Hubicka  wrote:
>> On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka  wrote:
>> >> >
>> >> > So the existing program needs to overwrite libsup++ symbol like we do 
>> >> > with malloc?
>> >> > Of course with user defineed malloc function we should not propagate 
>> >> > the attribute,
>> >> > but I think we could have it when we end up calling the runtime.
>> >>
>> >> I suspect the question is whether our current infrastructure permits
>> >> to distinguish
>> >> between declaration of 'operator new' we supply, and 'operator new' 
>> >> defined by
>> >> user.  The way we currently arrange for user-defined 'operator new' to 
>> >> take
>> >> over is that it is something that is done at linktime, (so is LTO
>> >> prepared for this?)
>> >
>> > I think so (I am not expert though :))
>> > The operator new we supply is called _Znwm and I want the particular decl 
>> > with
>> > assembler name _Znwm to have malloc attribute.  I get it right, it is the
>> > declaration we build by
>> >
>> > newtype = cp_build_type_attribute_variant (ptr_ftype_sizetype, 
>> > newattrs);
>> > newtype = build_exception_variant (newtype, new_eh_spec);
>> > deltype = cp_build_type_attribute_variant (void_ftype_ptr, extvisattr);
>> > deltype = build_exception_variant (deltype, empty_except_spec);
>> >
>> > push_cp_library_fn (NEW_EXPR, newtype);
>> > push_cp_library_fn (VEC_NEW_EXPR, newtype);
>> >
>> > User's new will be different declarations with different assembler name. 
>> > It is
>> > up to user to care about malloc attributes or whatever.
>>
>> For functions that are replaceable, what counts is the provenance of the
>> *definition*, not just of one its declarations.  The sequence of code that 
>> you
>> show is mandated by C++.  Quoting C++11 3.7.4/2
>>
>>The library provides default definitions for the global allocation and
>>deallocation functions. Some global allocation and deallocation functions
>>are replaceable (18.6.1). A C++ program shall provide at most one
>>definition of a replaceable allocation or deallocation function. Any such
>>function definition replaces the default version provided in the
>> library (17.6.4.6).
>>The following allocation and deallocation functions (18.6) are implicitly
>>declared in global scope in each translation unit of a program.
>
> This is quite unfortunate.   Thre is nothing standard promise about return
> value if this default new?

Oh, sure, there is.  Again, I am advocating *caution* (in order to support
existing idioms); I am not advocating against.  Concretely, that means we
need to refine your original proposal.  My previous analysis and suggestion
for LTO to be provenance-aware were made in that sense.

> I.e. can I have something like
>
> int a;
> test()
> {
>   int *b=new (int);
> }
>
> with custom implementation of new that returns &a?

If the user-supplied operator new returns &a, then it must
also ensure that 'a' is not used anywhere else -- e.g. I you can't
do lvalue-to-value conversion on 'a' to see what is written there.
Because its storage has been reused.  That is, aliasing is framed
in terms of object lifetime and uniqueness of ownership.

> While compiling given object file we do not know if the user program happens 
> to
> define it somewhere else or not.  Even with LTO I do not think we have
> mechanism to recognize statically or dynamically linked libsupc++ (we would
> have to LTO _Zwnm that will need to stabilize LTO format to start with).

Can we augment _DECLs and LTO to be provenance-aware?   For example,
in libstdc++ we already have pragmas saying that we are in a "system header"
so we don't warn about certain constructs there.  I'm sure my fellow libstdc++
maintainers could be convinced to add a pragma "system implementation" to
implementation files if they are assured that there are tangible
benefits to ripple
from doing that.

There are lot of opportunities for optimizing C++ programs if we can
do that, because
the standard library adds certain restrictions and make certain semantics
guarantees that we can't always expect from arbitrary user program fragments.

> We probably can go with -fno-user-overwritten-new or something similar?

-fno-user-supplied-allocation-function is possible but this is such a particular
case of a huge opportunity that it would be pity if we could just go
the extra mile.

-- Gaby

Re: [PATCH, AArch64] Fix configure test for AArch64 dwarf2 debug_line

[Julian Brown]

On Thu, 22 Aug 2013 18:39:42 +0200
Paolo Carlini  wrote:

> ... I'm testing the below. Works fine so far. I'm going to commit it
> as soon as a bootstrap on x86_64-linux completes again.

Sorry about that, I messed up doing some "harmless" reformatting
whilst preparing the patch :-(.

Thanks for fixing it!

Julian

Re: [PATCH, AArch64] Fix configure test for AArch64 dwarf2 debug_line

[Paolo Carlini]

... I'm testing the below. Works fine so far. I'm going to commit it as 
soon as a bootstrap on x86_64-linux completes again.


Paolo.


Index: configure.ac
===
--- configure.ac(revision 201924)
+++ configure.ac(working copy)
@@ -4219,8 +4219,8 @@ esac
 # ??? Once 2.11 is released, probably need to add first known working
 # version to the per-target configury.
 case "$cpu_type" in
-  aarch64 | alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze
-  | mips | pa | rs6000 | score | sparc | spu | tilegx | tilepro | xstormy16
+  aarch64 | alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze \
+  | mips | pa | rs6000 | score | sparc | spu | tilegx | tilepro | xstormy16 \
   | xtensa)
 insn="nop"
 ;;

Re: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C

[Aldy Hernandez]

On 08/21/13 14:59, Iyer, Balaji V wrote:




-Original Message- From: Aldy Hernandez
[mailto:al...@redhat.com] Sent: Wednesday, August 21, 2013 11:31 AM
To: Iyer, Balaji V Cc: r...@redhat.com; Jeff Law;
gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Cilk Keywords
(_Cilk_spawn and _Cilk_sync) for C

Even more review stuff.  Are you keeping track of all this Balaji?
:)



Yes I am. Please keep an eye out for a fixed patch soon.


+  if (warn) +warning (0, "suspicious use of _Cilk_spawn");


First, as I've mentioned, this error message is very ambiguous. You
should strive to provide better error messages.  See my previous
comment on this same line of code.

However... for all the checking you do in cilk_valid_spawn, I
don't see a single corresponding test.



Well, the name of the function is misleading.  I will fix that. I
think it should call it "detect_cilk_spawn" instead

What the function does it NOT to find whether there are syntax or
other issues in the spawned statement, but to check if spawn is used
in appropriate location. Here are some cases were you can use spawn
(I am sure I am missing something):

X = _Cilk_spawn foo ();

_Cilk_spawn foo ()

operator=(x, _Cilk_spawn foo ())

and these things can be kept in different kind of trees and so
adding this in individual tree's case statement can be a lot of
code-addition and is error prone.


It still sounds like some sort of type checking best done at the source
level.  You can analyze all this in the parser as suggested.  Checking 
if spawn is used in the appropriate location, as you mention, should not 
be done in the gimplifier.


And btw, the reason you have to check all these variants (whether in a a 
MODIFY_EXPR, INIT_EXPR, CALL_EXPR, operator, etc) is because you are 
dealing with trees.  If you handled this as a gimple tuple, things would 
have already been simplified enough for you to only have to worry about 
GIMPLE_CALL.  That being said, I understand it would be more work to 
redesign things to work at the gimple level, but it is something we want 
to do eventually.




The warning you see is more like an "heads up." I can take out of if
you like. If you notice, when I see an error, I don't bother
gimplifying the spawned function (but just let the compiler go ahead
as a regular function call) thereby not creating a new nested
function etc.


No, I don't want you to take it out.  For that matter (as I've suggested 
earlier up-thread), I would like you to expand on this and provide more 
verbose errors/warnings for each of the different things you can catch, 
instead of the the generic "suspicious" warning.





May I stress again the importance of tests-- which are especially
critical for new language features.  You don't want cilk silently
breaking thus rendering all your hard work moot, do you? :))

You particularly need tests for all quirks described in the Cilk
Plus language specification around here:

"A program is considered ill formed if the _Cilk_spawn form of
this expression appears other than in one of the following
contexts: [blah blah blah]".



I have several of those already (e.g. using spawn outside a
function, spawning something that is not a function, etc)


I just didn't see any test for the "suspicious" warning.






+  /* Strip off any conversion to void.  It does not affect
whether spawn + is supported here.  */ +  if (TREE_CODE
(exp) == CONVERT_EXPR && VOID_TYPE_P (TREE_TYPE

(exp)))

+exp = TREE_OPERAND (exp, 0);


Don't you need to strip off various levels here with a loop?
Also, could any of the following do the job? STRIP_NOPS,
STRIP_TYPE_NOPS, STRIP_USELESS_TYPE_CONVERSION.


@@ -7086,6 +7087,19 @@ gimplify_expr (tree *expr_p, gimple_seq
*pre_p,

gimple_seq *post_p,

else if (ret != GS_UNHANDLED) break;

+  if (flag_enable_cilkplus &&
lang_hooks.cilkplus.cilk_valid_spawn (expr_p)) +{ +   /* If
there are errors, there is no point in expanding the +
_Cilk_spawn.  Just gimplify like a normal call expr.  */ +if
(!seen_error ()) +  { +   ret = (enum gimplify_status) +
lang_hooks.cilkplus.gimplify_cilk_spawn (expr_p, pre_p,

post_p);

+ if (ret != GS_UNHANDLED) +continue; + } + 
} +


Oh, hell no!  You do realize you are drilling down and walking
every single expression being passed to the gimplifier to find
your spawn? That's not cool.  You need to find some way to
annotate expressions or do this more efficiently.  It may help to
bootstrap with -fcilkplus and do performance analysis, to make sure
you're not making the compiler slower on the non cilkplus code
path.

Could you not let the gimplifier do its thing and add a case for
CILK_SPAWN_STMT where you do the unwrapping and everything else?
I do realize that cilk_valid_spawn() is doing all sorts of type
checking, and validation, but the gimplifier is really not the
place to do this.  When possible, you should do type checking as
close to the source as possible, thus-- at the pa

RE: RFA: AVR: Support building AVR Linux targets

[Weddington, Eric]

> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Thursday, August 22, 2013 10:37 AM
> To: Nick Clifton
> Cc: cherty...@gmail.com; ae...@post.ru; Weddington, Eric; gcc-
> patc...@gcc.gnu.org
> Subject: Re: RFA: AVR: Support building AVR Linux targets
> 
> On Mon, 12 Aug 2013, Nick Clifton wrote:
> 
> > Hi Dennis, Hi Anatoly, Hi Eric,
> >
> >   I have run into a small problem building GCC for an AVR Linux
> target -
> >   glibc-c.o is not being built.  It turns out that the section
> handling
> >   "avr-*-*" in the config.gcc file is redefining tmake_file without
> >   allowing for the fact that t-glibc has already been added to it.
> 
> Your patch itself makes sense on general principles, but the concept of
> an
> AVR Linux target doesn't - this is an 8-bit processor  Really, the
> bug
> you've found is that there's an avr-*-* case that is too general,
> matching
> nonsensical targets such as AVR Linux rather than just avr-*-none /
> avr-*-elf.

Thanks for pointing that out Joseph.

Strangely, someone actually has run Linux on an AVR:
http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit

But only by running it on an ARM emulator running on the AVR. 

Eric

Re: [PATCH/Merge Request] Vtable Verification feature.

[Joseph S. Myers]

On Mon, 12 Aug 2013, Caroline Tice wrote:

> I have finished my first pass at the porting documentation.  It is now
> available on the vtable verification feature web site:
> http://gcc.gnu.org/wiki/vtv

Please provide the links there in a form that does not require JavaScript 
to read them (in particular, does not require running non-free JavaScript, 
as per GNU Project principles).  That's certainly possible for Google Docs 
documents; you can read 

 
(GCC Architectural Goals) without JavaScript, for example.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 11:08 AM, Jan Hubicka  wrote:
>>
>> This should be a C++ front-end bug.  The specific operator new
>> from  used in this placement-new should be folded,
>> even if -fno-inline.  Jason, is this something easily fixable?
>>
>> After overload resolution, we know exactly which operator new
>> we are picking, and we know it is the one coming from the
>> implementation with its definition.  So we should be good to go.
>
> Great!  I think this is quite important starting point to get some
> heap optimizations done in middle-end :)

In the placement-form, no allocation is done, so the fact that we are
not emitting identity opcode is a bug :-)

The ground for this is (quoting C++11, but this has been true forever)
18.6.1.3/1:

   These functions are reserved, a C++ program may not define functions
   that displace the versions in the Standard C++ library (17.6.4). The
   provisions of (3.7.4) do not apply to these reserved placement forms
   of operator new and operator delete.

 -- Gaby

Re: [PATCH/Merge Request] Vtable Verification feature.

[Caroline Tice]

I was not aware that the links required Javascript.  Can anybody tell
me how to fix them so that they don't?

-- Caroline Tice
cmt...@google.com

On Thu, Aug 22, 2013 at 9:58 AM, Joseph S. Myers
 wrote:
> On Mon, 12 Aug 2013, Caroline Tice wrote:
>
>> I have finished my first pass at the porting documentation.  It is now
>> available on the vtable verification feature web site:
>> http://gcc.gnu.org/wiki/vtv
>
> Please provide the links there in a form that does not require JavaScript
> to read them (in particular, does not require running non-free JavaScript,
> as per GNU Project principles).  That's certainly possible for Google Docs
> documents; you can read
> 
> (GCC Architectural Goals) without JavaScript, for example.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: [RFC] MULTILIB_COMPATIBLE option support in multilib

[Joseph S. Myers]

On Tue, 13 Aug 2013, Ilya Enkovich wrote:

> Any comments on the used approach?

You don't have any documentation (fragments.texi) in your patch.  Apart 
from that, this patch doesn't appear to do anything to engage with all the 
problems of having multiple multilibs in use at once, such as the 
inability of ld to handle multiple sysroots (so the single sysroot 
determined by SYSROOT_SUFFIX_SPEC would just get quietly used), and the 
need to get all search paths for one multilib (for libraries, and, 
separately, for headers) used before any paths for another - those paths 
may be accumulated from multiple specs rather than just a single spec, so 
I don't think anything just locally changing how specs are processed can 
suffice.

Certainly a much more detailed analysis of all the search paths that are 
related to a multilib in some way, and how the driver causes the linker 
and cc1 to search in those paths, and how multiple relevant options get 
processed by the linker and cc1 after being passed to them, would be 
needed to justify that a particular patch does achieve the desired search 
order.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

[Jakub Jelinek]

On Thu, Aug 22, 2013 at 09:39:48AM -0500, Bill Schmidt wrote:
> Hi Christian and Jakub,
> 
> I'm curious whether there was ever any resolution for:
> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.

The last mail I remember didn't make any sense:
#include "tconfig.h"

that includes it:

#ifndef GCC_TCONFIG_H
#define GCC_TCONFIG_H
#ifndef USED_FOR_TARGET
# define USED_FOR_TARGET
#endif
#include "auto-host.h"

in which there is :

#ifndef USED_FOR_TARGET
#define HAVE_SYS_SDT_H 1
#endif

That means USED_FOR_TARGET is defined and thus HAVE_SYS_SDT_H is never
defined, which is not desirable.

Jakub

Re: Request to merge Undefined Behavior Sanitizer in (take 3)

[Marek Polacek]

Ping.

On Thu, Aug 15, 2013 at 05:08:48PM +0200, Marek Polacek wrote:
> I've fixed a few unpleasant bugs; mainly the bug that introduced
> various uninitialized variable warnings was bothersome.
> Now it is possible to do bootstrap with -fsanitize=undefined,
> even though there are some comparison failures at the end.
> 
> v3:
>  - Fix Wuninitialized warnings because of SAVE_EXPRs
>http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00861.html
>  - [ubsan] Add -lpthread to POSTSTAGE1_LDFLAGS
>http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00793.html
>  - [ubsan] Fix assert in c-ubsan.c
>http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00802.html
>  - [ubsan] Properly create const char type
>http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00213.html
> 
> v2:
>  - [ubsan] Add -static-libubsan
>http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01467.html
>  - [ubsan] Don't try to sanitize shifts outside of functions
>http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01468.html
>  - [ubsan] Use build_constructor_va where possible
>http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01469.html
>  - [ubsan] Add bootstrap-ubsan.mk
>http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01470.html
>  - [ubsan] Rename obsolete variable
>http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01473.html
>  - [ubsan] Instrument expr only when doing shift or division
>http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01529.html
>  - [ubsan] Improve documentation of -fsanitize=undefined
>http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01540.html
>  - [ubsan] Add missing ubsan tests in g++.dg/dg.exp
>http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01563.html
> 
> Regtested/bootstrapped on x86_64-linux and ppc64-linux.
> 
> One patch is not in yet, but that isn't anything important:
>http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00376.html
> 
> Ok to merge ubsan into trunk?
> 
>   Marek



Marek

[PATCH, applied] PR57744 -- fix test

[Michael Meissner]

In doing make check, I noticed that I'm now getting warnings from one of the
tests that I wrote for power8 support (pr57744).  I applied this patch as
obvious:

2013-08-22  Michael Meissner  

* gcc.target/powerpc/pr57744.c: Declare abort.

Index: gcc/testsuite/gcc.target/powerpc/pr57744.c
===
--- gcc/testsuite/gcc.target/powerpc/pr57744.c  (revision 201924)
+++ gcc/testsuite/gcc.target/powerpc/pr57744.c  (working copy)
@@ -3,6 +3,8 @@
 /* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-options "-mcpu=power8 -O3" } */
 
+void abort (void);
+
 typedef unsigned U_16 __attribute__((mode(TI)));
 
 extern int libat_compare_exchange_16 (U_16 *, U_16 *, U_16, int, int)

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

[Bill Schmidt]

On Thu, 2013-08-22 at 19:47 +0200, Jakub Jelinek wrote:
> On Thu, Aug 22, 2013 at 09:39:48AM -0500, Bill Schmidt wrote:
> > Hi Christian and Jakub,
> > 
> > I'm curious whether there was ever any resolution for:
> > http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.
> 
> The last mail I remember didn't make any sense:
> #include "tconfig.h"
> 
> that includes it:
> 
> #ifndef GCC_TCONFIG_H
> #define GCC_TCONFIG_H
> #ifndef USED_FOR_TARGET
> # define USED_FOR_TARGET
> #endif
> #include "auto-host.h"
> 
> in which there is :
> 
> #ifndef USED_FOR_TARGET
> #define HAVE_SYS_SDT_H 1
> #endif
> 
> That means USED_FOR_TARGET is defined and thus HAVE_SYS_SDT_H is never
> defined, which is not desirable.
> 
>   Jakub
> 

Yes, that doesn't seem right at all.  OK, thanks.  I'll stick this on a
list as a low-priority item to fix one of these days.

Thanks,
Bill

Re: [PATCH] libitm: Add custom HTM fast path for RTM on x86_64.

[Torvald Riegel]

Attached is an updated patch.  Changes explained below.

On Wed, 2013-08-21 at 10:50 -0700, Richard Henderson wrote:
> > -#if defined(USE_HTM_FASTPATH) && !defined(HTM_CUSTOM_FASTPATH)
> > +#ifdef USE_HTM_FASTPATH
> >// HTM fastpath.  Only chosen in the absence of transaction_cancel to 
> > allow
> >// using an uninstrumented code path.
> >// The fastpath is enabled only by dispatch_htm's method group, which 
> > uses
> > @@ -187,6 +187,7 @@ GTM::gtm_thread::begin_transaction (uint32_t prop, 
> > const gtm_jmpbuf *jb)
> >// indeed in serial mode, and HW transactions should never need serial 
> > mode
> >// for any internal changes (e.g., they never abort visibly to the STM 
> > code
> >// and thus do not trigger the standard retry handling).
> > +#ifndef HTM_CUSTOM_FASTPATH
> >if (likely(htm_fastpath && (prop & pr_hasNoAbort)))
> >  {
> >for (uint32_t t = htm_fastpath; t; t--)
> > @@ -237,6 +238,49 @@ GTM::gtm_thread::begin_transaction (uint32_t prop, 
> > const gtm_jmpbuf *jb)
> > }
> > }
> >  }
> > +#else
> > +  // If we have a custom HTM fastpath in ITM_beginTransaction, we implement
> > +  // just the retry policy here.  We communicate with the custom fastpath
> 
> Don't you want this logic arranged as
> 
> #ifdef HTM_CUSTOM_FASTPATH
>  ... your new code
> #elif defined(USE_HTM_FASTPATH)
>  ... existing htm code
> #endif

It seems you didn't feel strongly about it (and neither do I), so I kept
this as is.  The current code arrangement has the advantage that the
general HTM fastpath comes first, and second the stuff for the custom,
more complex fastpath variants.

> > -   subq$56, %rsp
> > -   cfi_def_cfa_offset(64)
> > +   subq$64, %rsp
> > +   cfi_def_cfa_offset(72)
> 
> You now have an abi-misaligned stack.  Since the return address is pushed by
> the call, an aligned stack frame allocation is (N + 8) % 16 == 0.

Fixed, and added more suggestions by Richard.  We also discussed
splitting the xbegin into two paths, one for the first HTM abort --
where we'd save the jmpbuf -- and one for subsequent aborts -- where we
wouldn't need to save the jmpbuf.  But given that we only save the
jmpbuf when either going to non-HTM or after an HTM abort, the overheads
didn't seem to matter enough to justify the added complexity.

> > +  // Accessed from assembly language, thus the "asm" specifier on
> > +  // the name, avoiding complex name mangling.
> > +#ifdef __USER_LABEL_PREFIX__
> > +#define UPFX1(t) UPFX(t)
> > +#define UPFX(t) #t
> > +  static gtm_rwlock serial_lock
> > +__asm__(UPFX1(__USER_LABEL_PREFIX__) "gtm_serial_lock");
> > +#else
> > +  static gtm_rwlock serial_lock
> > +__asm__("gtm_serial_lock");
> > +#endif
> 
> Now that we have 3 copies of this, we should simplify things.  E.g.
> 
> #ifdef __USER_LABEL_PREFIX__
> # define UPFX1(X) #X
> # define UPFX UPFX1(__USER_LABEL_PREFIX__)
> #else
> # define UPFX
> #endif
> 
> static gtm_rwlock serial_lock __asm__(UPFX "gtm_serial_lock");

Fixed (including the one additional indirection that was necessary ;) ).

OK for trunk?
commit 428aa3302c5674326585f178409f734222edfa8b
Author: Torvald Riegel 
Date:   Wed Aug 21 11:40:54 2013 +0200

Add custom HTM fast path for RTM on x86_64.

* libitm_i.h (gtm_thread): Assign an asm name to serial_lock.
(htm_fastpath): Assign an asm name.
* libitm.h (_ITM_codeProperties): Add non-ABI flags used by custom
HTM fast paths.
(_ITM_actions): Likewise.
* config/x86/target.h (HTM_CUSTOM_FASTPATH): Enable custom fastpath on
x86_64.
* config/x86/sjlj.S (_ITM_beginTransaction): Add custom HTM fast path.
* config/posix/rwlock.h (gtm_rwlock): Update comments.  Move summary
field to the start of the structure.
* config/linux/rwlock.h (gtm_rwlock): Update comments.
* beginend.cc (gtm_thread::begin_transaction): Add retry policy
handling for custom HTM fast paths.

diff --git a/libitm/beginend.cc b/libitm/beginend.cc
index a3bf549..bd7b19e 100644
--- a/libitm/beginend.cc
+++ b/libitm/beginend.cc
@@ -165,7 +165,7 @@ GTM::gtm_thread::begin_transaction (uint32_t prop, const 
gtm_jmpbuf *jb)
   if (unlikely(prop & pr_undoLogCode))
 GTM_fatal("pr_undoLogCode not supported");
 
-#if defined(USE_HTM_FASTPATH) && !defined(HTM_CUSTOM_FASTPATH)
+#ifdef USE_HTM_FASTPATH
   // HTM fastpath.  Only chosen in the absence of transaction_cancel to allow
   // using an uninstrumented code path.
   // The fastpath is enabled only by dispatch_htm's method group, which uses
@@ -187,6 +187,7 @@ GTM::gtm_thread::begin_transaction (uint32_t prop, const 
gtm_jmpbuf *jb)
   // indeed in serial mode, and HW transactions should never need serial mode
   // for any internal changes (e.g., they never abort visibly to the STM code
   // and thus do not trigger the standard retry handling).
+#ifndef HTM_CUSTOM_FASTPATH
   if (likely(htm_fastpath && (prop & pr_hasNoAbort)))
 {
 

Re: [PATCH i386 1/8] [AVX512] Adjust register classes.

[Kirill Yukhin]

Hello,

On 21 Aug 13:02, Richard Henderson wrote:
> On 08/21/2013 11:28 AM, Kirill Yukhin wrote:
> > (eq_attr "alternative" "12,13")
> > - (cond [(ior (not (match_test "TARGET_SSE2"))
> > + (cond [(ior (match_test "EXT_REX_SSE_REGNO_P (REGNO 
> > (operands[0]))")
> > + (and (match_test "REG_P (operands[1])")
> > +  (match_test "EXT_REX_SSE_REGNO_P (REGNO 
> > (operands[1]))")))
> > +  (const_string "XI")
> > +(ior (not (match_test "TARGET_SSE2"))
> >   (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL"))
> >(const_string "V4SF")
> >  (match_test "TARGET_AVX")
> 
> Better.  And while it produces the correct results, using match_operand would
> be better than embedding a reference to operands within a match_test.

In order to get rid of direct references to operands in attrs
of scalar mov*_internal I've introduced new predicate and use it with
match_operand instead.

ChangeLog:
2013-08-22  Kirill Yukhin  

* gcc/config/i386/i386.md (*movti_internal): Use
predicate to determine if EVEX is needed.
(*movsi_internal): Ditto.
(*movdf_internal): Ditto.
(*movsf_internal): Ditto.
* gcc/config/i386/mmx.md (*mov_internal): Ditto.

Testing:
  1. Bootstrap pass.
  2. make check shows no regressions.
  3. Spec 2000 & 2006 build show no regressions both with and without -mavx512f 
option.
  4. Spec 2000 & 2006 run shows no stability regressions without -mavx512f 
option.

Is it ok to install to trunk?

--
Thanks, K

---
 gcc/config/i386/i386.md   | 20 
 gcc/config/i386/mmx.md|  5 ++---
 gcc/config/i386/predicates.md |  6 ++
 3 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index b55fd6f..3d7533a 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2059,9 +2059,8 @@
  (cond [(eq_attr "alternative" "2")
  (const_string "SI")
(eq_attr "alternative" "12,13")
- (cond [(ior (match_test "EXT_REX_SSE_REGNO_P (REGNO 
(operands[0]))")
- (and (match_test "REG_P (operands[1])")
-  (match_test "EXT_REX_SSE_REGNO_P (REGNO 
(operands[1]))")))
+ (cond [(ior (match_operand 0 "ext_sse_reg_operand")
+ (match_operand 1 "ext_sse_reg_operand"))
   (const_string "XI")
 (ior (not (match_test "TARGET_SSE2"))
  (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL"))
@@ -2192,9 +2191,8 @@
  (cond [(eq_attr "alternative" "2,3")
  (const_string "DI")
(eq_attr "alternative" "6,7")
- (cond [(ior (match_test "EXT_REX_SSE_REGNO_P (REGNO 
(operands[0]))")
- (and (match_test "REG_P (operands[1])")
-  (match_test "EXT_REX_SSE_REGNO_P (REGNO 
(operands[1]))")))
+ (cond [(ior (match_operand 0 "ext_sse_reg_operand")
+ (match_operand 1 "ext_sse_reg_operand"))
   (const_string "XI")
 (ior (not (match_test "TARGET_SSE2"))
  (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL"))
@@ -2923,9 +2921,8 @@
 
   /* movaps is one byte shorter for non-AVX targets.  */
   (eq_attr "alternative" "10,14")
-(cond [(ior (match_test "EXT_REX_SSE_REGNO_P (REGNO 
(operands[0]))")
-(and (match_test "REG_P (operands[1])")
- (match_test "EXT_REX_SSE_REGNO_P (REGNO 
(operands[1]))")))
+(cond [(ior (match_operand 0 "ext_sse_reg_operand")
+(match_operand 1 "ext_sse_reg_operand"))
  (const_string "V8DF")
(ior (not (match_test "TARGET_SSE2"))
 (match_test 
"TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL"))
@@ -3072,9 +3069,8 @@
  better to maintain the whole registers in single format
  to avoid problems on using packed logical operations.  */
   (eq_attr "alternative" "6")
-(cond [(ior (match_test "EXT_REX_SSE_REGNO_P (REGNO 
(operands[0]))")
-(and (match_test "REG_P (operands[1])")
- (match_test "EXT_REX_SSE_REGNO_P (REGNO 
(operands[1]))")))
+(cond [(ior  (match_operand 0 "ext_sse_reg_operand")
+ (match_operand 1 "ext_sse_reg_operand"))
  (const_string "V16SF")
(ior (match_test "TARGET_SSE_PARTIAL_REG_DEPENDENCY")
 (match_test "TARGET_SSE_SPLIT_REGS"))
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 681cdb7..17e2499 100644
--- a/gcc

Re: Request to merge Undefined Behavior Sanitizer in (take 3)

[Marek Polacek]

On Thu, Aug 22, 2013 at 07:51:07PM +0200, Marek Polacek wrote:
> Ping.

I'm withdrawing the ping for now.  I'll have to deal with some bootstrap
comparison failures first (ugh!).

Marek

Re: [PATCH] libitm: Add custom HTM fast path for RTM on x86_64.

[Richard Henderson]

On 08/22/2013 11:39 AM, Torvald Riegel wrote:
> + /* Store edi for future HTM fast path retries.  We use a stack slot
> +lower than the jmpbuf so that the jmpbuf's rip field will overlap
> +with the proper return address on the stack.  */
> + movl%edi, -64(%rsp)

You havn't allocated the stack frame here, and you're storing
outside the redzone.  This is invalid.

Two possibilities:

 (1) always allocate the stack frame on entry to
 the function (adds two register additions to
 the htm fast path -- in the noise i'd think)

 (2) store the edi value in the non-htm path, with
 the pr_HTMRetryableAbort bit or'd in.  (adds an
 extra store to the non-htm path; probably noise).
 You'd want to mask out that bit when you reload it.


r~

Re: [PATCH i386 1/8] [AVX512] Adjust register classes.

[Richard Henderson]

On 08/22/2013 11:56 AM, Kirill Yukhin wrote:
> ChangeLog:
> 2013-08-22  Kirill Yukhin  
> 
>   * gcc/config/i386/i386.md (*movti_internal): Use
>   predicate to determine if EVEX is needed.
>   (*movsi_internal): Ditto.
>   (*movdf_internal): Ditto.
>   (*movsf_internal): Ditto.
>   * gcc/config/i386/mmx.md (*mov_internal): Ditto.


Ok.


r~

Re: [PATCH i386 1/8] [AVX512] Adjust register classes.

[H.J. Lu]

On Thu, Aug 22, 2013 at 12:06 PM, Richard Henderson  wrote:
> On 08/22/2013 11:56 AM, Kirill Yukhin wrote:
>> ChangeLog:
>> 2013-08-22  Kirill Yukhin  
>>
>>   * gcc/config/i386/i386.md (*movti_internal): Use
>>   predicate to determine if EVEX is needed.
>>   (*movsi_internal): Ditto.
>>   (*movdf_internal): Ditto.
>>   (*movsf_internal): Ditto.
>>   * gcc/config/i386/mmx.md (*mov_internal): Ditto.
>
>
> Ok.
>
>
> r~

ChangeLog entry for ext_sse_reg_operand is missing.

-- 
H.J.

[Patch] Fix infinite loop/crash if array initializer index equals max value

[Selvaraj, Senthil_Kumar]

Hi,

This line of code causes gcc for the AVR target to loop 
for a while and eventually crash after exhausting virtual memory.

   char x[] = { [0xFF] = 2 };
   
output_pending_init_elements in gcc/c/c-typeck.c ends up in an
infinite loop if elt->purpose is a tree representing an integer
constant equal to max value of TREE_TYPE(constructor_unfilled_index).
For the AVR, that's 0xFF (PSI mode). 

This happens because output_init_element, in addition to recording
the initialization in a collection, logically increments
constructor_unfilled_index (by generating a size_binop_loc with a
PLUS_EXPR and a int const node representing the number 1, followed by
a fold and a forcefit to the type). This obviously causes a overflow 
if the tree passed in represents an integer constant that's already at 
the max limit.
   
This is not handled in the body of the while (elt) loop, and
constructor_unfilled_index keeps alternating between trees
representing 0 and 0xFF (max value), eventually running out of 
memory and crashing.
   
I tried to reproduce the problem for x86_64, but I get an ICE even
before output_pending_init_elements is called, apparently because
of PR 57821.
   
The below patch fixes the code to not consider an overflowed 
constructor_unfilled_index to be less than elt->purpose.
   
Is this ok?
   
Regards
Senthil

gcc/c/ChangeLog
2013-08-23  Senthil Kumar Selvaraj  
* c-typeck.c (output_pending_init_elements): Handle overflow of
constructor_unfilled_index.


diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index d9ae01c..f87c2a0 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -7953,8 +7953,9 @@ output_pending_init_elements (int all, struct obstack * 
braced_init_obstack)
 TREE_TYPE (constructor_type),
 constructor_unfilled_index, 0, false,
 braced_init_obstack);
- else if (tree_int_cst_lt (constructor_unfilled_index,
-   elt->purpose))
+ else if (!TREE_OVERFLOW_P (constructor_unfilled_index)
+  && tree_int_cst_lt (constructor_unfilled_index, 
+  elt->purpose))
{
  /* Advance to the next smaller node.  */
  if (elt->left)
@@ -7979,7 +7980,8 @@ output_pending_init_elements (int all, struct obstack * 
braced_init_obstack)
  while (elt->parent && elt->parent->right == elt)
elt = elt->parent;
  elt = elt->parent;
- if (elt && tree_int_cst_lt (constructor_unfilled_index,
+ if (elt && !TREE_OVERFLOW_P (constructor_unfilled_index)
+ && tree_int_cst_lt (constructor_unfilled_index,
  elt->purpose))
{
  next = elt->purpose;

Re: [patch][PR/42955] Don't install $(target)/bin/gcc, gfortran, etc.

[Brooks Moses]

Ping?

On 08/08/2013 02:10 PM, Brooks Moses wrote:

As discussed in PR/42955, when GCC is built as a cross-compiler, it
will install "gcc", "g++", "c++", and "gfortran" binaries in
$(target)/bin, as well as installing the $target-gcc and so forth in
bin.  However, these binaries in $(target)/bin do not work; they
cannot find libexec.

More to the point, this bug has been open for three years with no
traffic, and the failure started significantly before that.  Clearly,
making these work is not a priority.  Further, these binaries are real
files, not symlinks or hard links; they take up actual space.

As discussed on the bug, Joseph argues that $(target)/bin "contains
executables from binutils for internal use by GCC; that's its sole
purpose. The files installed by GCC there aren't used by GCC (rather,
the public installed copy of the driver gets used when collect2 needs
to call back to the driver), so shouldn't be installed."

Thus, this patch, which simply removes these broken executables.
Tested by building a cross-compiler and confirming that they are gone,
and by building a native compiler and confirming that the expected
bin/gcc, bin/g++, bin/c++, and bin/gfortran are still present.

Ok to commit?

- Brooks


2013-08-08  Brooks Moses  

 PR driver/42955
 * Makefile.in: Do not install driver binaries in $(target)/bin.

 PR driver/42955
 * Make-lang.in: Do not install driver binaries in $(target)/bin.

Re: [C++ patch] Set attributes for C++ runtime library calls

[Mike Stump]

On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis  
wrote:
>> I.e. can I have something like
>> 
>> int a;
>> test()
>> {
>>  int *b=new (int);
>> }
>> 
>> with custom implementation of new that returns &a?
> 
> If the user-supplied operator new returns &a, then it must
> also ensure that 'a' is not used anywhere else -- e.g. I you can't
> do lvalue-to-value conversion on 'a' to see what is written there.

This is wrong, in the c++97 standard there is no such limitation or restriction.

> Because its storage has been reused.  That is, aliasing is framed
> in terms of object lifetime and uniqueness of ownership.

Nope, this is wrong.  Example:

int i, j;

main() {
i = 1;
j = i;


i = 2;
char *cpi = (char*)&i;
char *cpj = (char*)&j;
for (k= 0; k < sizeof (int); ++k)
cpj[k] = cpi[k];
}

This is well defined.  i and j exist, as do the character objects that are 
pointed to by cpi and cpj.  One can use them and interleave them, they can 
alias, and the character objects are not unique from i and j.

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump  wrote:
> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis  
> wrote:
>>> I.e. can I have something like
>>>
>>> int a;
>>> test()
>>> {
>>>  int *b=new (int);
>>> }
>>>
>>> with custom implementation of new that returns &a?
>>
>> If the user-supplied operator new returns &a, then it must
>> also ensure that 'a' is not used anywhere else -- e.g. I you can't
>> do lvalue-to-value conversion on 'a' to see what is written there.
>
> This is wrong, in the c++97 standard there is no such limitation or 
> restriction.

Please, elaborate.

>
>> Because its storage has been reused.  That is, aliasing is framed
>> in terms of object lifetime and uniqueness of ownership.
>
> Nope, this is wrong.  Example:
>
> int i, j;
>
> main() {
> i = 1;
> j = i;
>
>
> i = 2;
> char *cpi = (char*)&i;
> char *cpj = (char*)&j;
> for (k= 0; k < sizeof (int); ++k)
> cpj[k] = cpi[k];
> }
>
> This is well defined.  i and j exist, as do the character objects that are 
> pointed to by cpi and cpj.  One can use them and interleave them, they can 
> alias, and the character objects are not unique from i and j.
>

but, this isn't what we are talking  about -- that pointers to
character types can
alias pretty much anything is admitted and isn't under debate; GCC already copes
with that.

-- Gaby

Re: [patch, Fortran] PR 58146, enable array slice compile-time bounds checking

[Mikael Morin]

Le 14/08/2013 23:46, Thomas Koenig a écrit :
> Hello world,
> 
> the attached patch enables more sophisticated bounds-checking on
> array slices by using gfc_dep_difference to calculate extents.
> The information may also be useful in other places of the
> front end, I don't really know.
> 
> There is one wrinkle (alluded to in the comments) which makes
> this harder.  When somebody changes the value of a variable
> used in detemining the size of an array, such as
> 
> subroutine foo(a,n)
>   real, dimension(n) :: a
> 
>   n = n -2
> 
>   print *,ubound(a(n-1:))
> 
> we cannot compare n-1 against n and think that their difference is
> one :-(
> 
> This is why I restricted myself to expressions where all
> indices are specified, e.g. in a(n+1:n+4) or none are specified,
> as in a(:).
> 
> In order for this to work on 64-bit systems, it was necessary
> to look through widening integer conversions, so I added that
> functionality to discard_nops.  Using this function in
> gfc_dep_compare_expr made this function shorter and cleaner.
> 
> Regression-tested.  OK for trunk?
> 
This looks mostly good.  The dependency.c cleanup is nice, I have yet to
understand what the 'end == NULL' condition is for.  I come back to you
soon.

Mikael

Re: [Patch, Fortran, OOP] PR 57843: Type-bound assignment is resolved to non-polymorphic procedure call

[Mikael Morin]

Le 22/08/2013 17:41, Janus Weil a écrit :
> Hi all,
> 
> here is a wrong-code fix for type-bound assignments, which makes sure
> that these are resolved to polymorphic procedure calls. This was not
> always the case, because we used the wrong ordering when checking for
> defined-assignment procedures (looking for non-typebound ones first,
> and for typebound ones only afterwards). See in particular comment 3 -
> 5 in the PR.
> 
> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
> 
OK.  Thanks.

Mikael

Re: [PATCH/Merge Request] Vtable Verification feature.

[Caroline Tice]

I believe I have figured this out and fixed the problem.  If you are
still seeing the issue, please let me know.

-- Caroline Tice
cmt...@google.com

On Thu, Aug 22, 2013 at 10:07 AM, Caroline Tice  wrote:
> I was not aware that the links required Javascript.  Can anybody tell
> me how to fix them so that they don't?
>
> -- Caroline Tice
> cmt...@google.com
>
> On Thu, Aug 22, 2013 at 9:58 AM, Joseph S. Myers
>  wrote:
>> On Mon, 12 Aug 2013, Caroline Tice wrote:
>>
>>> I have finished my first pass at the porting documentation.  It is now
>>> available on the vtable verification feature web site:
>>> http://gcc.gnu.org/wiki/vtv
>>
>> Please provide the links there in a form that does not require JavaScript
>> to read them (in particular, does not require running non-free JavaScript,
>> as per GNU Project principles).  That's certainly possible for Google Docs
>> documents; you can read
>> 
>> (GCC Architectural Goals) without JavaScript, for example.
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com

Re: [Patch, Fortran, OOP] PR 57305: ICE when calling SIZEOF on an unlimited polymorphic variable

[Mikael Morin]

Hello,

Le 22/08/2013 15:20, Janus Weil a écrit :
> Hi all,
> 
> the SIZEOF intrinsic currently returns the size according to the
> *declared* type for polymorphic variables. I think this doesn't really
> make much sense and it also causes ICEs when SIZEOF is called on
> CLASS(*) variables (which don't really have a declared type).
> Therefore I'm proposing to make SIZEOF return the size according to
> the *dynamic* type instead. The same is done by STORAGE_SIZE (F08),
> which however gives the size in bits. SIZEOF is a GNU extension, so we
> are free to decide on its behavior. I don't remember why the declared
> type was chosen in the first place, and I hope that no one seriously
> depends on the current behavior (the size of the declared type is
> probably not really useful after all).
> 
I'm slightly inclined to kindly invite the user to switch to
STORAGE_SIZE+SIZE instead.  Any other opinion?

> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
> 
Independently of the above, the patch seems to be forgetting the
arg->rank != 0 case.

Mikael

Re: [PATCH] libitm: Add custom HTM fast path for RTM on x86_64.

[Torvald Riegel]

On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
> On 08/22/2013 11:39 AM, Torvald Riegel wrote:
> > +   /* Store edi for future HTM fast path retries.  We use a stack slot
> > +  lower than the jmpbuf so that the jmpbuf's rip field will overlap
> > +  with the proper return address on the stack.  */
> > +   movl%edi, -64(%rsp)
> 
> You havn't allocated the stack frame here, and you're storing
> outside the redzone.  This is invalid.
> 
> Two possibilities:
> 
>  (1) always allocate the stack frame on entry to
>  the function (adds two register additions to
>  the htm fast path -- in the noise i'd think)
> 
>  (2) store the edi value in the non-htm path, with
>  the pr_HTMRetryableAbort bit or'd in.  (adds an
>  extra store to the non-htm path; probably noise).
>  You'd want to mask out that bit when you reload it.

Oops.  Picked fix (2).  Better now?
commit 42a3defc64d28dc2c96f5bbdf8547e5b7bd9a40b
Author: Torvald Riegel 
Date:   Wed Aug 21 11:40:54 2013 +0200

Add custom HTM fast path for RTM on x86_64.

* libitm_i.h (gtm_thread): Assign an asm name to serial_lock.
(htm_fastpath): Assign an asm name.
* libitm.h (_ITM_codeProperties): Add non-ABI flags used by custom
HTM fast paths.
(_ITM_actions): Likewise.
* config/x86/target.h (HTM_CUSTOM_FASTPATH): Enable custom fastpath on
x86_64.
* config/x86/sjlj.S (_ITM_beginTransaction): Add custom HTM fast path.
* config/posix/rwlock.h (gtm_rwlock): Update comments.  Move summary
field to the start of the structure.
* config/linux/rwlock.h (gtm_rwlock): Update comments.
* beginend.cc (gtm_thread::begin_transaction): Add retry policy
handling for custom HTM fast paths.

diff --git a/libitm/beginend.cc b/libitm/beginend.cc
index a3bf549..bd7b19e 100644
--- a/libitm/beginend.cc
+++ b/libitm/beginend.cc
@@ -165,7 +165,7 @@ GTM::gtm_thread::begin_transaction (uint32_t prop, const 
gtm_jmpbuf *jb)
   if (unlikely(prop & pr_undoLogCode))
 GTM_fatal("pr_undoLogCode not supported");
 
-#if defined(USE_HTM_FASTPATH) && !defined(HTM_CUSTOM_FASTPATH)
+#ifdef USE_HTM_FASTPATH
   // HTM fastpath.  Only chosen in the absence of transaction_cancel to allow
   // using an uninstrumented code path.
   // The fastpath is enabled only by dispatch_htm's method group, which uses
@@ -187,6 +187,7 @@ GTM::gtm_thread::begin_transaction (uint32_t prop, const 
gtm_jmpbuf *jb)
   // indeed in serial mode, and HW transactions should never need serial mode
   // for any internal changes (e.g., they never abort visibly to the STM code
   // and thus do not trigger the standard retry handling).
+#ifndef HTM_CUSTOM_FASTPATH
   if (likely(htm_fastpath && (prop & pr_hasNoAbort)))
 {
   for (uint32_t t = htm_fastpath; t; t--)
@@ -237,6 +238,49 @@ GTM::gtm_thread::begin_transaction (uint32_t prop, const 
gtm_jmpbuf *jb)
}
}
 }
+#else
+  // If we have a custom HTM fastpath in ITM_beginTransaction, we implement
+  // just the retry policy here.  We communicate with the custom fastpath
+  // through additional property bits and return codes, and either transfer
+  // control back to the custom fastpath or run the fallback mechanism.  The
+  // fastpath synchronization algorithm itself is the same.
+  // pr_HTMRetryableAbort states that a HW transaction started by the custom
+  // HTM fastpath aborted, and that we thus have to decide whether to retry
+  // the fastpath (returning a_tryHTMFastPath) or just proceed with the
+  // fallback method.
+  if (likely(htm_fastpath && (prop & pr_HTMRetryableAbort)))
+{
+  tx = gtm_thr();
+  if (unlikely(tx == NULL))
+{
+  // See below.
+  tx = new gtm_thread();
+  set_gtm_thr(tx);
+}
+  // If this is the first abort, reset the retry count.  We abuse
+  // restart_total for the retry count, which is fine because our only
+  // other fallback will use serial transactions, which don't use
+  // restart_total but will reset it when committing.
+  if (!(prop & pr_HTMRetriedAfterAbort))
+   tx->restart_total = htm_fastpath;
+
+  if (--tx->restart_total > 0)
+   {
+ // Wait until any concurrent serial-mode transactions have finished.
+ // Essentially the same code as above.
+ if (serial_lock.is_write_locked())
+   {
+ if (tx->nesting > 0)
+   goto stop_custom_htm_fastpath;
+ serial_lock.read_lock(tx);
+ serial_lock.read_unlock(tx);
+   }
+ // Let ITM_beginTransaction retry the custom HTM fastpath.
+ return a_tryHTMFastPath;
+   }
+}
+ stop_custom_htm_fastpath:
+#endif
 #endif
 
   tx = gtm_thr();
diff --git a/libitm/config/linux/rwlock.h b/libitm/config/linux/rwlock.h
index 428299f..c761edf 100644
--- a/libitm/config/linux/rwlock.h
+++ b/libitm/config/linux/rwlock.h
@@ -39,6 +39,11 @@ struct

Re: [RFC] Issues with intraprocedural devirtualization

[Jan Hubicka]

Hi,
I went through some statistics on firefox build (it is a source combining many 
coding styles).
I was basically curious where we do devirtualization.  The result is:

Before inline (i.e. important devirtualization)
624 ssa-pre devirt 0
this is interaprocedural devirutalization happening during early FRE by 
propagating
constant accesses into vtables entries. (i.e. not type based at all)

 10 ssa-pre devirt2 0
this is type based intraprocedural analysis during early optimizations
177 ipa-prop devirt
devirtualization in ipa-cp
243 ipa-cp inline devirt
this is devirtualization happening at IPA stage during inlining

After inline (i.e. devirtualization where we missed the chance to do something 
useful)
 82 gimple-fold devirt 1
this is the gimple-fold function in question (it also run pre-inline 
but apparently
always fail.  I will try the proposed patch and sed updated stats 
tomorrow)

 27 ipa-prop intra devirt 1
intraprocedural type based analysis
   1569 ssa-pre devirt 1
this is interaprocedural devirutalization happening during late FRE 
(not type based)

So overall type based analyssi accounts 430 devirtualizations pre-inline and 
109 post inline.
Low level propagation of vtable accesses gets 624 pre-inline and 1569 post 
inline.

Obviously the post inline numbers shows that we miss majority of interesting 
cases.
I hope we can noticeably improve this.

I am re-building with the proposed change now.

Honza

[GOOGLE] Update AutoFDO annotation

[Dehao Chen]

This patch has 2 changes:

1. Now that we have discriminator for inlined callsite, we don't need
special handling for callsite location any more.
2. If a source line is mapped to multiple BBs, only the first BB will
be annotated.
3. Before actual annotation, mark everythin BB/edge as not annotated.

Bootstrapped and passed regression test.

OK for google branch?

Thanks,
Dehao

Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 201927)
+++ gcc/auto-profile.c (working copy)
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.  If not see
 #include 
 #include 
 #include 
+#include 

 #include "config.h"
 #include "system.h"
@@ -100,6 +101,10 @@ typedef std::map icall_target
(execution_count, value_profile_histogram).  */
 typedef std::pair count_info;

+/* Set of inline_stack. Used to track if the profile is already used to
+   annotate the program.  */
+typedef std::set location_set;
+
 struct string_compare
 {
   bool operator() (const char *a, const char *b) const
@@ -202,7 +207,8 @@ class autofdo_source_profile {
   const function_instance *get_function_instance_by_decl (tree decl) const;
   /* Find profile info for a given gimple STMT. If found, store the profile
  info in INFO, and return true; otherwise return false.  */
-  bool get_count_info (gimple stmt, count_info *info) const;
+  bool get_count_info (gimple stmt, count_info *info,
+   const location_set *set) const;
   /* Find total count of the callee of EDGE.  */
   gcov_type get_callsite_total_count (struct cgraph_edge *edge) const;

@@ -284,17 +290,13 @@ static const char *get_original_name (const char *

 /* Return the combined location, which is a 32bit integer in which
higher 16 bits stores the line offset of LOC to the start lineno
-   of DECL, The lower 16 bits stores the discrimnator of LOC if
-   USE_DISCR is true, otherwise 0.  */
+   of DECL, The lower 16 bits stores the discrimnator.  */

 static unsigned
-get_combined_location (location_t loc, tree decl, bool use_discr)
+get_combined_location (location_t loc, tree decl)
 {
-  if (use_discr)
-return ((LOCATION_LINE (loc) - DECL_SOURCE_LINE (decl)) << 16)
-   | get_discriminator_from_locus (loc);
-  else
-return (LOCATION_LINE (loc) - DECL_SOURCE_LINE (decl)) << 16;
+  return ((LOCATION_LINE (loc) - DECL_SOURCE_LINE (decl)) << 16)
+ | get_discriminator_from_locus (loc);
 }

 /* Return the function decl of a given lexical BLOCK.  */
@@ -316,7 +318,7 @@ get_function_decl_from_block (tree block)
 }

 static void
-get_inline_stack (gimple stmt, bool use_discr, inline_stack *stack)
+get_inline_stack (gimple stmt, inline_stack *stack)
 {
   location_t locus = gimple_location (stmt);
   if (LOCATION_LOCUS (locus) == UNKNOWN_LOCATION)
@@ -337,14 +339,13 @@ static void

   tree decl = get_function_decl_from_block (block);
   stack->push_back (std::make_pair (
-  decl, get_combined_location (locus, decl, level == 0 && use_discr)));
+  decl, get_combined_location (locus, decl)));
   locus = tmp_locus;
   level++;
 }
   stack->push_back (std::make_pair (
   current_function_decl,
-  get_combined_location (locus, current_function_decl,
- level == 0 && use_discr)));
+  get_combined_location (locus, current_function_decl)));
 }


@@ -523,14 +524,16 @@ const function_instance *autofdo_source_profile::g
   return ret == map_.end() ? NULL : ret->second;
 }

-bool autofdo_source_profile::get_count_info (gimple stmt,
- count_info *info) const
+bool autofdo_source_profile::get_count_info (gimple stmt, count_info *info,
+ const location_set *set) const
 {
   if (LOCATION_LOCUS (gimple_location (stmt)) == cfun->function_end_locus)
 return false;

   inline_stack stack;
-  get_inline_stack (stmt, true, &stack);
+  get_inline_stack (stmt, &stack);
+  if (set && set->find(stack) != set->end())
+return false;
   if (stack.size () == 0)
 return false;
   const function_instance *s = get_function_instance_by_inline_stack (stack);
@@ -544,7 +547,7 @@ gcov_type autofdo_source_profile::get_callsite_tot
 {
   inline_stack stack;
   stack.push_back (std::make_pair(edge->callee->symbol.decl, 0));
-  get_inline_stack (edge->call_stmt, false, &stack);
+  get_inline_stack (edge->call_stmt, &stack);

   const function_instance *s = get_function_instance_by_inline_stack (stack);
   if (s == NULL)
@@ -821,7 +824,7 @@ afdo_vpt (gimple stmt, const icall_target_map &map
on statements.  */

 static gcov_type
-afdo_get_bb_count (basic_block bb)
+afdo_get_bb_count (basic_block bb, location_set *set)
 {
   gimple_stmt_iterator gsi;
   gcov_type max_count = 0;
@@ -831,7 +834,7 @@ static gcov_type
 {
   count_info info;
   gimple stmt = gsi_stmt (gsi);
-  if (afdo_source_profile->get_count_info (stmt, &info))
+  if (afdo_source_profile->get_count_info (stmt, &info, set))
  {
   if (info.first > max_count)
 max_count = info.first;
@@ -840,6 +843,14 

Re: powerpc64le multilibs and multiarch dir

[Alan Modra]

On Fri, Aug 23, 2013 at 01:45:14AM +0930, Alan Modra wrote:
> On Thu, Aug 22, 2013 at 10:06:48AM -0400, David Edelsohn wrote:
> > What is the purpose of the change to MULTILIB_OSDIRNAMES? Why the
> > addition of m64= and m32=? A secondary tmake file is not always set to
> > post-process those macros, AFAICT.
> 
> That m64= is the newer syntax that specifies a mapping from a
> MUTLILIB_OPTIONS selection.  And, yes, without another tmake file this
> gives us exactly the same result as before.
> 
> I needed to use the new syntax to specify the correct os dirs when
> adding cross-endian multilibs.

Without another tmake file it really is exactly the same as before.

old, after applying "make" string gunk
MULTILIB_OPTIONS = m64/m32
MULTILIB_OSDIRNAMES = ../lib64 ../lib

new
MULTILIB_OPTIONS = m64/m32
MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib

Either way, -m64 objects use ../lib64 and -m32 ../lib.


new with le multilib
MULTILIB_OPTIONS = m64/m32 mlittle
MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib m64.mlittle=../lib64le 
m32.mlittle=../lible

Trying to do the same with the old syntax isn't possible, because you
must specify 3 elements in MULTILIB_OSDIRNAMES to match the
combinations given in MULTILIB_OPTIONS, then the multilib machinery
mashes them together.  For instance

MULTILIB_OPTIONS = m64/m32 le
MULTILIB_OSDIRNAMES = ../lib64 ../lib le

results in
-m64 code to ../lib64
-m32 code to ../lib
-m64 -mlittle code to le
-m32 -mlittle code to ../lible

The reason you don't get ../lib64le for -m64 -mlittle is related to
-m64 being the default, -m64 is therefore omitted when compiling, and
just the "le" string used for the os multilib dir.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [C++ patch] Set attributes for C++ runtime library calls

[Mike Stump]

On Aug 22, 2013, at 2:28 PM, Gabriel Dos Reis  
wrote:
> On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump  wrote:
>> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis 
>>  wrote:
 I.e. can I have something like
 
 int a;
 test()
 {
 int *b=new (int);
 }
 
 with custom implementation of new that returns &a?
>>> 
>>> If the user-supplied operator new returns &a, then it must
>>> also ensure that 'a' is not used anywhere else -- e.g. I you can't
>>> do lvalue-to-value conversion on 'a' to see what is written there.
>> 
>> This is wrong, in the c++97 standard there is no such limitation or 
>> restriction.
> 
> Please, elaborate.

Sure, there is no wording that limits as you describe.  There is a limit for 
polymorphic classes and classes with virtual bases (See [class.cdtor], but that 
is due to the vtable pointer lifetime and vbase pointer (offset) lifetime.  
Essentially, you can't use viable pointers or do vbase conversions before they 
are set, and they are only set at a particular time.  The standard keeps it 
simple and expands to non-POD, but I'd argue that from a QOI we should not make 
things that can work, not work.  See below on QOI issues.

I can't quote it, since the limitation doesn't exist.  I can quote the language 
that allows & on an object, that you can then cast this to be of a different 
type, and then dereference and use that type, if you want.  I can quote the 
object lifetime rules, that describe when it comes into existence, and when it 
goes away.  But, none of these are terribly surprising.  If you want to narrow 
done what part of the language you're interested in, I can quote just that part.

int a;

a exists before the program runs, and exists till after the program is finished 
running (See [basic.stc.static]).  That's the lifetime of it.  During it's 
lifetime, you can use it in the ways the standard lets you.  For example, ++a;. 
 In the below:

void foo() {
char *cp = &a;

[ … ]
}

cp's lifetime is from the declaration of it, til the }.  The character object 
that cp points to has a lifetime.  It's lifetime is from before the program 
runs, til after the program finishes.  (See [basic.life])  It can be used any 
way that a lvalue character can be used.  Since you can't use cp before it's 
lifetime, to use this character object outside of the lifetime of cp, you'd 
need another reference to it beyond just cp.  Again, this isn't suppose to be 
surprising.

Now, we do have wording like:

15If  a program attempts to access the stored value of an object through
  an lvalue of other than one of the following  types  the  behavior  is
  undefined48):

and we do have latitude to do things that uses that as a basis, but, once one 
ensures locking, say with atomics or volatile, to ensure the variable hits 
memory, I will argue that we can't make as much use of that from a quality of 
implementation viewpoint, despite the standard wording.  Now, even without 
volatile and locking, from a quality of implementation point of view, we don't 
actually want to make full use of undefined.  QOI still forces us to do the 
right thing.  undefined means, we get to kill the user.  QOI means, even though 
we can, we refrain from it, cause if we did, they would not like us.

For the case of a int, and a placement new on that int, of an int.  The 
behavior is mandated by the standard to work.  For a allocation function, they 
are free to play games with persistence (or unexec a la emacs), with allocated 
objects and this too has to work.  This means they can alias, and the standard 
says they can write this code and the standard mandates that it works.

Now, the user can use:

@item malloc
@cindex @code{malloc} attribute
The @code{malloc} attribute is used to tell the compiler that a function
may be treated as if any non-@code{NULL} pointer it returns cannot
alias any other pointer valid when the function returns and that the memory
has undefined content.
This often improves optimization.
Standard functions with this property include @code{malloc} and
@code{calloc}.  @code{realloc}-like functions do not have this
property as the memory pointed to does not have undefined content.

on their allocation functions, if they want.  And if they do, than what it says 
is true, by definition, but not by standard.  When this isn't true, the user 
will refrain from using this attribute.

opt-info message change for vectorizer

[Xinliang David Li]

Hi, In this patch, loop alignment peeling and loop versioning
transformation will be reported via -fopt-info by default. This will
help vectorizer size tuning.

It also enhances the opt-info dump to include current function name as
context. Otherwise, we may see duplicate messeages from inline/cloned
instances.

An example opt report:



b.c:16:A::foo: note: Loop is vectorized

b.c:16:A::foo: note: Loop is versioned to remove aliases for vectorization

b.c:16:A::foo: note: Loop is peeled to enhance alignment for vectorization

b.c:16:A::foo: note: Completely unroll loop 6 times

b.c:12:A::foo: note: Completely unroll loop 6 times


Ok after testing?

thanks,

David
Index: tree-vectorizer.c
===
--- tree-vectorizer.c   (revision 201751)
+++ tree-vectorizer.c   (working copy)
@@ -119,7 +119,7 @@ vectorize_loops (void)
 if (LOCATION_LOCUS (vect_location) != UNKNOWN_LOC
&& dump_enabled_p ())
   dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
-   "Vectorized loop\n");
+   "Loop is vectorized\n");
vect_transform_loop (loop_vinfo);
num_vectorized_loops++;
   }
@@ -180,7 +180,7 @@ execute_vect_slp (void)
   vect_slp_transform_bb (bb);
   if (dump_enabled_p ())
 dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
-"Vectorized basic-block\n");
+"Basic block is vectorized\n");
 }
 }
 
Index: tree-vect-loop-manip.c
===
--- tree-vect-loop-manip.c  (revision 201751)
+++ tree-vect-loop-manip.c  (working copy)
@@ -2021,8 +2021,9 @@ vect_do_peeling_for_alignment (loop_vec_
   int bound = 0;
 
   if (dump_enabled_p ())
-dump_printf_loc (MSG_NOTE, vect_location,
- "=== vect_do_peeling_for_alignment ===");
+dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
+ "Loop is peeled to enhance"
+ " alignment for vectorization\n");
 
   initialize_original_copy_tables ();
 
@@ -2404,6 +2405,8 @@ vect_loop_versioning (loop_vec_info loop
   unsigned prob = 4 * REG_BR_PROB_BASE / 5;
   gimple_seq gimplify_stmt_list = NULL;
   tree scalar_loop_iters = LOOP_VINFO_NITERS (loop_vinfo);
+  bool version_align = LOOP_REQUIRES_VERSIONING_FOR_ALIGNMENT (loop_vinfo);
+  bool version_alias = LOOP_REQUIRES_VERSIONING_FOR_ALIAS (loop_vinfo);
 
   if (check_profitability)
 {
@@ -2413,11 +2416,11 @@ vect_loop_versioning (loop_vec_info loop
  is_gimple_condexpr, NULL_TREE);
 }
 
-  if (LOOP_REQUIRES_VERSIONING_FOR_ALIGNMENT (loop_vinfo))
+  if (version_align)
 vect_create_cond_for_align_checks (loop_vinfo, &cond_expr,
   &cond_expr_stmt_list);
 
-  if (LOOP_REQUIRES_VERSIONING_FOR_ALIAS (loop_vinfo))
+  if (version_alias)
 vect_create_cond_for_alias_checks (loop_vinfo, &cond_expr);
 
   cond_expr = force_gimple_operand_1 (cond_expr, &gimplify_stmt_list,
@@ -2427,6 +2430,17 @@ vect_loop_versioning (loop_vec_info loop
   initialize_original_copy_tables ();
   loop_version (loop, cond_expr, &condition_bb,
prob, prob, REG_BR_PROB_BASE - prob, true);
+
+  if (LOCATION_LOCUS (vect_location) != UNKNOWN_LOC
+  && dump_enabled_p ())
+{
+  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
+   "Loop is versioned to %s for vectorization\n",
+   (version_align && version_alias)
+  ? "enhance alignment and remove aliases"
+   : (version_align
+? "enhance alignment" : "remove aliases"));
+}
   free_original_copy_tables();
 
   /* Loop versioning violates an assumption we try to maintain during
Index: dumpfile.c
===
--- dumpfile.c  (revision 201751)
+++ dumpfile.c  (working copy)
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.
 #include "dumpfile.h"
 #include "gimple-pretty-print.h"
 #include "tree.h"
+#include "gimple.h"
 
 /* If non-NULL, return one past-the-end of the matching SUBPART of
the WHOLE string.  */
@@ -261,12 +262,20 @@ dump_loc (int dump_kind, FILE *dfile, so
   if (dump_kind)
 {
   if (LOCATION_LOCUS (loc) > BUILTINS_LOCATION)
-fprintf (dfile, "\n%s:%d: note: ", LOCATION_FILE (loc),
- LOCATION_LINE (loc));
+{
+  if (current_function_decl)
+fprintf (dfile, "\n%s:%d:%s: note: ", LOCATION_FILE (loc),
+ LOCATION_LINE (loc),
+ gimple_decl_printable_name (current_function_decl, 1));
+  else
+fprintf (dfile, "\n%s:%d: note: ", LOCATION_FILE (loc),
+ LOCATION_LINE (loc));
+}

Re: [PATCH] Fix PR57451 (Incorrect debug ranges emitted for -freorder-blocks-and-partition -g)

[Steve Ellcey]

On Mon, 2013-08-19 at 22:21 -0700, Teresa Johnson wrote:

> 2013-08-19  Teresa Johnson  
> 
> PR rtl-optimizations/57451
> * final.c (reemit_insn_block_notes): Prevent lexical blocks
> from crossing split section boundaries.
> 
> * testsuite/g++.dg/tree-prof/pr57451.C: New test.

Teresa,

This patch is causing a problem in my mips compiler.  I am creating a
cross-toolchain running on x86 targeting mips-mti-linux-gnu and if I
compile glibc using a GCC that has this patch all of the programs I
compile go into an infinite loop when run under the qemu simulator.  I
think it is the dynamic linker that is getting miscompiled, but I
haven't tracked down the exact nature of the miscompilation yet.  Has
anyone else reported any problems with it?  I am adding Richard
Sandiford to the email list since he is a mips expert and also might
have some insight to using next_active_insn vs. next_real_insn vs.
next_insn, though it doesn't look like you have changed what is used
here.

Steve Ellcey
sell...@mips.com

Re: [PATCH] Fix PR57451 (Incorrect debug ranges emitted for -freorder-blocks-and-partition -g)

[Kaz Kojima]

Steve Ellcey  wrote:
> On Mon, 2013-08-19 at 22:21 -0700, Teresa Johnson wrote:
> 
>> 2013-08-19  Teresa Johnson  
>> 
>> PR rtl-optimizations/57451
>> * final.c (reemit_insn_block_notes): Prevent lexical blocks
>> from crossing split section boundaries.
>> 
>> * testsuite/g++.dg/tree-prof/pr57451.C: New test.
> 
> Teresa,
> 
> This patch is causing a problem in my mips compiler.  I am creating a
> cross-toolchain running on x86 targeting mips-mti-linux-gnu and if I
> compile glibc using a GCC that has this patch all of the programs I
> compile go into an infinite loop when run under the qemu simulator.  I
> think it is the dynamic linker that is getting miscompiled, but I
> haven't tracked down the exact nature of the miscompilation yet.  Has
> anyone else reported any problems with it?  I am adding Richard
> Sandiford to the email list since he is a mips expert and also might
> have some insight to using next_active_insn vs. next_real_insn vs.
> next_insn, though it doesn't look like you have changed what is used
> here.

Similar on SH.  I've just filed rtl-optimization/58220.

Regards,
kaz

Re: libtool update for powerpc64le-linux

[Alan Modra]

On Fri, Aug 16, 2013 at 06:18:05PM +0930, Alan Modra wrote:
> I'd like to apply the following patch to the gcc repository (well,
> excluding the libgo part which I'm hoping someone will apply for me to
> the master go repository).  I know the normal procedure for autotools
> is to submit upstream then update when the patch is in the upstream
> autotools repository, but this simple libtool patch has been awaiting
> review for over two months.

The libtool.m4 patch has finally been reviewed and accepted upstream.

I'd like to import upstream libtool into gcc to support powerpc64le,
and please, can someone do the same for upstream libgo?  The reason we
need this patch is that on a powerpc64le linux host where the compiler
defaulted to producing 64-bit objects (which is how we generally build
compilers nowadays) libtool added -m elf64ppc to $LD.  Being the
option for 64-bit big-endian, that caused complete failure for
64-bit little-endian.

libjava is using a rather old version of libtool.  Importing doesn't
seem an option there, so for libjava patch acinclude.m4.  Please don't
ask me to modify libjava configure and makefiles to use current
libtool.  I tried, and failed.

* libtool.m4: Import upstream version.
libgo/
* config/libtool.m4: Import upstream version.
* libgo/configure: Regenerate.
libjava/libltdl/
* acinclude.m4 (_LT_ENABLE_LOCK ): Remove non-canonical
ppc host match.  Support little-endian powerpc linux hosts.
* configure: Regenerate.
gcc/
* configure: Regenerate.
libobjc/
* configure: Regenerate.
libgfortran/
* configure: Regenerate.
libffi/
* configure: Regenerate.
libssp/
* configure: Regenerate.
libitm/
* configure: Regenerate.
libgomp/
* configure: Regenerate.
libquadmath/
* configure: Regenerate.
libsanitizer/
* configure: Regenerate.
zlib/
* configure: Regenerate.
libstdc++-v3/
* configure: Regenerate.
libmudflap/
* configure: Regenerate.
boehm-gc/
* configure: Regenerate.
lto-plugin/
* configure: Regenerate.
libatomic/
* configure: Regenerate.
libbacktrace/
* configure: Regenerate.
libjava/
* configure: Regenerate.
libjava/classpath/
* configure: Regenerate.

Index: libjava/libltdl/acinclude.m4
===
--- libjava/libltdl/acinclude.m4(revision 200501)
+++ libjava/libltdl/acinclude.m4(working copy)
@@ -519,7 +519,7 @@
   rm -rf conftest*
   ;;
 
-x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
+x86_64-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
   # Find out which ABI we are using.
   echo 'int i;' > conftest.$ac_ext
   if AC_TRY_EVAL(ac_compile); then
@@ -529,7 +529,10 @@
 x86_64-*linux*)
   LD="${LD-ld} -m elf_i386"
   ;;
-ppc64-*linux*|powerpc64-*linux*)
+powerpc64le-*linux*)
+  LD="${LD-ld} -m elf32lppclinux"
+  ;;
+powerpc64-*linux*)
   LD="${LD-ld} -m elf32ppclinux"
   ;;
 s390x-*linux*)
@@ -545,7 +548,10 @@
 x86_64-*linux*)
   LD="${LD-ld} -m elf_x86_64"
   ;;
-ppc*-*linux*|powerpc*-*linux*)
+powerpcle-*linux*)
+  LD="${LD-ld} -m elf64lppc"
+  ;;
+powerpc-*linux*)
   LD="${LD-ld} -m elf64ppc"
   ;;
 s390*-*linux*)

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH]: Fix PR middle-end/56382 -- Only move MODE_COMPLEX_FLOAT by parts if we can create pseudos

[John David Anglin]

Ping.

On 28-Jul-13, at 12:17 PM, John David Anglin wrote:

This patch fixes PR middle-end/56382 on hppa64-hp-hpux11.11.  The  
patch prevents moving a complex float by parts if we can't
create pseudos.  On a big endian 64-bit target, we need a psuedo to  
move a complex float and this fails during reload.


OK for trunk?

Dave
--
John David Anglin   dave.ang...@bell.net





--
John David Anglin   dave.ang...@bell.net

Re: [go-nuts] Re: libtool update for powerpc64le-linux

[Ian Lance Taylor]

On Thu, Aug 22, 2013 at 5:35 PM, Alan Modra  wrote:
> On Fri, Aug 16, 2013 at 06:18:05PM +0930, Alan Modra wrote:
>> I'd like to apply the following patch to the gcc repository (well,
>> excluding the libgo part which I'm hoping someone will apply for me to
>> the master go repository).  I know the normal procedure for autotools
>> is to submit upstream then update when the patch is in the upstream
>> autotools repository, but this simple libtool patch has been awaiting
>> review for over two months.
>
> The libtool.m4 patch has finally been reviewed and accepted upstream.
>
> I'd like to import upstream libtool into gcc to support powerpc64le,
> and please, can someone do the same for upstream libgo?  The reason we
> need this patch is that on a powerpc64le linux host where the compiler
> defaulted to producing 64-bit objects (which is how we generally build
> compilers nowadays) libtool added -m elf64ppc to $LD.  Being the
> option for 64-bit big-endian, that caused complete failure for
> 64-bit little-endian.

I've updated libgo/config/libtool.m4 and libgo/configure on mainline.

Ian

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 6:16 PM, Mike Stump  wrote:
> On Aug 22, 2013, at 2:28 PM, Gabriel Dos Reis  
> wrote:
>> On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump  wrote:
>>> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis 
>>>  wrote:
> I.e. can I have something like
>
> int a;
> test()
> {
> int *b=new (int);
> }
>
> with custom implementation of new that returns &a?

 If the user-supplied operator new returns &a, then it must
 also ensure that 'a' is not used anywhere else -- e.g. I you can't
 do lvalue-to-value conversion on 'a' to see what is written there.
>>>
>>> This is wrong, in the c++97 standard there is no such limitation or 
>>> restriction.
>>
>> Please, elaborate.
>
> Sure, there is no wording that limits as you describe.  There is a limit for 
> polymorphic classes and classes with virtual bases (See [class.cdtor], but 
> that is due to the vtable pointer lifetime and vbase pointer (offset) 
> lifetime.  Essentially, you can't use viable pointers or do vbase conversions 
> before they are set, and they are only set at a particular time.  The 
> standard keeps it simple and expands to non-POD, but I'd argue that from a 
> QOI we should not make things that can work, not work.  See below on QOI 
> issues.

I think we must distinguish what is "wrong" according to the standards
we are implementing from what is "wrong" from a QoI point of view.

My reasoning (for C++98, but the same is true for C++11) is based
on 3.8/1:
   […]
   The lifetime of an object of type T ends when:
-- if T is a class type with a non-trivial destructor (12.4),
   the destructor call starts, or
--  the storage which the object occupies is reused or released.

Doing a placement-new on the storage occupied by 'a' is reusing
its storage, therefore ending its lifetime.

-- Gaby

>
> I can't quote it, since the limitation doesn't exist.  I can quote the 
> language that allows & on an object, that you can then cast this to be of a 
> different type, and then dereference and use that type, if you want.  I can 
> quote the object lifetime rules, that describe when it comes into existence, 
> and when it goes away.  But, none of these are terribly surprising.  If you 
> want to narrow done what part of the language you're interested in, I can 
> quote just that part.
>
> int a;
>
> a exists before the program runs, and exists till after the program is 
> finished running (See [basic.stc.static]).  That's the lifetime of it.  
> During it's lifetime, you can use it in the ways the standard lets you.  For 
> example, ++a;.  In the below:
>
> void foo() {
> char *cp = &a;
>
> [ … ]
> }
>
> cp's lifetime is from the declaration of it, til the }.  The character object 
> that cp points to has a lifetime.  It's lifetime is from before the program 
> runs, til after the program finishes.  (See [basic.life])  It can be used any 
> way that a lvalue character can be used.  Since you can't use cp before it's 
> lifetime, to use this character object outside of the lifetime of cp, you'd 
> need another reference to it beyond just cp.  Again, this isn't suppose to be 
> surprising.
>
> Now, we do have wording like:
>
> 15If  a program attempts to access the stored value of an object through
>   an lvalue of other than one of the following  types  the  behavior  is
>   undefined48):
>
> and we do have latitude to do things that uses that as a basis, but, once one 
> ensures locking, say with atomics or volatile, to ensure the variable hits 
> memory, I will argue that we can't make as much use of that from a quality of 
> implementation viewpoint, despite the standard wording.  Now, even without 
> volatile and locking, from a quality of implementation point of view, we 
> don't actually want to make full use of undefined.  QOI still forces us to do 
> the right thing.  undefined means, we get to kill the user.  QOI means, even 
> though we can, we refrain from it, cause if we did, they would not like us.
>
> For the case of a int, and a placement new on that int, of an int.  The 
> behavior is mandated by the standard to work.  For a allocation function, 
> they are free to play games with persistence (or unexec a la emacs), with 
> allocated objects and this too has to work.  This means they can alias, and 
> the standard says they can write this code and the standard mandates that it 
> works.
>
> Now, the user can use:
>
> @item malloc
> @cindex @code{malloc} attribute
> The @code{malloc} attribute is used to tell the compiler that a function
> may be treated as if any non-@code{NULL} pointer it returns cannot
> alias any other pointer valid when the function returns and that the memory
> has undefined content.
> This often improves optimization.
> Standard functions with this property include @code{malloc} and
> @code{calloc}.  @code{realloc}-like functions do not have this
> property as the memory pointed to does not have undefined content.
>
> on their allocatio

patch for wide-int branch

[Kenneth Zadeck]

cleaned up version of convert_modes that handles all constants in a 
uniform manner.


This is clean on x86-64.   Will test on other platforms tomorrow.

kenny

Index: gcc/expr.c
===
--- gcc/expr.c(revision 201884)
+++ gcc/expr.c(working copy)
@@ -710,64 +710,32 @@ convert_modes (enum machine_mode mode, e
   if (mode == oldmode)
 return x;

-  /* There is one case that we must handle specially: If we are
- converting a CONST_INT into a mode whose size is larger than
- HOST_BITS_PER_WIDE_INT and we are to interpret the constant as
- unsigned, gen_lowpart will do the wrong if the constant appears
- negative.  What we want to do is make the high-order word of the
- constant zero, not all ones.  */
-
-  if (unsignedp && GET_MODE_CLASS (mode) == MODE_INT
-  && GET_MODE_BITSIZE (mode) > HOST_BITS_PER_WIDE_INT
-  && CONST_INT_P (x) && INTVAL (x) < 0)
+  if (CONST_SCALAR_INT_P (x)
+  && GET_MODE_CLASS (mode) == MODE_INT
+  && (oldmode == VOIDmode || GET_MODE_CLASS (oldmode) == MODE_INT))
 {
-  wide_int val = std::make_pair (x, mode);
-  /* We need to zero extend VAL.  */
-  if (oldmode != VOIDmode)
-val = val.zext (GET_MODE_PRECISION (oldmode));
-
-  return immed_wide_int_const (val, mode);
+  wide_int w = std::make_pair (x, mode);
+  /* If the caller did not tell us the old mode, then there is
+ not much to do with respect to canonization.  */
+  if (oldmode != VOIDmode
+  && GET_MODE_PRECISION (mode) > GET_MODE_PRECISION (oldmode))
+w = w.ext (GET_MODE_PRECISION (oldmode), unsignedp ? UNSIGNED : 
SIGNED);

+  return immed_wide_int_const (w, mode);
 }

   /* We can do this with a gen_lowpart if both desired and current modes
  are integer, and this is either a constant integer, a register, or a
- non-volatile MEM.  Except for the constant case where MODE is no
- wider than HOST_BITS_PER_WIDE_INT, we must be narrowing the 
operand.  */

+ non-volatile MEM. */
+  if (GET_MODE_CLASS (mode) == MODE_INT
+  && GET_MODE_CLASS (oldmode) == MODE_INT
+  && GET_MODE_PRECISION (mode) <= GET_MODE_PRECISION (oldmode)
+  && ((MEM_P (x) && !MEM_VOLATILE_P (x) && direct_load[(int) mode])
+  || (REG_P (x)
+  && (!HARD_REGISTER_P (x)
+  || HARD_REGNO_MODE_OK (REGNO (x), mode))
+  && TRULY_NOOP_TRUNCATION_MODES_P (mode, GET_MODE (x)

-  if ((CONST_INT_P (x)
-   && GET_MODE_PRECISION (mode) <= HOST_BITS_PER_WIDE_INT)
-  || (GET_MODE_CLASS (mode) == MODE_INT
-  && GET_MODE_CLASS (oldmode) == MODE_INT
-  && (CONST_SCALAR_INT_P (x)
-  || (GET_MODE_PRECISION (mode) <= GET_MODE_PRECISION (oldmode)
-  && ((MEM_P (x) && ! MEM_VOLATILE_P (x)
-   && direct_load[(int) mode])
-  || (REG_P (x)
-  && (! HARD_REGISTER_P (x)
-  || HARD_REGNO_MODE_OK (REGNO (x), mode))
-  && TRULY_NOOP_TRUNCATION_MODES_P (mode,
-GET_MODE (x
-{
-  /* ?? If we don't know OLDMODE, we have to assume here that
- X does not need sign- or zero-extension.   This may not be
- the case, but it's the best we can do.  */
-  if (CONST_INT_P (x) && oldmode != VOIDmode
-  && GET_MODE_PRECISION (mode) > GET_MODE_PRECISION (oldmode))
-{
-  HOST_WIDE_INT val = INTVAL (x);
-
-  /* We must sign or zero-extend in this case.  Start by
- zero-extending, then sign extend if we need to.  */
-  val &= GET_MODE_MASK (oldmode);
-  if (! unsignedp
-  && val_signbit_known_set_p (oldmode, val))
-val |= ~GET_MODE_MASK (oldmode);
-
-  return gen_int_mode (val, mode);
-}
-
-  return gen_lowpart (mode, x);
-}
+   return gen_lowpart (mode, x);

   /* Converting from integer constant into mode is always equivalent to an
  subreg operation.  */

Re: [C++ patch] Set attributes for C++ runtime library calls

[Mike Stump]

On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis  
wrote:
> I think we must distinguish what is "wrong" according to the standards
> we are implementing from what is "wrong" from a QoI point of view.

Not if they match, we don't.

> My reasoning (for C++98, but the same is true for C++11) is based
> on 3.8/1:
>   […]
>   The lifetime of an object of type T ends when:
>-- if T is a class type with a non-trivial destructor (12.4),
>   the destructor call starts, or
>--  the storage which the object occupies is reused or released.
> 
> Doing a placement-new on the storage occupied by 'a' is reusing
> its storage, therefore ending its lifetime.

The problem is that reused is not well defined, so, we are into the weeds right 
there.

int i, j;

int *ip = &i;

i = 1;
j = 2;
*ip = j;
++i;
++j;

here, we sees the storage being reused in the *ip = j; statement, or, is it 
merely changing the value?  And what if we do a memcpy (ip, &j, sizeof (int));  
Is that reused, or merely changing the value.  I think the most logical line of 
reasoning is that when the requirements of [basic.lval] are met, the, this is a 
change of value of an object, not a modification to it's lifetime.  So, in the 
case quoted, since the type of the accesses are both int, we don't reuse the 
storage, since the requirements of [basic.lval] are met.  Indeed, the 
programmer expects that they can access i after *ip = j; and that the _value_ 
that object, while changed from the original 1, will be 2 just after the *ip = 
j; statement.

Since we know that i must be 3 at the end, we then know what the wording, 
reused, must mean, cause other meanings that could possibly make it work for 
you in the case you are considering, would destroy this property of pointers, 
and everyone knows the semantics of pointers, they are undisputed.  Or put 
another way, you cannot misread reused in this way.

Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis]

On Thu, Aug 22, 2013 at 8:51 PM, Mike Stump  wrote:
> On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis  
> wrote:
>> I think we must distinguish what is "wrong" according to the standards
>> we are implementing from what is "wrong" from a QoI point of view.
>
> Not if they match, we don't.

In abstract possibly; but your previous assertion needs refinement to
be as categorical as you implied.

>
>> My reasoning (for C++98, but the same is true for C++11) is based
>> on 3.8/1:
>>   […]
>>   The lifetime of an object of type T ends when:
>>-- if T is a class type with a non-trivial destructor (12.4),
>>   the destructor call starts, or
>>--  the storage which the object occupies is reused or released.
>>
>> Doing a placement-new on the storage occupied by 'a' is reusing
>> its storage, therefore ending its lifetime.
>
> The problem is that reused is not well defined,

I am not quite so sure.  But even so, in light of this, I don't think
you original assertion is definitive.

> so, we are into the weeds right there.
>
> int i, j;
>
> int *ip = &i;
>
> i = 1;
> j = 2;
> *ip = j;
> ++i;
> ++j;
>
> here, we sees the storage being reused in the *ip = j;

Really?

> statement, or, is it merely changing the value?

That is an assignment to an existing int storage.

> And what if we do a memcpy (ip, &j, sizeof (int));

Well, the case of 'memcpy' isn't defined by the standard and is
precisely the subject of a issue identified by the C++ SG12
that will be discussed at the Chicago meeting.

>  Is that reused, or merely changing the value.

The current proposal is that it constructs an int value, therefore
is moral equivalent of copy-constructor call.

> I think the most logical line of reasoning is that when the requirements of 
> [basic.lval] are met, the, this is a change of value of an object, not a 
> modification to it's lifetime.

Why?


>  So, in the case quoted, since the type of the accesses are both int, we 
> don't reuse the storage, since the requirements of [basic.lval] are met.

Consider:

struct S {
S(int);
~S();
// …
};

int main() {
S s(8);

 new (&s) S(9); // #1
}

Is #1 a reuse of storage to create a new object or assignment?

>  Indeed, the programmer expects that they can access i after *ip = j; and 
> that the _value_ that object, while changed from the original 1, will be 2 
> just after the *ip = j; statement.
>
> Since we know that i must be 3 at the end, we then know what the wording, 
> reused, must mean, cause other meanings that could possibly make it work for 
> you in the case you are considering, would destroy this property of pointers, 
> and everyone knows the semantics of pointers, they are undisputed.  Or put 
> another way, you cannot misread reused in this way.

And why do you assert that I misread 'reused' in this way?

-- Gaby