[PATCH] Fix PR64059

[Markus Trippelsdorf]

This fixes PR64059 where a call to get_dynamic_type wasn't guarded by
flag_devirtualize.

Tested on powerpc64-unknown-linux-gnu.
Preapproved by Honza on bugzilla. Commited to trunk.

PR ipa/64059
* ipa-prop.c (ipa_analyze_call_uses): Don't call get_dynamic_type when
devirtualization is disabled.

PR ipa/64059
* g++.dg/ipa/pr64059.C: New test.

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 2e0016bfbe66..eeffda449d9b 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -2155,7 +2155,7 @@ ipa_analyze_call_uses (struct func_body_info *fbi, gcall 
*call)
   if (cs && !cs->indirect_unknown_callee)
 return;
 
-  if (cs->indirect_info->polymorphic)
+  if (cs->indirect_info->polymorphic && flag_devirtualize)
 {
   tree instance;
   tree target = gimple_call_fn (call);
diff --git a/gcc/testsuite/g++.dg/ipa/pr64059.C 
b/gcc/testsuite/g++.dg/ipa/pr64059.C
new file mode 100644
index ..0269b45458d9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr64059.C
@@ -0,0 +1,56 @@
+// { dg-options "-r -nostdlib -O2 -flto -fno-devirtualize" }
+// { dg-require-effective-target lto }
+
+class A;
+class B
+{
+public:
+  A *operator->();
+};
+class C
+{
+public:
+  virtual void m_fn1 ();
+};
+class A
+{
+public:
+  C *m_fn2 ();
+};
+class D
+{
+public:
+  void
+  m_fn3 ()
+  {
+list_m->m_fn2 ()->m_fn1 ();
+  }
+  B list_m;
+};
+
+class F
+{
+public:
+  D m_fn4 ();
+};
+class G
+{
+public:
+  F m_fn5 (int, int);
+};
+class H
+{
+public:
+  void
+  m_fn6 ()
+  {
+fieldEngine_m.m_fn5 (0, 0).m_fn4 ().m_fn3 ();
+  }
+  G fieldEngine_m;
+};
+
+void
+fn1 (H a)
+{
+  a.m_fn6 ();
+}
-- 
2.1.3

-- 
Markus

Re: [PATCH] Fix find_base_term in 32-bit -fpic code (PR lto/64025)

[Uros Bizjak]

On Tue, Nov 25, 2014 at 12:25 AM, Jakub Jelinek  wrote:

> The fallback delegitimization I've added as last option mainly for
> debug info purposes, when we don't know if the base is a PIC register
> or say a PIC register plus some addend, unfortunately in some tests
> broke find_base_term, which for PLUS looks only at the first operand
> and recursion on it finds a base term, it returns it immediately.
> So, it found base term of _GLOBAL_OFFSET_TABLE_, when the right base
> term is actually in the second operand.
>
> This patch fixes it by swapping the operands, debug info doesn't care about
> the order, it won't match in any instruction anyway, but helps alias.c.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2014-11-24  Jakub Jelinek  
>
> PR lto/64025
> * config/i386/i386.c (ix86_delegitimize_address): Ensure result
> comes before (addend - _GLOBAL_OFFSET_TABLE_) term.

Can you also swap operands of (%ecx - %ebx) + foo? There is no point
digging into RTX involving registers only when we know that we are
looking for foo. This will also be consistent with the code you
patched below.

Uros.

>
> --- gcc/config/i386/i386.c.jj   2014-11-24 10:26:26.0 +0100
> +++ gcc/config/i386/i386.c  2014-11-24 20:17:27.659091709 +0100
> @@ -14848,7 +14848,7 @@ ix86_delegitimize_address (rtx x)
>  ...
>  movl foo@GOTOFF(%ecx), %edx
>  in which case we return (%ecx - %ebx) + foo
> -or (%ecx - _GLOBAL_OFFSET_TABLE_) + foo if pseudo_pic_reg
> +or foo + (%ecx - _GLOBAL_OFFSET_TABLE_) if pseudo_pic_reg
>  and reload has completed.  */
>if (pic_offset_table_rtx
>   && (!reload_completed || !ix86_use_pseudo_pic_reg ()))
> @@ -14859,7 +14859,14 @@ ix86_delegitimize_address (rtx x)
> {
>   rtx tmp = gen_rtx_SYMBOL_REF (Pmode, GOT_SYMBOL_NAME);
>   tmp = gen_rtx_MINUS (Pmode, copy_rtx (addend), tmp);
> - result = gen_rtx_PLUS (Pmode, tmp, result);
> + /* The order of the operands here is very important.  find_base_term
> +will only recurse into the first operand of PLUS if none of the
> +arguments is REG with REG_POINTER_P set on it, and if that finds
> +base term, it doesn't recurse into the second operand of PLUS.
> +We don't want find_base_term to return the artificial
> +_GLOBAL_OFFSET_TABLE_ symbol, so ensure it goes into the
> +second operand.  */
> + result = gen_rtx_PLUS (Pmode, result, tmp);
> }
>else
> return orig_x;
>
> Jakub

[Patch, Fortran] convert almost all {warning,error}_now to common diagnostic

[Tobias Burnus]

With this patch – and the still pending patch for gfc_internal_error at 
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03003.html – all 
error/warning messages have been converted to the common diagnostic, 
except for:


(a) those majority which might need buffering (gfc_error, gfc_warning);
(b) those 10 gfc_error_now_1 with two locations (%L %L or %L %C); and
(c) those 6 gfc_warning_now_1 in scanner.c, for which "location" 
(gfc_current_loc) is not properly set up. [Could be less, I haven't 
check all of them.]



As most *_now functions now go through common diagnostic, I remove the 
_2 from the name and changed the old one to _1. The increment of the 
errors is required to stop before going to the translation stage in case 
errors have occurred.


In order to have something to be placed in brackets behind a warning, I 
changed a bit the handling of -Wconvertion/-Wconversion-extra such that 
each gfc_warning_now is only triggered by one -W*. Related, I moved some 
-W* to an *.opt variable and used it was OPT_W* in the warning message.


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

Tobias
gcc/fortran/
	* gfortran.h (gfc_option_t): Remove flags moved as Var to .opt.
	(gfc_error_now_1): Renamed from gfc_error_now.
	(gfc_error_now): Renamed from gfc_error_now_2.
	(gfc_warning_now_1): Renamed from gfc_warning_now.
	(gfc_warning_now): Renamed from gfc_warning_now_2.
	* error.c (gfc_error_now_1): Renamed from gfc_error_now.
	(gfc_error_now): Renamed from gfc_error_now_2.
	(gfc_warning_now_1): Renamed from gfc_warning_now.
	(gfc_warning_now): Renamed from gfc_warning_now_2.
	(gfc_get_errors): Include common diagnostic in count.
	* lang.opt (Wc-binding-type, Wconversion, Wconversion-extra,
	Wintrinsics-std): Create a Var for those warnings.
	* check.c (gfc_check_cmplx): Pass warning flag to
	diagnostic function.
	* decl.c (get_proc_name, gfc_verify_c_interop_param, build_sym
	gfc_set_constant_character_len, verify_bind_c_sym): Ditto; use
	_1 for old diagnostic, remove _2 for new diagnostic.
	* expr.c (gfc_check_assign, gfc_check_vardef_context): Ditto.
	* frontend-passes.c (doloop_code, do_function): Ditto.
	* intrinsic.c (gfc_is_intrinsic, gfc_convert_type_warn): Ditto.
	* match.c (gfc_match_common): Ditto.
	* module.c (use_iso_fortran_env_module, gfc_use_module): Ditto.
	* parse.c (decode_statement, decode_gcc_attribute, next_free,
	next_fixed, gfc_check_do_variable): Ditto.
	* resolve.c (resolve_common_vars, resolve_ordinary_assign):
	Ditto.
	* scanner.c (add_path_to_list, skip_free_comments,
	gfc_next_char_literal, gfc_gobble_whitespace, load_line,
	preprocessor_line, load_file): Ditto.
	* symbol.c (gfc_set_default_type, verify_bind_c_derived_type):
	Ditto.
	* options.c (gfc_post_options): Ditto.
	(gfc_init_options, set_Wall, gfc_handle_option): Ditto; remove
	flags which now have a Var.
	* invoke.texi (Wconversion-extra): Make clear that the flag
	does not imply -Wconversion.

gcc/testsuite/
	* gfortran.dg/empty_label.f: Change test to continue testing
	for -fmax-errors=1.
	* gfortran.dg/empty_label.f90: Ditto.
	* gfortran.dg/warnings_are_errors_1.f90: Update dg-*.

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 8da59d5..5fea5a8 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1398,17 +1398,18 @@ gfc_check_cmplx (gfc_expr *x, gfc_expr *y, gfc_expr *kind)
   if (!kind_check (kind, 2, BT_COMPLEX))
 return false;
 
-  if (!kind && gfc_option.gfc_warn_conversion
+  if (!kind && warn_conversion
   && x->ts.type == BT_REAL && x->ts.kind > gfc_default_real_kind)
-gfc_warning_now ("Conversion from %s to default-kind COMPLEX(%d) at %L "
-		 "might lose precision, consider using the KIND argument",
-		 gfc_typename (&x->ts), gfc_default_real_kind, &x->where);
-  else if (y && !kind && gfc_option.gfc_warn_conversion
+gfc_warning_now (OPT_Wconversion, "Conversion from %s to default-kind "
+		 "COMPLEX(%d) at %L might lose precision, consider using "
+		 "the KIND argument", gfc_typename (&x->ts),
+		 gfc_default_real_kind, &x->where);
+  else if (y && !kind && warn_conversion
 	   && y->ts.type == BT_REAL && y->ts.kind > gfc_default_real_kind)
-gfc_warning_now ("Conversion from %s to default-kind COMPLEX(%d) at %L "
-		 "might lose precision, consider using the KIND argument",
-		 gfc_typename (&y->ts), gfc_default_real_kind, &y->where);
-
+gfc_warning_now (OPT_Wconversion, "Conversion from %s to default-kind "
+		 "COMPLEX(%d) at %L might lose precision, consider using "
+		 "the KIND argument", gfc_typename (&y->ts),
+		 gfc_default_real_kind, &y->where);
   return true;
 }
 
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 45e5b6c..e7c06f3 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -898,17 +898,17 @@ get_proc_name (const char *name, gfc_symbol **result, bool module_fcn_entry)
 	  && sym->attr.proc != 0
 	  && (sym->attr.subroutine || sym->attr.function)
 	  && sym->attr.if_sourc

Re: [Patch] Improving jump-thread pass for PR 54742

[Jeff Law]

On 11/24/14 18:09, Sebastian Pop wrote:

Sebastian Pop wrote:

I removed the return -1 and started a bootstrap on powerpc64-linux.


Bootstrap passed on top of the 4 previous patches on powerpc64-linux.


I will report the valgrind output.


The output from valgrind looks closer to the output of master with no other
patches: still 1M more instructions executed, and 300K more branches
Just ran my suite where we get ~25k more branches, which definitely puts 
us in the noise.  (that's with all 4 patches + fixing the return value 
).  I'm going to look at little closer at this stuff tomorrow, but I 
think we've resolved the performance issue.  I'll dig deeper into the 
implementation tomorrow as well.


Cheers,
Jeff

[PATCH] Fix a bug in bt-load.c

[Segher Boessenkool]

This caused ICEs on sh64.

`min_cost' and `def' here are supposed to refer to the same element;
removing it from the heap before asking the heap for the key doesn't
work (and at the end of the loop here we will ask for min_key on an
empty heap, which then does gcc_unreachable).

Bootstrapped and tested on powerpc64-linux, but I doubt it exercises
this code at all; only sh64 did ICE, and does not anymore.  Okay for
trunk?


Segher


2014-11-24  Segher Boessenkool  

gcc/
* bt-load.c (migrate_btr_defs): Get the key of a heap entry
before removing it, not after.

---
 gcc/bt-load.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/bt-load.c b/gcc/bt-load.c
index 3002b62..53c4db3 100644
--- a/gcc/bt-load.c
+++ b/gcc/bt-load.c
@@ -1434,8 +1434,8 @@ migrate_btr_defs (enum reg_class btr_class, int 
allow_callee_save)
 
   while (!all_btr_defs.empty ())
 {
-  btr_def def = all_btr_defs.extract_min ();
   int min_cost = -all_btr_defs.min_key ();
+  btr_def def = all_btr_defs.extract_min ();
   if (migrate_btr_def (def, min_cost))
{
  all_btr_defs.insert (-def->cost, def);
-- 
1.8.1.4

[PATCH] crtstuff: Add missing semicolon

[Segher Boessenkool]

I wonder how this survived so long, I must be building some strange
configs (it failed on an avr cross).  Okay for trunk?


Segher


2014-11-24  Segher Boessenkool  

libgcc/
* crtstuff.c (__do_glbal_ctors_1): Add missing semicolon.

---
 libgcc/crtstuff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 03a30fe..62a4b42 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -582,7 +582,7 @@ __do_global_ctors_1(void)
 #endif
 
 #ifdef __LIBGCC_JCR_SECTION_NAME__
-  void **jcr_list
+  void **jcr_list;
   __asm ("" : "=g" (jcr_list) : "0" (__JCR_LIST__));
   if (__builtin_expect (*jcr_list != NULL, 0))
 {
-- 
1.8.1.4

[PATCH] mn10300: Fix an ICE

[Segher Boessenkool]

`lcc' is not an insn but just a pattern.  This caused a build error in
libgcc.
Tested with a cross compiler build (which fails without and succeeds
with the patch).  Not tested much more; this compiler really likes to
ICE, something with ipa-icf.

Is this okay for trunk?


Segher


2014-11-24  Segher Boessenkool  

gcc/
* config/mn10300/mn10300.c (mn10300_insert_setlb_lcc): Remove
PATTERN call.

---
 gcc/config/mn10300/mn10300.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/mn10300/mn10300.c b/gcc/config/mn10300/mn10300.c
index 20330f0..1fc64ed 100644
--- a/gcc/config/mn10300/mn10300.c
+++ b/gcc/config/mn10300/mn10300.c
@@ -3217,7 +3217,7 @@ mn10300_insert_setlb_lcc (rtx label, rtx branch)
 lcc = gen_Lcc (comparison, label);
 
   rtx_insn *jump = emit_jump_insn_before (lcc, branch);
-  mark_jump_label (XVECEXP (PATTERN (lcc), 0, 0), jump, 0);
+  mark_jump_label (XVECEXP (lcc, 0, 0), jump, 0);
   JUMP_LABEL (jump) = label;
   DUMP ("Replacing branch insn...", branch);
   DUMP ("... with Lcc insn:", jump);
-- 
1.8.1.4

[PATCH] rs6000: Replace a stray addic with addi

[Segher Boessenkool]

Tested as usual...  okay for trunk?


Segher


2014-11-24  Segher Boessenkool  

gcc/
* config/rs6000/sysv4.h (ASM_OUTPUT_REG_POP): Use addi instead
of addic.

---
 gcc/config/rs6000/sysv4.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/sysv4.h b/gcc/config/rs6000/sysv4.h
index 64c5516..a946936 100644
--- a/gcc/config/rs6000/sysv4.h
+++ b/gcc/config/rs6000/sysv4.h
@@ -457,7 +457,7 @@ do {
\
 do {   \
   if (DEFAULT_ABI == ABI_V4)   \
 asm_fprintf (FILE, \
-"\tlwz %s,12(%s)\n\taddic %s,%s,16\n", \
+"\tlwz %s,12(%s)\n\taddi %s,%s,16\n",  \
 reg_names[REGNO], reg_names[1], reg_names[1],  \
 reg_names[1]); \
 } while (0)
-- 
1.8.1.4

[PATCH] rs6000: Remove iorxor/IORXOR code attrs

[Segher Boessenkool]

As Richard pointed out, those do nothing more than code/CODE.
Tested etc.; okay for trunk?


Segher


2014-11-21  Segher Boessenkool  

gcc/
* config/rs6000/rs6000.md (iorxor, IORXOR): Delete code_attrs.
(rest of file): Replace those with code resp. CODE.

---
 gcc/config/rs6000/rs6000.md | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index fe73acf..c8c3a68 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -460,8 +460,6 @@ (define_code_attr return_str [(return "") (simple_return 
"simple_")])
 
 ; Logical operators.
 (define_code_iterator iorxor [ior xor])
-(define_code_attr iorxor [(ior "ior") (xor "xor")])
-(define_code_attr IORXOR [(ior "IOR") (xor "XOR")])
 
 ; Signed/unsigned variants of ops.
 (define_code_iterator any_extend [sign_extend zero_extend])
@@ -2876,7 +2874,7 @@ (define_insn_and_split "*andsi3_internal6"
   [(set_attr "length" "8")])
 
 
-(define_expand "3"
+(define_expand "3"
   [(set (match_operand:SDI 0 "gpc_reg_operand" "")
(iorxor:SDI (match_operand:SDI 1 "gpc_reg_operand" "")
(match_operand:SDI 2 "reg_or_cint_operand" "")))]
@@ -2884,7 +2882,7 @@ (define_expand "3"
 {
   if (mode == DImode && !TARGET_POWERPC64)
 {
-  rs6000_split_logical (operands, , false, false, false);
+  rs6000_split_logical (operands, , false, false, false);
   DONE;
 }
 
@@ -2898,8 +2896,8 @@ (define_expand "3"
   HOST_WIDE_INT lo = value & 0x;
   HOST_WIDE_INT hi = value - lo;
 
-  emit_insn (gen_3 (tmp, operands[1], GEN_INT (hi)));
-  emit_insn (gen_3 (operands[0], tmp, GEN_INT (lo)));
+  emit_insn (gen_3 (tmp, operands[1], GEN_INT (hi)));
+  emit_insn (gen_3 (operands[0], tmp, GEN_INT (lo)));
   DONE;
 }
 
-- 
1.8.1.4

Re: [C PATCH] Fix PR63877

[Joseph Myers]

On Mon, 24 Nov 2014, Marek Polacek wrote:

> This PR is basically the same as PR54113, except this time it's about
> -Wmissing-declarations and not about -Wmissing-prototypes.  The problem
> here is that we were emitting bogus warning for a correct use of an
> inline function.  Thus fixed in the same way as PR54113, that is, don't
> warn for inline functions.
> 
> Bootstrapped/regtested on ppc64-linux, ok for trunk?
> 
> 2014-11-24  Marek Polacek  
> 
>   PR c/63877
>   * c-decl.c (start_function): Disable -Wmissing-declarations warning
>   for inline functions.
> 
>   * gcc.dg/pr63877.c: New test.

OK.

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

Re: [PATCH][AArch64] Remove crypto extension from default for cortex-a53, cortex-a57

[Gerald Pfeifer]

On Tuesday 2014-11-18 09:38, Kyrill Tkachov wrote:

Here's what I propose.


+  The cryptographic extensions to the ARMv8-A architecture are no
+   longer enabled by default when specifying the
+   -mcpu=cortex-a53, -mcpu=cortex-a57 or
+   -mcpu=cortex-a57.cortex-a53 options.  To enable these
+   extensions add the +crypto extension to your given
+   -mcpu or -march options' value.

"option's"?

Or better "to the value of your...option(s)"?

The description talks about -mcpu and mentions -march only once.
Isn't this a bit confusing?

GeraldIndex: htdocs/gcc-5/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.23
diff -U 3 -r1.23 changes.html
--- htdocs/gcc-5/changes.html	14 Nov 2014 10:49:51 -	1.23
+++ htdocs/gcc-5/changes.html	17 Nov 2014 17:46:41 -
@@ -257,6 +257,13 @@
Alternatively it can be enabled by default by configuring GCC with the
--enable-fix-cortex-a53-835769 option.
  
+  The cryptographic extensions to the ARMv8-A architecture are no
+   longer enabled by default when specifying the
+   -mcpu=cortex-a53, -mcpu=cortex-a57 or
+   -mcpu=cortex-a57.cortex-a53 options.  To enable these
+   extensions add the +crypto extension to your given
+   -mcpu or -march options' value.
+ 
 

 

Re: [Patch] Improving jump-thread pass for PR 54742

[Sebastian Pop]

Sebastian Pop wrote:
> I removed the return -1 and started a bootstrap on powerpc64-linux.

Bootstrap passed on top of the 4 previous patches on powerpc64-linux.

> I will report the valgrind output.

The output from valgrind looks closer to the output of master with no other
patches: still 1M more instructions executed, and 300K more branches

master no-patch:

==129233== I   refs:  13,910,221,913
==129233==
==129233== Branches:   1,925,715,095  (1,879,277,776 cond + 46,437,319 ind)
==129233== Mispredicts:  144,133,332  (  131,510,534 cond + 12,622,798 ind)
==129233== Mispred rate: 7.4% (  6.9% +   27.1%   )

4 previous patches + patch to return 0:

==149012== I   refs:  13,911,870,743
==149012== 
==149012== Branches:   1,926,092,629  (1,879,657,768 cond + 46,434,861 ind)
==149012== Mispredicts:  145,551,513  (  132,827,091 cond + 12,724,422 ind)
==149012== Mispred rate: 7.5% (  7.0% +   27.4%   )

==4492== I   refs:  13,911,899,691
==4492== 
==4492== Branches:   1,926,096,214  (1,879,661,186 cond + 46,435,028 ind)
==4492== Mispredicts:  145,551,707  (  132,827,231 cond + 12,724,476 ind)
==4492== Mispred rate: 7.5% (  7.0% +   27.4%   )

==19521== I   refs:  13,911,855,711
==19521== 
==19521== Branches:   1,926,090,982  (1,879,656,202 cond + 46,434,780 ind)
==19521== Mispredicts:  145,551,343  (  132,826,948 cond + 12,724,395 ind)
==19521== Mispred rate: 7.5% (  7.0% +   27.4%   )

Re: [RFC] First steps towards segregating types.

[Joseph Myers]

On Mon, 24 Nov 2014, Richard Biener wrote:

> > TREE_LIST should die (with the typical replacement being vec);
> > most lists do not need all the overhead of individually allocated objects
> > with (code, flags, type, chain, value, purpose).  Probably TREE_VEC too.
> 
> Note that there is nothing wrong with TREE_LIST or TREE_VEC if
> they were based off tree_base only.  That they inherit from
> tree_common is the bug to fix - either by not using TREE_LIST or
> TREE_VEC from the users that use fields from tree_common or
> tree_typed or by adjusting those users to not need those fields.

Even inheriting from tree_base, typically lists don't need code (because 
you know statically that something is a list) or flags.  And because 
generally something is statically a list or not a list, there is no 
particular benefit from sharing the static type of tree, and better 
compile-time checking if there is no such common base class for list and 
other objects at all.

(Identifiers are another case that doesn't generally benefit from having a 
common static type of tree.)

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

Re: [PATCH v3] Use strtoll instead of atoll in gcov-tool.c

[John David Anglin]

On 15-Sep-14, at 5:40 AM, Richard Biener wrote:


Let's wait for other opinions.


We now have implementations of strtol and strtoll in libiberty.  So,  
it's better to use
these than atoll.  As suggested by Jakub, the patch now falls back to  
int64_t if the

host doesn't have long long.

Tested on hppa2.0w-hpux11.11 and hppa64-hp-hpux11.11.

Okay for trunk?

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




gcov-tool.c.d.3
Description: Binary data

Re: [PATCH v2] gcc/c-family/c-cppbuiltin.c: Let buffer enough to print host wide integer value

[Chen Gang]

OK, thank you for your work, I shall send patch v3 for it.

Send from Lenovo A788t.

Joseph Myers  wrote:

>On Sun, 23 Nov 2014, Chen Gang wrote:
>
>> +  gcc_assert (wi::fits_to_tree_p(value, integer_type_node));
>
>Watch formatting: space before '(' in the wi::fits_to_tree_p call.  
>Applies elsewhere in this patch as well.
>
>When making such an interface change, (a) you should update the comment on 
>builtin_define_with_int_value to explain the new interface, and (b) you 
>should check existing callers to make sure their values are indeed in 
>range, and describe the check you did.
>
>In fact, -fabi-version=0 results in __GXX_ABI_VERSION being defined to 
>99 using builtin_define_with_int_value.  That's out of range of int on 
>targets with 16-bit int.  So that indicates against requiring the value to 
>be within range of int.  It might however be OK to require the value to be 
>within range of target long.
>
>> +  if (value >= 0)
>> +{
>> +  sprintf (buf, "%s="HOST_WIDE_INT_PRINT_DEC"%s",
>> +   macro, value,
>> +   value <= HOST_INT_MAX
>> +   ? ""
>> +   : value <= HOST_LONG_MAX
>> + ? "L" : "LL");
>
>Limits on the host's int and long are completely irrelevant here.  The 
>question is the target's int and long, not the host's - and consistency 
>indicates checking with wi::fits_to_tree_p (value, integer_type_node) if 
>the assertion checked with long_integer_type_node.
>
>-- 
>Joseph S. Myers
>jos...@codesourcery.com

Re: patch to fix PR63897

[H.J. Lu]

On Fri, Nov 21, 2014 at 1:32 PM, Vladimir Makarov  wrote:
> The following patch fixes PR63897.  The details can be found on
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63897
>
> The patch was successfully bootstrapped and tested on x86 and x86-64.
>
> Committed as rev. 217947.
>
> 2014-11-21  Vladimir Makarov  
>
> PR target/63897
> * lra-lives.c (mark_regno_live, mark_regno_dead): Remove last
> argument.
> (process_bb_lives): Rename dead_insn_p on remove_p
> and global_live_info_p on dead_insn_p.  Calculate local live info
> unconditionally.  Remove last argument in calls mark_regno_live and
> mark_regno_dead.  Reorganize body of EXECUTE_IF_SET_IN_BITMAP.
> (lra_create_live_ranges): Rename to lra_create_live_ranges_1.
> Return bool.  Rename global_live_info_p on dead_insn_p.  Return
> flag of live info change.
> (lra_create_live_ranges): New.

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64061

-- 
H.J.

[PATCH] Add verify_sese

[Tom de Vries]

Richard,

I ran into a problem with my oacc kernels directive patch series where 
tail-merge added another entry into a region that was previously 
single-entry-single-exit.


That resulted in hitting this assert in calc_dfs_tree:
...
  /* This aborts e.g. when there is _no_ path from ENTRY to EXIT at all.  */
  gcc_assert (di->nodes == (unsigned int) n_basic_blocks_for_fn (cfun) - 1);
...
during a call to move_sese_region_to_fn.

This patch makes sure that we abort earlier, with a clearer message of what is 
actually wrong.


Bootstrapped and reg-tested on x86_64.

OK for trunk/stage3?

Thanks,
- Tom
2014-11-23  Tom de Vries  

	* tree-cfg.c (verify_sese): New function.
	(move_sese_region_to_fn): Call verify_sese.
	* tree-cfg.h (verify_sese): Declare.
---
 gcc/tree-cfg.c | 55 +++
 gcc/tree-cfg.h |  1 +
 2 files changed, 56 insertions(+)

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index e78554f..db9f6c2 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -6870,6 +6870,58 @@ fixup_loop_arrays_after_move (struct function *fn1, struct function *fn2,
 fixup_loop_arrays_after_move (fn1, fn2, loop);
 }
 
+DEBUG_FUNCTION void
+verify_sese (basic_block entry, basic_block exit, vec *bbs_p)
+{
+  basic_block bb;
+  edge_iterator ei;
+  edge e;
+  bitmap bbs = BITMAP_ALLOC (NULL);
+  int i;
+
+  gcc_assert (entry != NULL);
+  gcc_assert (entry != exit);
+  gcc_assert (bbs_p != NULL);
+
+  gcc_assert (bbs_p->length () > 0);
+
+  FOR_EACH_VEC_ELT (*bbs_p, i, bb)
+bitmap_set_bit (bbs, bb->index);
+
+  gcc_assert (bitmap_bit_p (bbs, entry->index));
+  gcc_assert (exit == NULL || bitmap_bit_p (bbs, exit->index));
+
+  FOR_EACH_VEC_ELT (*bbs_p, i, bb)
+{
+  if (bb == entry)
+	{
+	  gcc_assert (single_pred_p (entry));
+	  gcc_assert (!bitmap_bit_p (bbs, single_pred (entry)->index));
+	}
+  else
+	for (ei = ei_start (bb->preds); !ei_end_p (ei); ei_next (&ei))
+	  {
+	e = ei_edge (ei);
+	gcc_assert (bitmap_bit_p (bbs, e->src->index));
+	  }
+
+  if (bb == exit)
+	{
+	  gcc_assert (single_succ_p (exit));
+	  gcc_assert (!bitmap_bit_p (bbs, single_succ (exit)->index));
+	}
+  else
+	for (ei = ei_start (bb->succs); !ei_end_p (ei); ei_next (&ei))
+	  {
+	e = ei_edge (ei);
+	gcc_assert (bitmap_bit_p (bbs, e->dest->index));
+	  }
+}
+
+  BITMAP_FREE (bbs);
+}
+
+
 /* Move a single-entry, single-exit region delimited by ENTRY_BB and
EXIT_BB to function DEST_CFUN.  The whole region is replaced by a
single basic block in the original CFG and the new basic block is
@@ -6918,6 +6970,9 @@ move_sese_region_to_fn (struct function *dest_cfun, basic_block entry_bb,
   bbs.create (0);
   bbs.safe_push (entry_bb);
   gather_blocks_in_sese_region (entry_bb, exit_bb, &bbs);
+#ifdef ENABLE_CHECKING
+  verify_sese (entry_bb, exit_bb, &bbs);
+#endif
 
   /* The blocks that used to be dominated by something in BBS will now be
  dominated by the new block.  */
diff --git a/gcc/tree-cfg.h b/gcc/tree-cfg.h
index 626e973..d35e5ba 100644
--- a/gcc/tree-cfg.h
+++ b/gcc/tree-cfg.h
@@ -73,6 +73,7 @@ extern bool gimple_duplicate_sese_tail (edge, edge, basic_block *, unsigned,
   basic_block *);
 extern void gather_blocks_in_sese_region (basic_block entry, basic_block exit,
 	  vec *bbs_p);
+extern void verify_sese (basic_block, basic_block, vec *);
 extern basic_block move_sese_region_to_fn (struct function *, basic_block,
    basic_block, tree);
 extern void dump_function_to_file (tree, FILE *, int);
-- 
1.9.1

Re: [PATCH v2] gcc/c-family/c-cppbuiltin.c: Let buffer enough to print host wide integer value

[Joseph Myers]

On Sun, 23 Nov 2014, Chen Gang wrote:

> +  gcc_assert (wi::fits_to_tree_p(value, integer_type_node));

Watch formatting: space before '(' in the wi::fits_to_tree_p call.  
Applies elsewhere in this patch as well.

When making such an interface change, (a) you should update the comment on 
builtin_define_with_int_value to explain the new interface, and (b) you 
should check existing callers to make sure their values are indeed in 
range, and describe the check you did.

In fact, -fabi-version=0 results in __GXX_ABI_VERSION being defined to 
99 using builtin_define_with_int_value.  That's out of range of int on 
targets with 16-bit int.  So that indicates against requiring the value to 
be within range of int.  It might however be OK to require the value to be 
within range of target long.

> +  if (value >= 0)
> +{
> +  sprintf (buf, "%s="HOST_WIDE_INT_PRINT_DEC"%s",
> +macro, value,
> +value <= HOST_INT_MAX
> +? ""
> +: value <= HOST_LONG_MAX
> +  ? "L" : "LL");

Limits on the host's int and long are completely irrelevant here.  The 
question is the target's int and long, not the host's - and consistency 
indicates checking with wi::fits_to_tree_p (value, integer_type_node) if 
the assertion checked with long_integer_type_node.

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

Re: [Patch] Improving jump-thread pass for PR 54742

[Sebastian Pop]

Jeff Law wrote:
> On 11/23/14 15:22, Sebastian Pop wrote:
> >Jeff Law wrote:
> >>>PS: I have run some perf analysis with the patch:
> >>>- on a bootstrap of GCC I see 3209 FSM jump threads
> >>>- libpng and libjpeg contain FSM jump threads, the perf increase is in the 
> >>>1%
> >>>   (measured on simulators and reduced data sets)
> >>>- coremark gets jump threaded (as expected)
> >>>- I'm setting up the llvm test-suite and I will report perf differences
> >>So that's *far* more jump threads than I would expect this to find
> >>in a bootstrap of GCC -- like 3 orders of magnitude more than I'd
> >>expect to find.
> >
> >The second patch attached limits the search for FSM jump threads to loops.  
> >With
> >that patch, we are now down to 470 jump threads in an x86_64-linux bootstrap
> >(and 424 jump threads on powerpc64-linux bootstrap.)
> [ ... ]
> 
> So why are we returning -1 (block should not be duplicated and not
> suitable for a joiner) at the end of thread_through_normal_block?
> 
> 
>   /* When COND cannot be simplified, try to find paths from a control
>  statement back through the PHI nodes which would affect
> that control
>  statement.  */
>   vec *bb_path;
>   vec_alloc (bb_path, n_basic_blocks_for_fn (cfun));
>   vec_safe_push (bb_path, e->dest);
>   hash_set *visited_phis = new hash_set;
> 
>   max_threaded_paths = PARAM_VALUE (PARAM_MAX_FSM_THREAD_PATHS);
>   fsm_find_control_statement_thread_paths (cond, visited_phis,
> bb_path);
> 
>   delete visited_phis;
>   vec_free (bb_path);
> 
>   return -1;
> 
> Returning -1 (instead of 0) says stop, there's no possibility to
> threading something on that path.   I think that's suppressing some
> profitable jump threads.  

Thanks for spotting this.

> I haven't done  more than verify the
> bitmap code returns to its prior state with that change.

I removed the return -1 and started a bootstrap on powerpc64-linux.
I will report the valgrind output.

Thanks,
Sebastian

[committed] Replace abort instruction with __builtin_trap() in config/pa/linux_atomic.c

[John David Anglin]

The attached change uses __builtin_trap() instead of an asm as the  
compiler can better

optimize code using __builtin_trap.

Tested on hppa-unknown-linux-gnu.  Committed to trunk.

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


2014-11-24  John David Anglin  

* config/pa/linux-atomic.c (ABORT_INSTRUCTION): Use __builtin_trap()
instead.

Index: config/pa/linux-atomic.c
===
--- config/pa/linux-atomic.c(revision 217974)
+++ config/pa/linux-atomic.c(working copy)
@@ -41,9 +41,6 @@
using the kernel helper defined below.  There is no support for
64-bit operations yet.  */
 
-/* A privileged instruction to crash a userspace program with SIGILL.  */
-#define ABORT_INSTRUCTION asm ("iitlbp %r0,(%sr0, %r0)")
-
 /* Determine kernel LWS function call (0=32-bit, 1=64-bit userspace).  */
 #define LWS_CAS (sizeof(long) == 4 ? 0 : 1)
 
@@ -64,7 +61,7 @@
: "r1", "r20", "r22", "r23", "r29", "r31", "memory"
   );
   if (__builtin_expect (lws_errno == -EFAULT || lws_errno == -ENOSYS, 0))
-ABORT_INSTRUCTION;
+__builtin_trap ();
 
   /* If the kernel LWS call succeeded (lws_errno == 0), lws_ret contains
  the old value from memory.  If this value is equal to OLDVAL, the
@@ -91,7 +88,7 @@
: "r1", "r20", "r22", "r29", "r31", "fr4", "memory"
   );
   if (__builtin_expect (lws_errno == -EFAULT || lws_errno == -ENOSYS, 0))
-ABORT_INSTRUCTION;
+__builtin_trap ();
 
   /* If the kernel LWS call fails, retrun EBUSY */
   if (!lws_errno && lws_ret)

[PATCH] Fix building of gengtype

[Jakub Jelinek]

Hi!

My last 2 bootstraps failed, both because of a race while building
host gengtype (each time different gengtype*.o).

Looking at the history, we have two versions of gengtype, one in build/,
another one in . (host one).
Initially, the copy in build/ was built with -DGENERATOR_FILE, included
bconfig.h, the other did not and included config.h.
Then, Steven noticed that eventhough gengtype is built for host, it really
for many reasons need GENERATOR_FILE define and defined it in the Makefile.
Except that change resulted in always including bconfig.h even in host
gengtype, which is presumably undesirable.
After another half a year Marcus probably hit similar race like I did
tonight, make trying to build host gengtype*.o when bconfig.h has not been
generated yet, and added for gengtype-lex.o $(BCONFIG_H) dependency
(but not to any other of the gengtype*.o files).

Note, config.h has an #error for #ifdef GENERATOR_FILE, to prevent people
from including config.h in build/gen* stuff by mistake.

So, this patch fixes this by just using a different define and defines
GENERATOR_FILE only after including config.h in the host gengtype* object
files.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2014-11-25  Jakub Jelinek  

* Makefile.in (gengtype-lex.o): Drop dependency on $(BCONFIG_H).
(CFLAGS-gengtype-lex.o, CFLAGS-gengtype-parse.o,
CFLAGS-gengtype-state.o, CFLAGS-gengtype.o): Add -DHOST_GENGTYPE
instead of -DGENERATOR_FILE.
* gengtype.c: Instead of testing GENERATOR_FILE define, test
HOST_GENGTYPE.  If defined, include config.h and define GENERATOR_FILE
afterwards, otherwise include bconfig.h.
* gengtype-parse.c, gengtype-state.c, gengtype-lex.l): Likewise.

--- gcc/Makefile.in.jj  2014-11-18 18:17:53.0 +0100
+++ gcc/Makefile.in 2014-11-24 21:43:47.960196848 +0100
@@ -2485,27 +2485,27 @@ build/gengenrtl.o : gengenrtl.c $(BCONFI
 # the build-%: rule doesn't apply to them.
 
 gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H)
-gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H)
-CFLAGS-gengtype-lex.o += -DGENERATOR_FILE
+gengtype-lex.o: $(CONFIG_H)
+CFLAGS-gengtype-lex.o += -DHOST_GENGTYPE
 build/gengtype-lex.o: $(BCONFIG_H)
 
 gengtype-parse.o build/gengtype-parse.o : gengtype-parse.c gengtype.h \
   $(SYSTEM_H)
 gengtype-parse.o: $(CONFIG_H)
-CFLAGS-gengtype-parse.o += -DGENERATOR_FILE
+CFLAGS-gengtype-parse.o += -DHOST_GENGTYPE
 build/gengtype-parse.o: $(BCONFIG_H)
 
 gengtype-state.o build/gengtype-state.o: gengtype-state.c $(SYSTEM_H) \
   gengtype.h errors.h double-int.h version.h $(HASHTAB_H) $(OBSTACK_H) \
   $(XREGEX_H)
 gengtype-state.o: $(CONFIG_H)
-CFLAGS-gengtype-state.o += -DGENERATOR_FILE
+CFLAGS-gengtype-state.o += -DHOST_GENGTYPE
 build/gengtype-state.o: $(BCONFIG_H)
 gengtype.o build/gengtype.o : gengtype.c $(SYSTEM_H) gengtype.h\
   rtl.def insn-notes.def errors.h double-int.h version.h   \
   $(HASHTAB_H) $(OBSTACK_H) $(XREGEX_H)
 gengtype.o: $(CONFIG_H)
-CFLAGS-gengtype.o += -DGENERATOR_FILE
+CFLAGS-gengtype.o += -DHOST_GENGTYPE
 build/gengtype.o: $(BCONFIG_H)
 
 build/genmddeps.o: genmddeps.c $(BCONFIG_H) $(SYSTEM_H) coretypes.h\
--- gcc/gengtype.c.jj   2014-11-20 17:06:24.0 +0100
+++ gcc/gengtype.c  2014-11-24 21:44:30.746446814 +0100
@@ -17,10 +17,11 @@
along with GCC; see the file COPYING3.  If not see
.  */
 
-#ifdef GENERATOR_FILE
-#include "bconfig.h"
-#else
+#ifdef HOST_GENGTYPE
 #include "config.h"
+#define GENERATOR_FILE 1
+#else
+#include "bconfig.h"
 #endif
 #include "system.h"
 #include "errors.h"/* for fatal */
--- gcc/gengtype-parse.c.jj 2014-09-25 15:03:05.0 +0200
+++ gcc/gengtype-parse.c2014-11-24 21:45:19.905585065 +0100
@@ -17,10 +17,11 @@
along with GCC; see the file COPYING3.  If not see
.  */
 
-#ifdef GENERATOR_FILE
-#include "bconfig.h"
-#else
+#ifdef HOST_GENGTYPE
 #include "config.h"
+#define GENERATOR_FILE 1
+#else
+#include "bconfig.h"
 #endif
 #include "system.h"
 #include "gengtype.h"
--- gcc/gengtype-state.c.jj 2014-09-25 15:01:57.0 +0200
+++ gcc/gengtype-state.c2014-11-24 21:44:59.293946382 +0100
@@ -23,10 +23,11 @@
and Basile Starynkevitch 
 */
 
-#ifdef GENERATOR_FILE
-#include "bconfig.h"
-#else
+#ifdef HOST_GENGTYPE
 #include "config.h"
+#define GENERATOR_FILE 1
+#else
+#include "bconfig.h"
 #endif
 #include "system.h"
 #include "errors.h"/* For fatal.  */
--- gcc/gengtype-lex.l.jj   2014-09-25 15:02:45.0 +0200
+++ gcc/gengtype-lex.l  2014-11-24 21:45:41.486206761 +0100
@@ -21,10 +21,11 @@ along with GCC; see the file COPYING3.
 %option noinput
 
 %{
-#ifdef GENERATOR_FILE
-#include "bconfig.h"
-#else
+#ifdef HOST_GENGTYPE
 #include "config.h"
+#define GENERATOR_FILE 1
+#else
+#include "bconfig.h"
 #endif
 #include "system.h"
 

Jakub

Re: [Patch, Fortran] Remove gfc_fatal_error_1

[Tobias Burnus]

Tobias Burnus wrote:
It converts the remaining fatal error calls to the common diagnostic 
infrastructure and retires (removes) the old gfc_fatal_error_1.


I will build and regtest it after Manuel's commit.
OK, when it succeeds?


The patch needed additionally a '...' added in two test-suite files due 
to %<...%> and the attached patch, which was committed as Rev.  218029.


Tobias
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 218028)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,6 +1,12 @@
+2014-11-24  Tobias Burnus  
+
+	* gfortran.dg/coarray_collectives_3.f90: Add dg-excess-errors.
+	* gfortran.dg/dollar_sym_1.f90: Ditto.
+	* gfortran.dg/dollar_sym_3.f: Ditto.
+
 2014-11-24  Alan Lawrence  
 
-* lib/target-supports.exp (check_effective_target_whole_vector_shift):
+	* lib/target-supports.exp (check_effective_target_whole_vector_shift):
 	Add aarch64{,_be}.
 
 2014-11-24  Richard Biener  
@@ -43,7 +49,7 @@
 2014-11-24  Tobias Burnus  
 
 	* gfortran.dg/dollar_sym_3.f: Update dg-error.
-	* gfortran.dg/dollar_sym_3.f: Ditto.
+	* gfortran.dg/coarray_collectives_3.f90: Ditto.
 
 2014-11-23  David Edelsohn  
 
Index: gcc/testsuite/gfortran.dg/coarray_collectives_3.f90
===
--- gcc/testsuite/gfortran.dg/coarray_collectives_3.f90	(Revision 218028)
+++ gcc/testsuite/gfortran.dg/coarray_collectives_3.f90	(Arbeitskopie)
@@ -8,3 +8,4 @@ program test
   integer :: val
   call co_max(val) ! { dg-error "Coarrays disabled at .1., use '-fcoarray=' to enable" }
 end program test
+! { dg-excess-errors "compilation terminated" }
Index: gcc/testsuite/gfortran.dg/dollar_sym_1.f90
===
--- gcc/testsuite/gfortran.dg/dollar_sym_1.f90	(Revision 218028)
+++ gcc/testsuite/gfortran.dg/dollar_sym_1.f90	(Arbeitskopie)
@@ -7,3 +7,4 @@
   PARAMETER (PLT$B_OPC=0) !  Unreachable as the error above is now fatal
   common /abc$def/ PLT$C_HOUSTPIX, PLT$C_COMMAND !  Unreachable as the error above is now fatal
   end
+! { dg-excess-errors "compilation terminated" }
Index: gcc/testsuite/gfortran.dg/dollar_sym_3.f
===
--- gcc/testsuite/gfortran.dg/dollar_sym_3.f	(Revision 218028)
+++ gcc/testsuite/gfortran.dg/dollar_sym_3.f	(Arbeitskopie)
@@ -8,3 +8,4 @@ c Segmentation fault in gfc_restore_last_undo_chec
   COMMON RADE3155V62$JUTMU9L9E(3,3,3), LADE314JUTMP9 ! { dg-error "Invalid character '\\$' at .1.. Use '-fdollar-ok' to allow it as an extension" }
  +LHEDDJNTMP9L(3,3,3)   
   end
+! { dg-excess-errors "compilation terminated" }

[PATCH] Fix find_base_term in 32-bit -fpic code (PR lto/64025)

[Jakub Jelinek]

Hi!

The fallback delegitimization I've added as last option mainly for
debug info purposes, when we don't know if the base is a PIC register
or say a PIC register plus some addend, unfortunately in some tests
broke find_base_term, which for PLUS looks only at the first operand
and recursion on it finds a base term, it returns it immediately.
So, it found base term of _GLOBAL_OFFSET_TABLE_, when the right base
term is actually in the second operand.

This patch fixes it by swapping the operands, debug info doesn't care about
the order, it won't match in any instruction anyway, but helps alias.c.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2014-11-24  Jakub Jelinek  

PR lto/64025
* config/i386/i386.c (ix86_delegitimize_address): Ensure result
comes before (addend - _GLOBAL_OFFSET_TABLE_) term.

--- gcc/config/i386/i386.c.jj   2014-11-24 10:26:26.0 +0100
+++ gcc/config/i386/i386.c  2014-11-24 20:17:27.659091709 +0100
@@ -14848,7 +14848,7 @@ ix86_delegitimize_address (rtx x)
 ...
 movl foo@GOTOFF(%ecx), %edx
 in which case we return (%ecx - %ebx) + foo
-or (%ecx - _GLOBAL_OFFSET_TABLE_) + foo if pseudo_pic_reg
+or foo + (%ecx - _GLOBAL_OFFSET_TABLE_) if pseudo_pic_reg
 and reload has completed.  */
   if (pic_offset_table_rtx
  && (!reload_completed || !ix86_use_pseudo_pic_reg ()))
@@ -14859,7 +14859,14 @@ ix86_delegitimize_address (rtx x)
{
  rtx tmp = gen_rtx_SYMBOL_REF (Pmode, GOT_SYMBOL_NAME);
  tmp = gen_rtx_MINUS (Pmode, copy_rtx (addend), tmp);
- result = gen_rtx_PLUS (Pmode, tmp, result);
+ /* The order of the operands here is very important.  find_base_term
+will only recurse into the first operand of PLUS if none of the
+arguments is REG with REG_POINTER_P set on it, and if that finds
+base term, it doesn't recurse into the second operand of PLUS.
+We don't want find_base_term to return the artificial
+_GLOBAL_OFFSET_TABLE_ symbol, so ensure it goes into the
+second operand.  */
+ result = gen_rtx_PLUS (Pmode, result, tmp);
}
   else
return orig_x;

Jakub

[PATCH] Fix linemap_line_start (PR preprocessor/60436)

[Jakub Jelinek]

Hi!

As mentioned in the PR, when preprocessing very large files, if there are
huge numbers of lines where no #line is emitted, we might not detect
overflowinging into adhoc locations.
Apparently in the add_map case we already handle that fine, by first
stopping tracking columns and after another 256M lines give up on tracking
locations, so this patch just makes sure we enter that path if
going over those limits.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2014-11-24  Jakub Jelinek  

PR preprocessor/60436
* line-map.c (linemap_line_start): If highest is above 0x6000
and we are still tracking columns or highest is above 0x7000,
force add_map.

--- libcpp/line-map.c.jj2014-11-12 08:06:57.0 +0100
+++ libcpp/line-map.c   2014-11-24 12:14:52.691276169 +0100
@@ -529,10 +529,10 @@ linemap_line_start (struct line_maps *se
  && line_delta * ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) > 1000)
   || (max_column_hint >= (1U << ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map)))
   || (max_column_hint <= 80
- && ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) >= 10))
-{
-  add_map = true;
-}
+ && ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) >= 10)
+  || (highest > 0x6000
+ && (set->max_column_hint || highest > 0x7000)))
+add_map = true;
   else
 max_column_hint = set->max_column_hint;
   if (add_map)
@@ -543,7 +543,7 @@ linemap_line_start (struct line_maps *se
  /* If the column number is ridiculous or we've allocated a huge
 number of source_locations, give up on column numbers. */
  max_column_hint = 0;
- if (highest >0x7000)
+ if (highest > 0x7000)
return 0;
  column_bits = 0;
}

Jakub

[committed] Fix !$omp atomic handling (PR fortran/63938)

[Jakub Jelinek]

Hi!

This fixes Fortran !$omp atomic handling to match C/C++, goa_lhs_expr_p
is not able to find out matches of more complex expressions after tree
unsharing, so this patch helps it find what it needs.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
Will backport soon.

2014-11-24  Jakub Jelinek  

PR fortran/63938
* trans-openmp.c (gfc_trans_omp_atomic): Make sure lhsaddr is
simple enough for goa_lhs_expr_p.

* libgomp.fortran/pr63938-1.f90: New test.
* libgomp.fortran/pr63938-2.f90: New test.

--- gcc/fortran/trans-openmp.c.jj   2014-10-10 13:07:42.0 +0200
+++ gcc/fortran/trans-openmp.c  2014-11-24 11:25:40.157171398 +0100
@@ -2683,6 +2683,18 @@ gfc_trans_omp_atomic (gfc_code *code)
 }
 
   lhsaddr = save_expr (lhsaddr);
+  if (TREE_CODE (lhsaddr) != SAVE_EXPR
+  && (TREE_CODE (lhsaddr) != ADDR_EXPR
+ || TREE_CODE (TREE_OPERAND (lhsaddr, 0)) != VAR_DECL))
+{
+  /* Make sure LHS is simple enough so that goa_lhs_expr_p can recognize
+it even after unsharing function body.  */
+  tree var = create_tmp_var_raw (TREE_TYPE (lhsaddr), NULL);
+  DECL_CONTEXT (var) = current_function_decl;
+  lhsaddr = build4 (TARGET_EXPR, TREE_TYPE (lhsaddr), var, lhsaddr,
+   NULL_TREE, NULL_TREE);
+}
+
   rhs = gfc_evaluate_now (rse.expr, &block);
 
   if (((atomic_code->ext.omp_atomic & GFC_OMP_ATOMIC_MASK)
--- libgomp/testsuite/libgomp.fortran/pr63938-1.f90.jj  2014-11-24 
11:27:33.060113895 +0100
+++ libgomp/testsuite/libgomp.fortran/pr63938-1.f90 2014-11-24 
11:28:13.339379860 +0100
@@ -0,0 +1,14 @@
+! PR fortran/63938
+! { dg-do run }
+
+program pr63938_1
+  integer :: i, x(1)
+  x(1) = 0
+!$omp parallel do
+  do i = 1, 1000
+!$omp atomic
+x(1) = x(1) + 1
+  end do
+!$omp end parallel do
+  if (x(1) .ne. 1000) call abort
+end program pr63938_1
--- libgomp/testsuite/libgomp.fortran/pr63938-2.f90.jj  2014-11-24 
11:28:22.836206793 +0100
+++ libgomp/testsuite/libgomp.fortran/pr63938-2.f90 2014-11-24 
11:28:53.217653132 +0100
@@ -0,0 +1,18 @@
+! PR fortran/63938
+! { dg-do run }
+
+program pr63938_2
+  type t
+integer :: x
+  end type
+  integer :: i
+  type(t) :: x
+  x%x = 0
+!$omp parallel do
+  do i = 1, 1000
+!$omp atomic
+x%x = x%x + 1
+  end do
+!$omp end parallel do
+  if (x%x .ne. 1000) call abort
+end program pr63938_2

Jakub

Re: [Patch] Improving jump-thread pass for PR 54742

[Jeff Law]

On 11/23/14 15:22, Sebastian Pop wrote:

Jeff Law wrote:

PS: I have run some perf analysis with the patch:
- on a bootstrap of GCC I see 3209 FSM jump threads
- libpng and libjpeg contain FSM jump threads, the perf increase is in the 1%
   (measured on simulators and reduced data sets)
- coremark gets jump threaded (as expected)
- I'm setting up the llvm test-suite and I will report perf differences

So that's *far* more jump threads than I would expect this to find
in a bootstrap of GCC -- like 3 orders of magnitude more than I'd
expect to find.


The second patch attached limits the search for FSM jump threads to loops.  With
that patch, we are now down to 470 jump threads in an x86_64-linux bootstrap
(and 424 jump threads on powerpc64-linux bootstrap.)

[ ... ]

So why are we returning -1 (block should not be duplicated and not 
suitable for a joiner) at the end of thread_through_normal_block?



  /* When COND cannot be simplified, try to find paths from a control
 statement back through the PHI nodes which would affect that 
control

 statement.  */
  vec *bb_path;
  vec_alloc (bb_path, n_basic_blocks_for_fn (cfun));
  vec_safe_push (bb_path, e->dest);
  hash_set *visited_phis = new hash_set;

  max_threaded_paths = PARAM_VALUE (PARAM_MAX_FSM_THREAD_PATHS);
  fsm_find_control_statement_thread_paths (cond, visited_phis, 
bb_path);


  delete visited_phis;
  vec_free (bb_path);

  return -1;

Returning -1 (instead of 0) says stop, there's no possibility to 
threading something on that path.   I think that's suppressing some 
profitable jump threads.  I haven't done  more than verify the bitmap 
code returns to its prior state with that change.


jeff

Re: PR 13631 Problems in messages

[François Dumont]

On 24/11/2014 01:23, Jonathan Wakely wrote:

On 24/11/14 00:13 +0100, François Dumont wrote:

Hello

   As we are at doing some evolution in the ABI I would like to take 
the opportunity to merge branch libstdcxx_so_7-2. The first fix was 


I don't think we want to merge everything, but it's certainly worth
looking to see if there are some fixes on that branch worth taking.


Indeed, there are only 2 patches on this branch and haven't plan to 
merge the other one for the debug mode. We will just be able to close 
the branch then.




It would have been better to do during stage 1 though :-\


Sorry about that, I submit patches when I can and you can delay them as 
you want to. Just tell me about when we will be able to make it in.




about a messages facet issue. So here is the version for the trunk 
which is the one from the branch plus management of the charset part. 
This way messages works too.


   There are still some uncovered points in this patch:
- I had to make codecvt _M_c_locale_codecvt public to access it from 
the messages facet code. How do you want to handle it properly ? A 
friend function to access it or do I make messages facet friend ?
- I haven't use the ABI tag yet. I know that there is a plan to tag 
locale facets, will it work for what I am doing ?


Unless I'm missing something you're not making any ABI changes to
std::messages, just making the definitiosn of some functions no longer
inline.


Yes, this is indeed what had been identified as the ABI breaking change, 
not a big one. Considering it now I think it is not a real one. 
Applications built with the former library will have an inlined wrong 
behavior. Application rebuilt will use the new correct one, is there 
really a problem ?




   Note that I could use std::tuple instead of combination of 
std::pair and std::unique_ptr instead of wchar_buffer if we were 
building it in C++11 mode. Is it possible ?


Yes, the symlink to the messages_members.cc file would need to be
moved from src/c++98/Makefile.am to src/c++11/Makefile.am


Index: include/bits/locale_facets_nonio.h
===
--- include/bits/locale_facets_nonio.h(revision 217816)
+++ include/bits/locale_facets_nonio.h(working copy)
@@ -1842,22 +1842,6 @@
  */
  virtual void
  do_close(catalog) const;
-
-  // Returns a locale and codeset-converted string, given a 
char* message.

-  char*
-  _M_convert_to_char(const string_type& __msg) const
-  {
-// XXX
-return reinterpret_cast(const_cast<_CharT*>(__msg.c_str()));
-  }
-
-  // Returns a locale and codeset-converted string, given a 
char* message.

-  string_type
-  _M_convert_from_char(char*) const
-  {
-// XXX
-return string_type();
-  }
 };


Those members are used by the ieee_1003.1-2001 locale.



Yes, I had plan to check but forgot.

I will prepare an updated version of this patch with those information 
and we will see how to handle it.


François

Re: [Patch] Improving jump-thread pass for PR 54742

[Jeff Law]

On 11/24/14 15:05, Sebastian Pop wrote:


I did an experiment around these lines over the week-end, and now that you
mention it, I feel less shy to speak about; well the patch does not yet pass
bootstrap, and there still are about 20 failing test-cases.  I feel better
reading the code generation part of jump-threading after this patch ;-)
Basically I think all the tree-ssa-threadupdate.c can be replaced by
duplicate_seme_region that generalizes the code generation.
Clearly next stage1 stuff, but definitely the right direction IMHO.  If 
you get the chance look at Bodik's thesis.As far as I know he's the 
only person to really look at how to structure context sensitive 
optimizations in a sane way.






I got my scripts installed on the gcc-farm.  I first used an x86_64 gcc75 and
valgrind was crashing not recognizing how to decode an instruction.  Then I
moved to gcc112 a powerpc64-linux where I got this data from stage2 cc1plus
compiling the same file alias.ii at -O2: (I got 3 runs of each mostly because
there is a bit of noise in all these numbers)
Yea, glibc & valgrind really need to update in lock-step as glibc gains 
support for new ISAs.  Certain instructions are supposed to be 
interpreted as nops, but valgrind instead raises an illegal instruction.


There's a bit of noise when using valgrind like this, but it has 
definitely proven useful in the past.


I'm looking at bitmap_ior_and_compl right now.  Not sure if cg_annotate 
is sending me on a wild goose chase yet or not.


jeff

Re: [Patch] Improving jump-thread pass for PR 54742

[Sebastian Pop]

Sebastian Pop wrote:
> > Using a SEME region copier is also something I really wanted to do
> > long term.  In fact, I believe a lot of tree-ssa-threadupdate.c
> > ought to be ripped out and replaced with a SEME based copier.
> 
> I did an experiment around these lines over the week-end, and now that you
> mention it, I feel less shy to speak about; well the patch does not yet pass
> bootstrap, and there still are about 20 failing test-cases.  I feel better
> reading the code generation part of jump-threading after this patch ;-)
> Basically I think all the tree-ssa-threadupdate.c can be replaced by
> duplicate_seme_region that generalizes the code generation.

For reference, here is the patch I am speaking about.

Sebastian
>From c7213811e2ec2443df9ffc3ca72b3b15a6c9aaf9 Mon Sep 17 00:00:00 2001
From: Sebastian Pop 
Date: Fri, 21 Nov 2014 13:17:12 -0600
Subject: [PATCH 2/3] use duplicate_seme to generate code for jump threading

---
 gcc/tree-cfg.c  |  142 +++
 gcc/tree-cfg.h  |2 +
 gcc/tree-ssa-threadedge.c   |   61 +-
 gcc/tree-ssa-threadupdate.c | 2487 +--
 gcc/tree-ssa-threadupdate.h |   23 +-
 5 files changed, 222 insertions(+), 2493 deletions(-)

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index 6d96c52..d6dc442 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -6120,6 +6120,148 @@ gimple_duplicate_sese_region (edge entry, edge exit,
   return true;
 }
 
+/* Duplicates a REGION (set of N_REGION basic blocks).  The edge ENTRY is
+   redirected to the duplicate of the region.  Dominance and loop information is
+   updated if UPDATE_DOMINANCE is true, but not the SSA web.  If
+   UPDATE_DOMINANCE is false then we assume that the caller will update the
+   dominance information after calling this function.  The new basic blocks are
+   stored to REGION_COPY in the same order as they had in REGION, provided that
+   REGION_COPY is not NULL.
+
+   Returns false if it is unable to copy the region, true otherwise.  */
+
+bool
+gimple_duplicate_seme_region (edge entry,
+			  basic_block *region, unsigned n_region,
+			  basic_block *region_copy,
+			  bool update_dominance)
+{
+  unsigned i;
+  bool free_region_copy = false, copying_header = false;
+  struct loop *loop = entry->dest->loop_father;
+  vec doms;
+  edge redirected;
+  int memo_loop_header_no = 0, memo_loop_latch_no = 0;
+  int total_freq = 0, entry_freq = 0;
+  gcov_type total_count = 0, entry_count = 0;
+
+  if (!can_copy_bbs_p (region, n_region))
+return false;
+
+  /* Some sanity checking.  Note that we do not check for all possible
+ missuses of the functions.  I.e. if you ask to copy something weird,
+ it will work, but the state of structures probably will not be
+ correct.  */
+  for (i = 0; i < n_region; i++)
+{
+  /* We do not handle subloops, i.e. all the blocks must belong to the
+	 same loop.  */
+  if (region[i]->loop_father != loop)
+	return false;
+
+  /* If we are copying a region that starts and ends in an arbirary place in
+	 the loop: keep track of which block will become our loop header.  */
+  if (region[i] != entry->dest && region[i] == loop->header)
+	memo_loop_header_no = i;
+
+  /* And which block will become our loop latch.  */
+  if (region[i] != entry->src && region[i] == loop->latch)
+	memo_loop_latch_no = i;
+}
+
+  initialize_original_copy_tables ();
+
+  if (copying_header)
+set_loop_copy (loop, loop_outer (loop));
+  else
+set_loop_copy (loop, loop);
+
+  if (!region_copy)
+{
+  region_copy = XNEWVEC (basic_block, n_region);
+  free_region_copy = true;
+}
+
+  /* Record blocks outside the region that are dominated by something
+ inside.  */
+  if (update_dominance)
+{
+  doms.create (0);
+  doms = get_dominated_by_region (CDI_DOMINATORS, region, n_region);
+}
+
+  if (entry->dest->count)
+{
+  total_count = entry->dest->count;
+  entry_count = entry->count;
+  /* Fix up corner cases, to avoid division by zero or creation of negative
+	 frequencies.  */
+  if (entry_count > total_count)
+	entry_count = total_count;
+}
+  else
+{
+  total_freq = entry->dest->frequency;
+  entry_freq = EDGE_FREQUENCY (entry);
+  /* Fix up corner cases, to avoid division by zero or creation of negative
+	 frequencies.  */
+  if (total_freq == 0)
+	total_freq = 1;
+  else if (entry_freq > total_freq)
+	entry_freq = total_freq;
+}
+
+  copy_bbs (region, n_region, region_copy, NULL, 0, NULL, loop,
+	split_edge_bb_loc (entry), update_dominance);
+  if (total_count)
+{
+  scale_bbs_frequencies_gcov_type (region, n_region,
+   total_count - entry_count,
+   total_count);
+  scale_bbs_frequencies_gcov_type (region_copy, n_region, entry_count,
+   total_count);
+}
+  else
+{
+  scale_bbs_frequencies_int (region, n_region, total_freq - entry_freq,
+ total_freq);
+ 

Re: [Patch] Improving jump-thread pass for PR 54742

[Sebastian Pop]

Jeff Law wrote:
> On 11/23/14 15:22, Sebastian Pop wrote:
> >The second patch attached limits the search for FSM jump threads to loops.  
> >With
> >that patch, we are now down to 470 jump threads in an x86_64-linux bootstrap
> >(and 424 jump threads on powerpc64-linux bootstrap.)
> >
> Yea, that was one of the things I was going to poke at as well as a
> quick scan of your patch gave me the impression it wasn't limited to
> loops.
> 
> Again, I haven't looked much at the patch, but I got the impression
> you're doing a backwards walk through the predecessors to discover
> the result of the COND_EXPR.  Correct?

Yes.

> 
> That's something I'd been wanting to do -- basically start with a
> COND_EXPR, then walk the dataflow backwards substituting values into
> the COND_EXPR (possibly creating non-gimple).  Ultimately the goal
> is to substitute and fold, getting to a constant :-)
> 
> The forward exhaustive stuff we do now is, crazy.   The backwards
> approach could be decoupled from DOM & VRP into an independent pass,
> which I think would be wise.
> 
> Using a SEME region copier is also something I really wanted to do
> long term.  In fact, I believe a lot of tree-ssa-threadupdate.c
> ought to be ripped out and replaced with a SEME based copier.

I did an experiment around these lines over the week-end, and now that you
mention it, I feel less shy to speak about; well the patch does not yet pass
bootstrap, and there still are about 20 failing test-cases.  I feel better
reading the code generation part of jump-threading after this patch ;-)
Basically I think all the tree-ssa-threadupdate.c can be replaced by
duplicate_seme_region that generalizes the code generation.

> 
> It appears you've built at least parts of two pieces needed to all
> this as a Bodik style optimizer.  Which is exactly the long term
> direction I think this code ought to take.
> 
> 
> >
> >One of the reasons I think we see more branches is that in sese region 
> >copying we
> >do not use the knowledge of the value of the condition for the last branch 
> >in a
> >jump-thread path: we rely on other propagation passes to remove the branch.  
> >The
> >last attached patch adds:
> >
> >   /* Remove the last branch in the jump thread path.  */
> >   remove_ctrl_stmt_and_useless_edges (region_copy[n_region - 1], 
> > exit->dest);
> That's certainly a possibility.  But I would expect that even with
> this limitation something would be picking up the fact that the
> branch is statically computable (even if it's an RTL optimizer).
> But it's definitely something to look for.
> 
> >
> >Please let me know if the attached patches are producing better results on 
> >gcc.
> 
> For the trunk:
>   instructions:1339016494968
>   branches :243568982489
> 
> First version of your patch:
> 
>   instructions:1339739533291
>   branches: 243806615986
> 
> Latest version of your patch:
> 
>   instructions:1339749122609
>   branches: 243809838262

I think I got about the same results.

I got my scripts installed on the gcc-farm.  I first used an x86_64 gcc75 and
valgrind was crashing not recognizing how to decode an instruction.  Then I
moved to gcc112 a powerpc64-linux where I got this data from stage2 cc1plus
compiling the same file alias.ii at -O2: (I got 3 runs of each mostly because
there is a bit of noise in all these numbers)

$ valgrind --tool=cachegrind --cache-sim=no --branch-sim=yes ./cc1plus -O2 
~/alias.ii

all 4 patches:

==153617== I   refs:  13,914,038,211
==153617== 
==153617== Branches:   1,926,407,760  (1,879,827,481 cond + 46,580,279 ind)
==153617== Mispredicts:  144,890,904  (  132,094,105 cond + 12,796,799 ind)
==153617== Mispred rate: 7.5% (  7.0% +   27.4%   )

==34993== I   refs:  13,915,335,629
==34993== 
==34993== Branches:   1,926,597,919  (1,880,017,558 cond + 46,580,361 ind)
==34993== Mispredicts:  144,974,266  (  132,177,440 cond + 12,796,826 ind)
==34993== Mispred rate: 7.5% (  7.0% +   27.4%   )

==140841== I   refs:  13,915,334,459
==140841== 
==140841== Branches:   1,926,597,819  (1,880,017,458 cond + 46,580,361 ind)
==140841== Mispredicts:  144,974,296  (  132,177,470 cond + 12,796,826 ind)
==140841== Mispred rate: 7.5% (  7.0% +   27.4%   )

patch 1:

==99902== I   refs:  13,915,069,710
==99902== 
==99902== Branches:   1,926,963,813  (1,880,376,148 cond + 46,587,665 ind)
==99902== Mispredicts:  145,501,564  (  132,656,576 cond + 12,844,988 ind)
==99902== Mispred rate: 7.5% (  7.0% +   27.5%   )

==3907== I   refs:  13,915,082,469
==3907== 
==3907== Branches:   1,926,965,218  (1,880,377,471 cond + 46,587,747 ind)
==3907== Mispredicts:  145,501,569  (  132,656,554 cond + 12,845,015 ind)
==3907== Mispred rate: 7.5% (  7.0% +   27.5%   )

==44271== I   refs:  13,915,111,997
==44271== 
==44271== Branches:   1,926

Re: [PATCH/TopLevel] Fix compiling libgo with a combined sources

[Jeff Law]

On 11/22/14 21:20, Andrew Pinski wrote:

Hi,
   The problem here is here is that OBJCOPY is not being set to the
newly built objcopy when compiling libgo.  This patch adds
OBJCOPY_FOR_TARGET to the toplevel configure/Makefile so that when
libgo is compiled OBJCOPY is set to OBJCOPY_FOR_TARGET.

I noticed this issue when building an aarch64 cross compile on an
older system where objcopy did not understand aarch64.

OK?  Bootstrapped and tested on x86_64 with no regressions.  Also
tested with a combined build for a cross compiler to
aarch64-linux-gnu.

Thanks,
Andrew Pinski


 * Makefile.def (flags_to_pass): Pass OBJCOPY_FOR_TARGET also.
 * Makefile.tpl (HOST_EXPORTS): Add OBJCOPY_FOR_TARGET.
 (BASE_TARGET_EXPORTS): Add OBJCOPY.
 (OBJCOPY_FOR_TARGET): New variable.
 (EXTRA_TARGET_FLAGS): Add OBJCOPY.
 * Makefile.in: Regenerate.
 * configure.ac: Check for already installed target objcopy.
 Also GCC_TARGET_TOOL on objcopy.
 * configure: Regenerate.

OK
Jeff

Re: [PATCH, ciklplus]: Use -ffloat-store for 32bit x86 in cilk-plus/AN/builtin_fn_{custom,mutating}.c

[Jeff Law]

On 11/22/14 11:50, Uros Bizjak wrote:

Hello!

These two tests fix PR target/63847 [1], where x87 excess precision
causes testcase to fail. The problem was triggered by -fpic, please
see the PR for analysis.

The patch adds -ffloat-store for 32bit x86 target, a standard and well
tested solution for this problem.

2014-11-22  Uros Bizjak  

 PR target/63847
 * c-c++-common/cilk-plus/AN/builtin_fn_custom.c: Add -ffloat-store
 for 32bit x86 targets.
 * c-c++-common/cilk-plus/AN/builtin_fn_mutating.c: Ditto.

OK.
Jeff

Re: [Android] Enable ifuncs on Android

[Jeff Law]

On 11/24/14 02:49, Alexander Ivchenko wrote:

*ping*

thanks,
Alexander
Can you put a reference to the actual patch you want to ping (or just 
attach the patch you want to ping)?  I'll review given the updated 
context/changes from HJ.


jeff

Re: [Patch] Improving jump-thread pass for PR 54742

[Jeff Law]

On 11/23/14 15:22, Sebastian Pop wrote:

The second patch attached limits the search for FSM jump threads to loops.  With
that patch, we are now down to 470 jump threads in an x86_64-linux bootstrap
(and 424 jump threads on powerpc64-linux bootstrap.)

Yea, that was one of the things I was going to poke at as well as a 
quick scan of your patch gave me the impression it wasn't limited to loops.


Again, I haven't looked much at the patch, but I got the impression 
you're doing a backwards walk through the predecessors to discover the 
result of the COND_EXPR.  Correct?


That's something I'd been wanting to do -- basically start with a 
COND_EXPR, then walk the dataflow backwards substituting values into the 
COND_EXPR (possibly creating non-gimple).  Ultimately the goal is to 
substitute and fold, getting to a constant :-)


The forward exhaustive stuff we do now is, crazy.   The backwards 
approach could be decoupled from DOM & VRP into an independent pass, 
which I think would be wise.


Using a SEME region copier is also something I really wanted to do long 
term.  In fact, I believe a lot of tree-ssa-threadupdate.c ought to be 
ripped out and replaced with a SEME based copier.


It appears you've built at least parts of two pieces needed to all this 
as a Bodik style optimizer.  Which is exactly the long term direction I 
think this code ought to take.





One of the reasons I think we see more branches is that in sese region copying 
we
do not use the knowledge of the value of the condition for the last branch in a
jump-thread path: we rely on other propagation passes to remove the branch.  The
last attached patch adds:

   /* Remove the last branch in the jump thread path.  */
   remove_ctrl_stmt_and_useless_edges (region_copy[n_region - 1], exit->dest);
That's certainly a possibility.  But I would expect that even with this 
limitation something would be picking up the fact that the branch is 
statically computable (even if it's an RTL optimizer).  But it's 
definitely something to look for.




Please let me know if the attached patches are producing better results on gcc.


For the trunk:
  instructions:1339016494968
  branches :243568982489

First version of your patch:

  instructions:1339739533291
  branches: 243806615986

Latest version of your patch:

  instructions:1339749122609
  branches: 243809838262

Which is in the noise for this test.  Which makes me wonder if I botched 
something on the latest run.  It doesn't appear so, but I'm re-running 
just to be sure.  I'm also turning on -g so that I can use cg_annotate 
to poke a bit deeper and perhaps identify one or more concrete examples 
where your patch is making this worse.


Jeff

Re: [PATCH, PR 63551] Use proper type in evaluate_conditions_for_known_args

[Richard Biener]

On November 24, 2014 7:12:01 PM CET, Martin Jambor  wrote:
>On Sat, Nov 22, 2014 at 07:36:59PM +0100, Richard Biener wrote:
>> On November 22, 2014 12:45:58 PM CET, Jakub Jelinek
> wrote:
>> >On Sat, Nov 22, 2014 at 12:09:46PM +0100, Martin Jambor wrote:
>> >> 2014-11-21  Martin Jambor  
>> >> 
>> >>   PR ipa/63551
>> >>   * ipa-inline-analysis.c (evaluate_conditions_for_known_args):
>> >Convert
>> >>   value of the argument to the type of the value in the condition.
>> >> 
>> >> testsuite/
>> >>   * gcc.dg/ipa/pr63551.c: New test.
>> >> 
>> >> 
>> >> Index: src/gcc/ipa-inline-analysis.c
>> >>
>===
>> >> --- src.orig/gcc/ipa-inline-analysis.c
>> >> +++ src/gcc/ipa-inline-analysis.c
>> >> @@ -880,7 +880,10 @@ evaluate_conditions_for_known_args (stru
>> >>   }
>> >>if (c->code == IS_NOT_CONSTANT || c->code == CHANGED)
>> >>   continue;
>> >> -  res = fold_binary_to_constant (c->code, boolean_type_node,
>> >val, c->val);
>> >> +  val = fold_unary (VIEW_CONVERT_EXPR, TREE_TYPE (c->val),
>val);
>> >
>> >VCE should only be used if the sizes of the types are the same.
>> >Is that always the case here?
>> 
>> I hope so. But I also think it will simply not fold otherwise?
>> 
>
>Unfortunately, neither is really the case.  I have modified the
>testcase so that the union view_converts an unsigned long to a
>structure of two signed shorts and sure enough, the code ended up
>folding a VIEW_CONVERT_EXPR of (unsigned long) -1 to signed short and
>did that successfully, getting the value of signed short -1.
>
>Should I add an extra check to make sure the type sizes match?

I would rather say you need to figure out how you end up not rejecting this 
during propagation.  I suppose only the low part will be handled correctly 
(thus it will fail with a less uniform value either on big or on little-endian).

I don't know the IPA code good enough to tell whether you need a size check or 
whether that would be enough.  Sure it
Is safer than no size check and I suppose fixing this even more can be done as 
follow-up.

Thus the VIEW_CONVERT patch is still OK.

Richard.

>
>Thanks,
>
>Martin

Re: Merging configure bits with Binutils

[Jeff Law]

On 11/24/14 09:52, Jan-Benedict Glaw wrote:

On Mon, 2014-11-24 09:42:57 -0700, Jeff Law  wrote:

On 11/23/14 00:31, Jan-Benedict Glaw wrote:

This is my current patch series for GCC to merge all the config
bits from Binutils. It's not yet testet, but I'd like to post it
early to get feedback. That way, I hope to not forget something
obvious.

FWIW, one could easily argue this should be a standard step in our
process to work towards a release.  The only question in my mind
would be timing, end of stage1 or start of stage3 seem the most
appropriate to me.


Full ACK.  I plan to keep my comparison script running.

   However, I'm not too sure if I'd like to commit /now/.

   First, there was a recent patch, so I need to rebase. And second,
I'm a bit late I think. I'm not 100% sure I won't break anything. And
in stage3, that's probably not the very best starting point for such a
patch?
It's pretty isolated stuff (in terms of what clauses are being changed 
in the configure bits), so I'm not too worried about breaking anything. 
 We can reach out to Joel to ensure the RTEMS bits are correct and 
those were, IMHO, the most important.


I think we're early enough in stage3 that this can go forward.

jeff

Re: [patch] Restore bootstrap on powerpc*-apple-darwin*

[Iain Sandoe]

On 24 Nov 2014, at 17:02, FX wrote:

> Bootstrap is currently broken on ppc-darwin due to PR63703 
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703).
> This is also broken on 4.9, and actually made it into the 4.9.2 release.
> 
> This patch fixes it, restores bootstrap (well, it gets cc1 to build, at 
> least… I don’t have a ppc to test the full bootstrap), obviously doesn’t 
> affect other targets.
> OK to commit to trunk and 4.9?
> 
> FX
> 
> 
> 
> 2014-11-24  Rohit  
> 
>   PR bootstrap/63703
>   * config/rs6000/darwin.h (REGISTER_NAMES): Update based on 32 newly
>   added GCC hard register numbers for SPE high registers.
> 
> 
> 

IMO, it's obvious, and as you say, doesn't touch any other target.
Iain

Re: [PATCH 9/9] ipa-inline uses sreal for as fibonacci_heap template argument.

[H.J. Lu]

On Thu, Nov 13, 2014 at 12:10 PM, mliska  wrote:
> gcc/ChangeLog:
>
> 2014-11-13  Martin Liska  
>
> * ipa-inline.c (edge_badness): long is replaced by sreal
> as fibonacci_heap template type.
> (update_edge_key): Likewise.
> (inline_small_functions): Likewise.

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64050

H.J.

[C++ Patch/RFC] PR 63757

[Paolo Carlini]

Hi,

in this rejects-valid, as part of build_user_type_conversion_1, 
standard_conversion is called by implicit_conversion with a *null* expr, 
thus the condition in standard_conversion


  /* [conv.ptr]
 A null pointer constant can be converted to a pointer type; ... A
 null pointer constant of integral type can be converted to an
 rvalue of type std::nullptr_t. */
  if ((tcode == POINTER_TYPE || TYPE_PTRMEM_P (to)
   || NULLPTR_TYPE_P (to))
  && expr && null_ptr_cst_p (expr))
conv = build_conv (ck_std, to, conv);

is false and the snippet is rejected. Should we pass a nullptr_node as 
expr in such cases, ie, when handling conversions functions returning 
std::nullptr_t?!? The below passes testing.


Thanks,
Paolo.

//
Index: cp/call.c
===
--- cp/call.c   (revision 218022)
+++ cp/call.c   (working copy)
@@ -3685,7 +3685,8 @@ build_user_type_conversion_1 (tree totype, tree ex
  conversion *ics
= implicit_conversion (totype,
   rettype,
-  0,
+  NULLPTR_TYPE_P (rettype)
+  ? nullptr_node : NULL_TREE,
   /*c_cast_p=*/false, convflags,
   complain);
 
Index: testsuite/g++.dg/cpp0x/nullptr33.C
===
--- testsuite/g++.dg/cpp0x/nullptr33.C  (revision 0)
+++ testsuite/g++.dg/cpp0x/nullptr33.C  (working copy)
@@ -0,0 +1,19 @@
+// PR c++/63757
+// { dg-do compile { target c++11 } }
+
+typedef decltype(nullptr) nullptr_t;
+
+void bar(void*) {}
+ 
+struct foo
+{
+  operator nullptr_t()
+  {
+return nullptr;
+  }
+};
+
+int main()
+{
+  bar(foo());
+}

Re: [PATCH] Fix dump scan in test devirt-40.C

[H.J. Lu]

On Mon, Nov 24, 2014 at 10:41 AM, Paolo Carlini
 wrote:
> Hi again,
>
>
> On 11/24/2014 07:33 PM, Paolo Carlini wrote:
>>
>> Hi,
>>
>> On 11/12/2014 03:02 AM, H.J. Lu wrote:
>>>
>>> I am checking in this.
>>
>> Looks like devirt-42.C is failing again and reverting your tweak would fix
>> it?!?
>
> Sorry, in fact now the line failing is "First type is base of second" 3, a
> different one.

I opened:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64060


-- 
H.J.

Re: [PATCH] Fix dump scan in test devirt-40.C

[Paolo Carlini]

Hi again,

On 11/24/2014 07:33 PM, Paolo Carlini wrote:

Hi,

On 11/12/2014 03:02 AM, H.J. Lu wrote:
I am checking in this. 
Looks like devirt-42.C is failing again and reverting your tweak would 
fix it?!?
Sorry, in fact now the line failing is "First type is base of second" 3, 
a different one.


Paolo.

Re: [PATCH] Fix dump scan in test devirt-40.C

[Paolo Carlini]

Hi,

On 11/12/2014 03:02 AM, H.J. Lu wrote:
I am checking in this. 
Looks like devirt-42.C is failing again and reverting your tweak would 
fix it?!?


Thanks,
Paolo.

Re: [PATCH, 8/8] Do simple omp lowering for no address taken var

[Tom de Vries]

On 24-11-14 13:12, Richard Biener wrote:

On Mon, 24 Nov 2014, Tom de Vries wrote:


On 24-11-14 12:28, Tom de Vries wrote:

On 17-11-14 11:13, Richard Biener wrote:

On Sat, 15 Nov 2014, Tom de Vries wrote:


On 15-11-14 13:14, Tom de Vries wrote:

Hi,

I'm submitting a patch series with initial support for the oacc

kernels

directive.

The patch series uses pass_parallelize_loops to implement

parallelization of

loops in the oacc kernels region.

The patch series consists of these 8 patches:
...
  1  Expand oacc kernels after pass_build_ealias
  2  Add pass_oacc_kernels
  3  Add pass_ch_oacc_kernels to pass_oacc_kernels
  4  Add pass_tree_loop_{init,done} to pass_oacc_kernels
  5  Add pass_loop_im to pass_oacc_kernels
  6  Add pass_ccp to pass_oacc_kernels
  7  Add pass_parloops_oacc_kernels to pass_oacc_kernels
  8  Do simple omp lowering for no address taken var
...


This patch lowers integer variables that do not have their address

taken as

local variable.  We use a copy at region entry and exit to copy the

value in

and out.

In the context of reduction handling in a kernels region, this allows

the

parloops reduction analysis to recognize the reduction, even after oacc
lowering has been done in pass_lower_omp.

In more detail, without this patch, the omp_data_i load and stores are
generated in place (in this case, in the loop):
...
 {
   .omp_data_iD.2201 = &.omp_data_arr.15D.2220;
   {
 unsigned intD.9 iD.2146;

 iD.2146 = 0;
 goto ;
 :
 D.2216 = .omp_data_iD.2201->cD.2203;
 c.9D.2176 = *D.2216;
 D.2177 = (long unsigned intD.10) iD.2146;
 D.2178 = D.2177 * 4;
 D.2179 = c.9D.2176 + D.2178;
 D.2180 = *D.2179;
 D.2217 = .omp_data_iD.2201->sumD.2205;
 D.2218 = *D.2217;
 D.2217 = .omp_data_iD.2201->sumD.2205;
 D.2219 = D.2180 + D.2218;
 *D.2217 = D.2219;
 iD.2146 = iD.2146 + 1;
 :
 if (iD.2146 <= 524287) goto ; else goto

;

 :
   }
...

With this patch, the omp_data_i load and stores for sum are generated

at entry

and exit:
...
 {
   .omp_data_iD.2201 = &.omp_data_arr.15D.2218;
   D.2216 = .omp_data_iD.2201->sumD.2205;
   sumD.2206 = *D.2216;
   {
 unsigned intD.9 iD.2146;

 iD.2146 = 0;
 goto ;
 :
 D.2217 = .omp_data_iD.2201->cD.2203;
 c.9D.2176 = *D.2217;
 D.2177 = (long unsigned intD.10) iD.2146;
 D.2178 = D.2177 * 4;
 D.2179 = c.9D.2176 + D.2178;
 D.2180 = *D.2179;
 sumD.2206 = D.2180 + sumD.2206;
 iD.2146 = iD.2146 + 1;
 :
 if (iD.2146 <= 524287) goto ; else goto

;

 :
   }
   *D.2216 = sumD.2206;
   #pragma omp return
 }
...


So, without the patch the reduction operation looks like this:
...
 *(.omp_data_iD.2201->sumD.2205) = *(.omp_data_iD.2201->sumD.2205)

+ x

...

And with this patch the reduction operation is simply:
...
 sumD.2206 = sumD.2206 + x:
...

OK for trunk?

I presume the reason you are trying to do that here is that otherwise
it happens too late?  What you do is what loop store motion would
do.


Richard,

Thanks for the hint. I've built a reduction example:
...
void __attribute__((noinline))
f (unsigned int *__restrict__ a, unsigned int *__restrict__ sum, unsigned
int n)
{
unsigned int i;
for (i = 0; i < n; ++i)
  *sum += a[i];
}...
and observed that store motion of the *sum store is done by pass_loop_im,
provided the *sum load is taken out of the the loop by pass_pre first.

So alternatively, we could use pass_pre and pass_loop_im to achieve the same
effect.

When trying out adding pass_pre as a part of the pass group
pass_oacc_kernels, I
found that also pass_copyprop was required to get parloops to recognize the
reduction.



Attached patch adds pass_copyprop to pass group pass_oacc_kernels.


Hum, you are gobbling up very many passes here.  In this case copyprop
will also perform trivial constant propagation so maybe it's enough
to replace ccp by copyprop.  Or go the full way and add a FRE pass.



Yep, replacing ccp by copyprop seems to work well enough.

I'll repost once bootstrap and reg-test are done.

Thanks,
- Tom

Re: [PATCH] [AArch64, RTL] Bics instruction generation for aarch64

[Alex Velenko]

On 11/11/14 10:38, Alex Velenko wrote:

 From 98bb6d7323ce79e28be8ef892b919391ed857e1f Mon Sep 17 00:00:00 2001
From: Alex Velenko 
Date: Fri, 31 Oct 2014 18:43:32 +
Subject: [PATCH] [AArch64, RTL] Bics instruction generation for aarch64

Hi,

This patch adds rtl patterns for aarch64 to generate bics instructions in
cases when caputed value gets discarded and only only the status regester
change of the instruction gets reused.

Previously, bics would only be generated, if the value computed by bics
would later be reused, which is not necessarily the case when computing
this value for "if" statements.

Is this patch ok?

Thanks,
Alex

gcc/

2014-11-10  Alex Velenko  

 * gcc/config/aarch64/aarch64.md
(and_one_cmpl3_compare0_no_reuse):
   New define_insn.
 * (and_one_cmpl_3_compare0_no_reuse):
   Likewise.

gcc/testsuite/

2014-11-10  Alex Velenko  

 * gcc.target/aarch64/bics1.c : New testcase.
---
  gcc/config/aarch64/aarch64.md | 26 
  gcc/testsuite/gcc.target/aarch64/bics_3.c | 69
+++
  2 files changed, 95 insertions(+)
  create mode 100644 gcc/testsuite/gcc.target/aarch64/bics_3.c

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 341c26f..6158d82 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -2845,6 +2845,18 @@
[(set_attr "type" "logics_reg")]
  )

+(define_insn "*and_one_cmpl3_compare0_no_reuse"
+  [(set (reg:CC_NZ CC_REGNUM)
+(compare:CC_NZ
+ (and:GPI (not:GPI
+   (match_operand:GPI 0 "register_operand" "r"))
+  (match_operand:GPI 1 "register_operand" "r"))
+ (const_int 0)))]
+  ""
+  "bics\\tzr, %1, %0"
+  [(set_attr "type" "logics_reg")]
+)
+
  (define_insn "*_one_cmpl_3"
[(set (match_operand:GPI 0 "register_operand" "=r")
  (LOGICAL:GPI (not:GPI
@@ -2894,6 +2906,20 @@
[(set_attr "type" "logics_shift_imm")]
  )

+(define_insn "*and_one_cmpl_3_compare0_no_reuse"
+  [(set (reg:CC_NZ CC_REGNUM)
+(compare:CC_NZ
+ (and:GPI (not:GPI
+   (SHIFT:GPI
+(match_operand:GPI 0 "register_operand" "r")
+(match_operand:QI 1 "aarch64_shift_imm_" "n")))
+  (match_operand:GPI 2 "register_operand" "r"))
+ (const_int 0)))]
+  ""
+  "bics\\tzr, %2, %0,  %1"
+  [(set_attr "type" "logics_shift_imm")]
+)
+
  (define_insn "clz2"
[(set (match_operand:GPI 0 "register_operand" "=r")
  (clz:GPI (match_operand:GPI 1 "register_operand" "r")))]
diff --git a/gcc/testsuite/gcc.target/aarch64/bics_3.c
b/gcc/testsuite/gcc.target/aarch64/bics_3.c
new file mode 100644
index 000..ecb53e9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/bics_3.c
@@ -0,0 +1,69 @@
+/* { dg-do run } */
+/* { dg-options "-O2 --save-temps" } */
+
+extern void abort (void);
+
+int __attribute__ ((noinline))
+bics_si_test (int a, int b)
+{
+  if (a & ~b)
+return 1;
+  else
+return 0;
+}
+
+int __attribute__ ((noinline))
+bics_si_test2 (int a, int b)
+{
+  if (a & ~ (b << 2))
+return 1;
+  else
+return 0;
+}
+
+typedef long long s64;
+
+int __attribute__ ((noinline))
+bics_di_test (s64 a, s64 b)
+{
+  if (a & ~b)
+return 1;
+  else
+return 0;
+}
+
+int __attribute__ ((noinline))
+bics_di_test2 (s64 a, s64 b)
+{
+  if (a & ~(b << 2))
+return 1;
+  else
+return 0;
+}
+
+int
+main (void)
+{
+  int a = 5;
+  int b = 5;
+  int c = 20;
+  s64 d = 5;
+  s64 e = 5;
+  s64 f = 20;
+  if (bics_si_test (a, b))
+abort ();
+  if (bics_si_test2 (c, b))
+abort ();
+  if (bics_di_test (d, e))
+abort ();
+  if (bics_di_test2 (f, e))
+abort ();
+  return 0;
+}
+
+/* { dg-final { scan-assembler-times "bics\twzr, w\[0-9\]+, w\[0-9\]+"
2 } } */
+/* { dg-final { scan-assembler-times "bics\twzr, w\[0-9\]+, w\[0-9\]+,
lsl 2" 1 } } */
+/* { dg-final { scan-assembler-times "bics\txzr, x\[0-9\]+, x\[0-9\]+"
2 } } */
+/* { dg-final { scan-assembler-times "bics\txzr, x\[0-9\]+, x\[0-9\]+,
lsl 2" 1 } } */
+
+/* { dg-final { cleanup-saved-temps } } */


Hi,
Could someone, please, approve?
Kind regards,
Alex

Re: [PATCH, PR 63551] Use proper type in evaluate_conditions_for_known_args

[Martin Jambor]

On Sat, Nov 22, 2014 at 07:36:59PM +0100, Richard Biener wrote:
> On November 22, 2014 12:45:58 PM CET, Jakub Jelinek  wrote:
> >On Sat, Nov 22, 2014 at 12:09:46PM +0100, Martin Jambor wrote:
> >> 2014-11-21  Martin Jambor  
> >> 
> >>PR ipa/63551
> >>* ipa-inline-analysis.c (evaluate_conditions_for_known_args):
> >Convert
> >>value of the argument to the type of the value in the condition.
> >> 
> >> testsuite/
> >>* gcc.dg/ipa/pr63551.c: New test.
> >> 
> >> 
> >> Index: src/gcc/ipa-inline-analysis.c
> >> ===
> >> --- src.orig/gcc/ipa-inline-analysis.c
> >> +++ src/gcc/ipa-inline-analysis.c
> >> @@ -880,7 +880,10 @@ evaluate_conditions_for_known_args (stru
> >>}
> >>if (c->code == IS_NOT_CONSTANT || c->code == CHANGED)
> >>continue;
> >> -  res = fold_binary_to_constant (c->code, boolean_type_node,
> >val, c->val);
> >> +  val = fold_unary (VIEW_CONVERT_EXPR, TREE_TYPE (c->val), val);
> >
> >VCE should only be used if the sizes of the types are the same.
> >Is that always the case here?
> 
> I hope so. But I also think it will simply not fold otherwise?
> 

Unfortunately, neither is really the case.  I have modified the
testcase so that the union view_converts an unsigned long to a
structure of two signed shorts and sure enough, the code ended up
folding a VIEW_CONVERT_EXPR of (unsigned long) -1 to signed short and
did that successfully, getting the value of signed short -1.

Should I add an extra check to make sure the type sizes match?

Thanks,

Martin

Re: Pushing recent libtool fix to binutils-gdb and newlib/libgloss

[FX]

> Done:
> https://sourceware.org/ml/binutils/2014-11/msg00318.html

Thanks!

Re: [PATCH] Don't unilaterally include when checking for fpsetmask

[FX]

>> The attached change fixes the build of libgfortran on hppa1.1-hp-hpux10.20 
>> (I know I'm going
>> for the oldest system that will build gfortran).

OK

[PATCH/AARCH64] make bswap vector consistent with scalar name

[Andrew Pinski]

I had some local patches in my tree which adds a bswap tree code.
This breaks the aarch64 back-end vectorizing of byteswaps as we use
the standard mechanism to see if a tree code vectorizes (optabs).
Since it make sense to have consistent of the pattern names between
the vector version and the scalar version, I am proposing this patch
to make them consistent.

OK?  Build and tested on aarch64-elf with no regressions.

Thanks,
Andrew Pinski

ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (bswap): Use CF2 rather
than CF10 so 2 is appended on the code.
* config/aarch64/aarch64-simd.md (bswap): Rename to ...
(bswap2): This so it matches for the optabs.
Index: config/aarch64/aarch64-simd.md
===
--- config/aarch64/aarch64-simd.md  (revision 218026)
+++ config/aarch64/aarch64-simd.md  (working copy)
@@ -286,7 +286,7 @@ (define_insn "mul3"
   [(set_attr "type" "neon_mul_")]
 )
 
-(define_insn "bswap"
+(define_insn "bswap2"
   [(set (match_operand:VDQHSD 0 "register_operand" "=w")
 (bswap:VDQHSD (match_operand:VDQHSD 1 "register_operand" "w")))]
   "TARGET_SIMD"
@@ -308,7 +308,7 @@ (define_expand "ctz2"
 (ctz:VS (match_operand:VS 1 "register_operand")))]
   "TARGET_SIMD"
   {
- emit_insn (gen_bswap (operands[0], operands[1]));
+ emit_insn (gen_bswap2 (operands[0], operands[1]));
  rtx op0_castsi2qi = simplify_gen_subreg(mode, operands[0],
 mode, 0);
  emit_insn (gen_aarch64_rbit (op0_castsi2qi, op0_castsi2qi));
Index: config/aarch64/aarch64-simd-builtins.def
===
--- config/aarch64/aarch64-simd-builtins.def(revision 218026)
+++ config/aarch64/aarch64-simd-builtins.def(working copy)
@@ -317,7 +317,7 @@
   VAR1 (UNOP, floatunsv4si, 2, v4sf)
   VAR1 (UNOP, floatunsv2di, 2, v2df)
 
-  VAR5 (UNOPU, bswap, 10, v4hi, v8hi, v2si, v4si, v2di)
+  VAR5 (UNOPU, bswap, 2, v4hi, v8hi, v2si, v4si, v2di)
 
   BUILTIN_VB (UNOP, rbit, 0)
 

Re: [patch] Define new std::ios_base::failure with abi_tag("cxx11")

[Tom de Vries]

On 24-11-14 18:12, Jonathan Wakely wrote:

On 24/11/14 17:48 +0100, Tom de Vries wrote:

On 14-11-14 13:18, Jonathan Wakely wrote:

This adds system_error support to iostreams, including the required
base class changes to std::ios_base::failure. The abi_tag is used to
make it a distinct type.  This changes the type of I/O exceptions
thrown by the library but exceptions are very rarely used with
iostreams.

Tested powerpc64-linux and x86_64-linux



I'm running into this failure with a non-bootstrap build from trunk.


Is this on i686?



No, x86_64-unknown-linux-gnu.


Could this be related?


Yes, definitely.

I was aware of the failures but hadn't been able to reproduce them.
With the info below I should be able to fix it, thanks.



Great :)

Thanks,
- Tom




2 incompatible symbols
0
_ZNSt8ios_base7failureB5cxx11C1ERKSsRKSt10error_code
std::ios_base::failure[abi:cxx11]::cxx11(std::string const&, std::error_code
const&)
version status: incompatible
GLIBCXX_3.4
type: function
status: added


1
_ZNSt8ios_base7failureB5cxx11C2ERKSsRKSt10error_code
std::ios_base::failure[abi:cxx11]::cxx11(std::string const&, std::error_code
const&)
version status: incompatible
GLIBCXX_3.4
type: function
status: added

Re: [PATCH] Don't unilaterally include when checking for fpsetmask

[John David Anglin]

On 8/7/2014 4:22 PM, John David Anglin wrote:
The attached change fixes the build of libgfortran on 
hppa1.1-hp-hpux10.20 (I know I'm going

for the oldest system that will build gfortran).

OK?


Ping.

Dave

--
John David Anglindave.ang...@bell.net

Re: Pushing recent libtool fix to binutils-gdb and newlib/libgloss

[H.J. Lu]

Done:

https://sourceware.org/ml/binutils/2014-11/msg00318.html

On Mon, Nov 24, 2014 at 9:04 AM, FX  wrote:
> *ping*
>
> Didn’t get any response to my question so far…
>
>
>>> Thanks everyone for the comments and review.
>>> Committed as r217366
>>
>> I cannot push the change to binutils-gdb as I don’t have write access there.
>> Also, Joseph Myers said I needed to commit to newlib/libgloss, but their 
>> webpage only mentions read-only CVS.
>>
>> Could someone do it for me?
>>
>> Thanks,
>> FX
>>
>>
>>
>>
>> commit 8d25b840ce688bfa601b0ad5f53c4185627c8975
>> Author: FX 
>> Date:   Wed Nov 12 13:26:06 2014 +0100
>>
>>* libtool.m4: Fix globbing of darwin versions.
>>
>> diff --git a/ChangeLog b/ChangeLog
>> index 32b3c15..5ed8242 100644
>> --- a/ChangeLog
>> +++ b/ChangeLog
>> @@ -1,3 +1,7 @@
>> +2014-11-12  Francois-Xavier Coudert  
>> +
>> +   * libtool.m4: Fix globbing of darwin versions.
>> +
>> 2014-10-15  Tristan Gingold  
>>
>>* src-release.sh (do_proto_toplev): Configure with --target.
>> diff --git a/libtool.m4 b/libtool.m4
>> index 797468f..c96d80c 100644
>> --- a/libtool.m4
>> +++ b/libtool.m4
>> @@ -1006,7 +1006,7 @@ _LT_EOF
>>   case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
>>10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
>>  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
>> -   10.[[012]]*)
>> +   10.[[012]][[,.]]*)
>>  _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined 
>> ${wl}sup
>>10.*)
>>  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
>>
>



-- 
H.J.

Re: [patch] Define new std::ios_base::failure with abi_tag("cxx11")

[Jonathan Wakely]

On 24/11/14 17:48 +0100, Tom de Vries wrote:

On 14-11-14 13:18, Jonathan Wakely wrote:

This adds system_error support to iostreams, including the required
base class changes to std::ios_base::failure. The abi_tag is used to
make it a distinct type.  This changes the type of I/O exceptions
thrown by the library but exceptions are very rarely used with
iostreams.

Tested powerpc64-linux and x86_64-linux



I'm running into this failure with a non-bootstrap build from trunk. 


Is this on i686?


Could this be related?


Yes, definitely.

I was aware of the failures but hadn't been able to reproduce them.
With the info below I should be able to fix it, thanks.



2 incompatible symbols
0
_ZNSt8ios_base7failureB5cxx11C1ERKSsRKSt10error_code
std::ios_base::failure[abi:cxx11]::cxx11(std::string const&, std::error_code 
const&)
version status: incompatible
GLIBCXX_3.4
type: function
status: added


1
_ZNSt8ios_base7failureB5cxx11C2ERKSsRKSt10error_code
std::ios_base::failure[abi:cxx11]::cxx11(std::string const&, std::error_code 
const&)
version status: incompatible
GLIBCXX_3.4
type: function
status: added

Go patch committed: Don't deref named pointer type for method

[Ian Lance Taylor]

This patch by Chris Manghane fixes the Go compiler to not dereference
a named pointer type when looking up a method.  Before this patch that
could happen if the pointer type pointed to a struct with an inherited
method.  This is http://golang.org/issue/9018.  Bootstrapped and ran
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian
diff -r 547a3bf5788a go/types.cc
--- a/go/types.cc   Fri Nov 21 10:21:33 2014 -0800
+++ b/go/types.cc   Mon Nov 24 09:05:18 2014 -0800
@@ -10035,6 +10035,18 @@
 
   if (found_level == 0)
 return false;
+  else if (found_is_method
+  && type->named_type() != NULL
+  && type->points_to() != NULL)
+{
+  // If this is a method inherited from a struct field in a named pointer
+  // type, it is invalid to automatically dereference the pointer to the
+  // struct to find this method.
+  if (level != NULL)
+   *level = found_level;
+  *is_method = true;
+  return false;
+}
   else if (!found_ambig1.empty())
 {
   go_assert(!found_ambig1.empty());

Pushing recent libtool fix to binutils-gdb and newlib/libgloss

[FX]

*ping*

Didn’t get any response to my question so far…


>> Thanks everyone for the comments and review.
>> Committed as r217366
> 
> I cannot push the change to binutils-gdb as I don’t have write access there.
> Also, Joseph Myers said I needed to commit to newlib/libgloss, but their 
> webpage only mentions read-only CVS.
> 
> Could someone do it for me?
> 
> Thanks,
> FX
> 
> 
> 
> 
> commit 8d25b840ce688bfa601b0ad5f53c4185627c8975
> Author: FX 
> Date:   Wed Nov 12 13:26:06 2014 +0100
> 
>* libtool.m4: Fix globbing of darwin versions.
> 
> diff --git a/ChangeLog b/ChangeLog
> index 32b3c15..5ed8242 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2014-11-12  Francois-Xavier Coudert  
> +
> +   * libtool.m4: Fix globbing of darwin versions.
> +
> 2014-10-15  Tristan Gingold  
> 
>* src-release.sh (do_proto_toplev): Configure with --target.
> diff --git a/libtool.m4 b/libtool.m4
> index 797468f..c96d80c 100644
> --- a/libtool.m4
> +++ b/libtool.m4
> @@ -1006,7 +1006,7 @@ _LT_EOF
>   case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
>10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
>  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
> -   10.[[012]]*)
> +   10.[[012]][[,.]]*)
>  _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined 
> ${wl}sup
>10.*)
>  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
> 

[patch] Restore bootstrap on powerpc*-apple-darwin*

[FX]

Bootstrap is currently broken on ppc-darwin due to PR63703 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703).
This is also broken on 4.9, and actually made it into the 4.9.2 release.

This patch fixes it, restores bootstrap (well, it gets cc1 to build, at least… 
I don’t have a ppc to test the full bootstrap), obviously doesn’t affect other 
targets.
OK to commit to trunk and 4.9?

FX



2014-11-24  Rohit  

PR bootstrap/63703
* config/rs6000/darwin.h (REGISTER_NAMES): Update based on 32 newly
added GCC hard register numbers for SPE high registers.




ppc.diff
Description: Binary data

Re: [PATCH 3/3] remove gengtype support for param_is use_param, if_marked and splay tree allocators

[Jeff Law]

On 11/23/14 21:11, tsaund...@mozilla.com wrote:

From: Trevor Saunders 

Hi,

The one interesting part of this is what we do about plugins.  As you can tell
from the diff removing support for these gengtype features makes things much
simpler, and I think the only way to do that is to remove the plugin hook for
adding caches.  Plugins should be fine converting to the new scheme with
hash_table we use in gcc so long as they can hook in at a point where they can
drop caches, and mark objects they need to stay alive.  Its a little odd, but
the PLUGIN_GGC_MARKING hook is actually called at a point they can do both.  We
could add a separate PLUGIN_GGC_DROP_CACHES hook, but I'm not sure what the
point would be.

Trev

gcc/

* plugin.c, plugin.def, ggc.h, ggc-common.c, gengtype.h, gengtype.c,
gengtype-state.c, gengtype-parse.c, gentype-lex.l, gcc-plugin.h,
doc/plugins.texi, doc/gty.texi: Remove support for if_marked and
param_is.

include/

* hashtab.h, splay-tree.h: Remove GTY markers.
I can't seem to find our porting-to document yet and I think this 
deserves a mention there.  Can you contact Jon and see if he's pulling 
something together in that space (I suspect he is due to the C++ ABI 
library changes).


I'm OK with this patch as I'd prefer to get the old interfaces to the GC 
system cleaned up now rather than waiting another release.


Give Richi and others as chance to object, but if they don't whenin the 
next couple days, go ahead and check it in.


jeff

Re: [PING][PATCH] Change contrib/test_installed for testing cross compilers

[Alan Lawrence]

Having just been experimenting with testing of installed compilers - yes 
something like this could be useful, however: to do cross-testing I found I also 
(a) had to set my target_list; so either an extra flag for that, or maybe just a 
generic 'extra_site_flags' parameter?
(b) I had to set up some boards...so maybe could have got there with the 
--tmpdir flag, ok;
(c) lost all the parallelism provided by the Makefile in build/gcc. It should be 
possible to use the (check-parallel-xxx rules from) Makefile in conjunction with 
the site.exp from contrib/test_installed, haven't got that far yet...


This does leave me wondering (1) whether a one-step "$ test_installed" is 
feasible, or a two-stage setup and then run is inevitable; (2) whether having 
all that parallelism expressed in the Makefile is the best place for it. Not 
that I have an alternative proposal at this point...


--Alan


Steve Ellcey wrote:

I noticed I never got a reply to this patch proposal I sent out back
in March.  Does anyone have an opinion on this? I think it would make
testing of installed cross compilers easier.

Steve Ellcey
sell...@imgtec.com


--- Original Email ---



I was doing some testing of an installed cross-compiler using the
test_installed script in contrib and I noticed that there was no way
to set the target_triplet in the site.exp script that test_installed
creates.  This patch adds a new option (--target) that can be used to
set target_triplet in site.exp before running the testsuite, thus
making it more useful when testing cross-compilers.  If you don't use
the option nothing is changed.

OK to checkin?

Steve Ellcey
sell...@mips.com


2014-03-06  Steve Ellcey  

* test_installed (--target=): New option.


diff --git a/contrib/test_installed b/contrib/test_installed
index e518cbc..8102e7f 100755
--- a/contrib/test_installed
+++ b/contrib/test_installed
@@ -46,7 +46,7 @@ while true; do
   case "$1" in
   --with-testsuite=*) testsuite=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --srcdir=*) srcdir=`echo "$1" | sed 's/[^=]*=//'`; shift;;
-
+  --target=*) target=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --prefix=*) prefix=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --with-gcc=*) GCC_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --with-g++=*) GXX_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
@@ -71,6 +71,9 @@ Supported arguments:
 --srcdir=/some/dirsame as --with-testsuite=/some/dir/gcc/testsuite
   [deduced from shell-script pathname]
 
+--target=triplet  The target architecture of the compiler being

+  tested if different then the host.
+
 --prefix=/some/diruse gcc, g++ and gfortran from /some/dir/bin 
[PATH]
 --with-gcc=/some/dir/bin/gcc  use specified gcc program [gcc]
 --with-g++=/some/dir/bin/g++  use specified g++ program [g++]
@@ -112,6 +115,9 @@ set GXX_UNDER_TEST 
"${GXX_UNDER_TEST-${prefix}${prefix+/bin/}g++}"
 set GFORTRAN_UNDER_TEST 
"${GFORTRAN_UNDER_TEST-${prefix}${prefix+/bin/}gfortran}"
 set OBJC_UNDER_TEST "${OBJC_UNDER_TEST-${prefix}${prefix+/bin/}gcc}"
 EOF
+if test x${target} != x; then
+  echo "set target_triplet $target" >> site.exp
+fi
 
 test x"${GCC_UNDER_TEST}" = x"no" || runtest --tool gcc ${1+"$@"}

 test x"${GXX_UNDER_TEST}" = x"no" || runtest --tool g++ ${1+"$@"}

Re: Merging configure bits with Binutils

[Jan-Benedict Glaw]

On Mon, 2014-11-24 09:42:57 -0700, Jeff Law  wrote:
> On 11/23/14 00:31, Jan-Benedict Glaw wrote:
> > This is my current patch series for GCC to merge all the config
> > bits from Binutils. It's not yet testet, but I'd like to post it
> > early to get feedback. That way, I hope to not forget something
> > obvious.
> FWIW, one could easily argue this should be a standard step in our
> process to work towards a release.  The only question in my mind
> would be timing, end of stage1 or start of stage3 seem the most
> appropriate to me.

Full ACK.  I plan to keep my comparison script running.

  However, I'm not too sure if I'd like to commit /now/.

  First, there was a recent patch, so I need to rebase. And second,
I'm a bit late I think. I'm not 100% sure I won't break anything. And
in stage3, that's probably not the very best starting point for such a
patch?

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: "really soon now":  an unspecified period of time, 
likly to
the second  : be greater than any reasonable 
definition
  of "soon".


signature.asc
Description: Digital signature

Re: [patch] Define new std::ios_base::failure with abi_tag("cxx11")

[Tom de Vries]

On 14-11-14 13:18, Jonathan Wakely wrote:

This adds system_error support to iostreams, including the required
base class changes to std::ios_base::failure. The abi_tag is used to
make it a distinct type.  This changes the type of I/O exceptions
thrown by the library but exceptions are very rarely used with
iostreams.

Tested powerpc64-linux and x86_64-linux



I'm running into this failure with a non-bootstrap build from trunk. Could this 
be related?

...
2 incompatible symbols
0
_ZNSt8ios_base7failureB5cxx11C1ERKSsRKSt10error_code
std::ios_base::failure[abi:cxx11]::cxx11(std::string const&, std::error_code 
const&)
version status: incompatible
GLIBCXX_3.4
type: function
status: added


1
_ZNSt8ios_base7failureB5cxx11C2ERKSsRKSt10error_code
std::ios_base::failure[abi:cxx11]::cxx11(std::string const&, std::error_code 
const&)
version status: incompatible
GLIBCXX_3.4
type: function
status: added



 libstdc++-v3 check-abi Summary 

# of added symbols:  143
# of missing symbols:0
# of undesignated symbols:   2
# of incompatible symbols:   2

using: baseline_symbols.txt
FAIL: libstdc++-abi/abi_check
...

Thanks,
- Tom


patch.txt


commit 8f8279579e72423450eb3ff744d9102f7b891d8d
Author: Jonathan Wakely
Date:   Thu Nov 13 19:30:15 2014 +

 Define C++11 version of std::ios_base::failure.

* config/abi/pre/gnu.ver: Add new exports.
* include/bits/ios_base.h (ios_base::failure): New definition using
abi_tag.
(io_errc, make_error_code, make_error_category, iostream_category):
Define.
* include/std/system_error (system_error): Add char* constructors.
* src/c++11/Makefile.am: Add new file.
* src/c++11/Makefile.in: Regenerate.
* src/c++11/cxx11-ios_failure.cc: New file.
* src/c++98/ios_failure.cc: Compile old definition without abi_tag.
* testsuite/27_io/ios_base/failure/cxx11.cc: New.
* testsuite/27_io/ios_base/failure/what-1.cc: Allow string returned by
ios_base::failure::what() to contain additional data.
* testsuite/27_io/ios_base/failure/what-2.cc: Likewise..
* testsuite/27_io/ios_base/failure/what-3.cc: Likewise..
* testsuite/27_io/ios_base/failure/what-big.cc: Likewise..

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index bd44bcc..78f3e77 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1473,6 +1473,18 @@ GLIBCXX_3.4.21 {
  # std::basic_ios::operator bool() const
  _ZNKSt9basic_iosI[cw]St11char_traitsI[cw]EEcvbEv;

+# C++11 version of std::ios_base::failure
+_ZNKSt8ios_base7failureB5cxx114whatEv;
+_ZNSt8ios_base7failureB5cxx11C[12]ERKSs;
+_ZNSt8ios_base7failureB5cxx11C[12]EPKcRKSt10error_code;
+_ZNSt8ios_base7failureB5cxx11C[12]ERKSsB5cxx11;
+_ZNSt8ios_base7failureB5cxx11C[12]ERKSsB5cxx11RKSt10error_code;
+_ZNSt8ios_base7failureB5cxx11D[012]Ev;
+_ZTINSt8ios_base7failureB5cxx11E;
+_ZTSNSt8ios_base7failureB5cxx11E;
+_ZTVNSt8ios_base7failureB5cxx11E;
+_ZSt17iostream_categoryv;
+
  # std::ctype_base::blank
  _ZNSt10ctype_base5blankE;

diff --git a/libstdc++-v3/include/bits/ios_base.h 
b/libstdc++-v3/include/bits/ios_base.h
index 5e33b81..8e60059 100644
--- a/libstdc++-v3/include/bits/ios_base.h
+++ b/libstdc++-v3/include/bits/ios_base.h
@@ -40,6 +40,12 @@
  #include 
  #include 

+#if __cplusplus < 201103L
+# include 
+#else
+# include 
+#endif
+
  namespace std _GLIBCXX_VISIBILITY(default)
  {
  _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -186,6 +192,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_S_ios_seekdir_end = 1L << 16
  };

+#if __cplusplus >= 201103L
+  /// I/O error code
+  enum class io_errc { stream = 1 };
+
+  template <> struct is_error_code_enum : public true_type { };
+
+  const error_category& iostream_category() noexcept;
+
+  inline error_code
+  make_error_code(io_errc e) noexcept
+  { return error_code(static_cast(e), iostream_category()); }
+
+  inline error_condition
+  make_error_condition(io_errc e) noexcept
+  { return error_condition(static_cast(e), iostream_category()); }
+#endif
+
// 27.4.2  Class ios_base
/**
 *  @brief  The base of the I/O class hierarchy.
@@ -198,6 +221,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*/
class ios_base
{
+#if _GLIBCXX_USE_CXX11_ABI
+#if __cplusplus < 201103L
+// Type that is layout-compatible with std::system_error
+struct system_error : std::runtime_error
+{
+  // Type that is layout-compatible with std::error_code
+  struct error_code
+  {
+   error_code() { }
+  private:
+   int _M_value;
+   const void* _M_cat;
+  } _M_code;
+};
+#endif
+#endif
public:

  /**
@@ -206,6 +245,28 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   *
   *  27.4.2.1.1  Class ios_base::failure
   */
+#if _GLIBCXX_USE_CXX11_ABI
+class _GLIBCXX_ABI_

Re: [PATCH 1/3] remove param_is from nvptx

[Jeff Law]

On 11/23/14 21:11, tsaund...@mozilla.com wrote:

From: Trevor Saunders 

Hi,

$subject

Trev

gcc/

* config/nvptx/nvptx.c: Convert htabs to hash_table.
This is fine and I think can go in now rather than waiting for the next 
stage1.  It's an obvious cleanup and one could argue I should have 
caught it during the nvptx review.


jeff

Re: [PATCH RFC 4/4] Regenerate ./configure

[Jeff Law]

On 11/23/14 00:33, Jan-Benedict Glaw wrote:

2014-11-22  Jan-Benedict Glaw  

* configure: Regenerate.

OK.
jeff

Re: [PATCH] Fix regressions in libgomp testsuite: set flag_fat_lto_objects for offload

[Ilya Verbin]

On 17 Nov 10:57, Richard Biener wrote:
> On Fri, Nov 14, 2014 at 6:08 PM, Ilya Verbin  wrote:
> > On 14 Nov 09:01, H.J. Lu wrote:
> >> On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin  wrote:
> >> > On 14 Nov 08:46, H.J. Lu wrote:
> >> >> What happens when -flto is used on command line?  Will we
> >> >> generate both LTO IR and offload IR?
> >> >
> >> > Right.
> >> >
> >> > I'm not sure whether we should make slim objects in case of LTO + 
> >> > offload IR...
> >> >
> >>
> >> Isn't __gnu_lto_slim only applied to regular LTO IR? Should offload IR be
> >> handled separately from regular LTO IR? It is odd to use 
> >> flag_fat_lto_objects
> >> to control offload IR.
> >
> > It is handled separately, but it uses a common infrastructure with regular 
> > LTO
> > for streaming, therefore compile_file automatically emits __gnu_lto_slim 
> > when
> > there is at least one section with IR (flag_generate_lto is set).  You 
> > propose
> > to introduce a second flag like flag_fat_lto_objects to disable 
> > __gnu_lto_slim?
> 
> Err... why is offloading not guarded with a new symbol like __gnu_lto_offload?

Well, it's possible to guard offload IR with a new symbol, using a patch like
this (it is not fully regtested).  But I don't like it...  Maybe we could just
change the meaning of "__gnu_lto_v1" from "object contains LTO IR" to "object
contains any IR"?  In collect2 both LTO and offload cases are handled
identically.  Is there other place where the symbol is used?

  -- Ilya


diff --git a/gcc/ada/gcc-interface/decl.c b/gcc/ada/gcc-interface/decl.c
index c133a22..f09d79d 100644
--- a/gcc/ada/gcc-interface/decl.c
+++ b/gcc/ada/gcc-interface/decl.c
@@ -1490,7 +1490,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, 
int definition)
&& definition
&& debug_info_p
&& !optimize
-   && !flag_generate_lto)
+   && !flag_generate_lto
+   && !flag_generate_offload)
  {
tree param = create_param_decl (gnu_entity_name, gnu_type, false);
gnat_pushdecl (param, gnat_entity);
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 2fd99a7..fed1a3e 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -2075,7 +2075,7 @@ ipa_passes (void)
 }
 
   /* Some targets need to handle LTO assembler output specially.  */
-  if (flag_generate_lto)
+  if (flag_generate_lto || flag_generate_offload)
 targetm.asm_out.lto_start ();
 
   if (!in_lto_p)
@@ -2092,7 +2092,7 @@ ipa_passes (void)
}
 }
 
-  if (flag_generate_lto)
+  if (flag_generate_lto || flag_generate_offload)
 targetm.asm_out.lto_end ();
 
   if (!flag_ltrans && (in_lto_p || !flag_lto || flag_fat_lto_objects))
@@ -2176,10 +2176,10 @@ symbol_table::compile (void)
 
   /* Offloading requires LTO infrastructure.  */
   if (!in_lto_p && g->have_offload)
-flag_generate_lto = 1;
+flag_generate_offload = 1;
 
   /* If LTO is enabled, initialize the streamer hooks needed by GIMPLE.  */
-  if (flag_generate_lto)
+  if (flag_generate_lto || flag_generate_offload)
 lto_streamer_hooks_init ();
 
   /* Don't run the IPA passes if there was any error or sorry messages.  */
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 9c3a1c5..2dcebcd 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -2392,12 +2392,16 @@ scan_prog_file (const char *prog_name, scanpass 
which_pass,
   if (found_lto)
 continue;
 
-  /* Look for the LTO info marker symbol, and add filename to
+  /* Look for the LTO or offload info marker symbol, and add filename 
to
  the LTO objects list if found.  */
   for (p = buf; (ch = *p) != '\0' && ch != '\n'; p++)
 if (ch == ' '  && p[1] == '_' && p[2] == '_'
-   && (strncmp (p + (p[3] == '_' ? 2 : 1), "__gnu_lto_v1", 12) == 
0)
-   && ISSPACE (p[p[3] == '_' ? 14 : 13]))
+   && (((strncmp (p + (p[3] == '_' ? 2 : 1),
+  "__gnu_lto_v1", 12) == 0)
+&& ISSPACE (p[p[3] == '_' ? 14 : 13]))
+   || ((strncmp (p + (p[3] == '_' ? 2 : 1),
+ "__gnu_offload_v1", 16) == 0)
+   && ISSPACE (p[p[3] == '_' ? 18 : 17]
   {
 add_lto_object (

Re: [PATCH RFC 3/4] Merge the ./config directory between GCC and Binutils

[Jeff Law]

On 11/23/14 00:33, Jan-Benedict Glaw wrote:

This pulls in the missing Binutils pieces into the ./config
directory. Contains these missing Binutils changes:

2014-08-14  Alan Modra  

* plugins.m4: Test for dlfcn.h or windows.h here to set default
for --enable-plugins.  Report error if someone tries to enable
plugins on a host we don't support.

2014-08-19  Alan Modra  

* plugins.m4 (AC_PLUGINS): If plugins are enabled, add -ldl to
LIBS via AC_SEARCH_LIBS.

OK.
jeff

Re: [PATCH RFC 1/4] Merge ./configure.ac with Binutils

[Jeff Law]

On 11/23/14 00:33, Jan-Benedict Glaw wrote:

GCC and Binutils had a common ./configure.ac after this commit:

commit 08d081652f50df83f7e9768f8dbb7a99b0df50a2
Author: sandra 
Date:   Wed May 14 23:20:59 2014 +

2014-05-14  Sandra Loosemore  

* configure.ac (target_makefile_frag): Set for nios2-*-elf*.
* configure: Regenerated.

config/
* mt-nios2-elf: New file.

Based on that file version, all GCC and Binutils commits to this file were
applied. This pulls in the following missing Binutils changes to configure.ac:

2014-07-21  Joel Sherrill  

Disable gdb for or1k*-*-* until supported
* configure.ac (or1k*-*-*): Disable gdb.
* configure: Regenerated.

2014-07-27  Joel Sherrill 

GDB not supported for or1k*-*-rtems*
* configure.ac (or1k*-*-rtems*): gdb not supported.  The ordering
of the stanzas results in this not being caught by or1k*-*-* later.
* configure. Regenerated.

2014-09-06  Kuan-Lin Chen  

* configure: Disable gdb for nds32*-*-* until supported.
* configure.ac: Disable gdb for nds32*-*-* until supported.

2014-09-12  Andrew Bennett  

* configure.ac: Add mips*-img-elf* target triple.
* configure: Regenerate.

#1 and #2 are OK.

jeff

Re: Merging configure bits with Binutils

[Jeff Law]

On 11/23/14 00:31, Jan-Benedict Glaw wrote:

Hi!

This is my current patch series for GCC to merge all the config bits
from Binutils. It's not yet testet, but I'd like to post it early to
get feedback. That way, I hope to not forget something obvious.
FWIW, one could easily argue this should be a standard step in our 
process to work towards a release.  The only question in my mind would 
be timing, end of stage1 or start of stage3 seem the most appropriate to me.


Jeff

Re: [C++ PATCH] Detect UB in shifts in constexpr functions

[Marek Polacek]

On Mon, Nov 24, 2014 at 05:05:08PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 24, 2014 at 04:58:22PM +0100, Marek Polacek wrote:
> > > Consider say:
> > > 
> > > constexpr int p = 1;
> > > constexpr int foo (int a)
> > > {
> > >   return a << (int) &p;
> > > }
> > > constexpr int bar (int a)
> > > {
> > >   return ((int) &p) << a;
> > > }
> > > constexpr int q = foo (5);
> > > constexpr int r = bar (2);
> > > constexpr int s = bar (0);
> > > 
> > > Now, for foo (5) and bar (2) fold_binary_loc returns NULL and thus
> > > your cxx_eval_check_shift_p is not called, for bar (0) it returns
> > > non-NULL and while the result still is not a constant expression and
> > > right now is diagnosed, with your patch it would ICE.
> > > 
> > > So, I'd just return false if either lhs or rhs are not INTEGER_CSTs.
> >  
> > Ok, I'll add that.  Thank for pointing that out.
> 
> Note, the above only with -m32 obviously, or supposedly for bar
> you could change return type and the cast and type of r/s to
> __PTRDIFF_TYPE__ or so.  foo, as gcc always casts the shift count to int,
> would supposedly need to stay the way it is and might produce different
> diagnostics between -m32 and -m64.

I changed int to __PTRDIFF_TYPE__.
You're right: with -m64 I get:
i.C: In function ‘constexpr int foo(int)’:
i.C:4:22: error: cast from ‘const int*’ to ‘int’ loses precision [-fpermissive]
   return a << (int) &p;
  ^
but not with -m32.  I dropped the foo from the testcase.

> I meant for the above computation, there you don't check any overflow.

I see.  I'm happy to change it, whatever you/Jason prefer.

The following is a version with INTEGER_CST check and a new test.

2014-11-24  Marek Polacek  

* constexpr.c (cxx_eval_check_shift_p): New function.
(cxx_eval_binary_expression): Call it.

* g++.dg/cpp0x/constexpr-shift1.C: New test.
* g++.dg/cpp1y/constexpr-shift1.C: New test.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 2678223..049ec0f 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -1451,6 +1451,45 @@ verify_constant (tree t, bool allow_non_constant, bool 
*non_constant_p,
   return *non_constant_p;
 }
 
+/* Return true if the shift operation on LHS and RHS is undefined.  */
+
+static bool
+cxx_eval_check_shift_p (enum tree_code code, tree lhs, tree rhs)
+{
+  if ((code != LSHIFT_EXPR && code != RSHIFT_EXPR)
+  || TREE_CODE (lhs) != INTEGER_CST
+  || TREE_CODE (rhs) != INTEGER_CST)
+return false;
+
+  tree lhstype = TREE_TYPE (lhs);
+  unsigned HOST_WIDE_INT uprec = TYPE_PRECISION (TREE_TYPE (lhs));
+
+  /* [expr.shift] The behavior is undefined if the right operand
+ is negative, or greater than or equal to the length in bits
+ of the promoted left operand.  */
+  if (tree_int_cst_sgn (rhs) == -1 || compare_tree_int (rhs, uprec) >= 0)
+return true;
+
+  /* The value of E1 << E2 is E1 left-shifted E2 bit positions; [...]
+ if E1 has a signed type and non-negative value, and E1x2^E2 is
+ representable in the corresponding unsigned type of the result type,
+ then that value, converted to the result type, is the resulting value;
+ otherwise, the behavior is undefined.  */
+  if (code == LSHIFT_EXPR && !TYPE_UNSIGNED (lhstype))
+{
+  if (tree_int_cst_sgn (lhs) == -1)
+   return true;
+  tree t = build_int_cst (unsigned_type_node, uprec - 1);
+  t = fold_build2 (MINUS_EXPR, unsigned_type_node, t, rhs);
+  tree ulhs = fold_convert (unsigned_type_for (lhstype), lhs);
+  t = fold_build2 (RSHIFT_EXPR, TREE_TYPE (ulhs), ulhs, t);
+  if (tree_int_cst_lt (integer_one_node, t))
+   return true;
+}
+
+  return false;
+}
+
 /* Subroutine of cxx_eval_constant_expression.
Attempt to reduce the unary expression tree T to a compile time value.
If successful, return the value.  Otherwise issue a diagnostic
@@ -1506,7 +1545,7 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, 
tree t,
   enum tree_code code = TREE_CODE (t);
   tree type = TREE_TYPE (t);
   r = fold_binary_loc (loc, code, type, lhs, rhs);
-  if (r == NULL_TREE)
+  if (r == NULL_TREE || cxx_eval_check_shift_p (code, lhs, rhs))
 {
   if (lhs == orig_lhs && rhs == orig_rhs)
r = t;
diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-shift1.C 
gcc/testsuite/g++.dg/cpp0x/constexpr-shift1.C
index e69de29..2551fbe 100644
--- gcc/testsuite/g++.dg/cpp0x/constexpr-shift1.C
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-shift1.C
@@ -0,0 +1,73 @@
+// { dg-do compile { target c++11 } }
+
+constexpr int
+fn1 (int i, int j)
+{
+  return i << j; // { dg-error "is not a constant expression" }
+}
+
+constexpr int i1 = fn1 (1, -1);
+
+constexpr int
+fn2 (int i, int j)
+{
+  return i << j; // { dg-error "is not a constant expression" }
+}
+
+constexpr int i2 = fn2 (1, 200);
+
+constexpr int
+fn3 (int i, int j)
+{
+  return i << j; // { dg-error "is not a constant expression" }
+}
+
+constexpr int i3 = fn3 (-1, 2);
+
+constexpr int
+fn4 (int i,

Re: Track dynamic type changes

[H.J. Lu]

On Sun, Oct 5, 2014 at 9:34 AM, Jan Hubicka  wrote:
> Hi,
> this patch makes ipa_polymorphic_call_context::get_dynamic_type to
> track if vptr has changed in between function entry and polymorphic
> call.
>
> The patch also add logic skipping if (a==0) checks in multiple
> inheritance so I can construct testcase more easily.
>
> I got my SVN tree into an inconsistent state yesterday by stopping in
> middle of commit.  The patch went in in two parts, so i am attaching
> both changes. Quite few of devirt-4*.C was broken overnight, I apologize
> for that.
>
> Honza
>
> * ipa-polymorphic-call.c (walk_ssa_copies): Recognize
> NULL pointer checks.
> (ipa_polymorphic_call_context::get_dynamic_type): Return true
> if type doesn't change.
> * cgraph.h (cgraph_indirect_call_info): New flag.
> * cgraph.c (cgraph_node::create_indirect_edge): Initialize it.
> (cgraph_node::dump): Dump it.
> * ipa-prop.c (ipa_analyze_call_uses):  Ignore return valud
> of context.get_dynamic_type.
> (ipa_make_edge_direct_to_target): Do not speculate
> edge that is already speuclative.
> (try_make_edge_direct_virtual_call): Use VPTR_CHANGED; Do not
> speculate to __builtin_unreachable
> (ipa_write_indirect_edge_info, ipa_read_indirect_edge_info): Stream
> vptr_changed.
> * ipa-cp.c (ipa_get_indirect_edge_target_1): Use vptr_changed.
> * g++.dg/ipa/devirt-47.C: New testcase.
>
> * ipa-polymorphic-call.c (possible_placement_new): Fix condition
> on size.
> (ipa_polymorphic_call_context::restrict_to_inner_type): Do not walk
> into vptr pointer.
> (ipa_polymorphic_call_context::dump): Fix formating.
> * ipa-prop.c (ipa_analyze_call_uses): Compute vptr_changed.
>

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049

-- 
H.J.

Improve inliner's handling of aliases

[Jan Hubicka]

Hi,
the original update of inliner for aliases contined some lazyness. This patch 
fixes I think
last remainder of it where inliner did not remove symbol with aliases on it.
This is more important now when ICF uses aliases quite often.

Bootstrapped/regtested x86_64-linux, comitted.

PR ipa/63671
* ipa-inline-transform.c (can_remove_node_now_p_1): Handle alises
and -fno-devirtualize more carefully.
(can_remove_node_now_p): Update.
Index: ipa-inline-transform.c
===
--- ipa-inline-transform.c  (revision 217980)
+++ ipa-inline-transform.c  (working copy)
@@ -93,19 +93,28 @@ update_noncloned_frequencies (struct cgr
copy of function was removed.  */
 
 static bool
-can_remove_node_now_p_1 (struct cgraph_node *node)
+can_remove_node_now_p_1 (struct cgraph_node *node, struct cgraph_edge *e)
 {
+  ipa_ref *ref;
+
+  FOR_EACH_ALIAS (node, ref)
+{
+  cgraph_node *alias = dyn_cast  (ref->referring);
+  if ((alias->callers && alias->callers != e)
+  || !can_remove_node_now_p_1 (alias, e))
+   return false;
+}
   /* FIXME: When address is taken of DECL_EXTERNAL function we still
  can remove its offline copy, but we would need to keep unanalyzed node in
  the callgraph so references can point to it.  */
   return (!node->address_taken
- && !node->has_aliases_p ()
  && node->can_remove_if_no_direct_calls_p ()
  /* Inlining might enable more devirtualizing, so we want to remove
 those only after all devirtualizable virtual calls are processed.
 Lacking may edges in callgraph we just preserve them post
 inlining.  */
- && !DECL_VIRTUAL_P (node->decl)
+ && (!DECL_VIRTUAL_P (node->decl)
+ || !opt_for_fn (node->decl, flag_devirtualize))
  /* During early inlining some unanalyzed cgraph nodes might be in the
 callgraph and they might reffer the function in question.  */
  && !cgraph_new_nodes.exists ());
@@ -119,7 +128,7 @@ static bool
 can_remove_node_now_p (struct cgraph_node *node, struct cgraph_edge *e)
 {
   struct cgraph_node *next;
-  if (!can_remove_node_now_p_1 (node))
+  if (!can_remove_node_now_p_1 (node, e))
 return false;
 
   /* When we see same comdat group, we need to be sure that all
@@ -128,9 +137,13 @@ can_remove_node_now_p (struct cgraph_nod
 return true;
   for (next = dyn_cast (node->same_comdat_group);
next != node; next = dyn_cast (next->same_comdat_group))
-if ((next->callers && next->callers != e)
-   || !can_remove_node_now_p_1 (next))
-  return false;
+{
+  if (next->alias)
+   continue;
+  if ((next->callers && next->callers != e)
+ || !can_remove_node_now_p_1 (next, e))
+return false;
+}
   return true;
 }
 

Re: [C++ PATCH] Detect UB in shifts in constexpr functions

[Jakub Jelinek]

On Mon, Nov 24, 2014 at 04:58:22PM +0100, Marek Polacek wrote:
> > Consider say:
> > 
> > constexpr int p = 1;
> > constexpr int foo (int a)
> > {
> >   return a << (int) &p;
> > }
> > constexpr int bar (int a)
> > {
> >   return ((int) &p) << a;
> > }
> > constexpr int q = foo (5);
> > constexpr int r = bar (2);
> > constexpr int s = bar (0);
> > 
> > Now, for foo (5) and bar (2) fold_binary_loc returns NULL and thus
> > your cxx_eval_check_shift_p is not called, for bar (0) it returns
> > non-NULL and while the result still is not a constant expression and
> > right now is diagnosed, with your patch it would ICE.
> > 
> > So, I'd just return false if either lhs or rhs are not INTEGER_CSTs.
>  
> Ok, I'll add that.  Thank for pointing that out.

Note, the above only with -m32 obviously, or supposedly for bar
you could change return type and the cast and type of r/s to
__PTRDIFF_TYPE__ or so.  foo, as gcc always casts the shift count to int,
would supposedly need to stay the way it is and might produce different
diagnostics between -m32 and -m64.
> 
> > > +
> > > +  /* The value of E1 << E2 is E1 left-shifted E2 bit positions; [...]
> > > + if E1 has a signed type and non-negative value, and E1x2^E2 is
> > > + representable in the corresponding unsigned type of the result type,
> > > + then that value, converted to the result type, is the resulting 
> > > value;
> > > + otherwise, the behavior is undefined.  */
> > > +  if (code == LSHIFT_EXPR && !TYPE_UNSIGNED (lhstype))
> > > +{
> > > +  if (tree_int_cst_sgn (lhs) == -1)
> > > + return true;
> > > +  tree t = build_int_cst (unsigned_type_node, uprec - 1);
> > > +  t = fold_build2 (MINUS_EXPR, unsigned_type_node, t, rhs);
> > > +  tree ulhs = fold_convert (unsigned_type_for (lhstype), lhs);
> > > +  t = fold_build2 (RSHIFT_EXPR, TREE_TYPE (ulhs), ulhs, t);
> > > +  if (tree_int_cst_lt (integer_one_node, t))
> > > + return true;
> > 
> > I'll leave to Jason whether this shouldn't be using the various
> > cxx_eval_*_expression calls instead, or perhaps int_const_binop or wide_int
> > stuff directly.
> 
> ISTR int_const_binop calls wide_int routines wi::rshift/wi::lshift and these
> return 0 and do not have any overflow flag, so that might not help (?).

I meant for the above computation, there you don't check any overflow.

Jakub

Re: [C++ PATCH] Detect UB in shifts in constexpr functions

[Marek Polacek]

On Mon, Nov 24, 2014 at 04:49:25PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 24, 2014 at 02:51:14PM +0100, Marek Polacek wrote:
> > --- gcc/cp/constexpr.c
> > +++ gcc/cp/constexpr.c
> > @@ -1451,6 +1451,43 @@ verify_constant (tree t, bool allow_non_constant, 
> > bool *non_constant_p,
> >return *non_constant_p;
> >  }
> >  
> > +/* Return true if the shift operation on LHS and RHS is undefined.  */
> > +
> > +static bool
> > +cxx_eval_check_shift_p (enum tree_code code, tree lhs, tree rhs)
> > +{
> > +  if (code != LSHIFT_EXPR && code != RSHIFT_EXPR)
> > +return false;
> > +
> > +  tree lhstype = TREE_TYPE (lhs);
> > +  unsigned HOST_WIDE_INT uprec = TYPE_PRECISION (TREE_TYPE (lhs));
> > +
> > +  /* [expr.shift] The behavior is undefined if the right operand
> > + is negative, or greater than or equal to the length in bits
> > + of the promoted left operand.  */
> > +  if (tree_int_cst_sgn (rhs) == -1 || compare_tree_int (rhs, uprec) >= 0)
> > +return true;
> 
> I think VERIFY_CONSTANT doesn't guarantee both operands are INTEGER_CSTs.

Oh well.  I ran the testsuite with an assert checking that I always have
INTEGER_CSTs and didn't see any ICEs.

> Consider say:
> 
> constexpr int p = 1;
> constexpr int foo (int a)
> {
>   return a << (int) &p;
> }
> constexpr int bar (int a)
> {
>   return ((int) &p) << a;
> }
> constexpr int q = foo (5);
> constexpr int r = bar (2);
> constexpr int s = bar (0);
> 
> Now, for foo (5) and bar (2) fold_binary_loc returns NULL and thus
> your cxx_eval_check_shift_p is not called, for bar (0) it returns
> non-NULL and while the result still is not a constant expression and
> right now is diagnosed, with your patch it would ICE.
> 
> So, I'd just return false if either lhs or rhs are not INTEGER_CSTs.
 
Ok, I'll add that.  Thank for pointing that out.

> > +
> > +  /* The value of E1 << E2 is E1 left-shifted E2 bit positions; [...]
> > + if E1 has a signed type and non-negative value, and E1x2^E2 is
> > + representable in the corresponding unsigned type of the result type,
> > + then that value, converted to the result type, is the resulting value;
> > + otherwise, the behavior is undefined.  */
> > +  if (code == LSHIFT_EXPR && !TYPE_UNSIGNED (lhstype))
> > +{
> > +  if (tree_int_cst_sgn (lhs) == -1)
> > +   return true;
> > +  tree t = build_int_cst (unsigned_type_node, uprec - 1);
> > +  t = fold_build2 (MINUS_EXPR, unsigned_type_node, t, rhs);
> > +  tree ulhs = fold_convert (unsigned_type_for (lhstype), lhs);
> > +  t = fold_build2 (RSHIFT_EXPR, TREE_TYPE (ulhs), ulhs, t);
> > +  if (tree_int_cst_lt (integer_one_node, t))
> > +   return true;
> 
> I'll leave to Jason whether this shouldn't be using the various
> cxx_eval_*_expression calls instead, or perhaps int_const_binop or wide_int
> stuff directly.

ISTR int_const_binop calls wide_int routines wi::rshift/wi::lshift and these
return 0 and do not have any overflow flag, so that might not help (?).

Marek

Re: [PING**4] [PATCH] Fix PR ipa/61190, 2nd edition�??

[Jan Hubicka]

+cgraph_node::call_for_symbol_thunks_and_aliases_1 (bool (*callback)
+(cgraph_node *, void *),
+  void *data,
+  bool include_overwritable,
+  bool exclude_virtual_thunks)

Instead of adding _1 variant into public API, please just add implicit agrumnet
bool exclude_virtual_thunks=false into
+cgraph_node::call_for_symbol_thunks_and_aliases
Index: gcc/ipa-pure-const.c
===
--- gcc/ipa-pure-const.c(revision 215888)
+++ gcc/ipa-pure-const.c(working copy)
@@ -744,6 +744,8 @@ analyze_function (struct cgraph_node *fn, bool ipa
 {
   /* Thunk gets propagated through, so nothing interesting happens.  */
   gcc_assert (ipa);
+  if (fn->thunk.virtual_offset_p)
+   l->pure_const_state = IPA_NEITHER;
   return l;
 }
 
This makes the lattice to be initialized correctly, but you also need the
function_symbol calls that will skip thunks replaced by
something like function_or_non_virtual_thunk_symbol.

Can you, please, send the updated patch?
Sorry for late review,
Honza

Index: gcc/testsuite/g++.old-deja/g++.mike/p4736b.C
===
--- gcc/testsuite/g++.old-deja/g++.mike/p4736b.C(revision 215888)
+++ gcc/testsuite/g++.old-deja/g++.mike/p4736b.C(working copy)
@@ -1,4 +1,5 @@
 // { dg-do run  }
+// { dg-options "-O2" }
 // prms-id: 4736
 
 class Rep {

Re: [C++ PATCH] Detect UB in shifts in constexpr functions

[Jakub Jelinek]

On Mon, Nov 24, 2014 at 02:51:14PM +0100, Marek Polacek wrote:
> --- gcc/cp/constexpr.c
> +++ gcc/cp/constexpr.c
> @@ -1451,6 +1451,43 @@ verify_constant (tree t, bool allow_non_constant, bool 
> *non_constant_p,
>return *non_constant_p;
>  }
>  
> +/* Return true if the shift operation on LHS and RHS is undefined.  */
> +
> +static bool
> +cxx_eval_check_shift_p (enum tree_code code, tree lhs, tree rhs)
> +{
> +  if (code != LSHIFT_EXPR && code != RSHIFT_EXPR)
> +return false;
> +
> +  tree lhstype = TREE_TYPE (lhs);
> +  unsigned HOST_WIDE_INT uprec = TYPE_PRECISION (TREE_TYPE (lhs));
> +
> +  /* [expr.shift] The behavior is undefined if the right operand
> + is negative, or greater than or equal to the length in bits
> + of the promoted left operand.  */
> +  if (tree_int_cst_sgn (rhs) == -1 || compare_tree_int (rhs, uprec) >= 0)
> +return true;

I think VERIFY_CONSTANT doesn't guarantee both operands are INTEGER_CSTs.
Consider say:

constexpr int p = 1;
constexpr int foo (int a)
{
  return a << (int) &p;
}
constexpr int bar (int a)
{
  return ((int) &p) << a;
}
constexpr int q = foo (5);
constexpr int r = bar (2);
constexpr int s = bar (0);

Now, for foo (5) and bar (2) fold_binary_loc returns NULL and thus
your cxx_eval_check_shift_p is not called, for bar (0) it returns
non-NULL and while the result still is not a constant expression and
right now is diagnosed, with your patch it would ICE.

So, I'd just return false if either lhs or rhs are not INTEGER_CSTs.

> +
> +  /* The value of E1 << E2 is E1 left-shifted E2 bit positions; [...]
> + if E1 has a signed type and non-negative value, and E1x2^E2 is
> + representable in the corresponding unsigned type of the result type,
> + then that value, converted to the result type, is the resulting value;
> + otherwise, the behavior is undefined.  */
> +  if (code == LSHIFT_EXPR && !TYPE_UNSIGNED (lhstype))
> +{
> +  if (tree_int_cst_sgn (lhs) == -1)
> + return true;
> +  tree t = build_int_cst (unsigned_type_node, uprec - 1);
> +  t = fold_build2 (MINUS_EXPR, unsigned_type_node, t, rhs);
> +  tree ulhs = fold_convert (unsigned_type_for (lhstype), lhs);
> +  t = fold_build2 (RSHIFT_EXPR, TREE_TYPE (ulhs), ulhs, t);
> +  if (tree_int_cst_lt (integer_one_node, t))
> + return true;

I'll leave to Jason whether this shouldn't be using the various
cxx_eval_*_expression calls instead, or perhaps int_const_binop or wide_int
stuff directly.

Jakub

Re: [RS6000] Fix -mlongcall with nested functions on AIX

[David Edelsohn]

[Please explicitly copy me on relevant patches]

2014-10-17  Eric Botcazou  

* config/rs6000/rs6000.c (rs6000_call_aix): For the AIX ABI, do not
load the static chain if the call was originally direct.


2014-10-17  Eric Botcazou  

* gcc.target/powerpc/longcall-2.c: New test.

Okay.

Thanks, David

Re: [PATCH] Improve i?86 address delegitimization after 32-bit pic changes (PR target/63542)

[H.J. Lu]

On Tue, Oct 21, 2014 at 9:03 AM, Jakub Jelinek  wrote:
> On Mon, Sep 29, 2014 at 01:08:56PM +0200, Jakub Jelinek wrote:
>> I wonder if during/after reload we just couldn't look at
>> ORIGINAL_REGNO of hard regs if ix86_use_pseudo_pic_reg.  Or is that
>> the other case, where you don't have any PIC register replacement around,
>> and want to subtract something?  Perhaps in that case we could just
>> subtract the value of _GLOBAL_OFFSET_TABLE_ symbol if we have nothing better
>> around.
>
> Here is a patch that implements both of these ideas.
>
> The number of lines like:
> note: non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location
> note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location
> during i686-linux bootstrap (not including regtest) went down from
> 14165 to 19.
>
> The patch trusts that a hard reg with ORIGINAL_REGNO containing the pic
> pseudo contains the _GLOBAL_OFFSET_TABLE_ value of the current shared
> library (or binary), I think that is reasonable assumption.
> And for ELF for the UNSPEC_GOTOFF it worse case can subtract
> _GLOBAL_OFFSET_TABLE_ symbol if it doesn't know what register to subtract.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2014-10-21  Jakub Jelinek  
>
> PR target/63542
> * config/i386/i386.c (ix86_pic_register_p): Also return
> true if x is a hard register with ORIGINAL_REGNO equal to
> pic_offset_table_rtx pseudo REGNO.
> (ix86_delegitimize_address): For ix86_use_pseudo_pic_reg ()
> after reload, subtract GOT_SYMBOL_NAME symbol if possible.
>
> * gcc.target/i386/pr63542-1.c: New test.
> * gcc.target/i386/pr63542-2.c: New test.
>

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025


-- 
H.J.

[C PATCH] Fix PR63877

[Marek Polacek]

This PR is basically the same as PR54113, except this time it's about
-Wmissing-declarations and not about -Wmissing-prototypes.  The problem
here is that we were emitting bogus warning for a correct use of an
inline function.  Thus fixed in the same way as PR54113, that is, don't
warn for inline functions.

Bootstrapped/regtested on ppc64-linux, ok for trunk?

2014-11-24  Marek Polacek  

PR c/63877
* c-decl.c (start_function): Disable -Wmissing-declarations warning
for inline functions.

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

diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 9288e2c..6413e6f 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -8353,7 +8353,8 @@ start_function (struct c_declspecs *declspecs, struct 
c_declarator *declarator,
   else if (warn_missing_declarations
   && TREE_PUBLIC (decl1)
   && old_decl == 0
-  && !MAIN_NAME_P (DECL_NAME (decl1)))
+  && !MAIN_NAME_P (DECL_NAME (decl1))
+  && !DECL_DECLARED_INLINE_P (decl1))
 warning_at (loc, OPT_Wmissing_declarations,
"no previous declaration for %qD",
decl1);
diff --git gcc/testsuite/gcc.dg/pr63877.c gcc/testsuite/gcc.dg/pr63877.c
index e69de29..5969b39 100644
--- gcc/testsuite/gcc.dg/pr63877.c
+++ gcc/testsuite/gcc.dg/pr63877.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-Wmissing-declarations" } */
+
+inline int foo (void) { return 42; } /* { dg-bogus "no previous declaration" } 
*/
+extern int foo (void);

Marek

Re: [PATCH RFC]Pair load store instructions using a generic scheduling fusion pass

[James Greenhalgh]

On Fri, Nov 14, 2014 at 02:43:12AM +, Bin.Cheng wrote:
> On Fri, Nov 7, 2014 at 7:13 AM, Jeff Law  wrote:
> > On 11/05/14 02:30, Bin.Cheng wrote:
> >> Thanks very much for reviewing.  I refined the patch according to your
> >> comments.  Also made two small changes: a)  skip breaking dependency
> >> between memory access and the corresponding base-reg modifying
> >> instruction.  This feature doesn't help load/store pair that much and
> >> only increases compilation time.  b) a minor bug fix in arm backend
> >> hook when calculating priority for memory accesses with minus offset.
> >>
> >> I am running bootstrap/test against latest trunk, and will adapt
> >> ChangeLog once get approved generally.  So how about this one?
> >
> > OK for the trunk.  Thanks for your patience.
> >
> > Jeff
> >
> 
> Thanks for reviewing.  For the record, attached patch is committed.
> The only update is I disabled the pass if peephole2 isn't in effect
> because it relies on peephole2 to do real fusion work.

Hi Bin,

The documentation for TARGET_SCHED_FUSION_PRIORITY doesn't look
right to me (see: https://gcc.gnu.org/onlinedocs/gccint/Scheduling.html ).

I think you'll need to wrap your examples in something like @smallexample
tags if you want to maintain their formatting.

Thanks,
James

> Index: gcc/target.def
> ===
> --- gcc/target.def(revision 217474)
> +++ gcc/target.def(working copy)
> @@ -1526,6 +1526,79 @@ parallelism required in output calculations chain.
>  int, (unsigned int opc, machine_mode mode),
>  hook_int_uint_mode_1)
>  
> +/* The following member value is a function that returns priority for
> +   fusion of each instruction via pointer parameters.  */
> +DEFHOOK
> +(fusion_priority,
> +"This hook is called by scheduling fusion pass.  It calculates fusion\n\
> +priorities for each instruction passed in by parameter.  The priorities\n\
> +are returned via pointer parameters.\n\
> +\n\
> +@var{insn} is the instruction whose priorities need to be calculated.\n\
> +@var{max_pri} is the maximum priority can be returned in any cases.\n\
> +@var{fusion_pri} is the pointer parameter through which @var{insn}'s\n\
> +fusion priority should be calculated and returned.\n\
> +@var{pri} is the pointer parameter through which @var{insn}'s priority\n\
> +should be calculated and returned.\n\
> +\n\
> +Same @var{fusion_pri} should be returned for instructions which should\n\
> +be scheduled together.  Different @var{pri} should be returned for\n\
> +instructions with same @var{fusion_pri}.  @var{fusion_pri} is the major\n\
> +sort key, @var{pri} is the minor sort key.  All instructions will be\n\
> +scheduled according to the two priorities.  All priorities calculated\n\
> +should be between 0 (exclusive) and @var{max_pri} (inclusive).  To avoid\n\
> +false dependencies, @var{fusion_pri} of instructions which need to be\n\
> +scheduled together should be smaller than @var{fusion_pri} of irrelevant\n\
> +instructions.\n\
> +\n\
> +Given below example:\n\
> +\n\
> +ldr r10, [r1, 4]\n\
> +add r4, r4, r10\n\
> +ldr r15, [r2, 8]\n\
> +sub r5, r5, r15\n\
> +ldr r11, [r1, 0]\n\
> +add r4, r4, r11\n\
> +ldr r16, [r2, 12]\n\
> +sub r5, r5, r16\n\
> +\n\
> +On targets like ARM/AArch64, the two pairs of consecutive loads should be\n\
> +merged.  Since peephole2 pass can't help in this case unless consecutive\n\
> +loads are actually next to each other in instruction flow.  That's where\n\
> +this scheduling fusion pass works.  This hook calculates priority for each\n\
> +instruction based on its fustion type, like:\n\
> +\n\
> +ldr r10, [r1, 4]  ; fusion_pri=99,  pri=96   \n\
> +add r4, r4, r10   ; fusion_pri=100, pri=100  \n\
> +ldr r15, [r2, 8]  ; fusion_pri=98,  pri=92   \n\
> +sub r5, r5, r15   ; fusion_pri=100, pri=100  \n\
> +ldr r11, [r1, 0]  ; fusion_pri=99,  pri=100  \n\
> +add r4, r4, r11   ; fusion_pri=100, pri=100  \n\
> +ldr r16, [r2, 12] ; fusion_pri=98,  pri=88   \n\
> +sub r5, r5, r16   ; fusion_pri=100, pri=100  \n\
> +\n\
> +Scheduling fusion pass then sorts all ready to issue instructions 
> according\n\
> +to the priorities.  As a result, instructions of same fusion type will be\n\
> +pushed together in instruction flow, like:\n\
> +\n\
> +ldr r11, [r1, 0]\n\
> +ldr r10, [r1, 4]\n\
> +ldr r15, [r2, 8]\n\
> +ldr r16, [r2, 12]\n\
> +add r4, r4, r10\n\
> +sub r5, r5, r15\n\
> +add r4, r4, r11\n\
> +sub r5, r5, r16\n\
> +\n\
> +Now peephole2 pass can simply merge the two pairs of loads.\n\
> +\n\
> +Since scheduling fusion pass relies on peephole2 to do real fusion\n\
> +work, it is only enabled by default when peephole2 is in effect.\n\
> +\n\
> +This is firstly introduced on ARM/AArch64 targets, please refer to\n\
> +the hook implementation for how different fusion types are supported.",
> +void, (rtx_insn *insn, int max_pri, int *fusion_pri, int *pri)

Re: [PATCH, MPX wrappers 2/3] Replace some function calls with wrapper calls during instrumentation

[Ilya Enkovich]

On 18 Nov 19:42, Ilya Enkovich wrote:
> On 18 Nov 16:23, Joseph Myers wrote:
> > On Tue, 18 Nov 2014, Ilya Enkovich wrote:
> > 
> > > +@item -fcheck-pointer-bounds
> > > +@opindex fcheck-pointer-bounds
> > > +@opindex fno-check-pointer-bounds
> > > +Enable Pointer Bounds Checker instrumentation.  Each memory reference
> > > +is instrumented with checks of pointer used for memory access against
> > > +bounds associated with that pointer.  Generated instrumentation may
> > > +be controlled by various @option{-fchkp-*} options.
> > 
> > If this is only operational given -mmpx and when the generated code is run 
> > on a processor supporting MPX, I think the documentation needs to make 
> > that clear.
> > 
> > > +@item -fchkp-use-fast-string-functions
> > > +@opindex fchkp-use-fast-string-functions
> > > +@opindex fno-chkp-use-fast-string-functions
> > > +Allow to use *_nobnd versions of string functions (not copying bounds)
> > > +by Pointer Bounds Checker.  Disabled by default.
> > 
> > @code{*_nobnd}.
> > 
> > > +@item -fchkp-use-nochk-string-functions
> > > +@opindex fchkp-use-nochk-string-functions
> > > +@opindex fno-chkp-use-nochk-string-functions
> > > +Allow to use *_nochk versions of string functions (not checking bounds)
> > > +by Pointer Bounds Checker.  Disabled by default.
> > 
> > @code{*_nochk).
> > 
> > > +@item -fchkp-instrument-marked-only
> > > +@opindex fchkp-instrument-marked-only
> > > +@opindex fno-chkp-instrument-marked-only
> > > +Instructs Pointer Bounds Checker to instrument only functions
> > > +marked with bnd_instrument attribute.  Disabled by default.
> > 
> > @code{bnd_instrument}.
> > 
> > > +@item -fchkp-use-wrappers
> > > +@opindex fchkp-use-wrappers
> > > +@opindex fno-chkp-use-wrappers
> > > +Allows Pointer Bounds Checker to replace calls to builtin function
> > > +with calls to wrapper functions.  Enabled by default.
> > 
> > "built-in functions".
> > 
> > -- 
> > Joseph S. Myers
> > jos...@codesourcery.com
> 
> Thank you for comments!  Below is a fixed version.
> 
> Ilya
> --


Here is a version with updated documentation.  Added -static-libmpx and 
-static-libmpxwrappers options.  Added description on runtime library 
dependencies.

Thanks,
Ilya
--
2014-11-24  Ilya Enkovich  

* c-family/c.opt (fchkp-use-wrappers): New.
* ipa-chkp.c (CHKP_WRAPPER_SYMBOL_PREFIX): New.
(chkp_wrap_function): New.
(chkp_build_instrumented_fndecl): Support wrapped
functions.
* doc/invoke.texi (-fcheck-pointer-bounds): New.
(-fchkp-check-incomplete-type): New.
(-fchkp-first-field-has-own-bounds): New.
(-fchkp-narrow-bounds): New.
(-fchkp-narrow-to-innermost-array): New.
(-fchkp-optimize): New.
(-fchkp-use-fast-string-functions): New.
(-fchkp-use-nochk-string-functions): New.
(-fchkp-use-static-bounds): New.
(-fchkp-use-static-const-bounds): New.
(-fchkp-treat-zero-dynamic-size-as-infinite): New.
(-fchkp-check-read): New.
(-fchkp-check-write): New.
(-fchkp-store-bounds): New.
(-fchkp-instrument-calls): New.
(-fchkp-instrument-marked-only): New.
(-fchkp-use-wrappers): New.
(-static-libmpx): New.
(-static-libmpxwrappers): New.


diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 283c632..3426059 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1040,6 +1040,10 @@ fchkp-instrument-marked-only
 C ObjC C++ ObjC++ LTO Report Var(flag_chkp_instrument_marked_only) Init(0)
 Instrument only functions marked with bnd_instrument attribute.
 
+fchkp-use-wrappers
+C ObjC C++ ObjC++ LTO Report Var(flag_chkp_use_wrappers) Init(1)
+Transform instrumented builtin calls into calls to wrappers.
+
 static-libmpx
 Driver
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 89edddb..cae40b8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -299,6 +299,15 @@ Objective-C and Objective-C++ Dialects}.
 @gccoptlist{-d@var{letters}  -dumpspecs  -dumpmachine  -dumpversion @gol
 -fsanitize=@var{style} -fsanitize-recover -fsanitize-recover=@var{style} @gol
 -fasan-shadow-offset=@var{number} -fsanitize-undefined-trap-on-error @gol
+-fcheck-pointer-bounds -fchkp-check-incomplete-type @gol
+-fchkp-first-field-has-own-bounds -fchkp-narrow-bounds @gol
+-fchkp-narrow-to-innermost-array -fchkp-optimize @gol
+-fchkp-use-fast-string-functions -fchkp-use-nochk-string-functions @gol
+-fchkp-use-static-bounds -fchkp-use-static-const-bounds @gol
+-fchkp-treat-zero-dynamic-size-as-infinite -fchkp-check-read @gol
+-fchkp-check-read -fchkp-check-write -fchkp-store-bounds @gol
+-fchkp-instrument-calls -fchkp-instrument-marked-only @gol
+-fchkp-use-wrappers @gol
 -fdbg-cnt-list -fdbg-cnt=@var{counter-value-list} @gol
 -fdisable-ipa-@var{pass_name} @gol
 -fdisable-rtl-@var{pass_name} @gol
@@ -469,6 +478,7 @@ Objective-C and Objective-C++ Dialects}.
 -nostartfiles  -nodefaultlibs  -nostdlib -pie -rdynamic @gol
 -s 

Re: [PATCH, MPX wrappers 1/3] Add MPX wrappers library

[Ilya Enkovich]

On 21 Nov 23:32, Joseph Myers wrote:
> On Fri, 21 Nov 2014, Ilya Enkovich wrote:
> 
> > * c-family/c.opt (static-libmpxwrappers): New.
> 
> New options need documenting in invoke.texi.  This includes driver 
> options.
> 
I'll include it into patch with all checker options documented bacause of 
options cross-references.

> > diff --git a/libmpx/mpxwrap/mpx_wrappers.c b/libmpx/mpxwrap/mpx_wrappers.c
> > new file mode 100644
> > index 000..bcff80f
> > --- /dev/null
> > +++ b/libmpx/mpxwrap/mpx_wrappers.c
> > @@ -0,0 +1,258 @@
> > +/* MPX Wrappers Library
> > +   Copyright (C) 2014 Free Software Foundation, Inc.
> > +   Contributed by Ilya Enkovich (ilya.enkov...@intel.com)
> > +
> > +   This file is part of the libmpxwrappers library.
> > +
> > +   This library is free software; you can redistribute it and/or
> > +   modify it under the terms of the GNU Lesser General Public
> > +   License as published by the Free Software Foundation; either
> > +   version 2.1 of the License, or (at your option) any later version.
> > +
> > +   This library is distributed in the hope that it will be useful,
> > +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > +   Lesser General Public License for more details.
> > +
> > +   You should have received a copy of the GNU Lesser General Public
> > +   License along with this library; if not, write to the Free Software
> > +   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  
> > USA.  */
> 
> Normally GCC target libraries assigned to the FSF would use GPL+exception 
> rather than LGPL (especially if the library might be linked in 
> statically), to keep predictable what requirements are imposed by linking 
> your program with GCC.  libquadmath is an exception because it contains 
> LGPL code not assigned to the FSF.

I'm OK to put it under GPL+exception.

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

Here is an updated version.

Thanks,
Ilya
--
gcc/

2014-11-24  Ilya Enkovich  

* gcc.c (LIBMPX_WRAPPERSSPEC): New.
(MPX_SPEC): Add wrappers library.
* c-family/c.opt (static-libmpxwrappers): New.

libmpx/

2014-11-24  Ilya Enkovich  

* Makefile.am (SUBDIRS): Add mpxwrap when used
AS supports MPX.
(MAKEOVERRIDES): New.
* Makefile.in: Regenerate.
* configure.ac: Check AS supports MPX.  Add
mpxintr/Makefile to config files.
* configure: Regenerate.
* mpxwrap/Makefile.am: New.
* mpxwrap/Makefile.in: New.
* mpxwrap/libtool-version: New.
* mpxwrap/mpx_wrappers.cc: New.
* mpxwrap/libmpxwrappers.map: New.


diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 8f5d76c..283c632 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1043,6 +1043,9 @@ Instrument only functions marked with bnd_instrument 
attribute.
 static-libmpx
 Driver
 
+static-libmpxwrappers
+Driver
+
 fcilkplus
 C ObjC C++ ObjC++ LTO Report Var(flag_cilkplus) Init(0)
 Enable Cilk Plus
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 75e5767..aa8c9a3 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -828,9 +828,23 @@ proper position among the other output files.  */
 #endif
 #endif
 
+#ifndef LIBMPXWRAPPERS_SPEC
+#if defined(HAVE_LD_STATIC_DYNAMIC)
+#define LIBMPXWRAPPERS_SPEC "\
+%{mmpx:%{fcheck-pointer-bounds:%{!fno-chkp-use-wrappers:\
+%{static:-lmpxwrappers}\
+%{!static:%{static-libmpxwrappers:" LD_STATIC_OPTION " --whole-archive}\
+-lmpxwrappers %{static-libmpxwrappers:--no-whole-archive "\
+LD_DYNAMIC_OPTION "}"
+#else
+#define LIBMPXWRAPPERS_SPEC "\
+%{mmpx:%{fcheck-pointer-bounds:{!fno-chkp-use-wrappers:-lmpxwrappers}}}"
+#endif
+#endif
+
 #ifndef MPX_SPEC
 #define MPX_SPEC "\
-%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC "}}"
+%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC LIBMPXWRAPPERS_SPEC "}}"
 #endif
 
 /* -u* was put back because both BSD and SysV seem to support it.  */
diff --git a/libmpx/Makefile.am b/libmpx/Makefile.am
index 6cee4ac..bd0a8b6 100644
--- a/libmpx/Makefile.am
+++ b/libmpx/Makefile.am
@@ -2,6 +2,9 @@ ACLOCAL_AMFLAGS = -I .. -I ../config
 
 if LIBMPX_SUPPORTED
 SUBDIRS = mpxrt
+if MPX_AS_SUPPORTED
+SUBDIRS += mpxwrap
+endif
 nodist_toolexeclib_HEADERS = libmpx.spec
 endif
 
@@ -45,3 +48,5 @@ AM_MAKEFLAGS = \
"PICFLAG=$(PICFLAG)" \
"RANLIB=$(RANLIB)" \
"DESTDIR=$(DESTDIR)"
+
+MAKEOVERRIDES =
diff --git a/libmpx/configure.ac b/libmpx/configure.ac
index dbfad02..4669525 100644
--- a/libmpx/configure.ac
+++ b/libmpx/configure.ac
@@ -100,6 +100,18 @@ AC_CHECK_TOOL(AS, as)
 AC_CHECK_TOOL(AR, ar)
 AC_CHECK_TOOL(RANLIB, ranlib, :)
 
+# Check we may build wrappers library
+echo "test:  bndmov %bnd0, %bnd1" > conftest.s
+if AC_TRY_COMMAND([$AS -o conftest.o conftest.s 1>&AS_MESSAGE_LOG_FD])
+then
+mpx_as=yes
+else
+mpx_as=no
+echo "configure: no MPX support fo as" >&AS_MESSAGE_LOG_FD
+fi
+rm -f conftest.o 

Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library

[Ilya Enkovich]

On 21 Nov 23:20, Joseph Myers wrote:
> On Fri, 21 Nov 2014, Ilya Enkovich wrote:
> 
> > +# Disable libmpx on unsupported systems.
> > +if test -d ${srcdir}/libmpx; then
> > +if test x$enable_libmpx = x; then
> > +   AC_MSG_CHECKING([for libmpx support])
> > +   if (srcdir=${srcdir}/libmpx; \
> > +   . ${srcdir}/configure.tgt; \
> > +   test "$LIBMPX_SUPPORTED" != "yes")
> > +   then
> > +   AC_MSG_RESULT([no])
> > +   noconfigdirs="$noconfigdirs target-libmpx"
> > +   else
> > +   AC_MSG_RESULT([yes])
> > +   fi
> > +fi
> > +fi
> 
> Using this at toplevel you can only enable or disable for all multilibs - 
> this code runs just once.  But:
> 
> > diff --git a/libmpx/configure.tgt b/libmpx/configure.tgt
> 
> > +LIBMPX_SUPPORTED=no
> > +case "${target}" in
> > +  x86_64-*-linux* | i?86-*-linux*)
> > +   # X32 doesn't support MPX.
> > +   echo "int i[sizeof (void *) == 4 ? 1 : -1] = { __x86_64__ };" > 
> > conftestx.c
> > +   if ${CC} ${CFLAGS} -c -o conftestx.o conftestx.c > /dev/null 2>&1; then
> > +   LIBMPX_SUPPORTED=no
> > +   else
> > +   LIBMPX_SUPPORTED=yes
> > +   fi
> > +   ;;
> 
> Here you are testing something per-multilib.  Furthermore, using CC and 
> CFLAGS here is wrong when used by toplevel configure, as at toplevel 
> they'll relate to the host rather than the target.
> 
> So you need to separate the two tests of (a) might MPX be supported for 
> some multilib on the target (usable at toplevel, not using CC or CFLAGS) 
> and (b) is it supported for the present multilib.  Thus the libmpx 
> directory will need configuring for all multilibs for supported targets.  
> Then, if the particular multilib doesn't support it (i.e. is x32), you'll 
> need to arrange for the directory not to build or install anything - much 
> like the libquadmath directory gets configured in some cases where it 
> doesn't build anything.

Right.  This works for both top level and multilib checks because failing test 
is used and CC is usually not set when it's called by the top level configure.  
If we configure with CC=... then it may go wrong.  I left only target check in 
configure.tgt and inlined test for x32 into libmpx configure.

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

Here is an updated version.

Thanks,
Ilya
--
diff --git a/Makefile.def b/Makefile.def
index 40bbca9..4a535d2 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -128,6 +128,9 @@ target_modules = { module= libsanitizer;
   bootstrap=true;
   lib_path=.libs;
   raw_cxx=true; };
+target_modules = { module= libmpx;
+  bootstrap=true;
+  lib_path=.libs; };
 target_modules = { module= libvtv;
   bootstrap=true;
   lib_path=.libs;
diff --git a/configure.ac b/configure.ac
index b27fb1d..ccb119b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -162,6 +162,7 @@ target_libraries="target-libgcc \
target-libstdc++-v3 \
target-libsanitizer \
target-libvtv \
+   target-libmpx \
target-libssp \
target-libquadmath \
target-libgfortran \
@@ -642,6 +643,25 @@ if test -d ${srcdir}/libvtv; then
 fi
 fi
 
+
+# Disable libmpx on unsupported systems.
+if test -d ${srcdir}/libmpx; then
+if test x$enable_libmpx = x; then
+   AC_MSG_CHECKING([for libmpx support])
+   if (srcdir=${srcdir}/libmpx; \
+   . ${srcdir}/configure.tgt; \
+   test "$LIBMPX_SUPPORTED" != "yes")
+   then
+   AC_MSG_RESULT([no])
+   noconfigdirs="$noconfigdirs target-libmpx"
+   else
+   AC_MSG_RESULT([yes])
+   fi
+fi
+fi
+
+
+
 # Disable libquadmath for some systems.
 case "${target}" in
   avr-*-*)
@@ -2652,6 +2672,11 @@ if echo " ${target_configdirs} " | grep " libvtv " > 
/dev/null 2>&1 &&
   bootstrap_target_libs=${bootstrap_target_libs}target-libvtv,
 fi
 
+# If we are building libmpx, bootstrap it.
+if echo " ${target_configdirs} " | grep " libmpx " > /dev/null 2>&1; then
+  bootstrap_target_libs=${bootstrap_target_libs}target-libmpx,
+fi
+
 # Determine whether gdb needs tk/tcl or not.
 # Use 'maybe' since enable_gdbtk might be true even if tk isn't available
 # and in that case we want gdb to be built without tk.  Ugh!
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 85dcb98..8f5d76c 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1040,6 +1040,9 @@ fchkp-instrument-marked-only
 C ObjC C++ ObjC++ LTO Report Var(flag_chkp_instrument_marked_only) Init(0)
 Instrument only functions marked with bnd_instrument attribute.
 
+static-libmpx
+Driver
+
 fcilkplus
 C ObjC C++ ObjC++ LTO Report Var(flag_cilkplus) Init(0)
 Enable Cilk Plus
diff --git a/gcc/config/i386/cpuid.h b/gcc/config/i386/cpuid.h
index 133e356..f85cebb 100644
--- a/gcc/config/i386/cpuid.h
+++ b/gcc/config/i386/cpuid.h

RE: [PATCH] Work around in-tree gmp configure problems

[Bernd Edlinger]

Hi Richard,


On Mon, 24 Nov 2014 14:11:19 +0100, Jan-Benedict Glaw wrote:
>
> Hi Richard,
>
> On Mon, 2014-11-24 12:53:11 +0100, Richard Biener 
>  wrote:
>> On Sat, Nov 22, 2014 at 4:34 PM, Jan-Benedict Glaw  wrote:
>>> On Sat, 2014-11-22 14:33:29 +0100, Bernd Edlinger 
>>>  wrote:
 since r217627 we use an updated AutoMake "missing" script. However
 that revealed a hidden bug in gmp-4.3.2's (up to gmp-6.0.0a)
 configure script. That is: an in-tree gmp/configure fails now if
 flex is missing. The gmp configure uses our missing flex script,
 and previously that emitted an error message and created a dummy
 lex.yy.c, The new version of that script does no longer create any
 lex.yy.c.
>>> [...]
 2014-11-22 Bernd Edlinger 

 * Makefile.def (module=gmp): Work around in-tree gmp configure
 bug with missing flex.
 * Makefile.in: Regenerated.
>>>
>>> Bernd and I discussed that patch; I'm all for it! Looks like that's
>>> the least-ugly thing we'd possibly come up with.
>>
>> I suppose it is fixed upstream now?
>
> *cough* No. Not at all.
>
> I subscribed to gmp-devel and sent a longish email with all the
> details, just to get it rejected: gmp-devel seems to be used for
> internal discussion between core developers. Re-sent it to
> gmp-discuss, but no response there at all. So up to now, there's no
> upstream change on the GMP side at all.
>
> In the mean time, I received other emails about specific problematic
> cases; the outcome there is that they're asking the GCC guys to not
> recommend the old 4.3.2 release, but to use some modern version and
> build it with --disable-assembly. Of course, that doesn't fix the
> observed configure problem. (However, using a modern version sounds
> like a fair request.)
>

Yes.

We disable the asm-parts by passing 
host=target="none-${host_vendor}-${host_os}".
Hope that still works.

Maybe I should note, that gmp-6.0.0a turned out to be incomatible to
mpfr-2.4.2 and mpc-0.8.1: gmp-6.0.0a does no longer define __gmp_const,
so these need to be updated at the same time.


Bernd.


  

[C++ PATCH] Detect UB in shifts in constexpr functions

[Marek Polacek]

Constant expressions can't contain undefined behavior, which means that
using an expression containing UB in a context requiring a constant
expression makes the program invalid and we're required to diagnose that.
We fail to diagnose UB if using shifts, because fold_binary_loc returns
zero for a shift containing UB.  So I wrote a function that checks whether
the shift operation is ok.
I'm not sure yet if anything else needs similar treatment.

Bootstrapped/regtested on ppc64-linux, ok for trunk?

2014-11-24  Marek Polacek  

* constexpr.c (cxx_eval_check_shift_p): New function.
(cxx_eval_binary_expression): Call it.

* g++.dg/cpp0x/constexpr-shift1.C: New test.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 2678223..2047a09 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -1451,6 +1451,43 @@ verify_constant (tree t, bool allow_non_constant, bool 
*non_constant_p,
   return *non_constant_p;
 }
 
+/* Return true if the shift operation on LHS and RHS is undefined.  */
+
+static bool
+cxx_eval_check_shift_p (enum tree_code code, tree lhs, tree rhs)
+{
+  if (code != LSHIFT_EXPR && code != RSHIFT_EXPR)
+return false;
+
+  tree lhstype = TREE_TYPE (lhs);
+  unsigned HOST_WIDE_INT uprec = TYPE_PRECISION (TREE_TYPE (lhs));
+
+  /* [expr.shift] The behavior is undefined if the right operand
+ is negative, or greater than or equal to the length in bits
+ of the promoted left operand.  */
+  if (tree_int_cst_sgn (rhs) == -1 || compare_tree_int (rhs, uprec) >= 0)
+return true;
+
+  /* The value of E1 << E2 is E1 left-shifted E2 bit positions; [...]
+ if E1 has a signed type and non-negative value, and E1x2^E2 is
+ representable in the corresponding unsigned type of the result type,
+ then that value, converted to the result type, is the resulting value;
+ otherwise, the behavior is undefined.  */
+  if (code == LSHIFT_EXPR && !TYPE_UNSIGNED (lhstype))
+{
+  if (tree_int_cst_sgn (lhs) == -1)
+   return true;
+  tree t = build_int_cst (unsigned_type_node, uprec - 1);
+  t = fold_build2 (MINUS_EXPR, unsigned_type_node, t, rhs);
+  tree ulhs = fold_convert (unsigned_type_for (lhstype), lhs);
+  t = fold_build2 (RSHIFT_EXPR, TREE_TYPE (ulhs), ulhs, t);
+  if (tree_int_cst_lt (integer_one_node, t))
+   return true;
+}
+
+  return false;
+}
+
 /* Subroutine of cxx_eval_constant_expression.
Attempt to reduce the unary expression tree T to a compile time value.
If successful, return the value.  Otherwise issue a diagnostic
@@ -1506,7 +1543,7 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, 
tree t,
   enum tree_code code = TREE_CODE (t);
   tree type = TREE_TYPE (t);
   r = fold_binary_loc (loc, code, type, lhs, rhs);
-  if (r == NULL_TREE)
+  if (r == NULL_TREE || cxx_eval_check_shift_p (code, lhs, rhs))
 {
   if (lhs == orig_lhs && rhs == orig_rhs)
r = t;
diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-shift1.C 
gcc/testsuite/g++.dg/cpp0x/constexpr-shift1.C
index e69de29..2551fbe 100644
--- gcc/testsuite/g++.dg/cpp0x/constexpr-shift1.C
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-shift1.C
@@ -0,0 +1,73 @@
+// { dg-do compile { target c++11 } }
+
+constexpr int
+fn1 (int i, int j)
+{
+  return i << j; // { dg-error "is not a constant expression" }
+}
+
+constexpr int i1 = fn1 (1, -1);
+
+constexpr int
+fn2 (int i, int j)
+{
+  return i << j; // { dg-error "is not a constant expression" }
+}
+
+constexpr int i2 = fn2 (1, 200);
+
+constexpr int
+fn3 (int i, int j)
+{
+  return i << j; // { dg-error "is not a constant expression" }
+}
+
+constexpr int i3 = fn3 (-1, 2);
+
+constexpr int
+fn4 (int i, int j)
+{
+  return i << j; // { dg-error "is not a constant expression" }
+}
+
+constexpr int i4 = fn4 (__INT_MAX__, 2);
+
+constexpr int
+fn5 (int i, int j)
+{
+  return i << j;
+}
+
+constexpr int i5 = fn5 (__INT_MAX__, 1);
+
+constexpr int
+fn6 (unsigned int i, unsigned int j)
+{
+  return i << j; // { dg-error "is not a constant expression" }
+}
+
+constexpr int i6 = fn6 (1, -1);
+
+constexpr int
+fn7 (int i, int j)
+{
+  return i >> j; // { dg-error "is not a constant expression" }
+}
+
+constexpr int i7 = fn7 (1, -1);
+
+constexpr int
+fn8 (int i, int j)
+{
+  return i >> j;
+}
+
+constexpr int i8 = fn8 (-1, 1);
+
+constexpr int
+fn9 (int i, int j)
+{
+  return i >> j;  // { dg-error "is not a constant expression" }
+}
+
+constexpr int i9 = fn9 (1, 200);

Marek

[PATCH] check_GNU_style.sh "80 characters exceeded" error fix

[Mantas Mikaitis]

check_GNU_style.sh error "Lines should not exceed 80 characters" does not 
return the file name and line number where error is present,
only the line of code. Whereas other kind of errors return full information.

This small patch will fix this and make check_GNU_style.sh return full 
information when patch contains lines longer than 80 errors.

Tested on patches containing >80 chars lines and the script produces full 
information as necessary.

Would this be a useful enhancement for trunk?

Mantas Mikaitis

gcc/ChangeLog:

 * contrib/check_GNU_style.sh (col): Got rid of cut operation
   from the pipe chain and instead added cut inside awk command.



diff --git a/contrib/check_GNU_style.sh b/contrib/check_GNU_style.sh
index ef8fdda..c405eeb 100755
--- a/contrib/check_GNU_style.sh
+++ b/contrib/check_GNU_style.sh
@@ -86,8 +86,7 @@ col (){
 shift 1
 grep -nH '^+' $* \
 	| grep -v ':+++' \
-	| cut -f 2 -d '+' \
-	| awk '{ if (length ($0) > 80) print $0 }' \
+	| awk -F':\\+' '{ if (length($2) > 80) print $0}' \
 	> $tmp
 if [ -s $tmp ]; then
 	printf "\n$msg\n"

RE: [PATCH] AArch64: Add TARGET_SCHED_REASSOCIATION_WIDTH

[Wilco Dijkstra]

> Richard Earnshaw wrote:
> If all cores seem to benefit from FP reassociation set to 4, then it
> seems odd that 4 is not also the default for generic.
> 
> Andrew, you may need to pick a target-specific value for ThunderX; I
> think Wilco has just picked something that seems plausible because he
> needs to put a real value in there.
> 
> What happens if the integer and vector numbers are bumped up?  I'd have
> thought that integer numbers >1 would be appropriate on all dual-issue
> or greater cores.

I tried int and vector as well, and setting int to 2 did give an improvement,
but vector had no effect, so I'll leave to 1 for now. The patch is the same 
as last time, it just sets integer to 2, and uses the same settings for all 
CPUs.

OK for commit?

ChangeLog:
2014-11-24  Wilco Dijkstra  

* gcc/config/aarch64/aarch64-protos.h (tune-params):
Add reasociation tuning parameters.
* gcc/config/aarch64/aarch64.c (TARGET_SCHED_REASSOCIATION_WIDTH):
Define.  (aarch64_reassociation_width): New function.
(generic_tunings) Add reassociation tuning parameters.
(cortexa53_tunings): Likewise.
(cortexa57_tunings): Likewise.
(thunderx_tunings): Likewise.

---
 gcc/config/aarch64/aarch64-protos.h |  3 +++
 gcc/config/aarch64/aarch64.c| 36 
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index a9985b5..ac3487b 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -170,6 +170,9 @@ struct tune_params
   const struct cpu_vector_cost *const vec_costs;
   const int memmov_cost;
   const int issue_rate;
+  const int int_reassoc_width;
+  const int fp_reassoc_width;
+  const int vec_reassoc_width;
 };
 
 HOST_WIDE_INT aarch64_initial_elimination_offset (unsigned, unsigned);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 3832123..e543161 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -314,7 +314,10 @@ static const struct tune_params generic_tunings =
   &generic_regmove_cost,
   &generic_vector_cost,
   NAMED_PARAM (memmov_cost, 4),
-  NAMED_PARAM (issue_rate, 2)
+  NAMED_PARAM (issue_rate, 2),
+  2,   /* int_reassoc_width.  */
+  4,   /* fp_reassoc_width.  */
+  1/* vec_reassoc_width.  */
 };
 
 static const struct tune_params cortexa53_tunings =
@@ -324,7 +327,10 @@ static const struct tune_params cortexa53_tunings =
   &cortexa53_regmove_cost,
   &generic_vector_cost,
   NAMED_PARAM (memmov_cost, 4),
-  NAMED_PARAM (issue_rate, 2)
+  NAMED_PARAM (issue_rate, 2),
+  2,   /* int_reassoc_width.  */
+  4,   /* fp_reassoc_width.  */
+  1/* vec_reassoc_width.  */
 };
 
 static const struct tune_params cortexa57_tunings =
@@ -334,7 +340,10 @@ static const struct tune_params cortexa57_tunings =
   &cortexa57_regmove_cost,
   &cortexa57_vector_cost,
   NAMED_PARAM (memmov_cost, 4),
-  NAMED_PARAM (issue_rate, 3)
+  NAMED_PARAM (issue_rate, 3),
+  2,   /* int_reassoc_width.  */
+  4,   /* fp_reassoc_width.  */
+  1/* vec_reassoc_width.  */
 };
 
 static const struct tune_params thunderx_tunings =
@@ -344,7 +353,10 @@ static const struct tune_params thunderx_tunings =
   &thunderx_regmove_cost,
   &generic_vector_cost,
   NAMED_PARAM (memmov_cost, 6),
-  NAMED_PARAM (issue_rate, 2)
+  NAMED_PARAM (issue_rate, 2),
+  2,   /* int_reassoc_width.  */
+  4,   /* fp_reassoc_width.  */
+  1/* vec_reassoc_width.  */
 };
 
 /* A processor implementing AArch64.  */
@@ -437,6 +449,19 @@ static const char * const aarch64_condition_codes[] =
   "hi", "ls", "ge", "lt", "gt", "le", "al", "nv"
 };
 
+static int
+aarch64_reassociation_width (unsigned opc ATTRIBUTE_UNUSED,
+enum machine_mode mode)
+{
+  if (VECTOR_MODE_P (mode))
+return aarch64_tune_params->vec_reassoc_width;
+  if (INTEGRAL_MODE_P (mode))
+return aarch64_tune_params->int_reassoc_width;
+  if (FLOAT_MODE_P (mode))
+return aarch64_tune_params->fp_reassoc_width;
+  return 1;
+}
+
 /* Provide a mapping from gcc register numbers to dwarf register numbers.  */
 unsigned
 aarch64_dbx_register_number (unsigned regno)
@@ -10499,6 +10524,9 @@ aarch64_gen_ccmp_next (rtx prev, int cmp_code, rtx op0, 
rtx op1, int
bit_code)
 #undef TARGET_PREFERRED_RELOAD_CLASS
 #define TARGET_PREFERRED_RELOAD_CLASS aarch64_preferred_reload_class
 
+#undef TARGET_SCHED_REASSOCIATION_WIDTH
+#define TARGET_SCHED_REASSOCIATION_WIDTH aarch64_reassociation_width
+
 #undef TARGET_SECONDARY_RELOAD
 #define TARGET_SECONDARY_RELOAD aarch64_secondary_reload
 
-- 
1.9.1

[Patch, Fortran] Move gfc_internal_error to common diagnostics

[Tobias Burnus]

Dear all,

this patch uses the common diagnostic code for gfc_internal_error; the
change is essentially only in error.c, but I additionally changed:

* Use gfc_fatal_error for the user-reachable message:
   if (gfc_option.flag_allow_leading_underscore && letter == '_')
 gfc_internal_error ("Option -fallow-leading-underscore is for use only by "
"gfortran developers, and should not be used for "
"implicitly typed variables");

* Used a bunch of %<...%> or %qs for nicer output

* Always use gfc_internal_error instead of internal_error

* Updated some gfc_*_now* comments to reflect the current status.


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

Tobias

PS: I used -fallow-leading-underscore to test the patch - before changing it
to gfc_fatal_error, which worked fine.

PPS: I somehow missed to commit the following bits with my fatal-errors patch;
I will commit them this evening - unless someone else wants to have the
honour:

diff --git a/gcc/testsuite/gfortran.dg/coarray_collectives_3.f90 
b/gcc/testsuite/gfortran.dg/coarray_collectives_3.f90
index bb4d2d3..2a3ddf4 100644
--- a/gcc/testsuite/gfortran.dg/coarray_collectives_3.f90
+++ b/gcc/testsuite/gfortran.dg/coarray_collectives_3.f90
@@ -10,0 +11 @@ end program test
+! { dg-excess-errors "compilation terminated" }
diff --git a/gcc/testsuite/gfortran.dg/dollar_sym_3.f 
b/gcc/testsuite/gfortran.dg/dollar_sym_3.f
index 8b26445..7b9b344 100644
--- a/gcc/testsuite/gfortran.dg/dollar_sym_3.f
+++ b/gcc/testsuite/gfortran.dg/dollar_sym_3.f
@@ -10,0 +11 @@ c Segmentation fault in gfc_restore_last_undo_checkpoint
+! { dg-excess-errors "compilation terminated" }
2014-11-24  Tobias Burnus  

	* error.c: Update comments.
	(gfc_internal_error): Convert to common diagnostics.
	* interface.c (gfc_find_sym_in_symtree): Use %qs.
	* intrinsic.c (make_generic, gfc_check_intrinsic_standard,
	gfc_convert_type_warn): Ditto.
	* module.c (write_symbol): Ditto.
	* symbol.c (gfc_get_default_type): Ditto; use fatal instead
	of internal error.
	* trans-array.c (gfc_walk_subexpr): Replace internal_error by
	gfc_internal_error.
	* trans-decl.c (gfc_get_symbol_decl,
	(gfc_create_module_variable): Ditto. Use %qs.
	* trans-intrinsic.c (gfc_conv_intrinsic_lib_function): Ditto.
	* trans-io.c (transfer_expr): Ditto.
	* trans-openmp.c (gfc_trans_omp_workshare): Ditto.
	* trans.c (trans_code): Ditto.

diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c
index 202dd88..a7d7e09 100644
--- a/gcc/fortran/error.c
+++ b/gcc/fortran/error.c
@@ -935,3 +935,4 @@ gfc_notify_std (int std, const char *gmsgid, ...)
 /* Immediate warning (i.e. do not buffer the warning).  */
-/* Use gfc_warning_now_2 instead, unless gmsgid contains a %L.  */
+/* Use gfc_warning_now_2 instead, except for scanner.c which might have an
+   invalid line buffer.  */
 
@@ -1096,3 +1097,4 @@ gfc_diagnostic_finalizer (diagnostic_context *context,
 /* Immediate warning (i.e. do not buffer the warning).  */
-/* This function uses the common diagnostics, but does not support %L, yet.  */
+/* This function uses the common diagnostics, but might not work for
+   scanner.c as it not always has a working line buffer.  */
 
@@ -1115,3 +1117,4 @@ gfc_warning_now_2 (int opt, const char *gmsgid, ...)
 /* Immediate warning (i.e. do not buffer the warning).  */
-/* This function uses the common diagnostics, but does not support %L, yet.  */
+/* This function uses the common diagnostics, but might not work for
+   scanner.c as it not always has a working line buffer.  */
 
@@ -1134,3 +1137,4 @@ gfc_warning_now_2 (const char *gmsgid, ...)
 /* Immediate error (i.e. do not buffer).  */
-/* This function uses the common diagnostics, but does not support %L, yet.  */
+/* This function uses the common diagnostics, but might not work for
+   scanner.c as it not always has a working line buffer.  */
 
@@ -1243,3 +1247,4 @@ warning:
 /* Immediate error.  */
-/* Use gfc_error_now_2 instead, unless gmsgid contains a %L.  */
+/* Use gfc_error_now_2 instead, except for scanner.c which might have an
+   invalid line buffer.  */
 
@@ -1276,17 +1281,13 @@ gfc_error_now (const char *gmsgid, ...)
 void
-gfc_internal_error (const char *format, ...)
+gfc_internal_error (const char *gmsgid, ...)
 {
   va_list argp;
+  diagnostic_info diagnostic;
 
-  buffer_flag = 0;
-
-  va_start (argp, format);
-
-  show_loci (&gfc_current_locus, NULL);
-  error_printf ("Internal Error at (1):");
-
-  error_print ("", format, argp);
+  va_start (argp, gmsgid);
+  diagnostic_set_info (&diagnostic, gmsgid, &argp, UNKNOWN_LOCATION, DK_ICE);
+  report_diagnostic (&diagnostic);
   va_end (argp);
 
-  exit (ICE_EXIT_CODE);
+  gcc_unreachable ();
 }
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 1eb09ac..1980ddf 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -3544,3 +3544,3 @@ gfc_find_sym_in_symtree (gfc_symbol *sym)
 }
-  gfc_internal_error ("Unable to find symbol %s", 

Re: [Patch, Fortran] Remove gfc_fatal_error_1

[H.J. Lu]

On Sun, Nov 23, 2014 at 12:21 PM, Tobias Burnus  wrote:
> This patch depends on Manuel's %L patch.
>
> It converts the remaining fatal error calls to the common diagnostic
> infrastructure and retires (removes) the old gfc_fatal_error_1.
>
> I will build and regtest it after Manuel's commit.
> OK, when it succeeds?
>
> Tobias

On Linux/x86, it caused:

FAIL: gfortran.dg/coarray_collectives_3.f90   -O  (test for excess errors)
FAIL: gfortran.dg/dollar_sym_1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/dollar_sym_3.f   -O  (test for excess errors)


-- 
H.J.

Re: [PATCH/TopLevel] Fix compiling libgo with a combined sources

[Jan-Benedict Glaw]

Hi Andrew,

On Sat, 2014-11-22 20:20:08 -0800, Andrew Pinski  wrote:
> Hi,
>   The problem here is here is that OBJCOPY is not being set to the
> newly built objcopy when compiling libgo.  This patch adds
> OBJCOPY_FOR_TARGET to the toplevel configure/Makefile so that when
> libgo is compiled OBJCOPY is set to OBJCOPY_FOR_TARGET.
> 
> I noticed this issue when building an aarch64 cross compile on an
> older system where objcopy did not understand aarch64.
> 
> OK?  Bootstrapped and tested on x86_64 with no regressions.  Also
> tested with a combined build for a cross compiler to
> aarch64-linux-gnu.

I just sent a patch set these days, bringing the configury of Binutils
and GCC in sync again.

  Quite a number of changes accumulated in both trees that weren't
merged. I'm quite willing to keep those in sync, but let's have a
dicision whether or not we see those as common files---or not.

  That is, I would be grateful if you'd commit that patch after mine
is accepted (or right away, if my patch set is rejected.) Would save
me from some rebase hell. ;-)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: Alles wird gut! ...und heute wirds schon ein bißchen 
besser.
the second  :


signature.asc
Description: Digital signature

Re: [PATCH] Work around in-tree gmp configure problems

[Jan-Benedict Glaw]

Hi Richard,

On Mon, 2014-11-24 12:53:11 +0100, Richard Biener  
wrote:
> On Sat, Nov 22, 2014 at 4:34 PM, Jan-Benedict Glaw  wrote:
> > On Sat, 2014-11-22 14:33:29 +0100, Bernd Edlinger 
> >  wrote:
> > > since r217627 we use an updated AutoMake "missing" script.  However
> > > that revealed a hidden bug in gmp-4.3.2's (up to gmp-6.0.0a)
> > > configure script.  That is: an in-tree gmp/configure fails now if
> > > flex is missing.  The gmp configure uses our missing flex script,
> > > and previously that emitted an error message and created a dummy
> > > lex.yy.c, The new version of that script does no longer create any
> > > lex.yy.c.
> > [...]
> > > 2014-11-22  Bernd Edlinger  
> > >
> > >   * Makefile.def (module=gmp): Work around in-tree gmp configure
> > >   bug with missing flex.
> > >   * Makefile.in: Regenerated.
> >
> > Bernd and I discussed that patch; I'm all for it! Looks like that's
> > the least-ugly thing we'd possibly come up with.
> 
> I suppose it is fixed upstream now?

*cough* No. Not at all.

I subscribed to gmp-devel and sent a longish email with all the
details, just to get it rejected: gmp-devel seems to be used for
internal discussion between core developers. Re-sent it to
gmp-discuss, but no response there at all. So up to now, there's no
upstream change on the GMP side at all.

  In the mean time, I received other emails about specific problematic
cases; the outcome there is that they're asking the GCC guys to not
recommend the old 4.3.2 release, but to use some modern version and
build it with --disable-assembly.  Of course, that doesn't fix the
observed configure problem. (However, using a modern version sounds
like a fair request.)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Fortschritt bedeutet, einen Schritt so zu machen,
the second  :   daß man den nächsten auch noch machen kann.


signature.asc
Description: Digital signature

Re: [C++ Patch] PR 63203

[Jason Merrill]

OK.

Jason

Re: C++ PATCH for c++/63942 (mangling compat alias problems)

[Jason Merrill]

On 11/21/2014 04:32 PM, Jason Merrill wrote:

In this testcase, the wrong old mangling for one constructor matches the
correct mangling for the other constructor, and the testcase was failing
to compile as a result.  But compatibility aliases should not be treated
as conflicting with real declarations; they should be discarded.


We also need to avoid creating the alias declarations if they aren't 
going to become symbol aliases.


Tested x86_64-pc-linux-gnu, applying to trunk.


commit 58386ef80f1ab5d7ec49dc96b23e365e5750a3a0
Author: Jason Merrill 
Date:   Sun Nov 23 22:23:44 2014 -0500

	PR c++/63942
	* mangle.c (mangle_decl): If we aren't going to create a symbol
	alias, don't build the alias DECL either.

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index a244669..71a6e3b 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3518,6 +3518,12 @@ mangle_decl (const tree decl)
   if (IDENTIFIER_GLOBAL_VALUE (id2))
 	return;
 
+  struct cgraph_node *n = NULL;
+  if (TREE_CODE (decl) == FUNCTION_DECL
+	  && !(n = cgraph_node::get (decl)))
+	/* Don't create an alias to an unreferenced function.  */
+	return;
+
   tree alias = make_alias_for (decl, id2);
   SET_IDENTIFIER_GLOBAL_VALUE (id2, alias);
   DECL_IGNORED_P (alias) = 1;
@@ -3526,11 +3532,7 @@ mangle_decl (const tree decl)
   if (vague_linkage_p (decl))
 	DECL_WEAK (alias) = 1;
   if (TREE_CODE (decl) == FUNCTION_DECL)
-	{
-	  /* Don't create an alias to an unreferenced function.  */
-	  if (struct cgraph_node *n = cgraph_node::get (decl))
-	n->create_same_body_alias (alias, decl);
-	}
+	n->create_same_body_alias (alias, decl);
   else
 	varpool_node::create_extra_name_alias (alias, decl);
 #endif

Re: [PATCH] Fix PR64044

[Andrew Haley]

On 11/24/2014 12:29 PM, Richard Biener wrote:
> 
> The following fixes an issue I found when more aggressively 
> constant-folding from static initializers.  The Java frontend
> fails to provide an initializer for the classdollar field
> it creates but nevertheless marks them with TREE_READONLY
> whilst being static.
> 
> Thus the following patch removes setting of TREE_READONLY.
> 
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> 
> Ok?

OK, thanks.

Andrew.

Re: [RFC,PATCH,testsuite] Set gcc_force_conventional_output even without LTO linker plugin

[Richard Biener]

On Mon, Nov 24, 2014 at 1:40 PM, Matthew Fortune
 wrote:
> Richard Biener  writes:
>> On Sun, Nov 23, 2014 at 10:15 AM, Matthew Fortune
>>  wrote:
>> > Hi,
>> >
>> > I have had to use this patch several times when performing cross testing
>> > but I'm not sure if it is the right fix. The MIPS target testsuite runs
>> > all tests regardless of the current compiler configuration and
>> downgrades
>> > run tests to link tests and then to assembly tests depending on what
>> > libraries and hardware is available in the current run.
>> >
>> > In order to experiment with how the tests behave for a different
>> > configurations I add things like:
>> >
>> > --target_board=multi-sim/-msoft-float
>> >
>> > Where the option I am trying may not have libraries available.
>> >
>> > The problem comes when the LTO options are tested. The choice of which
>> > LTO options are used is based on a test for whether the LTO linker
>> plugin
>> > is available.  This test fails in my case because there are no suitable
>> > libraries to link against.
>> >
>> > if [check_effective_target_lto] {
>> > # When having plugin test both slim and fat LTO and plugin/nonplugin
>> > # path.
>> > if [check_linker_plugin_available] {
>> >   set LTO_TORTURE_OPTIONS [list \
>> >   { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
>> >   { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
>> >   ]
>> >   set gcc_force_conventional_output "-ffat-lto-objects"
>> > } else {
>> >   set LTO_TORTURE_OPTIONS [list \
>> >   { -O2 -flto -flto-partition=none } \
>> >   { -O2 -flto }
>> >   ]
>> > }
>> > }
>> >
>> > The problem as I see it is that the gcc_force_conventional_output line
>> > only applies to the first case. I understand why this is generally OK
>> > but if the linker plugin is seen to be available at GCC config time
>> > but is not available for a specific test configuration then there is
>> > a problem.
>>
>> But don't you get errors from the -fuse-linker-plugin path if
>> that happens?
>
> No, my description was a bit poor. The use-case is pretty non-standard as
> I am using compile options for which no link can succeed, owing to missing
> libraries for the ABI under test. So the plugin is there and usable but
> the testsuite check for it will always fail given the compile options.
> This then leads to no assembly output as the compiler will default to
> -fno-fat-lto-objects and the tests which need assembly text then fail.
> Link tests in the rest of the testsuite will fail regardless but it is just
> experimentation in the mips.exp testsuite that I want to cover without
> building 50+ multilibs.
>
>> > I'd therefore like to apply the following. Any suggestions on the
>> > testing that this needs? Would a build + regression run of GCC
>> > with binutils configured --disable-plugins be sufficient?
>>
>> Sure, that sounds reasonable.  Note that I think the patch is ok
>> anyway - passing a "redundant" -ffat-lto-objects won't break
>> anything.
>>
>> Thus, ok.
>
> OK, I wasn't sure if there were any scenarios where an explicit
> -ffat-lto-objects would make a difference. I keep getting lost when
> trawling through the LTO option handling logic.

AFAIK it's only set for dg-scan-assembler and friends which always
needs fat LTO objects.

> I'll run a quick test anyway and commit.
>
> Thanks,
> Matthew
>
>>
>> > Matthew
>> >
>> > gcc/testsuite/
>> >
>> > * lib/gcc-dg.exp: Set gcc_force_conventional_output for whenever
>> > LTO is used.
>> >
>> > diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
>> > index 6df8ae1..8d5bf9b 100644
>> > --- a/gcc/testsuite/lib/gcc-dg.exp
>> > +++ b/gcc/testsuite/lib/gcc-dg.exp
>> > @@ -88,13 +88,13 @@ if [check_effective_target_lto] {
>> >   { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
>> >   { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
>> >]
>> > -  set gcc_force_conventional_output "-ffat-lto-objects"
>> >  } else {
>> >set LTO_TORTURE_OPTIONS [list \
>> >   { -O2 -flto -flto-partition=none } \
>> >   { -O2 -flto }
>> >]
>> >  }
>> > +set gcc_force_conventional_output "-ffat-lto-objects"
>> >  }
>> >
>> >  global orig_environment_saved

RE: [RFC,PATCH,testsuite] Set gcc_force_conventional_output even without LTO linker plugin

[Matthew Fortune]

Richard Biener  writes:
> On Sun, Nov 23, 2014 at 10:15 AM, Matthew Fortune
>  wrote:
> > Hi,
> >
> > I have had to use this patch several times when performing cross testing
> > but I'm not sure if it is the right fix. The MIPS target testsuite runs
> > all tests regardless of the current compiler configuration and
> downgrades
> > run tests to link tests and then to assembly tests depending on what
> > libraries and hardware is available in the current run.
> >
> > In order to experiment with how the tests behave for a different
> > configurations I add things like:
> >
> > --target_board=multi-sim/-msoft-float
> >
> > Where the option I am trying may not have libraries available.
> >
> > The problem comes when the LTO options are tested. The choice of which
> > LTO options are used is based on a test for whether the LTO linker
> plugin
> > is available.  This test fails in my case because there are no suitable
> > libraries to link against.
> >
> > if [check_effective_target_lto] {
> > # When having plugin test both slim and fat LTO and plugin/nonplugin
> > # path.
> > if [check_linker_plugin_available] {
> >   set LTO_TORTURE_OPTIONS [list \
> >   { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
> >   { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
> >   ]
> >   set gcc_force_conventional_output "-ffat-lto-objects"
> > } else {
> >   set LTO_TORTURE_OPTIONS [list \
> >   { -O2 -flto -flto-partition=none } \
> >   { -O2 -flto }
> >   ]
> > }
> > }
> >
> > The problem as I see it is that the gcc_force_conventional_output line
> > only applies to the first case. I understand why this is generally OK
> > but if the linker plugin is seen to be available at GCC config time
> > but is not available for a specific test configuration then there is
> > a problem.
> 
> But don't you get errors from the -fuse-linker-plugin path if
> that happens?

No, my description was a bit poor. The use-case is pretty non-standard as
I am using compile options for which no link can succeed, owing to missing
libraries for the ABI under test. So the plugin is there and usable but
the testsuite check for it will always fail given the compile options.
This then leads to no assembly output as the compiler will default to
-fno-fat-lto-objects and the tests which need assembly text then fail.
Link tests in the rest of the testsuite will fail regardless but it is just
experimentation in the mips.exp testsuite that I want to cover without
building 50+ multilibs.

> > I'd therefore like to apply the following. Any suggestions on the
> > testing that this needs? Would a build + regression run of GCC
> > with binutils configured --disable-plugins be sufficient?
> 
> Sure, that sounds reasonable.  Note that I think the patch is ok
> anyway - passing a "redundant" -ffat-lto-objects won't break
> anything.
> 
> Thus, ok.

OK, I wasn't sure if there were any scenarios where an explicit
-ffat-lto-objects would make a difference. I keep getting lost when
trawling through the LTO option handling logic.

I'll run a quick test anyway and commit.

Thanks,
Matthew

> 
> > Matthew
> >
> > gcc/testsuite/
> >
> > * lib/gcc-dg.exp: Set gcc_force_conventional_output for whenever
> > LTO is used.
> >
> > diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
> > index 6df8ae1..8d5bf9b 100644
> > --- a/gcc/testsuite/lib/gcc-dg.exp
> > +++ b/gcc/testsuite/lib/gcc-dg.exp
> > @@ -88,13 +88,13 @@ if [check_effective_target_lto] {
> >   { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
> >   { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
> >]
> > -  set gcc_force_conventional_output "-ffat-lto-objects"
> >  } else {
> >set LTO_TORTURE_OPTIONS [list \
> >   { -O2 -flto -flto-partition=none } \
> >   { -O2 -flto }
> >]
> >  }
> > +set gcc_force_conventional_output "-ffat-lto-objects"
> >  }
> >
> >  global orig_environment_saved

[PATCH] Fix PR64044

[Richard Biener]

The following fixes an issue I found when more aggressively 
constant-folding from static initializers.  The Java frontend
fails to provide an initializer for the classdollar field
it creates but nevertheless marks them with TREE_READONLY
whilst being static.

Thus the following patch removes setting of TREE_READONLY.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Ok?

Thanks,
Richard.

2014-11-24  Richard Biener  

PR java/64004
* class.c (build_classdollar_field): Do not set TREE_READONLY.

Index: gcc/java/class.c
===
--- gcc/java/class.c(revision 218010)
+++ gcc/java/class.c(working copy)
@@ -1085,7 +1085,6 @@ build_classdollar_field (tree type)
TYPE_QUAL_CONST)));
   TREE_STATIC (decl) = 1;
   TREE_CONSTANT (decl) = 1;
-  TREE_READONLY (decl) = 1;
   TREE_PUBLIC (decl) = 1;
   java_hide_decl (decl);
   DECL_IGNORED_P (decl) = 1;

Re: [PATCH, 8/8] Do simple omp lowering for no address taken var

[Richard Biener]

On Mon, 24 Nov 2014, Tom de Vries wrote:

> On 24-11-14 12:28, Tom de Vries wrote:
> > On 17-11-14 11:13, Richard Biener wrote:
> > > On Sat, 15 Nov 2014, Tom de Vries wrote:
> > > 
> > > > >On 15-11-14 13:14, Tom de Vries wrote:
> > > > > > >Hi,
> > > > > > >
> > > > > > >I'm submitting a patch series with initial support for the oacc
> > > > > kernels
> > > > > > >directive.
> > > > > > >
> > > > > > >The patch series uses pass_parallelize_loops to implement
> > > > > parallelization of
> > > > > > >loops in the oacc kernels region.
> > > > > > >
> > > > > > >The patch series consists of these 8 patches:
> > > > > > >...
> > > > > > >  1  Expand oacc kernels after pass_build_ealias
> > > > > > >  2  Add pass_oacc_kernels
> > > > > > >  3  Add pass_ch_oacc_kernels to pass_oacc_kernels
> > > > > > >  4  Add pass_tree_loop_{init,done} to pass_oacc_kernels
> > > > > > >  5  Add pass_loop_im to pass_oacc_kernels
> > > > > > >  6  Add pass_ccp to pass_oacc_kernels
> > > > > > >  7  Add pass_parloops_oacc_kernels to pass_oacc_kernels
> > > > > > >  8  Do simple omp lowering for no address taken var
> > > > > > >...
> > > > >
> > > > >This patch lowers integer variables that do not have their address
> > > > taken as
> > > > >local variable.  We use a copy at region entry and exit to copy the
> > > > value in
> > > > >and out.
> > > > >
> > > > >In the context of reduction handling in a kernels region, this allows
> > > > the
> > > > >parloops reduction analysis to recognize the reduction, even after oacc
> > > > >lowering has been done in pass_lower_omp.
> > > > >
> > > > >In more detail, without this patch, the omp_data_i load and stores are
> > > > >generated in place (in this case, in the loop):
> > > > >...
> > > > > {
> > > > >   .omp_data_iD.2201 = &.omp_data_arr.15D.2220;
> > > > >   {
> > > > > unsigned intD.9 iD.2146;
> > > > >
> > > > > iD.2146 = 0;
> > > > > goto ;
> > > > > :
> > > > > D.2216 = .omp_data_iD.2201->cD.2203;
> > > > > c.9D.2176 = *D.2216;
> > > > > D.2177 = (long unsigned intD.10) iD.2146;
> > > > > D.2178 = D.2177 * 4;
> > > > > D.2179 = c.9D.2176 + D.2178;
> > > > > D.2180 = *D.2179;
> > > > > D.2217 = .omp_data_iD.2201->sumD.2205;
> > > > > D.2218 = *D.2217;
> > > > > D.2217 = .omp_data_iD.2201->sumD.2205;
> > > > > D.2219 = D.2180 + D.2218;
> > > > > *D.2217 = D.2219;
> > > > > iD.2146 = iD.2146 + 1;
> > > > > :
> > > > > if (iD.2146 <= 524287) goto ; else goto
> > > > ;
> > > > > :
> > > > >   }
> > > > >...
> > > > >
> > > > >With this patch, the omp_data_i load and stores for sum are generated
> > > > at entry
> > > > >and exit:
> > > > >...
> > > > > {
> > > > >   .omp_data_iD.2201 = &.omp_data_arr.15D.2218;
> > > > >   D.2216 = .omp_data_iD.2201->sumD.2205;
> > > > >   sumD.2206 = *D.2216;
> > > > >   {
> > > > > unsigned intD.9 iD.2146;
> > > > >
> > > > > iD.2146 = 0;
> > > > > goto ;
> > > > > :
> > > > > D.2217 = .omp_data_iD.2201->cD.2203;
> > > > > c.9D.2176 = *D.2217;
> > > > > D.2177 = (long unsigned intD.10) iD.2146;
> > > > > D.2178 = D.2177 * 4;
> > > > > D.2179 = c.9D.2176 + D.2178;
> > > > > D.2180 = *D.2179;
> > > > > sumD.2206 = D.2180 + sumD.2206;
> > > > > iD.2146 = iD.2146 + 1;
> > > > > :
> > > > > if (iD.2146 <= 524287) goto ; else goto
> > > > ;
> > > > > :
> > > > >   }
> > > > >   *D.2216 = sumD.2206;
> > > > >   #pragma omp return
> > > > > }
> > > > >...
> > > > >
> > > > >
> > > > >So, without the patch the reduction operation looks like this:
> > > > >...
> > > > > *(.omp_data_iD.2201->sumD.2205) = *(.omp_data_iD.2201->sumD.2205)
> > > > + x
> > > > >...
> > > > >
> > > > >And with this patch the reduction operation is simply:
> > > > >...
> > > > > sumD.2206 = sumD.2206 + x:
> > > > >...
> > > > >
> > > > >OK for trunk?
> > > I presume the reason you are trying to do that here is that otherwise
> > > it happens too late?  What you do is what loop store motion would
> > > do.
> > 
> > Richard,
> > 
> > Thanks for the hint. I've built a reduction example:
> > ...
> > void __attribute__((noinline))
> > f (unsigned int *__restrict__ a, unsigne

Re: [PATCH, 8/8] Do simple omp lowering for no address taken var

[Richard Biener]

On Mon, 24 Nov 2014, Tom de Vries wrote:

> On 17-11-14 11:13, Richard Biener wrote:
> > On Sat, 15 Nov 2014, Tom de Vries wrote:
> > 
> > > >On 15-11-14 13:14, Tom de Vries wrote:
> > > > > >Hi,
> > > > > >
> > > > > >I'm submitting a patch series with initial support for the oacc
> > > > kernels
> > > > > >directive.
> > > > > >
> > > > > >The patch series uses pass_parallelize_loops to implement
> > > > parallelization of
> > > > > >loops in the oacc kernels region.
> > > > > >
> > > > > >The patch series consists of these 8 patches:
> > > > > >...
> > > > > >  1  Expand oacc kernels after pass_build_ealias
> > > > > >  2  Add pass_oacc_kernels
> > > > > >  3  Add pass_ch_oacc_kernels to pass_oacc_kernels
> > > > > >  4  Add pass_tree_loop_{init,done} to pass_oacc_kernels
> > > > > >  5  Add pass_loop_im to pass_oacc_kernels
> > > > > >  6  Add pass_ccp to pass_oacc_kernels
> > > > > >  7  Add pass_parloops_oacc_kernels to pass_oacc_kernels
> > > > > >  8  Do simple omp lowering for no address taken var
> > > > > >...
> > > >
> > > >This patch lowers integer variables that do not have their address taken
> > > as
> > > >local variable.  We use a copy at region entry and exit to copy the value
> > > in
> > > >and out.
> > > >
> > > >In the context of reduction handling in a kernels region, this allows the
> > > >parloops reduction analysis to recognize the reduction, even after oacc
> > > >lowering has been done in pass_lower_omp.
> > > >
> > > >In more detail, without this patch, the omp_data_i load and stores are
> > > >generated in place (in this case, in the loop):
> > > >...
> > > > {
> > > >   .omp_data_iD.2201 = &.omp_data_arr.15D.2220;
> > > >   {
> > > > unsigned intD.9 iD.2146;
> > > >
> > > > iD.2146 = 0;
> > > > goto ;
> > > > :
> > > > D.2216 = .omp_data_iD.2201->cD.2203;
> > > > c.9D.2176 = *D.2216;
> > > > D.2177 = (long unsigned intD.10) iD.2146;
> > > > D.2178 = D.2177 * 4;
> > > > D.2179 = c.9D.2176 + D.2178;
> > > > D.2180 = *D.2179;
> > > > D.2217 = .omp_data_iD.2201->sumD.2205;
> > > > D.2218 = *D.2217;
> > > > D.2217 = .omp_data_iD.2201->sumD.2205;
> > > > D.2219 = D.2180 + D.2218;
> > > > *D.2217 = D.2219;
> > > > iD.2146 = iD.2146 + 1;
> > > > :
> > > > if (iD.2146 <= 524287) goto ; else goto
> > > ;
> > > > :
> > > >   }
> > > >...
> > > >
> > > >With this patch, the omp_data_i load and stores for sum are generated at
> > > entry
> > > >and exit:
> > > >...
> > > > {
> > > >   .omp_data_iD.2201 = &.omp_data_arr.15D.2218;
> > > >   D.2216 = .omp_data_iD.2201->sumD.2205;
> > > >   sumD.2206 = *D.2216;
> > > >   {
> > > > unsigned intD.9 iD.2146;
> > > >
> > > > iD.2146 = 0;
> > > > goto ;
> > > > :
> > > > D.2217 = .omp_data_iD.2201->cD.2203;
> > > > c.9D.2176 = *D.2217;
> > > > D.2177 = (long unsigned intD.10) iD.2146;
> > > > D.2178 = D.2177 * 4;
> > > > D.2179 = c.9D.2176 + D.2178;
> > > > D.2180 = *D.2179;
> > > > sumD.2206 = D.2180 + sumD.2206;
> > > > iD.2146 = iD.2146 + 1;
> > > > :
> > > > if (iD.2146 <= 524287) goto ; else goto
> > > ;
> > > > :
> > > >   }
> > > >   *D.2216 = sumD.2206;
> > > >   #pragma omp return
> > > > }
> > > >...
> > > >
> > > >
> > > >So, without the patch the reduction operation looks like this:
> > > >...
> > > > *(.omp_data_iD.2201->sumD.2205) = *(.omp_data_iD.2201->sumD.2205) +
> > > x
> > > >...
> > > >
> > > >And with this patch the reduction operation is simply:
> > > >...
> > > > sumD.2206 = sumD.2206 + x:
> > > >...
> > > >
> > > >OK for trunk?
> > I presume the reason you are trying to do that here is that otherwise
> > it happens too late?  What you do is what loop store motion would
> > do.
> 
> Richard,
> 
> Thanks for the hint. I've built a reduction example:
> ...
> void __attribute__((noinline))
> f (unsigned int *__restrict__ a, unsigned int *__restrict__ sum, unsigned int
> n)
> {
>   unsigned int i;
>   for (i = 0; i < n; ++i)
> *sum += a[i];
> }...
> and observed that store motion of the *sum store is done by pass_loop_im,
> provided the *sum load is taken out of the the loop by pass_pre first.

That doesn't make m

Re: [PATCH 2/3] move gimple_canonical_types htab out of gc memory

[Richard Biener]

On Mon, Nov 24, 2014 at 5:11 AM,   wrote:
> From: Trevor Saunders 
>
> Hi,
>
> The memory allocated for the hash table is never rooted by anything, so 
> keeping
> it in gc memory only works if it never needs to survive a gc.

Ok.

Thanks,
Richard.

> Trev
>
> lto/
>
> * lto.c (read_cgraph_and_symbols): allocate gimple_canonical_types
> htab with malloc instead of ggc.
> ---
>  gcc/lto/lto.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index a1cd958..1ff02f8 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -2926,8 +2926,8 @@ read_cgraph_and_symbols (unsigned nfiles, const char 
> **fnames)
>symtab->state = LTO_STREAMING;
>
>canonical_type_hash_cache = new hash_map (251);
> -  gimple_canonical_types = htab_create_ggc (16381, 
> gimple_canonical_type_hash,
> -   gimple_canonical_type_eq, 0);
> +  gimple_canonical_types = htab_create (16381, gimple_canonical_type_hash,
> +   gimple_canonical_type_eq, NULL);
>gcc_obstack_init (&tree_scc_hash_obstack);
>tree_scc_hash = new hash_table (4096);
>
> --
> 2.1.3
>

Re: [RFC,PATCH,testsuite] Set gcc_force_conventional_output even without LTO linker plugin

[Richard Biener]

On Sun, Nov 23, 2014 at 10:15 AM, Matthew Fortune
 wrote:
> Hi,
>
> I have had to use this patch several times when performing cross testing
> but I'm not sure if it is the right fix. The MIPS target testsuite runs
> all tests regardless of the current compiler configuration and downgrades
> run tests to link tests and then to assembly tests depending on what
> libraries and hardware is available in the current run.
>
> In order to experiment with how the tests behave for a different
> configurations I add things like:
>
> --target_board=multi-sim/-msoft-float
>
> Where the option I am trying may not have libraries available.
>
> The problem comes when the LTO options are tested. The choice of which
> LTO options are used is based on a test for whether the LTO linker plugin
> is available.  This test fails in my case because there are no suitable
> libraries to link against.
>
> if [check_effective_target_lto] {
> # When having plugin test both slim and fat LTO and plugin/nonplugin
> # path.
> if [check_linker_plugin_available] {
>   set LTO_TORTURE_OPTIONS [list \
>   { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
>   { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
>   ]
>   set gcc_force_conventional_output "-ffat-lto-objects"
> } else {
>   set LTO_TORTURE_OPTIONS [list \
>   { -O2 -flto -flto-partition=none } \
>   { -O2 -flto }
>   ]
> }
> }
>
> The problem as I see it is that the gcc_force_conventional_output line
> only applies to the first case. I understand why this is generally OK
> but if the linker plugin is seen to be available at GCC config time
> but is not available for a specific test configuration then there is
> a problem.

But don't you get errors from the -fuse-linker-plugin path if
that happens?

> I'd therefore like to apply the following. Any suggestions on the
> testing that this needs? Would a build + regression run of GCC
> with binutils configured --disable-plugins be sufficient?

Sure, that sounds reasonable.  Note that I think the patch is ok
anyway - passing a "redundant" -ffat-lto-objects won't break
anything.

Thus, ok.

Thanks,
Richard.

> Matthew
>
> gcc/testsuite/
>
> * lib/gcc-dg.exp: Set gcc_force_conventional_output for whenever
> LTO is used.
>
> diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
> index 6df8ae1..8d5bf9b 100644
> --- a/gcc/testsuite/lib/gcc-dg.exp
> +++ b/gcc/testsuite/lib/gcc-dg.exp
> @@ -88,13 +88,13 @@ if [check_effective_target_lto] {
>   { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
>   { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
>]
> -  set gcc_force_conventional_output "-ffat-lto-objects"
>  } else {
>set LTO_TORTURE_OPTIONS [list \
>   { -O2 -flto -flto-partition=none } \
>   { -O2 -flto }
>]
>  }
> +set gcc_force_conventional_output "-ffat-lto-objects"
>  }
>
>  global orig_environment_saved

Re: [PATCH/TopLevel] Fix compiling libgo with a combined sources

[Richard Biener]

On Sun, Nov 23, 2014 at 5:20 AM, Andrew Pinski  wrote:
> Hi,
>   The problem here is here is that OBJCOPY is not being set to the
> newly built objcopy when compiling libgo.  This patch adds
> OBJCOPY_FOR_TARGET to the toplevel configure/Makefile so that when
> libgo is compiled OBJCOPY is set to OBJCOPY_FOR_TARGET.
>
> I noticed this issue when building an aarch64 cross compile on an
> older system where objcopy did not understand aarch64.
>
> OK?  Bootstrapped and tested on x86_64 with no regressions.  Also
> tested with a combined build for a cross compiler to
> aarch64-linux-gnu.

Ok.

Thanks,
Richard.

> Thanks,
> Andrew Pinski
>
>
> * Makefile.def (flags_to_pass): Pass OBJCOPY_FOR_TARGET also.
> * Makefile.tpl (HOST_EXPORTS): Add OBJCOPY_FOR_TARGET.
> (BASE_TARGET_EXPORTS): Add OBJCOPY.
> (OBJCOPY_FOR_TARGET): New variable.
> (EXTRA_TARGET_FLAGS): Add OBJCOPY.
> * Makefile.in: Regenerate.
> * configure.ac: Check for already installed target objcopy.
> Also GCC_TARGET_TOOL on objcopy.
> * configure: Regenerate.

Re: [PATCH] Improve shrink wrap for lo_sum

[Richard Biener]

On Sun, Nov 23, 2014 at 5:09 AM, Andrew Pinski  wrote:
> Hi,
>   As discussed at
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00997.html, this is the
> one line patch which improves shrink wrapping for lo_sum.
>
> OK?  Bootstrapped and tested on x86_64 and built and tested for
> aarch64-elf with no regressions.  It fixes shrink_wrap_symbol_ref_1.c
> which was failing with -mabi=ilp32.

Ok.

Thanks,
Richard.

> Thanks,
> Andrew
>
> ChangeLog:
> * shrink-wrap.c (move_insn_for_shrink_wrap): Allow LO_SUM also.

Re: [PATCH] Work around in-tree gmp configure problems

[Richard Biener]

On Sat, Nov 22, 2014 at 4:34 PM, Jan-Benedict Glaw  wrote:
> Hi!
>
> On Sat, 2014-11-22 14:33:29 +0100, Bernd Edlinger  
> wrote:
>> since r217627 we use an updated AutoMake "missing" script.  However
>> that revealed a hidden bug in gmp-4.3.2's (up to gmp-6.0.0a)
>> configure script.  That is: an in-tree gmp/configure fails now if
>> flex is missing.  The gmp configure uses our missing flex script,
>> and previously that emitted an error message and created a dummy
>> lex.yy.c, The new version of that script does no longer create any
>> lex.yy.c.
> [...]
>> This patch adds LEX="touch lex.yy.c" to the in-tree gmp configure
>> script, which does in fact the same thing as the flex tool when
>> called under these conditions.
>>
>> I have tested gmp-4.3.2 and gmp-6.0.0a in-tree and boot-strapped
>> under x86_64-linux-gnu successfully.
> [...]
>> 2014-11-22  Bernd Edlinger  
>>
>>   * Makefile.def (module=gmp): Work around in-tree gmp configure
>>   bug with missing flex.
>>   * Makefile.in: Regenerated.
>
> Bernd and I discussed that patch; I'm all for it! Looks like that's
> the least-ugly thing we'd possibly come up with.

I suppose it is fixed upstream now?

Ok.

Thanks,
Richard.

> MfG, JBG
>
> --
>   Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
> Signature of:  Fortschritt bedeutet, einen Schritt so zu machen,
> the second  :   daß man den nächsten auch noch machen kann.