Re: [PATCH] SPARC: add mcpu=leon3v7 target

[Daniel Hellstrom]

On 10/06/2014 06:57 PM, Eric Botcazou wrote:

I posted it with v2 in the subject. I have now attached it.

There is a pasto in the v2:

@@ -1764,6 +1772,12 @@ extern int sparc_indent_opcode;
  #define AS_LEON_FLAG "-Av8"
  #endif
  
+#ifdef HAVE_AS_LEONV7

+#define AS_LEONV7_FLAG "-Aleon"
+#else
+#define AS_LEONV7_FLAG "-Av7"
+#endif
+
  /* We use gcc _mcount for profiling.  */
  #define NO_PROFILE_COUNTERS 0
  


I think you would be better off adding a line to the arms of the existing code

#ifdef HAVE_AS_LEON
#define AS_LEON_FLAG "-Aleon"
#else
#define AS_LEON_FLAG "-Av8"
#endif

rather than duplicating it.


You're right. I have attached an updated patch. The new code becomes:

 #ifdef HAVE_AS_LEON
 #define AS_LEON_FLAG "-Aleon"
+#define AS_LEONV7_FLAG "-Aleon"
 #else
 #define AS_LEON_FLAG "-Av8"
+#define AS_LEONV7_FLAG "-Av7"
 #endif

Thanks!
>From bfecb09e9402c9bd55373a7eb08ce6e2b244729e Mon Sep 17 00:00:00 2001
From: Daniel Hellstrom 
Date: Wed, 20 Aug 2014 10:53:22 +0100
Subject: [PATCH v3] SPARC: add mcpu=leon3v7 target

The LEON3/4 soft-core CPU has support for both SPARCv7 and SPARCv8 that
is configurable at design time. The majority of the LEON3 ASICs are v8
compatible, however when designing an as small LEON3 as possible, v7
without FPU is frequently used.

The current GCC leon3 support implies the SPARCv8 instruction set
which is not compatible with SPARCv7. Relying on the standard SPARCv7
(-mcpu=v7) target for a LEON3-V7 is not feasible since the atomic
instruction (CAS) can not be generated by standard v7.

 * config.gcc (sparc*-*-*): Accept mcpu=leon3v7 processor
 * doc/invoke.texi (SPARC options): add mcpu=leon3v7 comment
 * config/sparc/leon.md (leon3_load, leon_store, leon_fp_*):
   handle leon3v7 as leon3
 * config/sparc/sparc-opts.h (enum processor_type): Add PROCESSOR_LEON3V7
 * config/sparc/sparc.c (sparc_option_override): add leon3v7 support
 * config/sparc/sparc.h (TARGET_CPU_leon3v7): new define
 * config/sparc/sparc.md (cpu): add leon3v7
 * config/sparc/sparc.opt (enum processor_type): Add leon3v7
---
 gcc/config.gcc|5 -
 gcc/config/sparc/leon.md  |   14 +++---
 gcc/config/sparc/sparc-opts.h |1 +
 gcc/config/sparc/sparc.c  |3 +++
 gcc/config/sparc/sparc.h  |   40 +---
 gcc/config/sparc/sparc.md |1 +
 gcc/config/sparc/sparc.opt|3 +++
 gcc/doc/invoke.texi   |   16 
 8 files changed, 52 insertions(+), 31 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 605efc0..199e387 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3065,6 +3065,9 @@ if test x$with_cpu = x ; then
 	*-leon[3-9]*)
 	  with_cpu=leon3
 	  ;;
+	*-leon[3-9]v7*)
+	  with_cpu=leon3v7
+	  ;;
 	*)
 	  with_cpu="`echo ${target} | sed 's/-.*$//'`"
 	  ;;
@@ -3749,7 +3752,7 @@ case "${target}" in
 			case ${val} in
 			"" | sparc | sparcv9 | sparc64 \
 			| v7 | cypress \
-			| v8 | supersparc | hypersparc | leon | leon3 \
+			| v8 | supersparc | hypersparc | leon | leon3 | leon3v7 \
 			| sparclite | f930 | f934 | sparclite86x \
 			| sparclet | tsc701 \
 			| v9 | ultrasparc | ultrasparc3 | niagara | niagara2 \
diff --git a/gcc/config/sparc/leon.md b/gcc/config/sparc/leon.md
index b511397..e8050fa 100644
--- a/gcc/config/sparc/leon.md
+++ b/gcc/config/sparc/leon.md
@@ -29,11 +29,11 @@
 
 ;; Use a double reservation to work around the load pipeline hazard on UT699.
 (define_insn_reservation "leon3_load" 1
-  (and (eq_attr "cpu" "leon3") (eq_attr "type" "load,sload"))
+  (and (eq_attr "cpu" "leon3,leon3v7") (eq_attr "type" "load,sload"))
   "leon_memory*2")
 
 (define_insn_reservation "leon_store" 2
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "store"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "store"))
   "leon_memory*2")
 
 ;; This describes Gaisler Research's FPU
@@ -44,21 +44,21 @@
 (define_cpu_unit "grfpu_ds" "grfpu")
 
 (define_insn_reservation "leon_fp_alu" 4
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fp,fpcmp,fpmul"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fp,fpcmp,fpmul"))
   "grfpu_alu, nothing*3")
 
 (define_insn_reservation "leon_fp_divs" 16
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivs"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivs"))
   "grfpu_ds*14, nothing*2")
 
 (define_insn_reservation "leon_fp_divd" 17
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivd"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivd"))
   "grfpu_ds*15, nothing*2")
 
 (define_insn_reservation "leon_fp_sqrts" 24
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpsqrts"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpsqrts"))
   "grfpu_ds*22, nothing*2")
 
 (define_insn_reservation "leon_fp_sqrtd" 25
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpsqrtd"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpsqrtd"))
   "gr

[Patch, MIPS] Add Octeon3 support

[Hurugalawadi, Naveen]

Hi,

This patch adds Cavium octeon3 support in mips.
Please review the patch and let us know if there should be any
modifications.

Submitting the patch on behalf of Andrew Pinski.

Thanks,

2014-10-07 Andrew Pinski 

* config/mips/mips-cpus.def (octeon3): New cpu.
* config/mips/mips.c (mips_rtx_cost_data): Add octeon3.
(mips_print_operand ): Fix a bug as the mode
of the comparison no longer matches mode of the operands.
(mips_issue_rate): Handle PROCESSOR_OCTEON3.
* config/mips/mips.h (TARGET_OCTEON):  Add Octeon3.
(TARGET_OCTEON2): Likewise.
(TUNE_OCTEON): Add Octeon3.
* config/mips/mips.md (processor): Add octeon3.
* config/mips/octeon.md (octeon_fpu): New automaton and cpu_unit.
(octeon_arith): Add octeon3.
(octeon_condmove): Remove.
(octeon_condmove_o1): New reservation.
(octeon_condmove_o2): New reservation.
(octeon_condmove_o3_int_on_cc): New reservation.
(octeon_load_o2): Add octeon3.
(octeon_cop_o2): Likewise.
(octeon_store): Likewise.
(octeon_brj_o2): Likewise.
(octeon_imul3_o2): Likewise.
(octeon_imul_o2): Likewise.
(octeon_mfhilo_o2): Likewise.
(octeon_imadd_o2): Likewise.
(octeon_idiv_o2_si): Likewise.
(octeon_idiv_o2_di): Likewise.
(octeon_fpu): Add to the automaton.
(octeon_fpu): New cpu unit.
(octeon_condmove_o2): Check for non floating point modes.
(octeon_load_o2): Add prefetchx.
(octeon_cop_o2): Don't check for octeon3.
(octeon3_faddsubcvt): New reservation.
(octeon3_fmul): Likewise.
(octeon3_fmadd): Likewise.
(octeon3_div_sf): Likewise.
(octeon3_div_df): Likewise.
(octeon3_sqrt_sf): Likewise.
(octeon3_sqrt_df): Likewise.
(octeon3_rsqrt_sf): Likewise.
(octeon3_rsqrt_df): Likewise.
(octeon3_fabsnegmov): Likewise.
(octeon_fcond): Likewise.
(octeon_fcondmov): Likewise.
(octeon_fpmtc1): Likewise.
(octeon_fpmfc1): Likewise.
(octeon_fpload): Likewise.
(octeon_fpstore): Likewise.
* config/mips/mips-tables.opt: Regenerate.diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 73d5d5a..9b7b517 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,53 @@
+2014-10-06  Andrew Pinski  
+
+	* config/mips/mips-cpus.def (octeon3): New cpu.
+	* config/mips/mips.c (mips_rtx_cost_data): Add octeon3.
+	(mips_print_operand ): Fix a bug as the mode
+	of the comparison no longer matches mode of the operands.
+	(mips_issue_rate): Handle PROCESSOR_OCTEON3.
+	* config/mips/mips.h (TARGET_OCTEON):  Add Octeon3.
+	(TARGET_OCTEON2): Likewise.
+	(TUNE_OCTEON): Add Octeon3.
+	* config/mips/mips.md (processor): Add octeon3.
+	* config/mips/octeon.md (octeon_fpu): New automaton and cpu_unit.
+	(octeon_arith): Add octeon3.
+	(octeon_condmove): Remove.
+	(octeon_condmove_o1): New reservation.
+	(octeon_condmove_o2): New reservation.
+	(octeon_condmove_o3_int_on_cc): New reservation.
+	(octeon_load_o2): Add octeon3.
+	(octeon_cop_o2): Likewise.
+	(octeon_store): Likewise.
+	(octeon_brj_o2): Likewise.
+	(octeon_imul3_o2): Likewise.
+	(octeon_imul_o2): Likewise.
+	(octeon_mfhilo_o2): Likewise.
+	(octeon_imadd_o2): Likewise.
+	(octeon_idiv_o2_si): Likewise.
+	(octeon_idiv_o2_di): Likewise.
+	(octeon_fpu): Add to the automaton.
+	(octeon_fpu): New cpu unit.
+	(octeon_condmove_o2): Check for non floating point modes.
+	(octeon_load_o2): Add prefetchx.
+	(octeon_cop_o2): Don't check for octeon3.
+	(octeon3_faddsubcvt): New reservation.
+	(octeon3_fmul): Likewise.
+	(octeon3_fmadd): Likewise.
+	(octeon3_div_sf): Likewise.
+	(octeon3_div_df): Likewise.
+	(octeon3_sqrt_sf): Likewise.
+	(octeon3_sqrt_df): Likewise.
+	(octeon3_rsqrt_sf): Likewise.
+	(octeon3_rsqrt_df): Likewise.
+	(octeon3_fabsnegmov): Likewise.
+	(octeon_fcond): Likewise.
+	(octeon_fcondmov): Likewise.
+	(octeon_fpmtc1): Likewise.
+	(octeon_fpmfc1): Likewise.
+	(octeon_fpload): Likewise.
+	(octeon_fpstore): Likewise.
+	* config/mips/mips-tables.opt: Regenerate.
+
 2014-10-06  Eric Botcazou  
 
 	* calls.c (expand_call): Do not use the target as the return slot if
diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-cpus.def
index d5528d3..e2985b8 100644
--- a/gcc/config/mips/mips-cpus.def
+++ b/gcc/config/mips/mips-cpus.def
@@ -162,4 +162,5 @@ MIPS_CPU ("loongson3a", PROCESSOR_LOONGSON_3A, 65, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU ("octeon", PROCESSOR_OCTEON, 65, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU ("octeon+", PROCESSOR_OCTEON, 65, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU ("octeon2", PROCESSOR_OCTEON2, 65, PTF_AVOID_BRANCHLIKELY)
+MIPS_CPU ("octeon3", PROCESSOR_OCTEON3, 65, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU ("xlp", PROCESSOR_XLP, 65, PTF_AVOID_BRANCHLIKELY)
diff --git a/gcc/config/mips/mips-tables.opt b/gcc/config/mips/mips-tables.opt
index 5791b41..99d2ed8 100644
--- a/gcc/config/mips/mips-tables.op

Re: RFA: fix mode confusion in caller-save.c:replace_reg_with_saved_mem

[Joern Rennecke]

On 6 October 2014 19:58, Jeff Law  wrote:
> What makes word_mode special here?  ie, why is special casing for word_mode
> the right thing to do?

The patch does not special-case word mode.  The if condition tests if
smode would
cover multiple hard registers.
If that would be the case, smode is replaced with word_mode.

Re: [gomp4] OpenACC wait directive

[Cesar Philippidis]

On 10/06/2014 03:56 AM, Ilmir Usmanov wrote:

> As usual, I'll mostly focus on fortran part, since I don't know CFE and
> ME well enough.
> 
> Nevertheless, is there a reason to differ C from Fortran in behavior of
> matching int-expr-list? I mean, in C you support only integer literals
> as parameter of wait, but in Fortran you also cover parameters.

Either Thomas or Jim Norris worked on the CFE. I just included in this
patch to make gomp-4_0-branch more in sync with our internal branch.

There are a couple of other places, like the parameter for
vector_length, where C only supports integer literals. I don't know what
the plan is for those.

> Anyway, Fortran part.
>>  gfc_match_oacc_wait (void)
>> +if (!gfc_resolve_expr (el->expr)
>> +|| el->expr->ts.type != BT_INTEGER || el->expr->rank != 0
>> +|| el->expr->expr_type != EXPR_CONSTANT)
>> +  {
>> +gfc_error ("WAIT clause at %L requires a scalar INTEGER
>> expression",
>> +   &el->expr->where);
>>
> As you probably know, in Fortran one can define a function after whole
> program.
> So, since you are resolving wait-list during match, you don't cover this
> case. But async clause works fine.

I moved that check back into resolve_omp_clauses. So it functions now.

> By the way, the same difference between wait and async presents in CFE.
>
> Otherwise, Fortran part looks good for me.

Thomas, any thoughts on the CFE?

Thanks,
Cesar


2014-10-06  Cesar Philippidis  
	James Norris  
	Thomas Schwinge  

	gcc/
	* builtin-types.def (BT_FN_VOID_INT_PTR_INT): Define.
	* oacc-builtins.def (DEF_GOACC_BUILTIN): Define.
	* omp-low.c (scan_sharing_clauses): Update handling of
	OMP_CLAUSE_ASYNC and OMP_CLAUSE_WAIT.
	(expand_oacc_offload): Likewise.
	(expand_omp_target): Likewise.
	* gimplify.c (gimplify_scan_omp_clauses): Call gimplify_expr for
	OMP_CLAUSE_ASYNC and OMP_CLAUSE_WAIT.
	(gimplify_adjust_omp_clauses): Don't treat OMP_CLAUSE_ASYNC and
	OMP_CLAUSE_WAIT as unreachable.

	gcc/c-family/
	* c-common.h (c_finish_oacc_wait): Declare.
	* c-omp.c (c_finish_oacc_wait): New function.
	* c-pragma.c (oacc_pragmas): Add an entry for "wait".
	* c-pragma.h (enum pragma_kind): Add PRAGMA_OACC_WAIT.
	(enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_ASYNC and
	PRAGMA_OMP_CLAUSE_WAIT.

	gcc/c/
	* c-parser.c (c_parser_omp_clause_name): Handle async and wait.
	(c_parser_oacc_integer_list): New function.
	(c_parser_oacc_int_list_parens): New function.
	(c_parser_oacc_clause_async): New function.
	(c_parser_oacc_clause_wait): New function.
	(c_parser_oacc_all_clauses): Handle PRAGMA_OMP_CLAUSE_ASYNC and
	PRAGMA_OMP_CLAUSE_WAIT.
	(OACC_KERNELS_CLAUSE_MASK): Add async and wait clauses.
	(OACC_PARALLEL_CLAUSE_MASK): Likewise.
	(OACC_UPDATE_CLAUSE_MASK): Likewise.
	(OACC_WAIT_CLAUSE_MASK): New define.
	(c_parser_oacc_wait): New function.
	(c_parser_omp_construct): Handle PRAGMA_OACC_WAIT.
	* c-typeck.c (c_finish_omp_clauses): Handle OMP_CLAUSE_ASYNC and
	OMP_CLAUSE_WAIT.

	gcc/fortran/
	* gfortran.h (struct gfc_omp_clauses): Remove non_clause_wait_expr.
	* dump-parse-tree.c (show_omp_clauses): Likewise.
	* openmp.c (gfc_free_omp_clauses): Likewise.
	(gfc_match_omp_clauses): Update handling of async.
	(OACC_WAIT_CLAUSE_MASK): New define.
	(gfc_match_oacc_wait): Make the wait directive comply with OpenACC 2.0.
	(resolve_omp_clauses): Use resolve_oacc_scalar_in_expr inspect
	arguments to the wait clause.
	(resolve_oacc_wait): Remove.
	(gfc_resolve_oacc_directive): Handle EXEC_OACC_WAIT with
	resolve_omp_clauses.
	* trans-openmp.c (gfc_trans_omp_clauses): Update handling of OpenACC
	wait arguments.
	(gfc_trans_oacc_wait_directive): New function.
	(gfc_trans_oacc_directive): Use it.
	* types.def (BT_FN_VOID_INT_PTR_INT): Define.

	gcc/testsuite/
	* c-c++-common/goacc/asyncwait-1.c: New test.
	* gfortran.dg/goacc/asyncwait-1.f95: New test.
	* gfortran.dg/goacc/asyncwait-2.f95: New test.
	* gfortran.dg/goacc/asyncwait-3.f95: New test.
	* gfortran.dg/goacc/asyncwait-4.f95: New test.

	libgomp/
	* libgomp.map (GOACC_2.0): Add GOACC_wait.
	* libgomp_g.h (GOACC_wait): Declare.
	* oacc-parallel.c (GOACC_wait): Define.


diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index 7c294af..094b3a8 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -358,6 +358,8 @@ DEF_FUNCTION_TYPE_3 (BT_FN_VOID_PTR_INT_SIZE,
 		 BT_VOID, BT_PTR, BT_INT, BT_SIZE)
 DEF_FUNCTION_TYPE_3 (BT_FN_VOID_PTR_INT_INT,
 		 BT_VOID, BT_PTR, BT_INT, BT_INT)
+DEF_FUNCTION_TYPE_3 (BT_FN_VOID_INT_PTR_INT,
+		 BT_VOID, BT_INT, BT_PTR, BT_INT)
 DEF_FUNCTION_TYPE_3 (BT_FN_VOID_CONST_PTR_PTR_SIZE,
 		 BT_VOID, BT_CONST_PTR, BT_PTR, BT_SIZE)
 DEF_FUNCTION_TYPE_3 (BT_FN_INT_STRING_CONST_STRING_VALIST_ARG,
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 5ec79a0..a03b3ab 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1211,6 +1211,7 @@ extern void c_finish_omp_taskwait (location_t);
 extern void c_finish_omp_tas

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

[Bin.Cheng]

On Tue, Oct 7, 2014 at 1:20 AM, Mike Stump  wrote:
> On Oct 6, 2014, at 4:32 AM, Richard Biener  wrote:
>> On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng  wrote:
>>
>> How many merging opportunities does sched2 undo again?  ISTR it
>> has the tendency of pushing stores down and loads up.
>
> So, the pass works by merging 2 or more loads into 1 load (at least on my 
> port).  sched2 would need to rip apart 1 load into 2 loads to be able to undo 
> the real work.  The non-real work, doesn't matter any.  Can sched2 rip apart 
> a single load?
On ARM and AARCH64, the two merged load/store are transformed into
single parallel insn by the following peephole2 pass, so that sched2
would not undo the fusion work.  I though sched2 works on the basis of
instructions, and it isn't good practice to have sched2 do split work.

Thanks,
bin

Re: [PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.

[Jason Merrill]

On 10/06/2014 08:50 PM, Siva Chandra wrote:

On Sat, Oct 4, 2014 at 11:14 AM, Jason Merrill  wrote:

On 10/03/2014 05:41 PM, Siva Chandra wrote:


I understand that knowing whether a copy-ctor or a d-tor has been
explicitly defaulted is not sufficient to determine the parameter
passing ABI. However, why is it not necessary? I could be wrong, but
doesn't the example I have given show that it is necessary?


An implicitly declared 'tor can also be trivial.


But, the question is whether it is required to determine the parameter
passing ABI. If there is no special marker to indicate that the user
declared 'tor is explicitly defaulted, then GDB could (in the absence
of other properties which make the 'tor non-trivial) incorrectly
conclude that the the 'tor is user defined, and hence not-trivial.


I've been thinking that we should just mark the 'tor as trivial or not 
directly rather than hint at it.  Does GDB have enough information to 
determine triviality if we just add defaulted info?


Jason

Re: [PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.

[Siva Chandra]

On Sat, Oct 4, 2014 at 11:14 AM, Jason Merrill  wrote:
> On 10/03/2014 05:41 PM, Siva Chandra wrote:
>>
>> I understand that knowing whether a copy-ctor or a d-tor has been
>> explicitly defaulted is not sufficient to determine the parameter
>> passing ABI. However, why is it not necessary? I could be wrong, but
>> doesn't the example I have given show that it is necessary?
>
> An implicitly declared 'tor can also be trivial.

But, the question is whether it is required to determine the parameter
passing ABI. If there is no special marker to indicate that the user
declared 'tor is explicitly defaulted, then GDB could (in the absence
of other properties which make the 'tor non-trivial) incorrectly
conclude that the the 'tor is user defined, and hence not-trivial.

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/7/14 7:18, Chen Gang wrote:
> On 10/7/14 1:29, Mike Stump wrote:
>> On Oct 6, 2014, at 8:36 AM, Chen Gang  wrote:
>>> For me, "make -k check" is suitable for one sub-system (e.g. for cross
>>> building, and mainly focus on gcc), but not for global check (full
>>> non-cross building check):
>>
>> In our world, there is no sub-system, so, talk of such is outside the scope 
>> of gcc.
>>
>> Let me repeat what he said differently.
>>
>> You have two choices, fixing the port so that there are no unexpected 
>> failures or running check with -k.
>>
>> I’d like to get to the point where all primary/secondary platforms can use 
>> make check directly, we’re not there yet.
>>
>> The idea is that the single return value tells if if the suite passed or 
>> not.  This is an absolute measure, that, when achieved means one never has 
>> to compare previous/present results, just know that the suite passed.  
>> Sometimes simple is better.
>>
>>> - "make check" is the standard check for global,
>>
>> No sub-system, no global.
>>
> 
> Theoretically, in each system (include gcc), always can be separated
> into several 'sub-systems', and then 'global' means the system itself.
> 
> In our case, we say let 'global' pass checking means let gcc, gfortran,
> g++, libjava ... all pass checking. But for mainly focus on constructing
> environments, I will try to use upstream glibc instead of Darwin glibc:
> 
>  - If fix Throw_2, we know it is environments construction issue.
> 
>  - Else, I shall skip it (since "make -k check" should be OK).
> 
> And after finish testsuite under Darwin, within this month, I shall try
> to find and send a patch for gcc, and pass testsuite under Darwin (it
> seems it is not quite difficult to me).
> 
> 

It is really unlucky, The upstream glibc does not support Darwin! And
sorry, send patches to glibc is really out of my current border, so I
have to give up. :-(

  bash-3.2# ../glibc/configure --with-prefix=/release/Darwin/ 
--with-sysroot=/release/Darwin
  checking build system type... x86_64-apple-darwin13.4.0
  checking host system type... x86_64-apple-darwin13.4.0
  checking for gcc... gcc
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  checking whether gcc accepts -g... yes
  checking for g++... g++
  checking whether we are using the GNU C++ compiler... yes
  checking whether g++ accepts -g... yes
  checking for readelf... no
  checking for sysdeps preconfigure fragments... aarch64 alpha arm hppa i386 
m68k microblaze mips powerpc s390 sh sparc tile x86_64 checking whether gcc 
compiles in -mx32 mode by default... no
  
  configure: running configure fragment for add-on libidn
  *** The GNU C library is currently not available for this platform.
  *** So far nobody cared to port it and if there is no volunteer it
  *** might never happen.  So, if you have interest to see glibc on
  *** this platform visit
  ***   http://www.gnu.org/software/libc/porting.html
  *** and join the group of porters


And I guess, this thread can be ended, and next, I shall try to find a
patch for gcc, and let it pass testsuite under Darwin.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [google/gcc-4_9] Add gcc driver option -no-pie

[Sriraman Tallam]

On Mon, Oct 6, 2014 at 3:22 PM, Joseph S. Myers  wrote:
> If adding a new option, you need to document it in invoke.texi.

Patch updated.

Thanks
Sri

>
> --
> Joseph S. Myers
> jos...@codesourcery.com
Add a negative for option -pie: -no-pie builds a position dependent executable.
Note that -no-pie also negates a prior -shared.

Index: gcc.c
===
--- gcc.c   (revision 212826)
+++ gcc.c   (working copy)
@@ -672,9 +672,9 @@ proper position among the other output files.  */
 
 #ifndef LINK_PIE_SPEC
 #ifdef HAVE_LD_PIE
-#define LINK_PIE_SPEC "%{pie:-pie} "
+#define LINK_PIE_SPEC "%{pie:-pie} %{no-pie:}"
 #else
-#define LINK_PIE_SPEC "%{pie:} "
+#define LINK_PIE_SPEC "%{pie:} %{no-pie:}"
 #endif
 #endif
 
@@ -3135,6 +3135,7 @@ display_help (void)
   fputs (_("  -c   Compile and assemble, but do not 
link\n"), stdout);
   fputs (_("  -o Place the output into \n"), 
stdout);
   fputs (_("  -pie Create a position independent 
executable\n"), stdout);
+  fputs (_("  -no-pie  Create a position dependent 
executable\n"), stdout);
   fputs (_("  -shared  Create a shared library\n"), stdout);
   fputs (_("\
   -x Specify the language of the following input files\n\
Index: testsuite/gcc.dg/option_no-pie.c
===
--- testsuite/gcc.dg/option_no-pie.c(revision 0)
+++ testsuite/gcc.dg/option_no-pie.c(revision 0)
@@ -0,0 +1,7 @@
+/* { dg-do link { target pie } } */
+/* { dg-options "-no-pie" } */
+
+int main(void)
+{
+  return 0;
+}
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 212826)
+++ doc/invoke.texi (working copy)
@@ -462,7 +462,7 @@ Objective-C and Objective-C++ Dialects}.
 @item Linker Options
 @xref{Link Options,,Options for Linking}.
 @gccoptlist{@var{object-file-name}  -l@var{library} @gol
--nostartfiles  -nodefaultlibs  -nostdlib -pie -rdynamic @gol
+-nostartfiles  -nodefaultlibs -no-pie -nostdlib -pie -rdynamic @gol
 -s  -static -static-libgcc -static-libstdc++ @gol
 -static-libasan -static-libtsan -static-liblsan -static-libubsan @gol
 -shared -shared-libgcc  -symbolic @gol
@@ -10574,6 +10574,11 @@ These entries are usually resolved by entries in
 libc.  These entry points should be supplied through some other
 mechanism when this option is specified.
 
+@item -no-pie
+@opindex no-pie
+Produce a position dependent executable.  This is the negative of option
+@option{-pie} which produces a position independent executable.
+
 @item -nostdlib
 @opindex nostdlib
 Do not use the standard system startup files or libraries when linking.
Index: common.opt
===
--- common.opt  (revision 212826)
+++ common.opt  (working copy)
@@ -2841,7 +2841,7 @@ x
 Driver Joined Separate
 
 shared
-Driver RejectNegative Negative(pie)
+Driver RejectNegative Negative(no-pie)
 Create a shared library
 
 shared-libgcc
@@ -2885,6 +2885,10 @@ Driver
 symbolic
 Driver
 
+no-pie
+Driver RejectNegative Negative(pie)
+Create a position dependent executable
+
 pie
 Driver RejectNegative Negative(shared)
 Create a position independent executable

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/7/14 1:29, Mike Stump wrote:
> On Oct 6, 2014, at 8:36 AM, Chen Gang  wrote:
>> For me, "make -k check" is suitable for one sub-system (e.g. for cross
>> building, and mainly focus on gcc), but not for global check (full
>> non-cross building check):
> 
> In our world, there is no sub-system, so, talk of such is outside the scope 
> of gcc.
> 
> Let me repeat what he said differently.
> 
> You have two choices, fixing the port so that there are no unexpected 
> failures or running check with -k.
> 
> I’d like to get to the point where all primary/secondary platforms can use 
> make check directly, we’re not there yet.
> 
> The idea is that the single return value tells if if the suite passed or not. 
>  This is an absolute measure, that, when achieved means one never has to 
> compare previous/present results, just know that the suite passed.  Sometimes 
> simple is better.
> 
>> - "make check" is the standard check for global,
> 
> No sub-system, no global.
> 

Theoretically, in each system (include gcc), always can be separated
into several 'sub-systems', and then 'global' means the system itself.

In our case, we say let 'global' pass checking means let gcc, gfortran,
g++, libjava ... all pass checking. But for mainly focus on constructing
environments, I will try to use upstream glibc instead of Darwin glibc:

 - If fix Throw_2, we know it is environments construction issue.

 - Else, I shall skip it (since "make -k check" should be OK).

And after finish testsuite under Darwin, within this month, I shall try
to find and send a patch for gcc, and pass testsuite under Darwin (it
seems it is not quite difficult to me).


Thanks
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [google/gcc-4_9] Add gcc driver option -no-pie

[Joseph S. Myers]

If adding a new option, you need to document it in invoke.texi.

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

Re: [patch] Flatten function.h take 2

[Andrew MacLeod]

Ping... anyone want to take a look?

Andrew

On 09/29/2014 01:23 PM, Andrew MacLeod wrote:

On 09/16/2014 05:23 PM, Andrew MacLeod wrote:

On 09/16/2014 05:12 PM, Joseph S. Myers wrote:

On Tue, 16 Sep 2014, Andrew MacLeod wrote:

I did an include file reduction on all the language/*.[ch] and core 
*.[ch]
files, but left the target files with the full complement of 7 
includes that
function.h use to have.  Its probably easier when this is all done 
to fully
reduce the targets one at a time... there are so many nooks and 
crannies I
figured I'd bust something right now if i tried to do all the 
targets as well

:-)
How did you determine what includes to remove?  You appear to have 
removed
tm.h includes from various files that do in fact use target macros; 
maybe

they get it indirectly included by some other header, but I thought a
principle of this flattening was to avoid relying on such indirect
inclusions.  Because of possible use of target macros in #ifdef
conditionals, "compiles with the include removed" is not a sufficient
condition for removing it.

cfgrtl.c
gimple-fold.c
mode-switching.c
tree-inline.c
vmsdbgout.c
fortran/f95-lang.c
fortran/trans-decl.c
objc/objc-act.c

Many of those files do in fact get numerous include files from 
expr.h, which are likely to get put back in when expr.h is 
flattened,  but there is a risk as you point out.


Perhaps I should proceed by simply moving the includes and removing 
any duplicate includes,  leaving the reduction for later date. There 
is less chance of that causing issues.  I did forget about the 
discussion last year concerning target macros from the RTL end of 
things... My mind is slowly going :-).



OK, here's take 2.. I left all the include files except ones which 
were duplicated as a result of the flattening. The first one was left, 
and any subsequent #Includes of the files were removed. we'll address 
"unneeded" includes separately and all at once.. perhaps with a newer 
tool that has been taught about input and output dependencies


Bootstrapepd on x86_64-unknown-linux-gnu with no new regressions. 
Currently config-list.mk is building, but Im not expecting any issues 
there.  assuming all is oK, ok to check in?


Andrew

PS.. the original commentary:

This flattens function.h.  It wasn't too bad, there were a few 
prototypes and defines in expr.h and rtl.h that belong in function.h, 
and a couple of other prototypes that belonged in other .h files.  A 
bunch of the gen*.c generated files actually use function.h.. so they 
needed some tweaking.




function.patch.gz
Description: application/gzip

[google/gcc-4_9] Add gcc driver option -no-pie

[Sriraman Tallam]

Hi,

   A build tool we are using adds -pie by default and I am adding
-no-pie to override this when necessary.

Is this patch alright?  Would this be suitable for trunk?

Thanks
Sri
Add a negative for option -pie: -no-pie builds a position dependent executable.
Note that -no-pie also negates a prior -shared.


Index: testsuite/gcc.dg/option_no-pie.c
===
--- testsuite/gcc.dg/option_no-pie.c(revision 0)
+++ testsuite/gcc.dg/option_no-pie.c(revision 0)
@@ -0,0 +1,7 @@
+/* { dg-do link { target pie } } */
+/* { dg-options "-no-pie" } */
+
+int main(void)
+{
+  return 0;
+}
Index: common.opt
===
--- common.opt  (revision 212826)
+++ common.opt  (working copy)
@@ -2841,7 +2841,7 @@ x
 Driver Joined Separate
 
 shared
-Driver RejectNegative Negative(pie)
+Driver RejectNegative Negative(no-pie)
 Create a shared library
 
 shared-libgcc
@@ -2885,6 +2885,10 @@ Driver
 symbolic
 Driver
 
+no-pie
+Driver RejectNegative Negative(pie)
+Create a position dependent executable
+
 pie
 Driver RejectNegative Negative(shared)
 Create a position independent executable
Index: gcc.c
===
--- gcc.c   (revision 212826)
+++ gcc.c   (working copy)
@@ -672,9 +672,9 @@ proper position among the other output files.  */
 
 #ifndef LINK_PIE_SPEC
 #ifdef HAVE_LD_PIE
-#define LINK_PIE_SPEC "%{pie:-pie} "
+#define LINK_PIE_SPEC "%{pie:-pie} %{no-pie:}"
 #else
-#define LINK_PIE_SPEC "%{pie:} "
+#define LINK_PIE_SPEC "%{pie:} %{no-pie:}"
 #endif
 #endif
 
@@ -3135,6 +3135,7 @@ display_help (void)
   fputs (_("  -c   Compile and assemble, but do not 
link\n"), stdout);
   fputs (_("  -o Place the output into \n"), 
stdout);
   fputs (_("  -pie Create a position independent 
executable\n"), stdout);
+  fputs (_("  -no-pie  Create a position dependent 
executable\n"), stdout);
   fputs (_("  -shared  Create a shared library\n"), stdout);
   fputs (_("\
   -x Specify the language of the following input files\n\

RE: [Patch, MIPS] Cleanup mips header files.

[Matthew Fortune]

Hi Steve,

You're the lucky recipient of my first review so apologies for being
slow and cautious...

I tried to find a reason why the files were originally separated like this
and I can't see anything obvious.  I assume you also found no reason.
Presumably the separation was just to avoid disturbing the 32-bit configs
but I think it is a sensible move to merge them.

> --- a/gcc/config/mips/gnu-user.h
> +++ b/gcc/config/mips/gnu-user.h
> @@ -52,16 +52,20 @@ along with GCC; see the file COPYING3.  If not see
>  #undef MIPS_DEFAULT_GVALUE
>  #define MIPS_DEFAULT_GVALUE 0
> 
> -/* Borrowed from sparc/linux.h */
>  #undef GNU_USER_TARGET_LINK_SPEC
> -#define GNU_USER_TARGET_LINK_SPEC \
> - "%(endian_spec) \
> -  %{shared:-shared} \
> +#define GNU_USER_TARGET_LINK_SPEC "\
> +%{G*} %{EB} %{EL} %{!EB:%{!EL:%(endian_spec)}} %{mips*} \
> +%{shared} \

Indent two lines above. The '%{!EB:%{!EL:%(endian_spec)}}' is
redundant as it is covered by the DRIVER_SELF_SPEC which you have added
below. The linker won't accept -mips16 so you should use
MIPS_ISA_LEVEL_OPTION_SPEC to avoid passing mips16. Although we still
end up with an explicit list at least there is just one copy to maintain.

>%{!shared: \
>  %{!static: \
>%{rdynamic:-export-dynamic} \
> -  -dynamic-linker " GNU_USER_DYNAMIC_LINKER "} \
> -  %{static:-static}}"
> +  %{mabi=n32: -dynamic-linker " GNU_USER_DYNAMIC_LINKERN32 "} \
> +  %{mabi=64: -dynamic-linker " GNU_USER_DYNAMIC_LINKER64 "} \
> +  %{mabi=32: -dynamic-linker " GNU_USER_DYNAMIC_LINKER32 "}} \
> +%{static:-static}} \

Very much a nit but if we are going to have %{shared} above then we should
have just %{static} here.

> +%{mabi=n32:-m" GNU_USER_LINK_EMULATIONN32 "} \
> +%{mabi=64:-m" GNU_USER_LINK_EMULATION64 "} \
> +%{mabi=32:-m" GNU_USER_LINK_EMULATION32 "}"
>  #undef LINK_SPEC
>  #define LINK_SPEC GNU_USER_TARGET_LINK_SPEC
> 
> @@ -122,7 +126,9 @@ extern const char *host_detect_local_cpu (int argc,
> const char **argv);
>   specs handling by removing a redundant option.  */  
> \
>"%{!mno-shared:%/* -mplt likewise has no effect for -mabi=64 without -msym32.  */  \
> -  "%{mabi=64:%{!msym32:% +  "%{mabi=64:%{!msym32:% +  " %{!EB:%{!EL:%(endian_spec)}}"\
> +  " %{!mabi=*: -" MULTILIB_ABI_DEFAULT "}"

Another nit, since this code is being changed can you update this from using
a leading space to be a comma separated list of strings like this:

> +  "%{mabi=64:%{!msym32:% +  "%{!EB:%{!EL:%(endian_spec)}}",\
> +  "%{!mabi=*: -" MULTILIB_ABI_DEFAULT "}"

With those changes can you double check that a default big and default little
endian build pass -EB/-EL respectively by default and are changed when using
-EL/-EB explicitly? There should only be one -E* option passed to the linker
theoretically, unless multiple explicit -E* options are given on the command
line.

Otherwise OK (assuming the link specs behave as described above).

Thanks,
Matthew

Re: [patch] Add -static-libquadmath option

[Joseph S. Myers]

On Mon, 6 Oct 2014, Steve Kargl wrote:

> On Mon, Oct 06, 2014 at 08:38:14PM +, Joseph S. Myers wrote:
> > Since -static-libquadmath introduces LGPL requirements on redistributing 
> > the resulting binaries (that you provide source or relinkable object files 
> > to allow relinking with modified versions of libquadmath) that don't 
> > otherwise generally apply simply through using GCC to build a program even 
> > if you link in GCC's other libraries statically, it would seem a good idea 
> > for the documentation of this option to make that explicit.
> 
> Or, change the license of libquadmath to be compatible with
> libgcci and libgfortran.

I believe we established when libquadmath was added that this wasn't an 
option as large parts of the code are not assigned to the FSF.

(Longer-term it might make sense to support TS 18661-3 in GCC and glibc, 
so that libquadmath isn't needed when using new glibc as the functions are 
available in libm under TS 18661-3 names such as sinf128.)

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

Re: sort_heap complexity guarantee

[Daniel Krügler]

2014-10-06 23:00 GMT+02:00 François Dumont :
> On 05/10/2014 22:54, Marc Glisse wrote:
>>
>> On Sun, 5 Oct 2014, François Dumont wrote:
>>
>>>I took a look at PR 61217 regarding pop_heap complexity guarantee.
>>> Looks like we have no test to check complexity of our algos so I start
>>> writing some starting with the heap operations. I found no issue with
>>> make_heap, push_heap and pop_heap despite what the bug report is saying
>>> however the attached testcase for sort_heap is failing.
>>>
>>>Standard is saying std::sort_heap shall use less than N * log(N)
>>> comparisons but with my test using 1000 random values the test is showing:
>>>
>>> 8687 comparisons on 6907.76 max allowed
>>>
>>>Is this a known issue of sort_heap ? Do you confirm that the test is
>>> valid ?
>>
>> I would first look for confirmation that the standard didn't just forget a
>> big-O or something. I would expect an implementation as n calls to pop_heap
>> to be legal, and if pop_heap makes 2*log(n) comparisons, that naively sums
>> to too much. And I don't expect the standard to contain an advanced
>> amortized analysis or anything like that...
>>
> Good point, with n calls to pop_heap it means that limit must be 2*log(1) +
> 2*log(2) +... + 2*log(n) which is 2*log(n!) and  which is also necessarily <
> 2*n*log(n). I guess Standard comittee has forgotten the factor 2 in the
> limit so this is what I am using as limit in the final test, unless someone
> prefer the stricter 2*log(n!) ?

François, could you please submit a corresponding LWG issue by sending
an email using the recipe described here:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue

?

Thanks,

- Daniel

Re: [Java PATCH] Generate declarations in jvgenmain.c

[Mark Wielaard]

On Mon, Oct 06, 2014 at 11:54:00AM +0200, Marek Polacek wrote:
> Java testsuite breaks with -std=gnu11 as a default and/or with 
> -Wimplicit-function-declaration on, since the jvgenmain.c program
> that generates a C file containing 'main' function which calls either
> 'JvRunMainName' or 'JvRunMain' does not generate forward declarations
> for these functions.  The fix is obvious IMHO.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?

I cannot approve (java) patches, but it does look ok to me.
With one nitpick. JvRunMain is only used when -findirect-dispatch
is given, and otherwise JvRunMainName is used. So you could output
only the actually used forward declaration by checking if (indirect).

If no java maintainer responds, try CCing java-patc...@gcc.gnu.org
to draw their attention.

Cheers,

Mark

Re: sort_heap complexity guarantee

[François Dumont]

On 05/10/2014 22:54, Marc Glisse wrote:

On Sun, 5 Oct 2014, François Dumont wrote:

   I took a look at PR 61217 regarding pop_heap complexity guarantee. 
Looks like we have no test to check complexity of our algos so I 
start writing some starting with the heap operations. I found no 
issue with make_heap, push_heap and pop_heap despite what the bug 
report is saying however the attached testcase for sort_heap is failing.


   Standard is saying std::sort_heap shall use less than N * log(N) 
comparisons but with my test using 1000 random values the test is 
showing:


8687 comparisons on 6907.76 max allowed

   Is this a known issue of sort_heap ? Do you confirm that the test 
is valid ?


I would first look for confirmation that the standard didn't just 
forget a big-O or something. I would expect an implementation as n 
calls to pop_heap to be legal, and if pop_heap makes 2*log(n) 
comparisons, that naively sums to too much. And I don't expect the 
standard to contain an advanced amortized analysis or anything like 
that...


Good point, with n calls to pop_heap it means that limit must be 
2*log(1) + 2*log(2) +... + 2*log(n) which is 2*log(n!) and  which is 
also necessarily < 2*n*log(n). I guess Standard comittee has forgotten 
the factor 2 in the limit so this is what I am using as limit in the 
final test, unless someone prefer the stricter 2*log(n!) ?


Ok to commit those new tests ?

2014-10-06  François Dumont  

* testsuite/util/testsuite_counter_type.h
(counter_type::operator<(const counter_type&)): Update
less_compare_count when called.
* testsuite/25_algorithms/make_heap/complexity.cc: New.
* testsuite/25_algorithms/pop_heap/complexity.cc: New.
* testsuite/25_algorithms/push_heap/complexity.cc: New.
* testsuite/25_algorithms/sort_heap/complexity.cc: New.


Tested under Linux x86_64.

François
Index: testsuite/25_algorithms/make_heap/complexity.cc
===
--- testsuite/25_algorithms/make_heap/complexity.cc	(revision 0)
+++ testsuite/25_algorithms/make_heap/complexity.cc	(working copy)
@@ -0,0 +1,50 @@
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, 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 General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++11" }
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+void test01()
+{
+  using __gnu_test::counter_type;
+  const std::size_t nb_values = 1000;
+
+  std::random_device dev;
+  std::uniform_int_distribution dist;
+  std::vector values;
+  values.reserve(nb_values);
+  for (std::size_t i = 0; i != nb_values; ++i)
+values.push_back(dist(dev));
+
+  counter_type::reset();
+
+  std::make_heap(values.begin(), values.end());
+
+  VERIFY( counter_type::less_compare_count <= 3.0 * nb_values );
+}
+
+int main()
+{
+  test01();
+  return 0;
+}
Index: testsuite/25_algorithms/pop_heap/complexity.cc
===
--- testsuite/25_algorithms/pop_heap/complexity.cc	(revision 0)
+++ testsuite/25_algorithms/pop_heap/complexity.cc	(working copy)
@@ -0,0 +1,53 @@
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, 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 General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++11" }
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+void test01()
+{
+  using __gnu_test::counter_type;
+  const std::size_t nb_values = 1000;
+
+  std::random_device dev;
+  std::uniform_int_distribution dist;
+  std::vector values;
+  values.reserve(nb_values);
+  for (std::size_t i = 0; i != nb_values; ++i)
+values.push_back(dist(dev));
+
+  std::make_heap(values.begin(), values.end());

Re: [patch] Add -static-libquadmath option

[Steve Kargl]

On Mon, Oct 06, 2014 at 08:38:14PM +, Joseph S. Myers wrote:
> Since -static-libquadmath introduces LGPL requirements on redistributing 
> the resulting binaries (that you provide source or relinkable object files 
> to allow relinking with modified versions of libquadmath) that don't 
> otherwise generally apply simply through using GCC to build a program even 
> if you link in GCC's other libraries statically, it would seem a good idea 
> for the documentation of this option to make that explicit.

Or, change the license of libquadmath to be compatible with
libgcci and libgfortran.

-- 
Steve

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[Sriraman Tallam]

Ping.

On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam  wrote:
> Ping.
>
> On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam  wrote:
>> Hi Richard,
>>
>> I also ran the gcc testsuite with
>> RUNTESTFLAGS="--tool_opts=-mcopyrelocs" to check for issues.  The only
>> test that failed was g++.dg/tsan/default_options.C.  It uses -fpie
>> -pie and BFD ld to link. Since BFD ld does not support copy
>> relocations with -pie, it does not link. I linked with gold to make
>> the test pass.
>>
>> Could you please take another look at this patch?
>>
>> Thanks
>> Sri
>>
>> On Mon, Sep 8, 2014 at 3:19 PM, Sriraman Tallam  wrote:
>>> On Tue, Sep 2, 2014 at 1:40 PM, Richard Henderson  wrote:
 On 06/20/2014 05:17 PM, Sriraman Tallam wrote:
> Index: config/i386/i386.c
> ===
> --- config/i386/i386.c(revision 211826)
> +++ config/i386/i386.c(working copy)
> @@ -12691,7 +12691,9 @@ legitimate_pic_address_disp_p (rtx disp)
>   return true;
>   }
> else if (!SYMBOL_REF_FAR_ADDR_P (op0)
> -&& SYMBOL_REF_LOCAL_P (op0)
> +&& (SYMBOL_REF_LOCAL_P (op0)
> +|| (TARGET_64BIT && ix86_copyrelocs && flag_pie
> +&& !SYMBOL_REF_FUNCTION_P (op0)))
>  && ix86_cmodel != CM_LARGE_PIC)
>   return true;
> break;

 This is the wrong place to patch.

 You ought to be adjusting SYMBOL_REF_LOCAL_P, by providing a modified
 TARGET_BINDS_LOCAL_P.
>>>
>>> I have done this in the new attached patch, I added a new function
>>> i386_binds_local_p which will check for this and call
>>> default_binds_local_p otherwise.
>>>

 Note in particular that I believe that you are doing the wrong thing with 
 weak
 and COMMON symbols, in that you probably ought not force a copy reloc 
 there.
>>>
>>> I added an extra check to not do this for WEAK symbols. I also added a
>>> check for DECL_EXTERNAL so I believe this will also not be called for
>>> COMMON symbols.
>>>

 Note the complexity of default_binds_local_p_1, and the fact that all you
 really want to modify is

   /* If PIC, then assume that any global name can be overridden by
  symbols resolved from other modules.  */
   else if (shlib)
 local_p = false;

 near the bottom of that function.
>>>
>>> I did not understand what you mean here? Were you suggesting an
>>> alternative way of doing this?
>>>
>>> Thanks for reviewing
>>> Sri
>>>


 r~

Re: [C PATCH] Use error_operand_p more

[Joseph S. Myers]

On Sun, 5 Oct 2014, Marek Polacek wrote:

> It occured to me that we should probably use error_operand_p
> in the C FE where appropriate.  Following change is meant only
> as a little cleanup.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2014-10-04  Marek Polacek  
> 
>   * c-convert.c (convert): Use error_operand_p.
>   * c-typeck.c (require_complete_type): Likewise.
>   (really_atomic_lvalue): Likewise.
>   (digest_init): Likewise.
>   (handle_omp_array_sections_1): Likewise.

OK.

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

Re: [patch] Add -static-libquadmath option

[Joseph S. Myers]

Since -static-libquadmath introduces LGPL requirements on redistributing 
the resulting binaries (that you provide source or relinkable object files 
to allow relinking with modified versions of libquadmath) that don't 
otherwise generally apply simply through using GCC to build a program even 
if you link in GCC's other libraries statically, it would seem a good idea 
for the documentation of this option to make that explicit.

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

Re: [PATCH] Indirect-call topn targets profiler (instrumentation)

[Xinliang David Li]

On Mon, Oct 6, 2014 at 1:31 PM, Jan Hubicka  wrote:
>>
>> Yes. That's doable. I'm just not sure if top 2 entries are enough. I
>> can see from your example that it will be useful for BBs having
>> multiple case stmt.
>
> I suppose we want real histogram profiler here.  I.e. something that is given
> value ranges and fill in the counts depending on value ranges.
> Other case where your profiler may be useful is the division/modulo 
> conversion.
> For hashtables divisions/modules are often small sets of prime numbers.

yes, tracking value ranges sounds interesting. The topn is also
configurable to track more values, but it will become more expensive
to use.

David

>>
>> Yes. I'm looking at this too. I actually ported the fdo-use part of
>> the patch and it passes spec2006. But it performs the transformation
>> using the old way (in gimple_ic_transform()) -- so I did not send out
>> that patch.
>> I'm trying to do this in the new way (in ipa-profile()). In any case,
>> that will be a separated patch.
>>
>> Also, the switch expansion profile should be also a separated patch.
>>
>> Is it ok to commit these two patches now?
>
> Yes, it is OK, thanks!
>
> Honza
>>
>> Thanks,
>>
>> -Rong
>>
>> >> >
>> >> > Thanks,
>> >> > Honza
>> >> >
>> >> > Index: gcc/tree-profile.c
>> >> > ===
>> >> > --- gcc/tree-profile.c  (revision 215886)
>> >> > +++ gcc/tree-profile.c  (working copy)
>> >> > @@ -56,6 +56,7 @@ along with GCC; see the file COPYING3.  If not see
>> >> >  #include "target.h"
>> >> >  #include "tree-cfgcleanup.h"
>> >> >  #include "tree-nested.h"
>> >> > +#include "params.h"
>> >> >
>> >> >  static GTY(()) tree gcov_type_node;
>> >> >  static GTY(()) tree tree_interval_profiler_fn;
>> >> > @@ -101,7 +102,10 @@ init_ic_make_global_vars (void)
>> >> >  {
>> >> >ic_void_ptr_var
>> >> > = build_decl (UNKNOWN_LOCATION, VAR_DECL,
>> >> > - get_identifier ("__gcov_indirect_call_callee"),
>> >> > + get_identifier (
>> >> > + (PARAM_VALUE 
>> >> > (PARAM_INDIR_CALL_TOPN_PROFILE) ?
>> >> > +  "__gcov_indirect_call_topn_callee" :
>> >> > +  "__gcov_indirect_call_callee")),
>> >> >   ptr_void);
>> >> >TREE_PUBLIC (ic_void_ptr_var) = 1;
>> >> >DECL_EXTERNAL (ic_void_ptr_var) = 1;
>> >> > @@ -131,7 +135,10 @@ init_ic_make_global_vars (void)
>> >> >  {
>> >> >ic_gcov_type_ptr_var
>> >> > = build_decl (UNKNOWN_LOCATION, VAR_DECL,
>> >> > - get_identifier ("__gcov_indirect_call_counters"),
>> >> > + get_identifier (
>> >> > + (PARAM_VALUE 
>> >> > (PARAM_INDIR_CALL_TOPN_PROFILE) ?
>> >> > +  "__gcov_indirect_call_topn_counters" :
>> >> > +  "__gcov_indirect_call_counters")),
>> >> >   gcov_type_ptr);
>> >> >TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
>> >> >DECL_EXTERNAL (ic_gcov_type_ptr_var) = 1;
>> >> > @@ -226,8 +233,10 @@ gimple_init_edge_profiler (void)
>> >> >   ptr_void,
>> >> >   NULL_TREE);
>> >> >   tree_indirect_call_profiler_fn
>> >> > - = build_fn_decl ("__gcov_indirect_call_profiler_v2",
>> >> > -ic_profiler_fn_type);
>> >> > + = build_fn_decl ( (PARAM_VALUE 
>> >> > (PARAM_INDIR_CALL_TOPN_PROFILE) ?
>> >> > +
>> >> > "__gcov_indirect_call_topn_profiler":
>> >> > +
>> >> > "__gcov_indirect_call_profiler_v2"),
>> >> > +  ic_profiler_fn_type);
>> >> >  }
>> >> >TREE_NOTHROW (tree_indirect_call_profiler_fn) = 1;
>> >> >DECL_ATTRIBUTES (tree_indirect_call_profiler_fn)
>> >> > @@ -398,6 +407,12 @@ gimple_gen_ic_profiler (histogram_value value, uns
>> >> >gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
>> >> >tree ref_ptr = tree_coverage_counter_addr (tag, base);
>> >> >
>> >> > +  if ( (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
>> >> > +tag == GCOV_COUNTER_V_INDIR) ||
>> >> > +   (!PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
>> >> > +tag == GCOV_COUNTER_ICALL_TOPNV))
>> >> > +return;
>> >> > +
>> >> >ref_ptr = force_gimple_operand_gsi (&gsi, ref_ptr,
>> >> >   true, NULL_TREE, true, 
>> >> > GSI_SAME_STMT);
>> >> >
>> >> > @@ -442,8 +457,7 @@ gimple_gen_ic_func_profiler (void)
>> >> >  stmt1: __gcov_indirect_call_profiler_v2 (profile_id,
>> >> >  ¤t_function_decl)
>> >> > */
>> >> > -  gsi =
>> >> > -gsi_after_labels 
>> >> > (split_edge (s

Re: [PATCH] Indirect-call topn targets profiler (instrumentation)

[Jan Hubicka]

> 
> Yes. That's doable. I'm just not sure if top 2 entries are enough. I
> can see from your example that it will be useful for BBs having
> multiple case stmt.

I suppose we want real histogram profiler here.  I.e. something that is given
value ranges and fill in the counts depending on value ranges. 
Other case where your profiler may be useful is the division/modulo conversion.
For hashtables divisions/modules are often small sets of prime numbers.
> 
> Yes. I'm looking at this too. I actually ported the fdo-use part of
> the patch and it passes spec2006. But it performs the transformation
> using the old way (in gimple_ic_transform()) -- so I did not send out
> that patch.
> I'm trying to do this in the new way (in ipa-profile()). In any case,
> that will be a separated patch.
> 
> Also, the switch expansion profile should be also a separated patch.
> 
> Is it ok to commit these two patches now?

Yes, it is OK, thanks!

Honza
> 
> Thanks,
> 
> -Rong
> 
> >> >
> >> > Thanks,
> >> > Honza
> >> >
> >> > Index: gcc/tree-profile.c
> >> > ===
> >> > --- gcc/tree-profile.c  (revision 215886)
> >> > +++ gcc/tree-profile.c  (working copy)
> >> > @@ -56,6 +56,7 @@ along with GCC; see the file COPYING3.  If not see
> >> >  #include "target.h"
> >> >  #include "tree-cfgcleanup.h"
> >> >  #include "tree-nested.h"
> >> > +#include "params.h"
> >> >
> >> >  static GTY(()) tree gcov_type_node;
> >> >  static GTY(()) tree tree_interval_profiler_fn;
> >> > @@ -101,7 +102,10 @@ init_ic_make_global_vars (void)
> >> >  {
> >> >ic_void_ptr_var
> >> > = build_decl (UNKNOWN_LOCATION, VAR_DECL,
> >> > - get_identifier ("__gcov_indirect_call_callee"),
> >> > + get_identifier (
> >> > + (PARAM_VALUE 
> >> > (PARAM_INDIR_CALL_TOPN_PROFILE) ?
> >> > +  "__gcov_indirect_call_topn_callee" :
> >> > +  "__gcov_indirect_call_callee")),
> >> >   ptr_void);
> >> >TREE_PUBLIC (ic_void_ptr_var) = 1;
> >> >DECL_EXTERNAL (ic_void_ptr_var) = 1;
> >> > @@ -131,7 +135,10 @@ init_ic_make_global_vars (void)
> >> >  {
> >> >ic_gcov_type_ptr_var
> >> > = build_decl (UNKNOWN_LOCATION, VAR_DECL,
> >> > - get_identifier ("__gcov_indirect_call_counters"),
> >> > + get_identifier (
> >> > + (PARAM_VALUE 
> >> > (PARAM_INDIR_CALL_TOPN_PROFILE) ?
> >> > +  "__gcov_indirect_call_topn_counters" :
> >> > +  "__gcov_indirect_call_counters")),
> >> >   gcov_type_ptr);
> >> >TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
> >> >DECL_EXTERNAL (ic_gcov_type_ptr_var) = 1;
> >> > @@ -226,8 +233,10 @@ gimple_init_edge_profiler (void)
> >> >   ptr_void,
> >> >   NULL_TREE);
> >> >   tree_indirect_call_profiler_fn
> >> > - = build_fn_decl ("__gcov_indirect_call_profiler_v2",
> >> > -ic_profiler_fn_type);
> >> > + = build_fn_decl ( (PARAM_VALUE 
> >> > (PARAM_INDIR_CALL_TOPN_PROFILE) ?
> >> > +
> >> > "__gcov_indirect_call_topn_profiler":
> >> > +"__gcov_indirect_call_profiler_v2"),
> >> > +  ic_profiler_fn_type);
> >> >  }
> >> >TREE_NOTHROW (tree_indirect_call_profiler_fn) = 1;
> >> >DECL_ATTRIBUTES (tree_indirect_call_profiler_fn)
> >> > @@ -398,6 +407,12 @@ gimple_gen_ic_profiler (histogram_value value, uns
> >> >gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
> >> >tree ref_ptr = tree_coverage_counter_addr (tag, base);
> >> >
> >> > +  if ( (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
> >> > +tag == GCOV_COUNTER_V_INDIR) ||
> >> > +   (!PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
> >> > +tag == GCOV_COUNTER_ICALL_TOPNV))
> >> > +return;
> >> > +
> >> >ref_ptr = force_gimple_operand_gsi (&gsi, ref_ptr,
> >> >   true, NULL_TREE, true, 
> >> > GSI_SAME_STMT);
> >> >
> >> > @@ -442,8 +457,7 @@ gimple_gen_ic_func_profiler (void)
> >> >  stmt1: __gcov_indirect_call_profiler_v2 (profile_id,
> >> >  ¤t_function_decl)
> >> > */
> >> > -  gsi =
> >> > -gsi_after_labels 
> >> > (split_edge (single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun;
> >> > +  gsi = gsi_after_labels (split_edge (single_succ_edge 
> >> > (ENTRY_BLOCK_PTR_FOR_FN (cfun;
> >> >
> >> >cur_func = force_gimple_operand_gsi (&gsi,
> >> >build_addr (current_function_decl,
> >> > Index: gcc/val

Re: [PATCH] Indirect-call topn targets profiler (instrumentation)

[Rong Xu]

On Mon, Oct 6, 2014 at 12:21 PM, Jan Hubicka  wrote:
>> On Mon, Oct 6, 2014 at 11:22 AM, Jan Hubicka  wrote:
>> > Rong,
>> > Would be possible to use topn profiler to get resonale histograms for 
>> > switch
>> > expansion, too?  In that case it may make sense to have value version of 
>> > it as well.
>>

Yes. That's doable. I'm just not sure if top 2 entries are enough. I
can see from your example that it will be useful for BBs having
multiple case stmt.

>> The underlying topn_profiler can be used the same way as the current
>> one_value profiler for different scenarios. However, I wonder if it is
>> useful for switch value profiling -- the arc profiling can do the
>> same.
>
> Well, for switch expansion one really wants a histogram of values across the 
> switch
> values for the decision tree balancing.  But I guess this profiler does not 
> fit
> that very well.
>
> Consider cases like
>
> switch (a)
> {
>case 3:
>case 5:
>case 7:
> prime();
>case 2:
>case 4:
>case 6:
> even();
>   default:
> bogus ();
> }
>
> Arc profiling does tell you how often a is prime or even, but it does not 
> help you
> to balance the tree, because the value ranges are iinterlacing
>>
>> David
>>
>> >
>> > Otherwise the patch seems OK.  I would implement it myself by introducing 
>> > separate
>> > variables holding the topn profiler declaration, but can not think of 
>> > downsides of
>> > doing it your way.
>> >
>> > The topn profiler should be better on determining the dominating target, 
>> > so perhaps
>> > you could look into hooking it into ipa-profile.c.  Extending speculative 
>> > edges for
>> > multiple targets ought to be also quite easy - we need to update 
>> > speculative_call_info
>> > to collect edges annotated to a given call stmt into a vector instead of 
>> > taking the
>> > two references it does now.
>> >
>> > It would be also very nice to update it to handle case where all the edges 
>> > are direct
>> > so we can use it tospeculatively inlinine functions that can be interposed 
>> > at runtime.

Yes. I'm looking at this too. I actually ported the fdo-use part of
the patch and it passes spec2006. But it performs the transformation
using the old way (in gimple_ic_transform()) -- so I did not send out
that patch.
I'm trying to do this in the new way (in ipa-profile()). In any case,
that will be a separated patch.

Also, the switch expansion profile should be also a separated patch.

Is it ok to commit these two patches now?

Thanks,

-Rong

>> >
>> > Thanks,
>> > Honza
>> >
>> > Index: gcc/tree-profile.c
>> > ===
>> > --- gcc/tree-profile.c  (revision 215886)
>> > +++ gcc/tree-profile.c  (working copy)
>> > @@ -56,6 +56,7 @@ along with GCC; see the file COPYING3.  If not see
>> >  #include "target.h"
>> >  #include "tree-cfgcleanup.h"
>> >  #include "tree-nested.h"
>> > +#include "params.h"
>> >
>> >  static GTY(()) tree gcov_type_node;
>> >  static GTY(()) tree tree_interval_profiler_fn;
>> > @@ -101,7 +102,10 @@ init_ic_make_global_vars (void)
>> >  {
>> >ic_void_ptr_var
>> > = build_decl (UNKNOWN_LOCATION, VAR_DECL,
>> > - get_identifier ("__gcov_indirect_call_callee"),
>> > + get_identifier (
>> > + (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) 
>> > ?
>> > +  "__gcov_indirect_call_topn_callee" :
>> > +  "__gcov_indirect_call_callee")),
>> >   ptr_void);
>> >TREE_PUBLIC (ic_void_ptr_var) = 1;
>> >DECL_EXTERNAL (ic_void_ptr_var) = 1;
>> > @@ -131,7 +135,10 @@ init_ic_make_global_vars (void)
>> >  {
>> >ic_gcov_type_ptr_var
>> > = build_decl (UNKNOWN_LOCATION, VAR_DECL,
>> > - get_identifier ("__gcov_indirect_call_counters"),
>> > + get_identifier (
>> > + (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) 
>> > ?
>> > +  "__gcov_indirect_call_topn_counters" :
>> > +  "__gcov_indirect_call_counters")),
>> >   gcov_type_ptr);
>> >TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
>> >DECL_EXTERNAL (ic_gcov_type_ptr_var) = 1;
>> > @@ -226,8 +233,10 @@ gimple_init_edge_profiler (void)
>> >   ptr_void,
>> >   NULL_TREE);
>> >   tree_indirect_call_profiler_fn
>> > - = build_fn_decl ("__gcov_indirect_call_profiler_v2",
>> > -ic_profiler_fn_type);
>> > + = build_fn_decl ( (PARAM_VALUE 
>> > (PARAM_INDIR_CALL_TOPN_PROFILE) ?
>> > +"__gcov_indirect_call_topn_profiler":
>> > +"__gcov_indirect_call_profiler_v2"),
>> > + 

[jit] Merger of trunk r215958 into jit branch

[David Malcolm]

I've merged today's svn trunk into the git branch
dmalcolm/jit, pushing it as
81d39bf76e3ffd4e62c307cc8d22df18572eec19

Specifically, this is from trunk r215958 aka
e012cdc775868e9922f5fef9068a764546876d93
bringing in all changes since 215803 aka
68874c5d021dd6b8b740ffd23960e46e333270b5 (2014-10-02)

[am continuing to experiment with embedding the driver in-process within
the jit library, and wanted r215861 as part of that]

Re: [PATCH] Indirect-call topn targets profiler (instrumentation)

[Jan Hubicka]

> On Mon, Oct 6, 2014 at 11:22 AM, Jan Hubicka  wrote:
> > Rong,
> > Would be possible to use topn profiler to get resonale histograms for switch
> > expansion, too?  In that case it may make sense to have value version of it 
> > as well.
> 
> The underlying topn_profiler can be used the same way as the current
> one_value profiler for different scenarios. However, I wonder if it is
> useful for switch value profiling -- the arc profiling can do the
> same.

Well, for switch expansion one really wants a histogram of values across the 
switch
values for the decision tree balancing.  But I guess this profiler does not fit
that very well.

Consider cases like

switch (a)
{
   case 3:
   case 5:
   case 7:
prime();
   case 2:
   case 4:
   case 6:
even();
  default:
bogus ();
}

Arc profiling does tell you how often a is prime or even, but it does not help 
you
to balance the tree, because the value ranges are iinterlacing
> 
> David
> 
> >
> > Otherwise the patch seems OK.  I would implement it myself by introducing 
> > separate
> > variables holding the topn profiler declaration, but can not think of 
> > downsides of
> > doing it your way.
> >
> > The topn profiler should be better on determining the dominating target, so 
> > perhaps
> > you could look into hooking it into ipa-profile.c.  Extending speculative 
> > edges for
> > multiple targets ought to be also quite easy - we need to update 
> > speculative_call_info
> > to collect edges annotated to a given call stmt into a vector instead of 
> > taking the
> > two references it does now.
> >
> > It would be also very nice to update it to handle case where all the edges 
> > are direct
> > so we can use it tospeculatively inlinine functions that can be interposed 
> > at runtime.
> >
> > Thanks,
> > Honza
> >
> > Index: gcc/tree-profile.c
> > ===
> > --- gcc/tree-profile.c  (revision 215886)
> > +++ gcc/tree-profile.c  (working copy)
> > @@ -56,6 +56,7 @@ along with GCC; see the file COPYING3.  If not see
> >  #include "target.h"
> >  #include "tree-cfgcleanup.h"
> >  #include "tree-nested.h"
> > +#include "params.h"
> >
> >  static GTY(()) tree gcov_type_node;
> >  static GTY(()) tree tree_interval_profiler_fn;
> > @@ -101,7 +102,10 @@ init_ic_make_global_vars (void)
> >  {
> >ic_void_ptr_var
> > = build_decl (UNKNOWN_LOCATION, VAR_DECL,
> > - get_identifier ("__gcov_indirect_call_callee"),
> > + get_identifier (
> > + (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) ?
> > +  "__gcov_indirect_call_topn_callee" :
> > +  "__gcov_indirect_call_callee")),
> >   ptr_void);
> >TREE_PUBLIC (ic_void_ptr_var) = 1;
> >DECL_EXTERNAL (ic_void_ptr_var) = 1;
> > @@ -131,7 +135,10 @@ init_ic_make_global_vars (void)
> >  {
> >ic_gcov_type_ptr_var
> > = build_decl (UNKNOWN_LOCATION, VAR_DECL,
> > - get_identifier ("__gcov_indirect_call_counters"),
> > + get_identifier (
> > + (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) ?
> > +  "__gcov_indirect_call_topn_counters" :
> > +  "__gcov_indirect_call_counters")),
> >   gcov_type_ptr);
> >TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
> >DECL_EXTERNAL (ic_gcov_type_ptr_var) = 1;
> > @@ -226,8 +233,10 @@ gimple_init_edge_profiler (void)
> >   ptr_void,
> >   NULL_TREE);
> >   tree_indirect_call_profiler_fn
> > - = build_fn_decl ("__gcov_indirect_call_profiler_v2",
> > -ic_profiler_fn_type);
> > + = build_fn_decl ( (PARAM_VALUE 
> > (PARAM_INDIR_CALL_TOPN_PROFILE) ?
> > +"__gcov_indirect_call_topn_profiler":
> > +"__gcov_indirect_call_profiler_v2"),
> > +  ic_profiler_fn_type);
> >  }
> >TREE_NOTHROW (tree_indirect_call_profiler_fn) = 1;
> >DECL_ATTRIBUTES (tree_indirect_call_profiler_fn)
> > @@ -398,6 +407,12 @@ gimple_gen_ic_profiler (histogram_value value, uns
> >gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
> >tree ref_ptr = tree_coverage_counter_addr (tag, base);
> >
> > +  if ( (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
> > +tag == GCOV_COUNTER_V_INDIR) ||
> > +   (!PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
> > +tag == GCOV_COUNTER_ICALL_TOPNV))
> > +return;
> > +
> >ref_ptr = force_gimple_operand_gsi (&gsi, ref_ptr,
> >   true, NULL_TREE, true, GSI_SAME_STMT);
> >
> > @@ -442,8 +457,7 @@ gimple_gen_ic_func_profiler (

Re: RFA: fix mode confusion in caller-save.c:replace_reg_with_saved_mem

[Jeff Law]

On 10/06/14 02:51, Joern Rennecke wrote:

Investigating an ICE while trying to compile libgcc2.c:__udivmoddi4 for
a new avr variant with different register set/allocation order, I found
replace_reg_with_saved_mem falling over its own nonsense.  The instruction:

(debug_insn 97 96 98 2 (var_location:SI __x2 (mult:SI (lshiftrt:SI
(reg/v:SI 18 r18 [orig:58 q0 ] [58])
 (const_int 16 [0x10]))
 (reg/v:SI 61 [ __vl ])))
../../gcc/gcc/testsuite/gcc.target/avr/tiny-caller-save.c:67 -1
  (nil))

would be transformed into:

(debug_insn 97 96 98 2 (var_location:SI __x2 (mult:SI (lshiftrt:SI (concatn:SI [
 (reg:SI 18 r18)
 (reg:SI 19 r19)
 (mem/c:QI (plus:HI (reg/f:HI 28 r28)
 (const_int 43 [0x2b])) [6  S1 A8])
 (mem/c:QI (plus:HI (reg/f:HI 28 r28)
 (const_int 44 [0x2c])) [6  S1 A8])
 ])
 (const_int 16 [0x10]))
 (reg/v:SI 61 [ __vl ])))
../../gcc/gcc/testsuite/gcc.target/avr/tiny-caller-save.c:67 -1

Note that r18 and r19 inside the concatn are supposed to be single hard
registers, but as the word size of this processor is 8 bit, SImode
extends actually
over four hard registers.  save_mode is SImode because four registers can be
saved/restored at once.

The attached patch fixes the failure by using word_mode if smode would cover
multiple hard registers.
bootstrapped & regtested on i686-pc-linux-gnu.

OK to apply?
What makes word_mode special here?  ie, why is special casing for 
word_mode the right thing to do?


jeff

Re: [PATCH] Indirect-call topn targets profiler (instrumentation)

[Xinliang David Li]

On Mon, Oct 6, 2014 at 11:22 AM, Jan Hubicka  wrote:
> Rong,
> Would be possible to use topn profiler to get resonale histograms for switch
> expansion, too?  In that case it may make sense to have value version of it 
> as well.

The underlying topn_profiler can be used the same way as the current
one_value profiler for different scenarios. However, I wonder if it is
useful for switch value profiling -- the arc profiling can do the
same.

David

>
> Otherwise the patch seems OK.  I would implement it myself by introducing 
> separate
> variables holding the topn profiler declaration, but can not think of 
> downsides of
> doing it your way.
>
> The topn profiler should be better on determining the dominating target, so 
> perhaps
> you could look into hooking it into ipa-profile.c.  Extending speculative 
> edges for
> multiple targets ought to be also quite easy - we need to update 
> speculative_call_info
> to collect edges annotated to a given call stmt into a vector instead of 
> taking the
> two references it does now.
>
> It would be also very nice to update it to handle case where all the edges 
> are direct
> so we can use it tospeculatively inlinine functions that can be interposed at 
> runtime.
>
> Thanks,
> Honza
>
> Index: gcc/tree-profile.c
> ===
> --- gcc/tree-profile.c  (revision 215886)
> +++ gcc/tree-profile.c  (working copy)
> @@ -56,6 +56,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "target.h"
>  #include "tree-cfgcleanup.h"
>  #include "tree-nested.h"
> +#include "params.h"
>
>  static GTY(()) tree gcov_type_node;
>  static GTY(()) tree tree_interval_profiler_fn;
> @@ -101,7 +102,10 @@ init_ic_make_global_vars (void)
>  {
>ic_void_ptr_var
> = build_decl (UNKNOWN_LOCATION, VAR_DECL,
> - get_identifier ("__gcov_indirect_call_callee"),
> + get_identifier (
> + (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) ?
> +  "__gcov_indirect_call_topn_callee" :
> +  "__gcov_indirect_call_callee")),
>   ptr_void);
>TREE_PUBLIC (ic_void_ptr_var) = 1;
>DECL_EXTERNAL (ic_void_ptr_var) = 1;
> @@ -131,7 +135,10 @@ init_ic_make_global_vars (void)
>  {
>ic_gcov_type_ptr_var
> = build_decl (UNKNOWN_LOCATION, VAR_DECL,
> - get_identifier ("__gcov_indirect_call_counters"),
> + get_identifier (
> + (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) ?
> +  "__gcov_indirect_call_topn_counters" :
> +  "__gcov_indirect_call_counters")),
>   gcov_type_ptr);
>TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
>DECL_EXTERNAL (ic_gcov_type_ptr_var) = 1;
> @@ -226,8 +233,10 @@ gimple_init_edge_profiler (void)
>   ptr_void,
>   NULL_TREE);
>   tree_indirect_call_profiler_fn
> - = build_fn_decl ("__gcov_indirect_call_profiler_v2",
> -ic_profiler_fn_type);
> + = build_fn_decl ( (PARAM_VALUE 
> (PARAM_INDIR_CALL_TOPN_PROFILE) ?
> +"__gcov_indirect_call_topn_profiler":
> +"__gcov_indirect_call_profiler_v2"),
> +  ic_profiler_fn_type);
>  }
>TREE_NOTHROW (tree_indirect_call_profiler_fn) = 1;
>DECL_ATTRIBUTES (tree_indirect_call_profiler_fn)
> @@ -398,6 +407,12 @@ gimple_gen_ic_profiler (histogram_value value, uns
>gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
>tree ref_ptr = tree_coverage_counter_addr (tag, base);
>
> +  if ( (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
> +tag == GCOV_COUNTER_V_INDIR) ||
> +   (!PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
> +tag == GCOV_COUNTER_ICALL_TOPNV))
> +return;
> +
>ref_ptr = force_gimple_operand_gsi (&gsi, ref_ptr,
>   true, NULL_TREE, true, GSI_SAME_STMT);
>
> @@ -442,8 +457,7 @@ gimple_gen_ic_func_profiler (void)
>  stmt1: __gcov_indirect_call_profiler_v2 (profile_id,
>  ¤t_function_decl)
> */
> -  gsi =
> -gsi_after_labels (split_edge 
> (single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun;
> +  gsi = gsi_after_labels (split_edge (single_succ_edge 
> (ENTRY_BLOCK_PTR_FOR_FN (cfun;
>
>cur_func = force_gimple_operand_gsi (&gsi,
>build_addr (current_function_decl,
> Index: gcc/value-prof.c
> ===
> --- gcc/value-prof.c(revision 215886)
> +++ gcc/value-prof.c(working copy)
> @@ -60,6 +6

Re: [PATCH] Indirect-call topn targets profiler (instrumentation)

[Jan Hubicka]

Rong,
Would be possible to use topn profiler to get resonale histograms for switch
expansion, too?  In that case it may make sense to have value version of it as 
well.

Otherwise the patch seems OK.  I would implement it myself by introducing 
separate
variables holding the topn profiler declaration, but can not think of downsides 
of
doing it your way.

The topn profiler should be better on determining the dominating target, so 
perhaps
you could look into hooking it into ipa-profile.c.  Extending speculative edges 
for
multiple targets ought to be also quite easy - we need to update 
speculative_call_info
to collect edges annotated to a given call stmt into a vector instead of taking 
the
two references it does now.

It would be also very nice to update it to handle case where all the edges are 
direct
so we can use it tospeculatively inlinine functions that can be interposed at 
runtime.

Thanks,
Honza

Index: gcc/tree-profile.c
===
--- gcc/tree-profile.c  (revision 215886)
+++ gcc/tree-profile.c  (working copy)
@@ -56,6 +56,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "tree-cfgcleanup.h"
 #include "tree-nested.h"
+#include "params.h"
 
 static GTY(()) tree gcov_type_node;
 static GTY(()) tree tree_interval_profiler_fn;
@@ -101,7 +102,10 @@ init_ic_make_global_vars (void)
 {
   ic_void_ptr_var
= build_decl (UNKNOWN_LOCATION, VAR_DECL,
- get_identifier ("__gcov_indirect_call_callee"),
+ get_identifier (
+ (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) ?
+  "__gcov_indirect_call_topn_callee" :
+  "__gcov_indirect_call_callee")),
  ptr_void);
   TREE_PUBLIC (ic_void_ptr_var) = 1;
   DECL_EXTERNAL (ic_void_ptr_var) = 1;
@@ -131,7 +135,10 @@ init_ic_make_global_vars (void)
 {
   ic_gcov_type_ptr_var
= build_decl (UNKNOWN_LOCATION, VAR_DECL,
- get_identifier ("__gcov_indirect_call_counters"),
+ get_identifier (
+ (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) ?
+  "__gcov_indirect_call_topn_counters" :
+  "__gcov_indirect_call_counters")),
  gcov_type_ptr);
   TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
   DECL_EXTERNAL (ic_gcov_type_ptr_var) = 1;
@@ -226,8 +233,10 @@ gimple_init_edge_profiler (void)
  ptr_void,
  NULL_TREE);
  tree_indirect_call_profiler_fn
- = build_fn_decl ("__gcov_indirect_call_profiler_v2",
-ic_profiler_fn_type);
+ = build_fn_decl ( (PARAM_VALUE 
(PARAM_INDIR_CALL_TOPN_PROFILE) ?
+"__gcov_indirect_call_topn_profiler":
+"__gcov_indirect_call_profiler_v2"),
+  ic_profiler_fn_type);
 }
   TREE_NOTHROW (tree_indirect_call_profiler_fn) = 1;
   DECL_ATTRIBUTES (tree_indirect_call_profiler_fn)
@@ -398,6 +407,12 @@ gimple_gen_ic_profiler (histogram_value value, uns
   gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
   tree ref_ptr = tree_coverage_counter_addr (tag, base);
 
+  if ( (PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
+tag == GCOV_COUNTER_V_INDIR) ||
+   (!PARAM_VALUE (PARAM_INDIR_CALL_TOPN_PROFILE) &&
+tag == GCOV_COUNTER_ICALL_TOPNV))
+return;
+
   ref_ptr = force_gimple_operand_gsi (&gsi, ref_ptr,
  true, NULL_TREE, true, GSI_SAME_STMT);
 
@@ -442,8 +457,7 @@ gimple_gen_ic_func_profiler (void)
 stmt1: __gcov_indirect_call_profiler_v2 (profile_id,
 ¤t_function_decl)
*/
-  gsi =
-gsi_after_labels (split_edge 
(single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun;
+  gsi = gsi_after_labels (split_edge (single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN 
(cfun;
 
   cur_func = force_gimple_operand_gsi (&gsi,
   build_addr (current_function_decl,
Index: gcc/value-prof.c
===
--- gcc/value-prof.c(revision 215886)
+++ gcc/value-prof.c(working copy)
@@ -60,6 +60,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "builtins.h"
 #include "tree-nested.h"
 #include "hash-set.h"
+#include "params.h"
 
 /* In this file value profile based optimizations are placed.  Currently the
following optimizations are implemented (for more detailed descriptions
@@ -359,6 +360,22 @@ dump_histogram_value (FILE *dump_file, histogram_v
   }
   fprintf (dump_file, ".\n");
   break;
+case HIST_TYPE_INDIR_CALL_TOPN:
+

Re: RFA: Merge definitions of get_some_local_dynamic_name

[Richard Sandiford]

Rainer Orth  writes:
> Hi Richard,
>> Rainer Orth  writes:
>>> Hi Richard,
> It seems the new get_some_local_dynamic_name implementation in
> function.c lost the non-NULL check the sparc.c version had.  I'm
> currently testing the following patch:

 Could you do a:

   call debug_rtx (...)

 on the insn that contains a null pointer?  Normally insn patterns
 shouldn't contain nulls, so I was wondering whether this was some
 SPARC-specific construct.
>>>
>>> proved a bit difficult to do: at the default -O2, insn was optimized
>>> away, at -g3 -O0, I only got
>>>
>>> can't compute CFA for this frame
>>>
>>> with gdb 7.8 even after recompiling all of the gcc dir with -g3 -O0.
>>>
>>> Here's what I find after inserting the call in the source:
>>>
>>> (insn 30 6 28 (sequence [
>>> (call_insn:TI 8 6 7 (parallel [
>>> (set (reg:SI 8 %o0)
>>> (call (mem:SI (unspec:SI [
>>> (symbol_ref:SI 
>>> ("__tls_get_addr"))
>>> ] UNSPEC_TLSLDM) [0  S4 A32])
>>> (const_int 1 [0x1])))
>>> (clobber (reg:SI 15 %o7))
>>> ]) /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:936 
>>> 390 {tldm_call32}
>>>  (expr_list:REG_EH_REGION (const_int -2147483648 
>>> [0x8000])
>>> (nil))
>>> (expr_list (use (reg:SI 8 %o0))
>>> (nil)))
>>> (insn 7 8 28 (set (reg:SI 8 %o0)
>>> (plus:SI (reg:SI 23 %l7)
>>> (unspec:SI [
>>> (reg:SI 8 %o0 [112])
>>> ] UNSPEC_TLSLDM))) 388 {tldm_add32}
>>>  (nil))
>>> ]) /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:936 -1
>>>  (nil))
>>
>> Bah, a sequence.  Hadn't thought of that.
>>
>> IMO it's a bug for a walk on a PATTERN to pull in non-PATTERN parts
>> of an insn.  We should really be looking at the patterns of the two
>> subinsns instead and ignore the other stuff.  Let me have a think
>> about it.
>
> did you come to a conclusion here?

Sorry, forgot to come back to this.  I have a patch that iterates over
PATTERNs of a SEQUENCE if the SEQUENCE (rather than its containing insn)
is the topmost iterated rtx.  So if PATTERN (insn) is a SEQUENCE:

   FOR_EACH_SUBRTX (, insn, x)
 ...

will iterate over the insns in the SEQUENCE (including pattern, notes,
jump label, etc.), whereas:

   FOR_EACH_SUBRTX (, PATTERN (insn), x)
 ...

would only iterate over the patterns of the insns in the SEQUENCE.

I'll need to pass it through internal review before sending, but hope
to post soon.

Thanks,
Richard

[jit] Fix "make check-jit"

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/ChangeLog.jit:
* Make-lang.in (lang_checks): Append "check-jit".

* docs/internals/index.rst (Running the test suite): Use
"check-jit" rather than "check-parallel-jit".
---
 gcc/jit/Make-lang.in | 2 ++
 gcc/jit/docs/internals/index.rst | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in
index e79d5d0..666a92b 100644
--- a/gcc/jit/Make-lang.in
+++ b/gcc/jit/Make-lang.in
@@ -236,6 +236,8 @@ jit.man:
 
 jit.srcman:
 
+lang_checks += check-jit
+
 #
 # Install hooks:
 jit.install-common: installdirs
diff --git a/gcc/jit/docs/internals/index.rst b/gcc/jit/docs/internals/index.rst
index c8b05e0..9765862 100644
--- a/gcc/jit/docs/internals/index.rst
+++ b/gcc/jit/docs/internals/index.rst
@@ -36,7 +36,7 @@ Running the test suite
 .. code-block:: console
 
   [build] $ cd gcc
-  [gcc] $ make check-parallel-jit RUNTESTFLAGS="-v -v -v"
+  [gcc] $ make check-jit RUNTESTFLAGS="-v -v -v"
 
 A summary of the tests can then be seen in:
 
@@ -62,7 +62,7 @@ You can compile and run individual tests by passing 
"jit.exp=TESTNAME" to RUNTES
 
 .. code-block:: console
 
-   [gcc] $ make check-parallel-jit RUNTESTFLAGS="-v -v -v 
jit.exp=test-factorial.c"
+   [gcc] $ make check-jit RUNTESTFLAGS="-v -v -v jit.exp=test-factorial.c"
 
 and once a test has been compiled, you can debug it directly:
 
-- 
1.7.11.7

Re: [PATCH 0/14+2][Vectorizer] Made reductions endianness-neutral, fixes PR/61114

[Alan Lawrence]

Ok, so unless there are objections, I plan to commit patches 1, 2, 4, 5, and 6,
which have been previously approved, in that sequence. (Of those, all bar patch
2 are AArch64 only.) I think this is better than maintaining an ever-expanding
patch series.

Then I'll get to work on migrating all backends to the new _scal_ optab (and
removing the vector optab). Certainly I'd like to replace vec_shr/l with
vec_perm_expr too, but I'm conscious that the end of stage 1 is approaching!

--Alan


Richard Biener wrote:

On Thu, Sep 18, 2014 at 1:41 PM, Alan Lawrence  wrote:

The end goal here is to remove this code from tree-vect-loop.c
(vect_create_epilog_for_reduction):

  if (BYTES_BIG_ENDIAN)
bitpos = size_binop (MULT_EXPR,
 bitsize_int (TYPE_VECTOR_SUBPARTS (vectype) -
1),
 TYPE_SIZE (scalar_type));
  else

as this is the root cause of PR/61114 (see testcase there, failing on all
bigendian targets supporting reduc_[us]plus_optab). Quoting Richard Biener,
"all code conditional on BYTES/WORDS_BIG_ENDIAN in tree-vect* is
suspicious". The code snippet above is used on two paths:

(Path 1) (patches 1-6) Reductions using REDUC_(PLUS|MIN|MAX)_EXPR =
reduc_[us](plus|min|max)_optab.
The optab is documented as "the scalar result is stored in the least
significant bits of operand 0", but the tree code as "the first element in
the vector holding the result of the reduction of all elements of the
operand". This mismatch means that when the tree code is folded, the code
snippet above reads the result from the wrong end of the vector.

The strategy (as per
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00041.html) is to define new
tree codes and optabs that produce scalar results directly; this seems
better than tying (the element of the vector into which the result is
placed) to (the endianness of the target), and avoids generating extra moves
on current bigendian targets. However, the previous optabs are retained for
now as a migration strategy so as not to break existing backends; moving
individual platforms over will follow.

A complication here is on AArch64, where we directly generate
REDUC_PLUS_EXPRs from intrinsics in gimple_fold_builtin; I temporarily
remove this folding in order to decouple the midend and AArch64 backend.


Sounds fine.  I hope we can transition all backends for 5.0 and remove
the vector variant optabs (maybe renaming the scalar ones).


(Path 2) (patches 7-13) Reductions using whole-vector-shifts, i.e.
VEC_RSHIFT_EXPR and vec_shr_optab. Here the tree code as well as the optab
is defined in an endianness-dependent way, leading to significant
complication in fold-const.c. (Moreover, the "equivalent" vec_shl_optab is
never used!). Few platforms appear to handle vec_shr_optab (and fewer
bigendian - I see only PowerPC and MIPS), so it seems pertinent to change
the existing optab to be endianness-neutral.

Patch 10 defines vec_shr for AArch64, for the old specification; patch 13
updates that implementation to fit the new endianness-neutral specification,
serving as a guide for other existing backends. Patches/RFCs 15 and 16 are
equivalents for MIPS and PowerPC; I haven't tested these but hope they act
as useful pointers for the port maintainers.

Finally patch 14 cleans up the affected part of tree-vect-loop.c
(vect_create_epilog_for_reduction).


As said during the individual patches review I'd like the vectorizer to
use a VEC_PERM_EXPR instead of VEC_RSHIFT_EXPR (with
only whole-element amounts).  This means we can remove
VEC_RSHIFT_EXPR.  It also means that if the backend defines
vec_perm_const (which it really should) it can handle the special
permutes that boil down to a possibly more efficient vector shift
there (a good optimization anyway).  Until it does that all backends
would at least create correct code (with the endian dependent
vec_shr removed).

Richard.


--Alan

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Mike Stump]

On Oct 6, 2014, at 8:36 AM, Chen Gang  wrote:
> For me, "make -k check" is suitable for one sub-system (e.g. for cross
> building, and mainly focus on gcc), but not for global check (full
> non-cross building check):

In our world, there is no sub-system, so, talk of such is outside the scope of 
gcc.

Let me repeat what he said differently.

You have two choices, fixing the port so that there are no unexpected failures 
or running check with -k.

I’d like to get to the point where all primary/secondary platforms can use make 
check directly, we’re not there yet.

The idea is that the single return value tells if if the suite passed or not.  
This is an absolute measure, that, when achieved means one never has to compare 
previous/present results, just know that the suite passed.  Sometimes simple is 
better.

> - "make check" is the standard check for global,

No sub-system, no global.

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

[Mike Stump]

On Oct 6, 2014, at 4:32 AM, Richard Biener  wrote:
> On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng  wrote:
> 
> How many merging opportunities does sched2 undo again?  ISTR it
> has the tendency of pushing stores down and loads up.

So, the pass works by merging 2 or more loads into 1 load (at least on my 
port).  sched2 would need to rip apart 1 load into 2 loads to be able to undo 
the real work.  The non-real work, doesn’t matter any.  Can sched2 rip apart a 
single load?

Re: [PATCH] SPARC: add mcpu=leon3v7 target

[Eric Botcazou]

> I posted it with v2 in the subject. I have now attached it.

There is a pasto in the v2:

@@ -1764,6 +1772,12 @@ extern int sparc_indent_opcode;
 #define AS_LEON_FLAG "-Av8"
 #endif
 
+#ifdef HAVE_AS_LEONV7
+#define AS_LEONV7_FLAG "-Aleon"
+#else
+#define AS_LEONV7_FLAG "-Av7"
+#endif
+
 /* We use gcc _mcount for profiling.  */
 #define NO_PROFILE_COUNTERS 0
 

I think you would be better off adding a line to the arms of the existing code

#ifdef HAVE_AS_LEON
#define AS_LEON_FLAG "-Aleon"
#else
#define AS_LEON_FLAG "-Av8"
#endif

rather than duplicating it.

-- 
Eric Botcazou

[PATCH] Indirect-call topn targets profiler (runtime)

[Rong Xu]

Hi,

I ported the indirect-call topn target profile from google branch. It
implements the algorithm described in "Value profiling and
optimization" by Brad Calder and Peter Feller. This patch is the
runtime support.

Tested with gcc regression tests and the instrumentation patch (in a
separated patch).

Thanks,

-Rong


patch1_diff
Description: Binary data

[PATCH] Indirect-call topn targets profiler (instrumentation)

[Rong Xu]

Hi,

I ported the indirect-call topn target profile from google branch. It
implements the algorithm described in "Value profiling and
optimization" by Brad Calder and Peter Feller. This patch is about the
instrumentation. When --param=indir-call-topn-profile=1 is specified,
we will use indirection-call-topn profiler in this patch, instead of
indirect_call_profiler_v2.

Tested with gcc regression tests and the runtime patch (in a separated patch).

Thanks,

-Rong


patch2_diff
Description: Binary data

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

[Jonathan Wakely]

On 28/03/14 08:56 +0900, Luke Allardyce wrote:

It looks like the new standard also requires the precision to be
ignored for hexfloat


For conversion from a floating-point type, if floatfield != (ios_base::fixed | 
ios_base:: scientific), str.precision() is specified as precision in the 
conversion specification. Otherwise, no precision is specified.


I've made this change and adjusted the test so that it doesn't make
any assumptions about the exact format of hexadecimal float output, as
it's unspecified whether you get e.g. 0x1.ep+3 or 0xfp+0 for 15.

As Luke pointed out, this changes the behaviour of some valid C++03
programs, but I think that's the right thing to do in this case. I'll
document that in the release notes.

Tested x86_64-linux, committed to trunk.
commit 7090c2fca0e3858ea527b66a1eb44fd504f1ba4e
Author: Jonathan Wakely 
Date:   Mon Sep 22 23:10:54 2014 +0100

2014-10-06  Rüdiger Sonderfeld  
	Jonathan Wakely  

	PR libstdc++/59987
	* doc/xml/manual/status_cxx2011.xml: Remove hexfloat from notes.
	* doc/html/manual/status.html: Regenerate.
	* include/bits/ios_base.h (hexfloat): New function.
	(defaultfloat): New function.
	* src/c++98/locale_facets.cc (__num_base::_S_format_float): Support
	hexadecimal floating point format.
	* testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:
	New file.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index 5b36556..108de36 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
@@ -2131,7 +2131,6 @@ particular release.
   
 Missing io_errc and iostream_category.
 ios_base::failure is not derived from system_error.
-	Missing ios_base::hexfloat.
   
 
 
diff --git a/libstdc++-v3/include/bits/ios_base.h b/libstdc++-v3/include/bits/ios_base.h
index fb448fd..5e33b81 100644
--- a/libstdc++-v3/include/bits/ios_base.h
+++ b/libstdc++-v3/include/bits/ios_base.h
@@ -984,6 +984,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 return __base;
   }
 
+#if __cplusplus >= 201103L
+  // New C++11 floatfield manipulators
+
+  /// Calls
+  /// base.setf(ios_base::fixed|ios_base::scientific, ios_base::floatfield)
+  inline ios_base&
+  hexfloat(ios_base& __base)
+  {
+__base.setf(ios_base::fixed | ios_base::scientific, ios_base::floatfield);
+return __base;
+  }
+
+  /// Calls @c base.unsetf(ios_base::floatfield)
+  inline ios_base&
+  defaultfloat(ios_base& __base)
+  {
+__base.unsetf(ios_base::floatfield);
+return __base;
+  }
+#endif
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
 
diff --git a/libstdc++-v3/src/c++98/locale_facets.cc b/libstdc++-v3/src/c++98/locale_facets.cc
index 3669acb..7ed04e6 100644
--- a/libstdc++-v3/src/c++98/locale_facets.cc
+++ b/libstdc++-v3/src/c++98/locale_facets.cc
@@ -69,19 +69,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 if (__flags & ios_base::showpoint)
   *__fptr++ = '#';
 
-// As per DR 231: _always_, not only when 
-// __flags & ios_base::fixed || __prec > 0
-*__fptr++ = '.';
-*__fptr++ = '*';
+ios_base::fmtflags __fltfield = __flags & ios_base::floatfield;
+
+if (__fltfield != (ios_base::fixed | ios_base::scientific))
+  {
+// As per DR 231: not only when __flags & ios_base::fixed || __prec > 0
+*__fptr++ = '.';
+*__fptr++ = '*';
+  }
 
 if (__mod)
   *__fptr++ = __mod;
-ios_base::fmtflags __fltfield = __flags & ios_base::floatfield;
 // [22.2.2.2.2] Table 58
 if (__fltfield == ios_base::fixed)
   *__fptr++ = 'f';
 else if (__fltfield == ios_base::scientific)
   *__fptr++ = (__flags & ios_base::uppercase) ? 'E' : 'e';
+#ifdef _GLIBCXX_USE_C99
+else if (__fltfield == (ios_base::fixed | ios_base::scientific))
+  *__fptr++ = (__flags & ios_base::uppercase) ? 'A' : 'a';
+#endif
 else
   *__fptr++ = (__flags & ios_base::uppercase) ? 'G' : 'g';
 *__fptr = '\0';
diff --git a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
new file mode 100644
index 000..485a485
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
@@ -0,0 +1,152 @@
+// { dg-options "-std=gnu++11" }
+
+// 2014-03-27 Rüdiger Sonderfeld
+// test the hexadecimal floating point inserters (facet num_put)
+
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, 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 war

[PATCH 5/n] OpenMP 4.0 offloading infrastructure: libgomp

[Ilya Verbin]

Hello,

This patch adds plugin support to libgomp, as well as memory mapping and
interaction with target devices through plugin's interface.

Bootstrapped and regtested on top of patch 4.  Is it OK for trunk?

Thanks,
  -- Ilya


2014-10-06  Jakub Jelinek  
Ilya Verbin  
Thomas Schwinge  
Andrey Turetskiy  

libgomp/
* libgomp.map (GOMP_4.0.1): New symbol version.
Add GOMP_offload_register.
* libgomp_target.h: New file.
* splay-tree.h: New file.
* target.c: Include config.h, libgomp_target.h, dlfcn.h, splay-tree.h.
(gomp_target_init): New forward declaration.
(gomp_is_initialized): New static variable.
(splay_tree_node, splay_tree, splay_tree_key): New typedefs.
(struct target_mem_desc, struct splay_tree_key_s, offload_image_descr):
New structures.
(offload_images, num_offload_images, devices, num_devices): New static
variables.
(splay_compare): New static function.
(struct gomp_device_descr): New structure.
(gomp_get_num_devices): Call gomp_target_init.
(resolve_device, gomp_map_vars_existing, gomp_map_vars, gomp_unmap_tgt)
(gomp_unmap_vars, gomp_update, gomp_init_device): New static functions.
(GOMP_offload_register): New function.
(GOMP_target): Arrange for host callback to be performed in a separate
initial thread and contention group, inheriting ICVs from
gomp_global_icv etc.  Call gomp_map_vars and gomp_unmap_vars.
Add device initialization and lookup for target function in splay tree.
(GOMP_target_data): Add device initialization and call gomp_map_vars.
(GOMP_target_end_data): Call gomp_unmap_vars.
(GOMP_target_update): Add device initialization and call gomp_update.
(gomp_load_plugin_for_device, gomp_register_images_for_device)
(gomp_target_init): New static functions.

---

diff --git a/libgomp/libgomp.map b/libgomp/libgomp.map
index b102fd8..f36df23 100644
--- a/libgomp/libgomp.map
+++ b/libgomp/libgomp.map
@@ -227,3 +227,8 @@ GOMP_4.0 {
GOMP_target_update;
GOMP_teams;
 } GOMP_3.0;
+
+GOMP_4.0.1 {
+  global:
+   GOMP_offload_register;
+} GOMP_4.0;
diff --git a/libgomp/libgomp_target.h b/libgomp/libgomp_target.h
new file mode 100644
index 000..f7d19d0
--- /dev/null
+++ b/libgomp/libgomp_target.h
@@ -0,0 +1,44 @@
+/* Copyright (C) 2014 Free Software Foundation, Inc.
+
+   This file is part of the GNU OpenMP Library (libgomp).
+
+   Libgomp is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   Libgomp 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 General Public License for
+   more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+#ifndef LIBGOMP_TARGET_H
+#define LIBGOMP_TARGET_H 1
+
+/* Type of offload target device.  */
+enum offload_target_type
+{
+  OFFLOAD_TARGET_TYPE_HOST,
+  OFFLOAD_TARGET_TYPE_INTEL_MIC
+};
+
+/* Auxiliary struct, used for transferring a host-target address range mapping
+   from plugin to libgomp.  */
+struct mapping_table
+{
+  uintptr_t host_start;
+  uintptr_t host_end;
+  uintptr_t tgt_start;
+  uintptr_t tgt_end;
+};
+
+#endif /* LIBGOMP_TARGET_H */
diff --git a/libgomp/splay-tree.h b/libgomp/splay-tree.h
new file mode 100644
index 000..eb8011a
--- /dev/null
+++ b/libgomp/splay-tree.h
@@ -0,0 +1,232 @@
+/* A splay-tree datatype.
+   Copyright 1998-2014
+   Free Software Foundation, Inc.
+   Contributed by Mark Mitchell (m...@markmitchell.com).
+
+   This file is part of the GNU OpenMP Library (libgomp).
+
+   Libgomp is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   Libgomp 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 General Public License for
+   more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+

RE: [RFC: Patch, PR 60102] [4.9/4.10 Regression] powerpc fp-bit ices@dwf_regno

[rohitarul...@freescale.com]

> From: Dharmakan Rohit-B30502
> Sent: Monday, September 29, 2014 3:54 PM
> 
> > From: Ulrich Weigand [mailto:uweig...@de.ibm.com] Maciej W. Rozycki
> > wrote:
> > > On Mon, 4 Aug 2014, Edmar wrote:
> > >
> > > > Committed on trunk, revision 213596 Committed on 4.9 branch,
> > > > revision 213597
> > >
> > >  This change regressed GDB for e500v2 multilibs, presumably because
> > > it does not understand the new DWARF register numbers and does not
> > > know how to map them to hardware registers.
> >
> > As I understand it, the change was supposed to only affect GCC
> > internals, all externally generated debug info was supposed to remain
> unchanged.
> >
> > If there are changes in debug info, something must have gone wrong.
> 
> Let me check if I can track this down.

Maciej/Ulrich,

I was able to narrow down the issue.

Debug info generated with the current patch:
<2><334>: Abbrev Number: 10 (DW_TAG_formal_parameter)
<335>   DW_AT_name: u   
<337>   DW_AT_decl_file   : 1   
<338>   DW_AT_decl_line   : 51  
<339>   DW_AT_type: <0x357> 
<33d>   DW_AT_location: 7 byte block: 90 7d 93 4 58 93 4
(DW_OP_regx: 125 (r125); DW_OP_piece: 4; DW_OP_reg8 (r8); DW_OP_piece: 4)

Expected debug info:
<2><334>: Abbrev Number: 10 (DW_TAG_formal_parameter)
<335>   DW_AT_name: u   
<337>   DW_AT_decl_file   : 1   
<338>   DW_AT_decl_line   : 51  
<339>   DW_AT_type: <0x359> 
<33d>   DW_AT_location: 8 byte block: 90 b8 9 93 4 58 93 4  
(DW_OP_regx: 1208 (r1208); DW_OP_piece: 4; DW_OP_reg8 (r8); DW_OP_piece: 4)

While emitting the location descriptors of multiple registers (SPE high/low 
part) individually, the GCC hard register number is converted in to DWARF 
register number using "dbx_reg_number" [Statement "A",  "B" & "C" below].

File1: gcc-4.9/gcc/config/rs6000/rs6000.h
=

...
/* Use standard DWARF numbering for DWARF debugging information.  */
#define DBX_REGISTER_NUMBER(REGNO) rs6000_dbx_register_number (REGNO)   
-(A)
...


File2: gcc-4.9/gcc/dwarf2out.c
=

/* Given an RTL of a register, return a location descriptor that
   designates a value that spans more than one register.  */

static dw_loc_descr_ref
multiple_reg_loc_descriptor (rtx rtl, rtx regs,
 enum var_init_status initialized)
{

...
  /* Now onto stupid register sets in non contiguous locations.  */


  for (i = 0; i < XVECLEN (regs, 0); ++i)
{
  dw_loc_descr_ref t;
  t = one_reg_loc_descriptor (dbx_reg_number (XVECEXP (regs, 0, i)),  
VAR_INIT_STATUS_INITIALIZED); ---(B)
  ...

}
.
  
}
static unsigned int
dbx_reg_number (const_rtx rtl)
{
 
 
  regno = DBX_REGISTER_NUMBER (regno);  
-(C)
  gcc_assert (regno != INVALID_REGNUM);
  return regno;
}

File3:gcc-4.9/gcc/config/rs6000/sysv4.h
===

/* This target uses the sysv4.opt file.  */
#define TARGET_USES_SYSV4_OPT 1

#undef DBX_REGISTER_NUMBER  
--(D)


But statement "C" macro "DBX_REGISTER_NUMBER" gets undefined by statement "D" 
hence the GCC hard register number gets emitted in the debug info instead of 
DWARF register number.
Previously, without this patch for SPE high registers the GCC hard register 
number was same as the DWARF register number (1200 onwards), hence we didn't 
see this issue.

Removing statement "D"  from "sysv4.h" file so as to generate expected DWARF 
register number does work, but will there be any side effects?

Regards,
Rohit

Re: [RFC PATCH] Enable V32HI/V64QI const permutations

[Jakub Jelinek]

On Mon, Oct 06, 2014 at 06:09:07PM +0400, Ilya Tocar wrote:
> > Speaking of -mavx512{bw,vl,f}, there apparently is a full 2 operand shuffle
> > for V32HI, V16S[IF], V8D[IF], so the only one instruction full
> > 2 operand shuffle we are missing is V64QI, right?
> > 
> > What would be best worst case sequence for that?
> > 
> > I'd think 2x vpermi2w, 2x vpshufb and one vpor could achieve that,
> > (first vpermi2w would put the even bytes into the right word positions
> > (i.e. at the right position or one above it), second vpermi2w would put
> > the odd bytes into the right word positions (i.e. at the right position
> > or one below it),
> I think we will also need to spend insns converting byte-sized mask into
> word-sized mask.

I'm talking about the constant permutations here (see my other mail to
Kirill).  In that case, you can tweak the mask as much as you want.

I mean something like (completely untested, would need a separate function):

  if (TARGET_AVX512BW && d->vmode == V64QImode)
;
  else
return false;

  /* We can emit arbitrary two operand V64QImode permutations
 with 2 vpermi2w, 2 vpshufb and one vpor instruction.  */
  if (d->testing_p)
return true;

  struct expand_vec_perm_d ds[2];
  rtx rperm[128], vperm, target0, target1;
  for (i = 0; i < 2; i++)
{
  ds[i] = *d;
  ds[i].vmode = V32HImode;
  ds[i].nelt = 32;
  ds[i].target = gen_reg_rtx (V32HImode);
  ds[i].op0 = gen_lowpart (V32HImode, d->op0);
  ds[i].op1 = gen_lowpart (V32HImode, d->op1);
}
  /* Prepare permutations such that the first one takes care of
 putting the even bytes into the right positions or one higher
 positions (ds[0]) and the second one takes care of
 putting the odd bytes into the right positions or one below
 (ds[1]).  
 
  for (i = 0; i < nelt; i++)
{
  ds[i & 1].perm[i / 2] = d->perm[i] / 2;
  if (i & 1)
{
  rperm[i] = constm1_rtx;
  rperm[i + 64] = GEN_INT ((i & 14) + 1 - (d->perm[i] & 1));
}
  else
{
  rperm[i] = GEN_INT ((i & 14) + (d->perm[i] & 1));
  rperm[i + 64] = constm1_rtx;
}
}

  bool ok = expand_vec_perm_1 (&ds[0]);
  gcc_assert (ok);
  ds[0].target = gen_lowpart (V64QImode, ds[0].target);

  ok = expand_vec_perm_1 (&ds[1]);
  gcc_assert (ok);
  ds[1].target = gen_lowpart (V64QImode, ds[1].target);

  vperm = gen_rtx_CONST_VECTOR (V64QImode, gen_rtvec_v (64, rperm));
  vperm = force_reg (vmode, vperm);
  target0 = gen_reg_rtx (V64QImode);
  emit_insn (gen_avx512bw_pshufbv64qi3 (target0, ds[0].target, vperm));

  vperm = gen_rtx_CONST_VECTOR (V64QImode, gen_rtvec_v (64, rperm + 64));
  vperm = force_reg (vmode, vperm);
  target1 = gen_reg_rtx (V64QImode);
  emit_insn (gen_avx512bw_pshufbv64qi3 (target1, ds[1].target, vperm));

  emit_insn (gen_iorv64qi3 (d->target, target0, target1));

Jakub

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/6/14 22:59, Andrew Haley wrote:
> On 10/06/2014 04:00 PM, Chen Gang wrote:
>> On 10/6/14 22:28, Andrew Haley wrote:
[...]
>>> The testsuite isn't breaking: it's telling you something useful.
>>>
>>
>> Sorry it is breaked, at present, I temporarily skipped it and then can
>> let "make check" finish, the related temporarily skip diff may like
>> below (in real action, I modify the related Makefile, directly):
> 
> You're missing what I'm saying.  The testuite is not broken.
> 
> You should be running "make -k check".
> 

For me, "make -k check" is suitable for one sub-system (e.g. for cross
building, and mainly focus on gcc), but not for global check (full
non-cross building check):

 - "make check" is the standard check for global, so when find new
   issues (include environment construction), need stop in time.

 - If one sub-system wants to skip the known issue, it can mark it as
   'unexpected', or just simply return 0 to Makefile to let checking
   continue (I guess, most of other sub-system do in this way).

 - Or for other members (especially for newbies, e.g. me), he/she can
   not sure whether the environment construction for testsuite is OK or
   not:

 e.g. For our case, after build upstream glibc and let testsuite use
 it instead of Darwin glibc, all things may go OK. If really it is,
 it is environments construction (not testsuite or code) issue.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Andrew Haley]

On 10/06/2014 04:00 PM, Chen Gang wrote:
> On 10/6/14 22:28, Andrew Haley wrote:
>> On 10/06/2014 03:27 PM, Chen Gang wrote:
>>> On 10/6/14 21:54, Andrew Haley wrote:
 On 10/06/2014 02:53 PM, Chen Gang wrote:
> On 10/6/14 16:37, Andrew Haley wrote:
>> On 06/10/14 05:08, Chen Gang wrote:
>>> After try normal configure, get almost the same result, I guess, our
>>> testsuite under Darwin x86_64 is OK.
>>>
>>> If no any additional reply within a week, I shall continue to try to
>>> analyze the libjava Throw_2 issue.
>>
>> Throw_2 is a test specially contrived to detect segfaults that are
>> not being correctly detected and turned into NullPointerException()s.
>> A failure indicates that the segfault signal handler is broken.
>
> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
> and after run it without any parameters, "1" is printed, but "2" is not
> printed.
>
> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>
> And I shall continue to try to analyze it (within this month), and 
> welcome any additional ideas, suggestions, and completion for it, 

 Not every platform supports unwinding through signal handlers.  In x86
 Linux there is some very clever code which interacts with the kernel to
 allow this.
>>>
>>> Excuse me, I am not quite familiar with Java, I guess what you said is:
>>>
>>>  - The related feature need OS kernel support, if OS kernel does not
>>>support, it may report "Abort trap: 6" or others.
>>>
>>>  - And OS kernel has feature to support "1" printed does not mean it
>>>also has feature to support "2" printed.
>>>
>>>  - And I need try to make sure that my current Darwin kernel whether
>>>supports it or not.
>>>
>>> If what I guess is incorrect, please let me know, thanks.
>>
>> That sounds approximately right, but it's changed a lot since I last
>> looked.  It may be that the magic is in glibc rather than the kernel.
>>
> 
> OK, thanks, I shall also notice about glibc when I try to analyze it,
> e.g. need try to build and install upstream glibc instead of the Darwin
> glibc (I am not quite sure whether I can do that, I guess I can).
> 
>  
>>> For me, whether Darwin kernel supports or not, we have to improve
>>> current implementation (may be testsuite configure or Makefile) to
>>> avoid testsuite breaking.
>>
>> The testsuite isn't breaking: it's telling you something useful.
>>
> 
> Sorry it is breaked, at present, I temporarily skipped it and then can
> let "make check" finish, the related temporarily skip diff may like
> below (in real action, I modify the related Makefile, directly):

You're missing what I'm saying.  The testuite is not broken.

You should be running "make -k check".

Andrew.

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/6/14 22:28, Andrew Haley wrote:
> On 10/06/2014 03:27 PM, Chen Gang wrote:
>> On 10/6/14 21:54, Andrew Haley wrote:
>>> On 10/06/2014 02:53 PM, Chen Gang wrote:
 On 10/6/14 16:37, Andrew Haley wrote:
> On 06/10/14 05:08, Chen Gang wrote:
>> After try normal configure, get almost the same result, I guess, our
>> testsuite under Darwin x86_64 is OK.
>>
>> If no any additional reply within a week, I shall continue to try to
>> analyze the libjava Throw_2 issue.
>
> Throw_2 is a test specially contrived to detect segfaults that are
> not being correctly detected and turned into NullPointerException()s.
> A failure indicates that the segfault signal handler is broken.

 OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
 and after run it without any parameters, "1" is printed, but "2" is not
 printed.

 Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
 but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
 code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".

 And I shall continue to try to analyze it (within this month), and 
 welcome any additional ideas, suggestions, and completion for it, 
>>>
>>> Not every platform supports unwinding through signal handlers.  In x86
>>> Linux there is some very clever code which interacts with the kernel to
>>> allow this.
>>
>> Excuse me, I am not quite familiar with Java, I guess what you said is:
>>
>>  - The related feature need OS kernel support, if OS kernel does not
>>support, it may report "Abort trap: 6" or others.
>>
>>  - And OS kernel has feature to support "1" printed does not mean it
>>also has feature to support "2" printed.
>>
>>  - And I need try to make sure that my current Darwin kernel whether
>>supports it or not.
>>
>> If what I guess is incorrect, please let me know, thanks.
> 
> That sounds approximately right, but it's changed a lot since I last
> looked.  It may be that the magic is in glibc rather than the kernel.
>

OK, thanks, I shall also notice about glibc when I try to analyze it,
e.g. need try to build and install upstream glibc instead of the Darwin
glibc (I am not quite sure whether I can do that, I guess I can).

 
>> For me, whether Darwin kernel supports or not, we have to improve
>> current implementation (may be testsuite configure or Makefile) to
>> avoid testsuite breaking.
> 
> The testsuite isn't breaking: it's telling you something useful.
> 

Sorry it is breaked, at present, I temporarily skipped it and then can
let "make check" finish, the related temporarily skip diff may like
below (in real action, I modify the related Makefile, directly):

diff --git a/libjava/testsuite/Makefile.in b/libjava/testsuite/Makefile.in
index 28fc102..d1e77de 100644
--- a/libjava/testsuite/Makefile.in
+++ b/libjava/testsuite/Makefile.in
@@ -390,7 +390,7 @@ check-DEJAGNU: site.exp
if $(SHELL) -c "$$runtest --version" > /dev/null 2>&1; then \
  exit_status=0; l='$(DEJATOOL)'; for tool in $$l; do \
if $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS) 
$(RUNTESTFLAGS); \
-   then :; else exit_status=1; fi; \
+   then :; else exit_status=0; fi; \
  done; \
else echo "WARNING: could not find \`runtest'" 1>&2; :;\
fi; \
ba

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH, rs6000] Document issues with permutes for analyze_swaps

[David Edelsohn]

On Sun, Oct 5, 2014 at 6:06 PM, Bill Schmidt
 wrote:
> Hi,
>
> I spent some time thinking about handling vperm instructions in the
> analyze_swaps pass, and convinced myself that it isn't necessarily wise
> to do so.  At the least it will require adding a cost model to the pass
> to determine whether a computation involving permutes should be
> optimized.
>
> At this time I don't intend to implement this, but I want to record the
> information about how it could be done should it be deemed necessary.
> So this patch just adds a few paragraphs of documentation about the
> issue.  No change in behavior intended.
>
> I've ensured that rs6000.c still compiles successfully on
> powerpc64le-unknown-linux-gnu.  Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> 2014-10-05  Bill Schmidt  
>
> * config/rs6000/rs6000.c (analyze_swaps commentary): Add
> discussion of permutes and why we don't handle them.

Great!

Thanks, David

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Andrew Haley]

On 10/06/2014 03:27 PM, Chen Gang wrote:
> On 10/6/14 21:54, Andrew Haley wrote:
>> On 10/06/2014 02:53 PM, Chen Gang wrote:
>>> On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
> After try normal configure, get almost the same result, I guess, our
> testsuite under Darwin x86_64 is OK.
>
> If no any additional reply within a week, I shall continue to try to
> analyze the libjava Throw_2 issue.

 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.
>>>
>>> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
>>> and after run it without any parameters, "1" is printed, but "2" is not
>>> printed.
>>>
>>> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
>>> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
>>> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>>>
>>> And I shall continue to try to analyze it (within this month), and 
>>> welcome any additional ideas, suggestions, and completion for it, 
>>
>> Not every platform supports unwinding through signal handlers.  In x86
>> Linux there is some very clever code which interacts with the kernel to
>> allow this.
> 
> Excuse me, I am not quite familiar with Java, I guess what you said is:
> 
>  - The related feature need OS kernel support, if OS kernel does not
>support, it may report "Abort trap: 6" or others.
> 
>  - And OS kernel has feature to support "1" printed does not mean it
>also has feature to support "2" printed.
> 
>  - And I need try to make sure that my current Darwin kernel whether
>supports it or not.
> 
> If what I guess is incorrect, please let me know, thanks.

That sounds approximately right, but it's changed a lot since I last
looked.  It may be that the magic is in glibc rather than the kernel.

> For me, whether Darwin kernel supports or not, we have to improve
> current implementation (may be testsuite configure or Makefile) to
> avoid testsuite breaking.

The testsuite isn't breaking: it's telling you something useful.

Andrew.

Re: [gofrontend-dev] [PATCH 5/9] Gccgo port to s390[x] -- part I

[Ian Lance Taylor]

On Mon, Oct 6, 2014 at 12:42 AM, Dominik Vogt  wrote:
>
> On s390[x] the symbol value of a section symbol is definitely not
> zero.

Is true even in an object file?  I agree that in an executable a
section symbol will have a non-zero value, but that case doesn't arise
since an executable won't have (non-dynamic) relocations.  But I'm
quite surprised that hear that the section symbol would be non-zero in
an object file.

Ian

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/6/14 21:54, Andrew Haley wrote:
> On 10/06/2014 02:53 PM, Chen Gang wrote:
>> On 10/6/14 16:37, Andrew Haley wrote:
>>> On 06/10/14 05:08, Chen Gang wrote:
 After try normal configure, get almost the same result, I guess, our
 testsuite under Darwin x86_64 is OK.

 If no any additional reply within a week, I shall continue to try to
 analyze the libjava Throw_2 issue.
>>>
>>> Throw_2 is a test specially contrived to detect segfaults that are
>>> not being correctly detected and turned into NullPointerException()s.
>>> A failure indicates that the segfault signal handler is broken.
>>
>> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
>> and after run it without any parameters, "1" is printed, but "2" is not
>> printed.
>>
>> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
>> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
>> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>>
>> And I shall continue to try to analyze it (within this month), and 
>> welcome any additional ideas, suggestions, and completion for it, 
> 
> Not every platform supports unwinding through signal handlers.  In x86
> Linux there is some very clever code which interacts with the kernel to
> allow this.
> 

Excuse me, I am not quite familiar with Java, I guess what you said is:

 - The related feature need OS kernel support, if OS kernel does not
   support, it may report "Abort trap: 6" or others.

 - And OS kernel has feature to support "1" printed does not mean it
   also has feature to support "2" printed.

 - And I need try to make sure that my current Darwin kernel whether
   supports it or not.

If what I guess is incorrect, please let me know, thanks.

For me, whether Darwin kernel supports or not, we have to improve
current implementation (may be testsuite configure or Makefile) to
avoid testsuite breaking.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH i386 AVX512] [63/n] Add vpshufb, perm autogen.

[Jakub Jelinek]

On Mon, Oct 06, 2014 at 04:55:28PM +0400, Kirill Yukhin wrote:
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -21364,20 +21364,113 @@ ix86_expand_vec_perm_vpermi2 (rtx target, rtx op0, 
> rtx mask, rtx op1)
>enum machine_mode mode = GET_MODE (op0);
>switch (mode)
>  {
> +  /* There is no byte version of vpermi2.  So we use vpermi2w.  */
> +case V64QImode:
> +  if (!TARGET_AVX512BW)
> + return false;
> +  rtx mask_lowpart, op0_lowpart, op1_lowpart;
> +  rtx perm_lo, perm_hi, tmp, res_lo, tmp2, res_hi;
> +
> +  mask_lowpart = gen_lowpart (V32HImode, force_reg (V64QImode, mask));
> +  op0_lowpart = gen_lowpart (V32HImode, op0);
> +  op1_lowpart = gen_lowpart (V32HImode, op1);
> +  tmp = gen_reg_rtx (V32HImode);
> +  tmp2 = gen_reg_rtx (V32HImode);
> +  perm_lo = gen_reg_rtx (V32HImode);
> +  perm_hi = gen_reg_rtx (V32HImode);
> +  res_lo = gen_reg_rtx (V32HImode);
> +  res_hi = gen_reg_rtx (V32HImode);
> +
> +  emit_insn (gen_ashlv32hi3 (tmp, mask_lowpart, GEN_INT (8)));
> +  emit_insn (gen_ashrv32hi3 (perm_lo, tmp, GEN_INT (9)));
> +  emit_insn (gen_ashrv32hi3 (perm_hi, mask_lowpart, GEN_INT (9)));
> +  emit_insn (gen_avx512bw_vpermi2varv32hi3 (res_lo, op0_lowpart,
> + perm_lo, op1_lowpart));
> +  emit_insn (gen_avx512bw_vpermi2varv32hi3 (tmp2, op0_lowpart,
> + perm_hi, op1_lowpart));
> +  emit_insn (gen_ashlv32hi3 (res_hi, tmp2, GEN_INT (8)));
> +  emit_insn (gen_avx512bw_blendmv64qi (target, gen_lowpart (V64QImode, 
> res_lo),
> +gen_lowpart (V64QImode, res_hi),
> +force_reg (DImode, GEN_INT 
> (0xLL;
> +  return true;

I believe this case doesn't belong to this function, other than this
case ix86_expand_vec_perm_vpermi2 emits always just a single insn, and
so it should always do that, and there should be a separate function
that expands the worst case of V64QImode full 2 operand permutation.
See my previous mail, IMHO it is doable with 5 instructions rather than 7.
And IMHO we should have a separate function which emits that, supposedly
one for the constant permutations, one for the variable case (perhaps
then your 7 insn sequence is best?).

Also, IMHO rather than building a CONST_VECTOR ahead in each of the callers,
supposedly ix86_expand_vec_perm_vpermi2 could take the arguments it takes
right now plus D, either D would be NULL (then it would behave as now), or
SEL would be NULL, then it would create a CONST_VECTOR on the fly if needed.
I.e. the function would start with a switch that would just contain the
if (...)
return false; 
hunks plus break; for the success case, then code to generate CONST_VECTOR
if sel is NULL_RTX from d, and finally another switch with just the emit
cases.  Or, the first switch could just set a function pointer before
break, and just use one common
emit_insn (gen (target, op0, force_reg (vmode, mask), op1));

> +case V8HImode:
> +  if (!TARGET_AVX512VL)
> + return false;
> +  emit_insn (gen_avx512vl_vpermi2varv8hi3 (target, op0,
> +force_reg (V8HImode, mask), 
> op1));
> +  return true;
> +case V16HImode:
> +  if (!TARGET_AVX512VL)
> + return false;
> +  emit_insn (gen_avx512vl_vpermi2varv16hi3 (target, op0,
> +  force_reg (V16HImode, mask), op1));
> +  return true;

Aren't these two insns there only if both TARGET_AVX512VL && TARGET_AVX512BW?
I mean, the ISA pdf mentions both of the CPUID flags simultaneously, and I
think neither of these depends on the other one in GCC.  That's unlike insns
where CPUID AVX512VL and AVX512F are mentioned together, because in GCC
AVX512VL depends on AVX512F.

> @@ -42662,7 +42764,12 @@ expand_vec_perm_blend (struct expand_vec_perm_d *d)
>  
>if (d->one_operand_p)
>  return false;
> -  if (TARGET_AVX2 && GET_MODE_SIZE (vmode) == 32)
> +  if (TARGET_AVX512F && GET_MODE_SIZE (vmode) == 64 &&
> +  GET_MODE_SIZE (GET_MODE_INNER (vmode)) >= 4)

Formatting, && belongs on the second line.

> +;
> +  else if (TARGET_AVX512VL)

I'd add && GET_MODE_SIZE (GET_MODE_INNER (vmode) == 64 here.
AVX512VL is not going to handle 64-bit vectors, or 1024-bit ones,
and the == 32 and == 16 cases are handled because AVX512VL implies
TARGET_AVX2 and TARGET_SSE4_1, doesn't it?

> @@ -43012,6 +43125,17 @@ expand_vec_perm_pshufb (struct expand_vec_perm_d *d)
> return false;
>   }
>   }
> +  else if (GET_MODE_SIZE (d->vmode) == 64)
> + {
> +   if (!TARGET_AVX512BW)
> + return false;
> +   if (vmode == V64QImode)
> + {
> +   for (i = 0; i < nelt; ++i)
> + if ((d->perm[i] ^ i) & (nelt / 4))
> +   return false;

Missing comment, I'd duplicat

Re: [RFC PATCH] Enable V32HI/V64QI const permutations

[Ilya Tocar]

On 06 Oct 09:08, Jakub Jelinek wrote:
> On Fri, Oct 03, 2014 at 04:39:08PM +0200, Jakub Jelinek wrote:
> > Just to stress the new testcases some more, I've enabled the
> > vec_perm_const{32hi,64qi} patterns.
> > Got several ICEs in expand_vec_perm_broadcast_1,
> > on the final gcc_unreachable () in the function.  That function
> > is only called if it couldn't be broadcasted in a single insn,
> > which I believe for TARGET_AVX512BW must be always possible.
> > Shall I look at this, or do you plan to address this in the near future?
> 
> Speaking of -mavx512{bw,vl,f}, there apparently is a full 2 operand shuffle
> for V32HI, V16S[IF], V8D[IF], so the only one instruction full
> 2 operand shuffle we are missing is V64QI, right?
> 
> What would be best worst case sequence for that?
> 
> I'd think 2x vpermi2w, 2x vpshufb and one vpor could achieve that,
> (first vpermi2w would put the even bytes into the right word positions
> (i.e. at the right position or one above it), second vpermi2w would put
> the odd bytes into the right word positions (i.e. at the right position
> or one below it),
I think we will also need to spend insns converting byte-sized mask into
word-sized mask.
> each vpshufb would swap the byte pairs where necessary
> and zero out the other (odd or even) byte,
This will probably also require vpshufb mask preparation (setting high
bit for zeroing)
> and vpor merge the results), do you have something better?
Currently (in branch) it's implemented as  2x vpermi2w + 4x shift +
blend. 3 shifts to prepare masks for vpermi2w,
2 vpermi2w to put odd/even bytes in low part of right position,
shift to move low part into high part and finally blend with
101010.. mask to get a result.
> What about arbitrary one operand V64QI const permutation?
>
Currently it loads const-vector into register and uses the same codepath
as non-const version (this probably can be improved).

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Andrew Haley]

On 10/06/2014 02:53 PM, Chen Gang wrote:
> On 10/6/14 16:37, Andrew Haley wrote:
>> On 06/10/14 05:08, Chen Gang wrote:
>>> After try normal configure, get almost the same result, I guess, our
>>> testsuite under Darwin x86_64 is OK.
>>>
>>> If no any additional reply within a week, I shall continue to try to
>>> analyze the libjava Throw_2 issue.
>>
>> Throw_2 is a test specially contrived to detect segfaults that are
>> not being correctly detected and turned into NullPointerException()s.
>> A failure indicates that the segfault signal handler is broken.
> 
> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
> and after run it without any parameters, "1" is printed, but "2" is not
> printed.
> 
> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
> 
> And I shall continue to try to analyze it (within this month), and 
> welcome any additional ideas, suggestions, and completion for it, 

Not every platform supports unwinding through signal handlers.  In x86
Linux there is some very clever code which interacts with the kernel to
allow this.

Andrew.

Re: [C++ Patch] PR 55250

[Jason Merrill]

On 10/06/2014 04:56 AM, Paolo Carlini wrote:

+   && ! is_typedef_decl (var)
+   && ! TYPE_DECL_ALIAS_P (var))


Maybe "&& DECL_IMPLICIT_TYPEDEF_P (var)" instead of the above?  OK 
either way.


Jason

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/6/14 16:37, Andrew Haley wrote:
> On 06/10/14 05:08, Chen Gang wrote:
>> After try normal configure, get almost the same result, I guess, our
>> testsuite under Darwin x86_64 is OK.
>>
>> If no any additional reply within a week, I shall continue to try to
>> analyze the libjava Throw_2 issue.
> 
> Throw_2 is a test specially contrived to detect segfaults that are
> not being correctly detected and turned into NullPointerException()s.
> A failure indicates that the segfault signal handler is broken.
> 

OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
and after run it without any parameters, "1" is printed, but "2" is not
printed.

Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".

And I shall continue to try to analyze it (within this month), and 
welcome any additional ideas, suggestions, and completion for it, 


Thanks
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[PATCH] misc cleanup

[Marek Polacek]

This patch fixes some miscellaneous stuff in the testsuite.
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02656.html for more info.

Tested on x86_64-linux: vanilla results == results with this patch ==
results with this patch and gnu11 as a default.

Applying to trunk.

2014-10-06  Marek Polacek  

boehm-gc/
* testsuite/boehm-gc.c/gctest.c: Fix defaulting to int.
gcc/testsuite/
* c-c++-common/raw-string-3.c: Use -std=gnu89 for C.
* g++.dg/lto/pr54625-1_0.c: Fix defaulting to int.
* g++.dg/lto/pr54625-2_0.c: Likewise.
* gcc.misc-tests/gcov-14.c: Use -fgnu89-inline.

diff --git gcc/boehm-gc/testsuite/boehm-gc.c/gctest.c 
gcc/boehm-gc/testsuite/boehm-gc.c/gctest.c
index 1180ab1..cc03e96 100644
--- gcc/boehm-gc/testsuite/boehm-gc.c/gctest.c
+++ gcc/boehm-gc/testsuite/boehm-gc.c/gctest.c
@@ -1701,6 +1701,7 @@ int APIENTRY WinMain(HINSTANCE instance, HINSTANCE prev, 
LPSTR cmd, int n)
 
 
 #ifdef PCR
+int
 test()
 {
 PCR_Th_T * th1;
@@ -1738,6 +1739,7 @@ void * thr_run_one_test(void * arg)
 #endif
 
 #if defined(GC_SOLARIS_THREADS) && !defined(GC_SOLARIS_PTHREADS)
+int
 main()
 {
 thread_t th1;
@@ -1781,6 +1783,7 @@ main()
   --> bad news
 #endif
 
+int
 main()
 {
 pthread_t th1;
diff --git gcc/gcc/testsuite/c-c++-common/raw-string-3.c 
gcc/gcc/testsuite/c-c++-common/raw-string-3.c
index 1dde113..326e309 100644
--- gcc/gcc/testsuite/c-c++-common/raw-string-3.c
+++ gcc/gcc/testsuite/c-c++-common/raw-string-3.c
@@ -1,7 +1,7 @@
 // If not c++0x/gnu99, the {,u,u8,U,L}R prefix should be parsed as separate
 // token.
 // { dg-do compile }
-// { dg-options "" { target c } }
+// { dg-options "-std=gnu89" { target c } }
 // { dg-options "-std=c++98" { target c++ } }
 
 const void *s0 = R"(a)";   // { dg-error "was not 
declared|undeclared" "undeclared" }
diff --git gcc/gcc/testsuite/g++.dg/lto/pr54625-1_0.c 
gcc/gcc/testsuite/g++.dg/lto/pr54625-1_0.c
index 5ab90dd..48bbdf0 100644
--- gcc/gcc/testsuite/g++.dg/lto/pr54625-1_0.c
+++ gcc/gcc/testsuite/g++.dg/lto/pr54625-1_0.c
@@ -3,6 +3,7 @@
 
 float a;
 double sin ();
+void
 speex_resampler_init_frac ()
 {
   a = sin (0);
diff --git gcc/gcc/testsuite/g++.dg/lto/pr54625-2_0.c 
gcc/gcc/testsuite/g++.dg/lto/pr54625-2_0.c
index 6511ba5..3e67d4f 100644
--- gcc/gcc/testsuite/g++.dg/lto/pr54625-2_0.c
+++ gcc/gcc/testsuite/g++.dg/lto/pr54625-2_0.c
@@ -3,6 +3,7 @@
 
 float a;
 double sin ();
+void
 update_filter ()
 {
   a = sin (0);
diff --git gcc/gcc/testsuite/gcc.misc-tests/gcov-14.c 
gcc/gcc/testsuite/gcc.misc-tests/gcov-14.c
index de7ac0d..78dd7be 100644
--- gcc/gcc/testsuite/gcc.misc-tests/gcov-14.c
+++ gcc/gcc/testsuite/gcc.misc-tests/gcov-14.c
@@ -1,6 +1,6 @@
 /* Test gcov extern inline.  */
 
-/* { dg-options "-O2 -fprofile-arcs -ftest-coverage" } */
+/* { dg-options "-O2 -fprofile-arcs -ftest-coverage -fgnu89-inline" } */
 /* The following line arranges that Darwin has behavior like elf weak import.  
*/
 /* { dg-additional-options "-flat_namespace -undefined suppress" { target 
*-*-darwin* }  } */
 /* { dg-require-weak "" } */

Marek

[PATCH] gcc.target/i386/ cleanup

[Marek Polacek]

This patch is a cleanup of tests in gcc.target/i386/ directory.
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02656.html for more info.

Tested on x86_64-linux: vanilla results == results with this patch ==
results with this patch and gnu11 as a default.

Applying to trunk.

2014-10-06  Marek Polacek  

* gcc.target/i386/20040112-1.c: Fix defaulting to int.
* gcc.target/i386/avxfp-1.c: Likewise.
* gcc.target/i386/avxfp-2.c: Likewise.
* gcc.target/i386/cadd.c: Likewise.
* gcc.target/i386/cmov2.c: Likewise.
* gcc.target/i386/cmov3.c: Likewise.
* gcc.target/i386/cmov4.c: Likewise.
* gcc.target/i386/cold-attribute-1.c: Likewise.
* gcc.target/i386/cvt-1.c: Likewise.
* gcc.target/i386/fpcvt-1.c: Likewise.
* gcc.target/i386/fpcvt-2.c: Likewise.
* gcc.target/i386/fpcvt-3.c: Likewise.
* gcc.target/i386/local.c: Likewise.
* gcc.target/i386/memcpy-2.c: Likewise.
* gcc.target/i386/memcpy-3.c: Likewise.
* gcc.target/i386/memset-1.c: Likewise.
* gcc.target/i386/minmax-1.c: Likewise.
* gcc.target/i386/minmax-2.c: Likewise.
* gcc.target/i386/pr45352-2.c: Likewise.
* gcc.target/i386/pr46253.c: Likewise.
* gcc.target/i386/pr53623.c: Likewise.
* gcc.target/i386/pr60902.c: Likewise.
* gcc.target/i386/pr57003.c: Likewise.
* gcc.target/i386/sse-14.c: Likewise.
* gcc.target/i386/sse-19.c: Likewise.
* gcc.target/i386/sse-22.c: Likewise.
* gcc.target/i386/sse4a-extract.c: Likewise.
* gcc.target/i386/sse4a-insert.c: Likewise.
* gcc.target/i386/ssefp-1.c: Likewise.
* gcc.target/i386/ssefp-2.c: Likewise.
* gcc.target/i386/testimm-10.c: Likewise.
* gcc.target/i386/vectorize4-avx.c: Likewise.
* gcc.target/i386/980709-1.c: Fix implicit declarations.
* gcc.target/i386/avx-pr57233.c: Likewise.
* gcc.target/i386/avx2-pr57233.c: Likewise.
* gcc.target/i386/avx2-vpop-check.h: Likewise.
* gcc.target/i386/avx256-unaligned-load-7.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-7.c: Likewise.
* gcc.target/i386/crc32-4.c: Likewise.
* gcc.target/i386/pr20204.c: Likewise.
* gcc.target/i386/pr23570.c: Likewise.
* gcc.target/i386/pr26449-1.c: Likewise.
* gcc.target/i386/pr28839.c: Likewise.
* gcc.target/i386/pr37101.c: Likewise.
* gcc.target/i386/pr61923.c: Likewise.
* gcc.target/i386/shrink_wrap_1.c: Likewise.
* gcc.target/i386/sse2-pr57233.c: Likewise.
* gcc.target/i386/vect-abs-s16.c: Likewise.
* gcc.target/i386/vect-abs-s32.c: Likewise.
* gcc.target/i386/vect-abs-s8.c: Likewise.
* gcc.target/i386/xop-pr57233.c: Likewise.
* gcc.target/i386/xop-rotate2-vector.c: Likewise.
* gcc.target/i386/cold-attribute-2.c: Fix defaulting to int.  Fix
implicit declarations.
* gcc.target/i386/xop-shift1-vector.c: Fix typo.
* gcc.target/i386/xop-shift2-vector.c: Likewise.
* gcc.target/i386/xop-shift3-vector.c: Likewise.

diff --git gcc/gcc/testsuite/gcc.target/i386/20040112-1.c 
gcc/gcc/testsuite/gcc.target/i386/20040112-1.c
index 168fd2f..9dd0989 100644
--- gcc/gcc/testsuite/gcc.target/i386/20040112-1.c
+++ gcc/gcc/testsuite/gcc.target/i386/20040112-1.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-final { scan-assembler "testb" } } */
+void
 ftn (char *sp)
 {
   char status;
diff --git gcc/gcc/testsuite/gcc.target/i386/980709-1.c 
gcc/gcc/testsuite/gcc.target/i386/980709-1.c
index 595b7cb..dcc873f 100644
--- gcc/gcc/testsuite/gcc.target/i386/980709-1.c
+++ gcc/gcc/testsuite/gcc.target/i386/980709-1.c
@@ -13,6 +13,7 @@ extern __inline__ int test_and_set_bit(int nr, volatile void 
* addr)
 struct buffer_head {
unsigned long b_state;   
 };
+void __wait_on_buffer (struct buffer_head *);
 extern void lock_buffer(struct buffer_head * bh)
 {
while (test_and_set_bit(2 , &bh->b_state))
diff --git gcc/gcc/testsuite/gcc.target/i386/avx-pr57233.c 
gcc/gcc/testsuite/gcc.target/i386/avx-pr57233.c
index ffc71d9..1363495 100644
--- gcc/gcc/testsuite/gcc.target/i386/avx-pr57233.c
+++ gcc/gcc/testsuite/gcc.target/i386/avx-pr57233.c
@@ -4,6 +4,8 @@
 
 #include "avx-check.h"
 
+int do_main (void);
+
 static void
 avx_test (void)
 {
diff --git gcc/gcc/testsuite/gcc.target/i386/avx2-pr57233.c 
gcc/gcc/testsuite/gcc.target/i386/avx2-pr57233.c
index 3fb2608..e0c8b96 100644
--- gcc/gcc/testsuite/gcc.target/i386/avx2-pr57233.c
+++ gcc/gcc/testsuite/gcc.target/i386/avx2-pr57233.c
@@ -4,6 +4,8 @@
 
 #include "avx2-check.h"
 
+int do_main (void);
+
 static void
 avx2_test (void)
 {
diff --git gcc/gcc/testsuite/gcc.target/i386/avx2-vpop-check.h 
gcc/gcc/testsuite/gcc.target/i386/avx2-vpop-check.h
index 204b11c..c590940 100644
--- gcc/gcc/testsuite/gcc.target/i386/avx2-vpop-check.

Re: RFA: Merge definitions of get_some_local_dynamic_name

[Rainer Orth]

Hi Richard,

> Rainer Orth  writes:
>> Hi Richard,
 It seems the new get_some_local_dynamic_name implementation in
 function.c lost the non-NULL check the sparc.c version had.  I'm
 currently testing the following patch:
>>>
>>> Could you do a:
>>>
>>>   call debug_rtx (...)
>>>
>>> on the insn that contains a null pointer?  Normally insn patterns
>>> shouldn't contain nulls, so I was wondering whether this was some
>>> SPARC-specific construct.
>>
>> proved a bit difficult to do: at the default -O2, insn was optimized
>> away, at -g3 -O0, I only got
>>
>> can't compute CFA for this frame
>>
>> with gdb 7.8 even after recompiling all of the gcc dir with -g3 -O0.
>>
>> Here's what I find after inserting the call in the source:
>>
>> (insn 30 6 28 (sequence [
>> (call_insn:TI 8 6 7 (parallel [
>> (set (reg:SI 8 %o0)
>> (call (mem:SI (unspec:SI [
>> (symbol_ref:SI 
>> ("__tls_get_addr"))
>> ] UNSPEC_TLSLDM) [0  S4 A32])
>> (const_int 1 [0x1])))
>> (clobber (reg:SI 15 %o7))
>> ]) /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:936 
>> 390 {tldm_call32}
>>  (expr_list:REG_EH_REGION (const_int -2147483648 
>> [0x8000])
>> (nil))
>> (expr_list (use (reg:SI 8 %o0))
>> (nil)))
>> (insn 7 8 28 (set (reg:SI 8 %o0)
>> (plus:SI (reg:SI 23 %l7)
>> (unspec:SI [
>> (reg:SI 8 %o0 [112])
>> ] UNSPEC_TLSLDM))) 388 {tldm_add32}
>>  (nil))
>> ]) /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:936 -1
>>  (nil))
>
> Bah, a sequence.  Hadn't thought of that.
>
> IMO it's a bug for a walk on a PATTERN to pull in non-PATTERN parts
> of an insn.  We should really be looking at the patterns of the two
> subinsns instead and ignore the other stuff.  Let me have a think
> about it.

did you come to a conclusion here?

> Now that we know the underlying cause, I personally wouldn't mind the
> null check being committed as a workaround.  If you do though, please
> could you add a comment saying that this is for SEQUENCEs?

I've had the following in my local tree for some weeks now to keep SPARC
bootstrap working:

2014-10-06  Rainer Orth  

* final.c (get_some_local_dynamic_name): Guard against NULL
const_rtx.

# HG changeset patch
# Parent 5768379d027521837a7be746630c3f53cc5bce83
Fix SPARC bootstrap: get_some_local_dynamic_name

diff --git a/gcc/final.c b/gcc/final.c
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -1739,7 +1739,8 @@ get_some_local_dynamic_name ()
   FOR_EACH_SUBRTX (iter, array, PATTERN (insn), ALL)
 	{
 	  const_rtx x = *iter;
-	  if (GET_CODE (x) == SYMBOL_REF)
+	  /* NULL check to guard against SEQUENCEs.  */
+	  if (x && GET_CODE (x) == SYMBOL_REF)
 	{
 	  if (SYMBOL_REF_TLS_MODEL (x) == TLS_MODEL_LOCAL_DYNAMIC)
 		return some_local_dynamic_name = XSTR (x, 0);

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[PATCH i386 AVX512] [63/n] Add vpshufb, perm autogen.

[Kirill Yukhin]

Hello,
This patch extends permutations for AVX-512*.
Comments are welcome!

Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
* config/i386/i386.c
(ix86_expand_vec_perm_vpermi2): Handle V64QImode, V8HImode, V16HImode,
V32HImode, V4SImode, V8SImode, V4SFmode, V8SFmode, V2DImode, V4DImode,
V2DFmode, V4DFmode.
(ix86_expand_sse_unpack): Handle V64QImode.
(expand_vec_perm_blend): Update conditions for TARGET, handle
V8DFmode, V16SFmode, V32HImode, V64QImode, V16SImode, V8DImode.
(expand_vec_perm_pshufb): Handle V64QImode.
(expand_vec_perm_1): Handle V64QImode, V32HImode, V16SImode, V16SFmode,
V8DFmode, V8DImode, V4DFmode, V2DFmode, V8SFmode, V4SFmode.
(ix86_expand_vec_perm_const_1): Call  ix86_expand_vec_perm_vpermi2.
(ix86_vectorize_vec_perm_const_ok): Handle V32HImode, V64QImode.
(ix86_expand_vecop_qihi): Handle V64QImode.
* config/i386/sse.md
(define_mode_iterator VI1_AVX2): Add V64QI mode.
(define_mode_iterator VEC_PERM_AVX2): Add V32HI mode.
(define_mode_iterator VEC_PERM_CONST): Add V64QI and V32HI mode.
(define_insn "_pshufb3"): Add masking.

--
Thanks, K

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 352ab81..d759a45 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -21364,20 +21364,113 @@ ix86_expand_vec_perm_vpermi2 (rtx target, rtx op0, 
rtx mask, rtx op1)
   enum machine_mode mode = GET_MODE (op0);
   switch (mode)
 {
+  /* There is no byte version of vpermi2.  So we use vpermi2w.  */
+case V64QImode:
+  if (!TARGET_AVX512BW)
+   return false;
+  rtx mask_lowpart, op0_lowpart, op1_lowpart;
+  rtx perm_lo, perm_hi, tmp, res_lo, tmp2, res_hi;
+
+  mask_lowpart = gen_lowpart (V32HImode, force_reg (V64QImode, mask));
+  op0_lowpart = gen_lowpart (V32HImode, op0);
+  op1_lowpart = gen_lowpart (V32HImode, op1);
+  tmp = gen_reg_rtx (V32HImode);
+  tmp2 = gen_reg_rtx (V32HImode);
+  perm_lo = gen_reg_rtx (V32HImode);
+  perm_hi = gen_reg_rtx (V32HImode);
+  res_lo = gen_reg_rtx (V32HImode);
+  res_hi = gen_reg_rtx (V32HImode);
+
+  emit_insn (gen_ashlv32hi3 (tmp, mask_lowpart, GEN_INT (8)));
+  emit_insn (gen_ashrv32hi3 (perm_lo, tmp, GEN_INT (9)));
+  emit_insn (gen_ashrv32hi3 (perm_hi, mask_lowpart, GEN_INT (9)));
+  emit_insn (gen_avx512bw_vpermi2varv32hi3 (res_lo, op0_lowpart,
+   perm_lo, op1_lowpart));
+  emit_insn (gen_avx512bw_vpermi2varv32hi3 (tmp2, op0_lowpart,
+   perm_hi, op1_lowpart));
+  emit_insn (gen_ashlv32hi3 (res_hi, tmp2, GEN_INT (8)));
+  emit_insn (gen_avx512bw_blendmv64qi (target, gen_lowpart (V64QImode, 
res_lo),
+  gen_lowpart (V64QImode, res_hi),
+  force_reg (DImode, GEN_INT 
(0xLL;
+  return true;
+case V8HImode:
+  if (!TARGET_AVX512VL)
+   return false;
+  emit_insn (gen_avx512vl_vpermi2varv8hi3 (target, op0,
+  force_reg (V8HImode, mask), 
op1));
+  return true;
+case V16HImode:
+  if (!TARGET_AVX512VL)
+   return false;
+  emit_insn (gen_avx512vl_vpermi2varv16hi3 (target, op0,
+force_reg (V16HImode, mask), op1));
+  return true;
+case V32HImode:
+  emit_insn (gen_avx512bw_vpermi2varv32hi3 (target, op0,
+force_reg (V32HImode, mask), op1));
+  return true;
+case V4SImode:
+  if (!TARGET_AVX512VL)
+   return false;
+  emit_insn (gen_avx512vl_vpermi2varv4si3 (target, op0,
+   force_reg (V4SImode, mask), op1));
+  return true;
+case V8SImode:
+  if (!TARGET_AVX512VL)
+   return false;
+  emit_insn (gen_avx512vl_vpermi2varv8si3 (target, op0,
+   force_reg (V8SImode, mask), op1));
+  return true;
 case V16SImode:
   emit_insn (gen_avx512f_vpermi2varv16si3 (target, op0,
  force_reg (V16SImode, mask),
  op1));
   return true;
+case V4SFmode:
+  if (!TARGET_AVX512VL)
+   return false;
+  emit_insn (gen_avx512vl_vpermi2varv4sf3 (target, op0,
+  force_reg (V4SImode, mask), 
op1));
+  return true;
+case V8SFmode:
+  if (!TARGET_AVX512VL)
+   return false;
+  emit_insn (gen_avx512vl_vpermi2varv8sf3 (target, op0,
+  force_reg (V8SImode, mask), 
op1));
+  return true;
 case V16SFmode:
   emit_insn (gen_avx512f_vpermi2varv16sf3 (target, op0,
   

Re: [RFC PATCH] Enable V32HI/V64QI const permutations

[Kirill Yukhin]

Hello Jakub,
On 03 Oct 16:39, Jakub Jelinek wrote:
> --- gcc/config/i386/sse.md.jj 2014-09-26 10:33:18.0 +0200
> +++ gcc/config/i386/sse.md2014-10-03 15:03:44.170446452 +0200
> @@ -10386,7 +10386,8 @@ (define_mode_iterator VEC_PERM_CONST
> (V8SI "TARGET_AVX") (V4DI "TARGET_AVX")
> (V32QI "TARGET_AVX2") (V16HI "TARGET_AVX2")
> (V16SI "TARGET_AVX512F") (V8DI "TARGET_AVX512F")
> -   (V16SF "TARGET_AVX512F") (V8DF "TARGET_AVX512F")])
> +   (V16SF "TARGET_AVX512F") (V8DF "TARGET_AVX512F")
> +   (V32HI "TARGET_AVX512BW") (V64QI "TARGET_AVX512BW")])
This is subject of 63/n patch (will post tomorrow).

--
Thanks, K

[patch] Add std::experimental::apply()

[Jonathan Wakely]

From the Fundamentals TS.


Tested x86_64-linux, committed to trunk.
commit df1e59560b6723da563f3aae8d95dcfe2781173b
Author: Jonathan Wakely 
Date:   Fri Oct 3 17:51:31 2014 +0100

	* include/Makefile.am: Add new header.
	* include/Makefile.in: Regenerate.
	* include/experimental/tuple: New
	* doc/xml/manual/status_cxx2014.xml: Update.
	* doc/html/manual/status.html: Regenerate.
	* testsuite/experimental/feat-lib-fund.cc: Test for new header.
	* testsuite/experimental/tuple/apply.cc: New.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
index 11254d6..b7ed7ed 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
@@ -353,14 +353,13 @@ not in any particular release.
 
 
 
-  
   
 	http://www.w3.org/1999/xlink"; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3915.pdf";>
 	  N3915
 	
   
   apply() call a function with arguments from a tuple
-  N
+  Y
   Library Fundamentals TS
 
 
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 5476a37..dee4a3f 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -642,7 +642,8 @@ experimental_headers = \
 	${experimental_srcdir}/any \
 	${experimental_srcdir}/optional \
 	${experimental_srcdir}/string_view \
-	${experimental_srcdir}/string_view.tcc
+	${experimental_srcdir}/string_view.tcc \
+	${experimental_srcdir}/tuple
 
 # This is the common subset of C++ files that all three "C" header models use.
 c_base_srcdir = $(C_INCLUDE_DIR)
diff --git a/libstdc++-v3/include/experimental/tuple b/libstdc++-v3/include/experimental/tuple
new file mode 100644
index 000..bbfbdfa
--- /dev/null
+++ b/libstdc++-v3/include/experimental/tuple
@@ -0,0 +1,70 @@
+//  -*- C++ -*-
+
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, 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 General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file experimental/tuple
+ *  This is a TS C++ Library header.
+ */
+
+#ifndef _GLIBCXX_EXPERIMENTAL_TUPLE
+#define _GLIBCXX_EXPERIMENTAL_TUPLE 1
+
+#pragma GCC system_header
+
+#if __cplusplus <= 201103L
+# include 
+#else
+
+#include 
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+namespace experimental
+{
+inline namespace fundamentals_v1
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+  template 
+constexpr decltype(auto)
+__apply_impl(_Fn&& f, _Tuple&& t, std::index_sequence<_Idx...>)
+{ return std::forward<_Fn>(f)(get<_Idx>(forward<_Tuple>(t))...); }
+
+  template 
+constexpr decltype(auto)
+apply(_Fn&& f, _Tuple&& t)
+{
+  using _Indices =
+	std::make_index_sequence>::value>;
+  return __apply_impl(std::forward<_Fn>(f), std::forward<_Tuple>(t),
+			  _Indices{});
+}
+
+_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace fundamentals_v1
+} // namespace experimental
+} // namespace std
+
+#endif // C++14
+
+#endif // _GLIBCXX_EXPERIMENTAL_TUPLE
diff --git a/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc b/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc
index 50d1ce2..0c73f09 100644
--- a/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc
+++ b/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc
@@ -23,3 +23,7 @@
 #if !__has_include()
 #  error ""
 #endif
+
+#if !__has_include()
+#  error ""
+#endif
diff --git a/libstdc++-v3/testsuite/experimental/tuple/apply.cc b/libstdc++-v3/testsuite/experimental/tuple/apply.cc
new file mode 100644
index 000..170a8d9
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/tuple/apply.cc
@@ -0,0 +1,49 @@
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be us

[PATCH] libitm.c/ cleanup

[Marek Polacek]

This patch is a cleanup of tests in libitm.c/ directory.
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02656.html for more info.

Only two tests needed fixing this time around.

Tested on x86_64-linux: vanilla results == results with this patch ==
results with this patch and gnu11 as a default.

Applying to trunk.

2014-10-06  Marek Polacek  

* testsuite/libitm.c/memcpy-1.c: Declare getpagesize.
* testsuite/libitm.c/memset-1.c: Likewise.

diff --git gcc/libitm/testsuite/libitm.c/memcpy-1.c 
gcc/libitm/testsuite/libitm.c/memcpy-1.c
index 03b3812..32a4b6c 100644
--- gcc/libitm/testsuite/libitm.c/memcpy-1.c
+++ gcc/libitm/testsuite/libitm.c/memcpy-1.c
@@ -32,6 +32,7 @@
 static unsigned char *buf1, *buf2;
 static size_t bufsize, page_size;
 static int fail;
+int getpagesize (void);
 
 static void
 do_test (size_t align1, size_t align2, size_t len)
diff --git gcc/libitm/testsuite/libitm.c/memset-1.c 
gcc/libitm/testsuite/libitm.c/memset-1.c
index 11aea45..91ae285 100644
--- gcc/libitm/testsuite/libitm.c/memset-1.c
+++ gcc/libitm/testsuite/libitm.c/memset-1.c
@@ -32,6 +32,7 @@
 static unsigned char *buf;
 static size_t bufsize, page_size;
 static int fail;
+int getpagesize (void);
 
 #ifndef MAP_ANONYMOUS
 #  ifdef MAP_ANON

Marek

Re: [gomp4] Offload option handling

[Bernd Schmidt]

On 10/03/2014 04:31 PM, Andrey Turetskiy wrote:


I've applied your option patch on our offload branch (w/o
'-ftarget-options' switch yet) and it seems to be working fine.
However the patch looks a bit unfinished:

@@ -440,7 +554,11 @@ access_check (const char *name, int mode

  static char*
  prepare_target_image (const char *target, const char *compiler_path,
-  unsigned in_argc, char *in_argv[])
+  unsigned in_argc, char *in_argv[],
+  struct cl_decoded_option *compiler_opts,
+  unsigned int compiler_opt_count,
+  struct cl_decoded_option * /*linker_opts */,
+  unsigned int /*linker_opt_count*/)
  {
const char **argv;
struct obstack argv_obstack;
@@ -469,8 +587,6 @@ prepare_target_image (const char *target
/* Generate temp file name.  */
filename = make_temp_file (".target.o");

-  /* --  */
-  /* Run gcc for target.  */
obstack_init (&argv_obstack);
obstack_ptr_grow (&argv_obstack, compiler);
obstack_ptr_grow (&argv_obstack, "-o");
@@ -479,6 +595,8 @@ prepare_target_image (const char *target
for (i = 1; i < in_argc; ++i)
  if (strncmp (in_argv[i], "-fresolution=", sizeof ("-fresolution=") - 1))
obstack_ptr_grow (&argv_obstack, in_argv[i]);
+
+  append_compiler_options (&argv_obstack, compiler_opts, compiler_opt_count);
obstack_ptr_grow (&argv_obstack, NULL);

argv = XOBFINISH (&argv_obstack, const char **);

argv = XOBFINISH (&argv_obstack, char **);

What do you suppose to do with 'linker_opts'?


Unclear at this point. For ptx, at the moment we don't even perform a 
linking step. This is likely to change, but even then the host linker 
options are probably not relevant. Most likely we could scan for things 
like "-lgfortran" which we could assume must exist on the offload target 
and pass these down.



Bernd

Re: [PATCH,i386] Fix adxintrin on mingw.

[Uros Bizjak]

On Thu, Oct 2, 2014 at 4:29 PM, Ilya Tocar  wrote:
> Hi,
>
> sizeof (long) == 4 on windows, so we should use long long as param type.
> Patch below does it.
> Ok for trunk?
>
> 2014-10-02  Ilya Tocar  
>
> * config/i386/adxintrin.h (_subborrow_u64): Use long long for param
> type.
> (_addcarry_u64): Ditto.
> (_addcarryx_u64): Ditto.

OK everywhere.

Thanks,
Uros.

Re: [PATCH] libgomp.c/ cleanup

[Marek Polacek]

On Mon, Oct 06, 2014 at 12:46:51PM +0200, Jakub Jelinek wrote:
> On Mon, Oct 06, 2014 at 12:18:33PM +0200, Marek Polacek wrote:
> > --- gcc/libgomp/testsuite/libgomp.c/affinity-1.c
> > +++ gcc/libgomp/testsuite/libgomp.c/affinity-1.c
> > @@ -31,6 +31,7 @@
> >  
> >  #ifdef DO_FORK
> >  #include 
> > +pid_t waitpid (pid_t, int *, int);
> 
> I'd #include  here instead.
> 
> > --- gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
> > +++ gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
> > @@ -6,6 +6,7 @@
> >  #include 
> >  #include 
> >  
> > +unsigned long int strtoul(const char *, char **, int);
> 
> and #include  here.
> 
> > --- gcc/libgomp/testsuite/libgomp.c/thread-limit-1.c
> > +++ gcc/libgomp/testsuite/libgomp.c/thread-limit-1.c
> > @@ -4,6 +4,11 @@
> >  #include 
> >  #include 
> >  
> > +extern int omp_get_thread_limit (void);
> > +extern int omp_set_dynamic (int);
> > +extern void omp_set_nested (int);
> > +extern int omp_get_num_threads (void);
> > +
> >  int
> >  main ()
> >  {
> > diff --git gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c 
> > gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c
> > index 0fc9dae..ca9ad23 100644
> > --- gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c
> > +++ gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c
> > @@ -4,6 +4,11 @@
> >  #include 
> >  #include 
> >  
> > +extern int omp_get_thread_limit (void);
> > +extern int omp_set_dynamic (int);
> > +extern void omp_set_nested (int);
> > +extern int omp_get_num_threads (void);
> 
> Please #include  in the above two tests instead.

Ok, sorry.  I'm fixing those with the following.

Applying to trunk.

2014-10-06  Marek Polacek  

* testsuite/libgomp.c/affinity-1.c: Include .
* testsuite/libgomp.c/nqueens-1.c: Include .
* testsuite/libgomp.c/thread-limit-1.c: Include 
* testsuite/libgomp.c/thread-limit-2.c: Likewise.

diff --git gcc/libgomp/testsuite/libgomp.c/affinity-1.c 
gcc/libgomp/testsuite/libgomp.c/affinity-1.c
index a1a2a12..21f344c 100644
--- gcc/libgomp/testsuite/libgomp.c/affinity-1.c
+++ gcc/libgomp/testsuite/libgomp.c/affinity-1.c
@@ -31,7 +31,7 @@
 
 #ifdef DO_FORK
 #include 
-pid_t waitpid (pid_t, int *, int);
+#include 
 #endif
 #ifdef HAVE_PTHREAD_AFFINITY_NP
 #include 
diff --git gcc/libgomp/testsuite/libgomp.c/nqueens-1.c 
gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
index ed6c179..9742b7a 100644
--- gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
+++ gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
@@ -5,8 +5,8 @@
 #include 
 #include 
 #include 
+#include 
 
-unsigned long int strtoul(const char *, char **, int);
 int cnt;
 #pragma omp threadprivate (cnt)
 
diff --git gcc/libgomp/testsuite/libgomp.c/thread-limit-1.c 
gcc/libgomp/testsuite/libgomp.c/thread-limit-1.c
index 7571f23..1d9794a 100644
--- gcc/libgomp/testsuite/libgomp.c/thread-limit-1.c
+++ gcc/libgomp/testsuite/libgomp.c/thread-limit-1.c
@@ -3,11 +3,7 @@
 
 #include 
 #include 
-
-extern int omp_get_thread_limit (void);
-extern int omp_set_dynamic (int);
-extern void omp_set_nested (int);
-extern int omp_get_num_threads (void);
+#include 
 
 int
 main ()
diff --git gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c 
gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c
index ca9ad23..1a97fb6 100644
--- gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c
+++ gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c
@@ -3,11 +3,7 @@
 
 #include 
 #include 
-
-extern int omp_get_thread_limit (void);
-extern int omp_set_dynamic (int);
-extern void omp_set_nested (int);
-extern int omp_get_num_threads (void);
+#include 
 
 int
 main ()

Marek

[PATCH] gcc.dg/ cleanup

[Marek Polacek]

This patch is a cleanup of the rest of the tests in gcc.dg/ directory that
haven't been fixed in previous patches.
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02656.html for more info.

Tested on x86_64-linux: vanilla results == results with this patch ==
results with this patch and gnu11 as a default.

Applying to trunk.

2014-10-06  Marek Polacek  

* gcc.dg/20001012-1.c: Fix defaulting to int.
* gcc.dg/20001012-2.c: Likewise.
* gcc.dg/20001108-1.c: Likewise.
* gcc.dg/20010516-1.c: Likewise.
* gcc.dg/20011008-2.c: Likewise.
* gcc.dg/20030612-1.c: Likewise.
* gcc.dg/20040219-1.c: Likewise.
* gcc.dg/20050603-2.c: Likewise.
* gcc.dg/20070507-1.c: Likewise.
* gcc.dg/attr-alias-3.c: Likewise.
* gcc.dg/fastmath-1.c: Likewise.
* gcc.dg/fork-instrumentation.c: Likewise.
* gcc.dg/fwrapv-1.c: Likewise.
* gcc.dg/fwrapv-2.c: Likewise.
* gcc.dg/memmove-1.c: Likewise.
* gcc.dg/non-local-goto-1.c: Likewise.
* gcc.dg/non-local-goto-2.c: Likewise.
* gcc.dg/noreturn-8.c: Likewise.
* gcc.dg/parse-decl-after-if.c: Likewise.
* gcc.dg/parse-decl-after-label.c: Likewise.
* gcc.dg/pr25795-1.c: Likewise.
* gcc.dg/pr25795.c: Likewise.
* gcc.dg/pr28574.c: Likewise.
* gcc.dg/pr30189.c: Likewise.
* gcc.dg/pr31529-2.c: Likewise.
* gcc.dg/pr33923.c: Likewise.
* gcc.dg/pr34263.c: Likewise.
* gcc.dg/pr36194.c: Likewise.
* gcc.dg/pr45415.c: Likewise.
* gcc.dg/pr47443.c: Likewise.
* gcc.dg/pr47763.c: Likewise.
* gcc.dg/pr49000.c: Likewise.
* gcc.dg/pr50340.c: Likewise.
* gcc.dg/webizer.c: Likewise.
* gcc.dg/pr59940.c: Likewise.
* gcc.dg/pr63186.c: Likewise.
* gcc.dg/simulate-thread/atomic-load-int.c: Likewise.
* gcc.dg/simulate-thread/atomic-load-int128.c: Likewise.
* gcc.dg/simulate-thread/atomic-load-longlong.c: Likewise.
* gcc.dg/simulate-thread/atomic-load-short.c: Likewise.
* gcc.dg/simulate-thread/atomic-other-int.c: Likewise.
* gcc.dg/sms-1.c: Likewise.
* gcc.dg/unused-3.c: Likewise.
* gcc.dg/varpool-1.c: Likewise.
* gcc.dg/pr35899.c: Use -std=gnu89.
* gcc.dg/pr59963-1.c: Likewise.
* gcc.dg/redecl-15.c: Likewise.
* gcc.dg/20041213-1.c: Likewise.
* gcc.dg/20080820.c: Likewise.
* gcc.dg/920413-1.c: Likewise.
* gcc.dg/Wold-style-definition-1.c: Likewise.
* gcc.dg/Wmissing-parameter-type-no.c: Likewise.
* gcc.dg/decl-nospec-1.c: Likewise.
* gcc.dg/decl-nospec-2.c: Likewise.
* gcc.dg/decl-nospec-3.c: Likewise.
* gcc.dg/bitfld-1.c: Likewise.
* gcc.dg/bitfld-9.c: Likewise.
* gcc.dg/parm-impl-decl-1.c: Likewise.
* gcc.dg/parm-impl-decl-3.c: Likewise.
* gcc.dg/pr18596-1.c: Likewise.
* gcc.dg/pr18596-2.c: Likewise.
* gcc.dg/pr18596-3.c: Likewise.
* gcc.dg/pr60139.c: Likewise.
* gcc.dg/utf-dflt.c: Likewise.
* gcc.dg/utf-dflt2.c: Likewise.
* gcc.dg/wtr-func-def-1.c: Likewise.
* gcc.dg/declspec-5.c: Likewise.
* gcc.dg/declspec-6.c: Likewise.
* gcc.dg/ftrapv-2.c: Likewise.
* gcc.dg/20020430-1.c: Fix implicit declarations.
* gcc.dg/20030702-1.c: Likewise.
* gcc.dg/20040127-2.c: Likewise.
* gcc.dg/20041122-1.c: Likewise.
* gcc.dg/20050309-1.c: Likewise.
* gcc.dg/20061026.c: Likewise.
* gcc.dg/20101010-1.c: Likewise.
* gcc.dg/Werror-1.c: Likewise.
* gcc.dg/Werror-10.c: Likewise.
* gcc.dg/Werror-11.c: Likewise.
* gcc.dg/Werror-12.c: Likewise.
* gcc.dg/Werror-2.c: Likewise.
* gcc.dg/Werror-3.c: Likewise.
* gcc.dg/Werror-4.c: Likewise.
* gcc.dg/Werror-5.c: Likewise.
* gcc.dg/Werror-6.c: Likewise.
* gcc.dg/Werror-7.c: Likewise.
* gcc.dg/Werror-8.c: Likewise.
* gcc.dg/Wstrict-overflow-20.c: Likewise.
* gcc.dg/cpp/trad/macroargs.c: Likewise.
* gcc.dg/delay-slot-2.c: Likewise.
* gcc.dg/errno-1.c: Likewise.
* gcc.dg/globalalias.c: Likewise.
* gcc.dg/inline-3.c: Likewise.
* gcc.dg/localalias.c: Likewise.
* gcc.dg/pr19633-1.c: Likewise.
* gcc.dg/pr19633.c: Likewise.
* gcc.dg/pr23408.c: Likewise.
* gcc.dg/pr23470-1.c: Likewise.
* gcc.dg/pr28121.c: Likewise.
* gcc.dg/pr28243.c: Likewise.
* gcc.dg/pr30260.c: Likewise.
* gcc.dg/pr32573.c: Likewise.
* gcc.dg/pr33826.c: Likewise.
* gcc.dg/pr35065.c: Likewise.
* gcc.dg/pr38616.c: Likewise.
* gcc.dg/pr39867.c: Likewise.
* gcc.dg/pr41470.c: Likewise.
* gcc.dg/pr41837.c: Likewise.
* gcc.dg/pr44024.c: Likewise.
* gcc.dg/pr44699.c: Likewise.
*

Re: [patch] Fix miscompilation of gnat1 in LTO bootstrap

[Richard Biener]

On Mon, Oct 6, 2014 at 12:16 PM, Eric Botcazou  wrote:
> Hi,
>
> this is a regression from GCC 4.8.x: gnat1 (uintp.adb:UI_Lt) is miscompiled
> during a LTO boostrap when Init_Operand is inlined into it.  A store is
> wrongly deleted by GIMPLE DSE because of a missed aliasing relationship
> between 2 array types with TYPE_NONALIASED_COMPONENT set, one being a derived
> of the other in Ada, hence the latter being allowed to alias the former.
>
> Tested on x86_64-suse-linux, OK for the mainline and 4.9 branch?

Testcase?  I think it would be better to handle this in the canonical type
merging code in lto.c - or how does it end up working without LTO?  That is,
what does the Ada frontend do to make sure get_alias_set handles this
correctly?

Thanks,
Richard.

>
> 2014-10-06  Eric Botcazou  
>
> * gimple.c (gimple_get_alias_set): Return 0 for array types with non-
> aliased component and that contain PLACEHOLDER_EXPRs.
>
>
> --
> Eric Botcazou

Re: [patch] Fix internal error in LTO mode on Ada code

[Richard Biener]

On Mon, Oct 6, 2014 at 12:10 PM, Eric Botcazou  wrote:
> Hi,
>
> LTO quickly breaks on Ada code involving floating-point comparisons because
> the Ada compiler defaults to -fnon-call-exceptions -fno-trapping-math (on most
> platforms) and only -fnon-call-exceptions is restored on the LTO side, so you
> can end up with the wrong number of edges on FP comparisons during LTRANS.
>
> Tested on x86_64-suse-linux, OK for the mainline?

Ok.

Thanks,
Richard.

>
> 2014-10-06  Eric Botcazou  
>
> * lto-opts.c (lto_write_options): Handle -fmath-errno, -fsigned-zeros
> and -ftrapping-math.
> * lto-wrapper.c (merge_and_complain): Likewise.
> (run_gcc): Likewise.
>
>
> 2014-10-06  Eric Botcazou  
>
> * gnat.dg/lto16.adb: New test.
> * gnat.dg/lto16_pkg.adb: New helper.
>
>
> --
> Eric Botcazou

Re: [patch] Turn 1 lra_assert into 1 gcc_assert

[Richard Biener]

On Mon, Oct 6, 2014 at 12:02 PM, Eric Botcazou  wrote:
> Hi,
>
> we have run into a case on the ARM where LRA silently generates wrong code in
> release mode, while reload (-mno-lra) would stop with the usual spill failure.
>
> Tested on x86_64-suse-linux, OK for the mainline?

The docs on the asm_p flags say there is sth wrong with the asm constraints
so maybe better do

 if (!asm_p)
   error_at (loc, "");

with an appropriate message and location?

Richard.

>
> 2014-10-06  Eric Botcazou  
>
> * lra-assigns.c (assign_by_spills): Turn lra_assert into gcc_assert.
>
>
> --
> Eric Botcazou

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

[Richard Biener]

On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng  wrote:
> On Wed, Oct 1, 2014 at 5:06 AM, Mike Stump  wrote:
>> On Sep 30, 2014, at 2:22 AM, Bin Cheng  wrote:
>>> Then I decided to take one step forward to introduce a generic
>>> instruction fusion infrastructure in GCC, because in essence, load/store
>>> pair is nothing different with other instruction fusion, all these 
>>> optimizations
>>> want is to push instructions together in instruction flow.
>>
>> I like the step you took.  I had exactly this in mind when I wrote the 
>> original.
>>
>>> N0 ~= 1300
>>> N1/N2 ~= 5000
>>> N3 ~= 7500
>>
>> Nice.  Would be nice to see metrics for time to ensure that the code isn't 
>> actually worse (CSiBE and/or spec and/or some other).  I didn't have any 
>> large scale benchmark runs with my code and I did worry about extending 
>> lifetimes and register pressure.
>
> Hi Mike,
> I did collect spec2k performance after pairing load/store using this
> patch on both aarch64 and cortex-a15.  The performance is improved
> obviously, especially on cortex-a57.  There are some (though not many)
> benchmarks are regressed a little.  There is no register pressure
> problem here because this pass is put between register allocation and
> sched2, I guess sched2 should resolve most pipeline hazards introduced
> by this pass.

How many merging opportunities does sched2 undo again?  ISTR it
has the tendency of pushing stores down and loads up.

Richard.

>>
>>> I cleared up Mike's patch and fixed some implementation bugs in it
>>
>> So, I'm wondering what the bugs or missed opportunities were?  And, if they 
>> were of the type of problem that generated incorrect code or if they were of 
>> the type that was merely a missed opportunity.
> Just missed opportunity issues.
>
> Thanks,
> bin

Re: [patch] Work harder to find DECL_STRUCT_FUNCTION

[Richard Biener]

On Mon, Oct 6, 2014 at 11:52 AM, Eric Botcazou  wrote:
> Hi,
>
> you can have chains of clone functions in the callgraph but can_inline_edge_p
> stops at the first clone when it is looking for DECL_STRUCT_FUNCTION, which
> can fool the following conditions in the predicate.
>
> Tested on x86_64-suse-linux, OK for the mainline?

I wonder if this is worth abstracting into a callee_fn () cgraph edge method?

Honzas call.

Thanks,
Richard.

>
> 2014-10-06  Eric Botcazou  
>
> * ipa-inline.c (can_inline_edge_p): Recurse on clones to find the
> DECL_STRUCT_FUNCTION of the original node.
>
>
> --
> Eric Botcazou

Re: [patch] Fix unaligned access in function returning composite type

[Richard Biener]

On Mon, Oct 6, 2014 at 11:40 AM, Eric Botcazou  wrote:
> Hi,
>
> In Ada, we support all sorts of data structure layout, including on strict-
> alignment targets, and the compiler must generate glue code if necessary.
> The problem here is a function returning a structure by invisible reference
> into a field which is not sufficient aligned because the enclosing object is
> packed: in this case, the caller passes an address that is not correctly
> aligned to the callee, which can result in an unaligned access in the callee.
>
> Tested on x86_64-suse-linux and SPARC/Solaris, OK for the mainline.

Ok.

Thanks,
Richard.

>
> 2014-10-06  Eric Botcazou  
>
> * calls.c (expand_call): Do not use the target as the return slot if
> it is not sufficiently aligned.
>
>
> 2014-10-06  Eric Botcazou  
>
> * gnat.dg/return4.adb: New test.
> * gnat.dg/return4_pkg.ad[sb]: New helper.
>
>
> --
> Eric Botcazou

Re: [PATCH] lto.c: add ARG_UNUSED for an argument

[Richard Biener]

On Mon, Oct 6, 2014 at 11:36 AM, Martin Liška  wrote:
> Hello.
>
> In lto.c, if #ifdef HAVE_WORKING_FORK isn't defined, 'last' argument is
> unused and in that case GCC cannot bootstrap due to a warning.
>
> Ready for trunk?
> Built on x86_64-linux-gnu.

Ok.

Thanks,
Richard.

> Thanks,
> Martin

Re: [PATCHv3][Kasan][PING^2] Allow to override Asan shadow offset from command line

[Yury Gribov]

On 10/06/2014 03:06 PM, Yury Gribov wrote:

On 09/29/2014 09:21 PM, Yury Gribov wrote:

Hi all,


Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit architectures.


New patch which checks that -fasan-shadow-offset is only enabled for
-fsanitize=kernel-address. I (unfortunately) can't make this --param
because this can be a 64-bit value.

Bootstrapped and regtested on x64.

-Y


Added Jakub.

Re: [PATCH,i386] Fix adxintrin on mingw.

[Ilya Tocar]

On 03 Oct 07:53, H.J. Lu wrote:
> On Fri, Oct 3, 2014 at 6:46 AM, Ilya Tocar  wrote:
> > On 02 Oct 07:41, H.J. Lu wrote:
> >> On Thu, Oct 2, 2014 at 7:29 AM, Ilya Tocar  wrote:
> >>
> >> The same is true for x32.  Can you add a testcase to show it
> >> fails on x32 without the fix?
> >>
> >
> > This could only be done with runtime test.
> > I've had troubles running sde (emulator) on x32 enabled system,
> > but replacing long long with int in intrinsic signature will cause
> > adx-addcarryx64-2.c to fail under sde on 64 bits. I believe it will
> > also fail on sde+{win,x32} or real hardware, when it's available.
> >
> 
> Can we scan the assembly output for the wrong instruction?
>
I don't think so.
Incorrect instruction is movl (instead of movq) for value load.
However with x32 we also generate movl for pointer moves,
So scanning for movl doesn't make sense. And hardcoding particular
movl will make test quite fragile.

[SPARC] Remove an unused predicate

[Eric Botcazou]

Tested on SPARC/Solaris, applied on the mainline.


2014-10-06  Eric Botcazou  

* config/sparc/predicates.md (int_register_operand): Delete.


-- 
Eric BotcazouIndex: config/sparc/predicates.md
===
--- config/sparc/predicates.md	(revision 215843)
+++ config/sparc/predicates.md	(working copy)
@@ -260,11 +260,6 @@ (define_predicate "fp_register_operand"
   return REG_P (op) && SPARC_FP_REG_P (REGNO (op));
 })
 
-;; Return true if OP is an integer register.
-(define_special_predicate "int_register_operand"
-  (ior (match_test "register_operand (op, SImode)")
-   (match_test "TARGET_ARCH64 && register_operand (op, DImode)")))
-
 ;; Return true if OP is an integer register of the appropriate mode
 ;; for a cstore result.
 (define_special_predicate "cstore_result_operand"

[PATCHv3][Kasan][PING^2] Allow to override Asan shadow offset from command line

[Yury Gribov]

On 09/29/2014 09:21 PM, Yury Gribov wrote:

Hi all,


Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit architectures.


New patch which checks that -fasan-shadow-offset is only enabled for
-fsanitize=kernel-address. I (unfortunately) can't make this --param
because this can be a 64-bit value.

Bootstrapped and regtested on x64.

-Y


commit 05829f7922915b075c0f4275d3613947aa793a9c
Author: Yury Gribov 
Date:   Fri Aug 29 11:58:03 2014 +0400

Allow to override Asan shadow offset.

2014-09-26  Yury Gribov  

gcc/
	* asan.c (set_asan_shadow_offset): New function.
	(asan_shadow_offset): Likewise.
	(asan_emit_stack_protection): Call asan_shadow_offset.
	(build_shadow_mem_access): Likewise.
	* asan.h (set_asan_shadow_offset): Declare.
	* common.opt (fasan-shadow-offset): New option.
	* doc/invoke.texi (fasan-shadow-offset): Describe new option.
	* opts-global.c (handle_common_deferred_options): Handle
	-fasan-shadow-offset.
	* opts.c (common_handle_option): Likewise.

gcc/testsuite/
	* c-c++-common/asan/shadow-offset-1.c: New test.

diff --git a/gcc/asan.c b/gcc/asan.c
index f520eab..63f99f5 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -238,6 +238,39 @@ along with GCC; see the file COPYING3.  If not see
A destructor function that calls the runtime asan library function
_asan_unregister_globals is also installed.  */
 
+static unsigned HOST_WIDE_INT asan_shadow_offset_value;
+static bool asan_shadow_offset_computed;
+
+/* Sets shadow offset to value in string VAL.  */
+
+bool
+set_asan_shadow_offset (const char *val)
+{
+  char *endp;
+  
+  errno = 0;
+  asan_shadow_offset_value = strtoul (val, &endp, 0);
+  if (!(*val != '\0' && *endp == '\0' && errno == 0))
+return false;
+
+  asan_shadow_offset_computed = true;
+
+  return true;
+}
+
+/* Returns Asan shadow offset.  */
+
+static unsigned HOST_WIDE_INT
+asan_shadow_offset ()
+{
+  if (!asan_shadow_offset_computed)
+{
+  asan_shadow_offset_computed = true;
+  asan_shadow_offset_value = targetm.asan_shadow_offset ();
+}
+  return asan_shadow_offset_value;
+}
+
 alias_set_type asan_shadow_set = -1;
 
 /* Pointer types to 1 resp. 2 byte integers in shadow memory.  A separate
@@ -1124,7 +1157,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb,
 			  NULL_RTX, 1, OPTAB_DIRECT);
   shadow_base
 = plus_constant (Pmode, shadow_base,
-		 targetm.asan_shadow_offset ()
+		 asan_shadow_offset ()
 		 + (base_align_bias >> ASAN_SHADOW_SHIFT));
   gcc_assert (asan_shadow_set != -1
 	  && (ASAN_RED_ZONE_SIZE >> ASAN_SHADOW_SHIFT) == 4);
@@ -1502,7 +1535,7 @@ insert_if_then_before_iter (gimple cond,
 }
 
 /* Build
-   (base_addr >> ASAN_SHADOW_SHIFT) + targetm.asan_shadow_offset ().  */
+   (base_addr >> ASAN_SHADOW_SHIFT) + asan_shadow_offset ().  */
 
 static tree
 build_shadow_mem_access (gimple_stmt_iterator *gsi, location_t location,
@@ -1519,7 +1552,7 @@ build_shadow_mem_access (gimple_stmt_iterator *gsi, location_t location,
   gimple_set_location (g, location);
   gsi_insert_after (gsi, g, GSI_NEW_STMT);
 
-  t = build_int_cst (uintptr_type, targetm.asan_shadow_offset ());
+  t = build_int_cst (uintptr_type, asan_shadow_offset ());
   g = gimple_build_assign_with_ops (PLUS_EXPR,
 make_ssa_name (uintptr_type, NULL),
 gimple_assign_lhs (g), t);
diff --git a/gcc/asan.h b/gcc/asan.h
index 198433f..eadf029 100644
--- a/gcc/asan.h
+++ b/gcc/asan.h
@@ -36,7 +36,7 @@ extern gimple_stmt_iterator create_cond_insert_point
 extern alias_set_type asan_shadow_set;
 
 /* Shadow memory is found at
-   (address >> ASAN_SHADOW_SHIFT) + targetm.asan_shadow_offset ().  */
+   (address >> ASAN_SHADOW_SHIFT) + asan_shadow_offset ().  */
 #define ASAN_SHADOW_SHIFT	3
 
 /* Red zone size, stack and global variables are padded by ASAN_RED_ZONE_SIZE
@@ -76,4 +76,6 @@ asan_red_zone_size (unsigned int size)
   return c ? 2 * ASAN_RED_ZONE_SIZE - c : ASAN_RED_ZONE_SIZE;
 }
 
+extern bool set_asan_shadow_offset (const char *);
+
 #endif /* TREE_ASAN */
diff --git a/gcc/common.opt b/gcc/common.opt
index b4f0ed4..90f6bd4 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -879,6 +879,10 @@ fsanitize=
 Common Driver Report Joined
 Select what to sanitize
 
+fasan-shadow-offset=
+Common Joined RejectNegative Var(common_deferred_options) Defer
+-fasan-shadow-offset=	Use custom shadow memory offset.
+
 fsanitize-recover
 Common Report Var(flag_sanitize_recover) Init(1)
 After diagnosing undefined behavior attempt to continue execution
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index f6c3b42..d9bd1f7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -297,7 +297,7 @@ Objective-C and Objective-C++ Dialects}.
 @xref{Debugging Options,,Options for Debugging Your Program or GCC}.
 @gccoptlist{-d@var{letters}  -dumpspecs  -dum

Re: [gomp4] OpenACC wait directive

[Ilmir Usmanov]

Hi Cesar!

Thank you for the update!

On 05.10.2014 02:32, Cesar Philippidis wrote:

On 10/03/2014 07:34 AM, Cesar Philippidis wrote:

On 09/24/2014 12:18 AM, Ilmir Usmanov wrote:

Hi Cesar!

Thank you for the patch!

On 24.09.2014 02:29, Cesar Philippidis wrote:

This patch adds support for the async clause in the wait directive in
fortran. It should be pretty straight forward. The fortran FE already
supports the wait directive, but the async clause was introduced to the
wait directive in OpenACC 2.0 and that was missing in gomp-4_0-branch.



Sorry for the delay. I encountered some problems with the runtime in our
internal branch, and that slowed things down a bit.

Anyway, you are correct, I broke the optional argument to wait in the
previous patch. This new patch addresses that and it also make the wait
construct conform with OpenACC 2.0. Specifically,

   !$acc wait (1, 2) async (3)

should behave as ex[ected.

If you look at gfc_trans_oacc_wait_directive, you'll note that a call to
GOACC_wait is emitted for the wait directive. Since I had to add a
runtime library stub for that builtin function, I decided to go ahead an
include the c front end bits.

Is this patch OK for gomp-4_0-branch? Julian is working on working on a
more complete implementation of the runtime. The runtime stub that I
included is only temporary.

I noticed that I forgot to include the changes to gimplify.c in that
patch. This new patch includes those changes.

Cesar




As usual, I'll mostly focus on fortran part, since I don't know CFE and 
ME well enough.


Nevertheless, is there a reason to differ C from Fortran in behavior of 
matching int-expr-list? I mean, in C you support only integer literals 
as parameter of wait, but in Fortran you also cover parameters.


Anyway, Fortran part.

 gfc_match_oacc_wait (void)
+if (!gfc_resolve_expr (el->expr)
+|| el->expr->ts.type != BT_INTEGER || el->expr->rank != 0
+|| el->expr->expr_type != EXPR_CONSTANT)
+  {
+gfc_error ("WAIT clause at %L requires a scalar INTEGER 
expression",

+   &el->expr->where);

As you probably know, in Fortran one can define a function after whole 
program.
So, since you are resolving wait-list during match, you don't cover this 
case. But async clause works fine.

By the way, the same difference between wait and async presents in CFE.

Otherwise, Fortran part looks good for me.

--
Ilmir.

Re: [PATCH] libgomp.c/ cleanup

[Jakub Jelinek]

On Mon, Oct 06, 2014 at 12:18:33PM +0200, Marek Polacek wrote:
> --- gcc/libgomp/testsuite/libgomp.c/affinity-1.c
> +++ gcc/libgomp/testsuite/libgomp.c/affinity-1.c
> @@ -31,6 +31,7 @@
>  
>  #ifdef DO_FORK
>  #include 
> +pid_t waitpid (pid_t, int *, int);

I'd #include  here instead.

> --- gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
> +++ gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  
> +unsigned long int strtoul(const char *, char **, int);

and #include  here.

> --- gcc/libgomp/testsuite/libgomp.c/thread-limit-1.c
> +++ gcc/libgomp/testsuite/libgomp.c/thread-limit-1.c
> @@ -4,6 +4,11 @@
>  #include 
>  #include 
>  
> +extern int omp_get_thread_limit (void);
> +extern int omp_set_dynamic (int);
> +extern void omp_set_nested (int);
> +extern int omp_get_num_threads (void);
> +
>  int
>  main ()
>  {
> diff --git gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c 
> gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c
> index 0fc9dae..ca9ad23 100644
> --- gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c
> +++ gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c
> @@ -4,6 +4,11 @@
>  #include 
>  #include 
>  
> +extern int omp_get_thread_limit (void);
> +extern int omp_set_dynamic (int);
> +extern void omp_set_nested (int);
> +extern int omp_get_num_threads (void);

Please #include  in the above two tests instead.

Thanks.

Jakub

[patch] Fix ICE during LTRANS on big Ada application

[Eric Botcazou]

Hi,

we have run into an ICE in LTO mode on a big Ada application with our 4.9-
based compiler, whose error message is:

xx.constprop.15627/1865799 (xxx.constprop) 
@0x76835bd0
  Type: function definition analyzed
  Visibility: used_from_other_partition public visibility_specified 
visibility:hidden artificial
  References: __gnat_personality_v0/19663 (addr)__gnat_others_value/19664 
(addr)
  Referring: 
  Read from file: xx.ltrans31.o
  Availability: local
  First run: 0
  Function flags: local
  Called by: 
yyy.constprop.15352/1865524 
z.constprop.15343/1865515 
  Calls: 
xx.constprop.15628/1865800 
(1.00 per call) 
xx.part.62.lto_priv.21947/1557884 
(can throw external) __gnat_end_handler/19660 (can throw external) 
__builtin_eh_pointer/20253 __gnat_begin_handler/19662 __gnat_end_handler/19660 
(can throw external) 
lto1: fatal error: xx.ltrans31.o: section 
xx.constprop.15627 is missing

So LTRANS complains that a .constprop function is missing on disk, which 
doesn't really make sense since it's a clone so it is not streamed.

The problem is that a clone function has it clone_of field zeroed during clone 
materialization by cgraph_node::remove:

  /* We are removing node with clones.  This makes clones inconsistent,
 but assume they will be removed subsequently and just keep clone
 tree intact.  This can happen in unreachable function removal since
 we remove unreachable functions in random order, not by bottom-up
 walk of clone trees.  */
  for (n = clones; n; n = next)
{
   next = n->next_sibling_clone;
   n->next_sibling_clone = NULL;
   n->prev_sibling_clone = NULL;
   n->clone_of = NULL;
}

because it's the clone of an inlined_to node that gets discarded because it's 
inlined into another clone(!).  So the first clone function cannot (and is 
never) materialized and the compiler ICEs later when its body is requested.

It seems to be that the root cause is clone_inlined_nodes overriding a master 
clone that has non-inline clones, hence the attached patch.

Tested on x86_64-suse-linux, OK for the mainline?


2014-10-06  Eric Botcazou  

* ipa-inline-transform.c (can_remove_node_now_p_1): Return false for a
master clone that has non-inline clones.


-- 
Eric BotcazouIndex: ipa-inline-transform.c
===
--- ipa-inline-transform.c	(revision 215843)
+++ ipa-inline-transform.c	(working copy)
@@ -82,6 +82,13 @@ update_noncloned_frequencies (struct cgr
 static bool
 can_remove_node_now_p_1 (struct cgraph_node *node)
 {
+  /* We cannot remove a master clone that has non-inline clones until after
+ these clones are materialized.  */
+  if (!node->clone_of)
+for (struct cgraph_node *n = node->clones; n; n = n->next_sibling_clone)
+  if (n->decl != node->decl)
+	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.  */

[PATCH] libgomp.c/ cleanup

[Marek Polacek]

This patch is a cleanup of tests in libgomp.c/ directory.
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02656.html for more info.

Tested on x86_64-linux: vanilla results == results with this patch ==
results with this patch and gnu11 as a default.

Applying to trunk.

2014-10-06  Marek Polacek  

* testsuite/libgomp.c/affinity-1.c: Fix implicit declarations.
* testsuite/libgomp.c/nqueens-1.c: Likewise.
* testsuite/libgomp.c/pr26943-3.c: Likewise.
* testsuite/libgomp.c/pr26943-4.c: Likewise.
* testsuite/libgomp.c/pr36802-2.c: Likewise.
* testsuite/libgomp.c/pr36802-3.c: Likewise.
* testsuite/libgomp.c/thread-limit-1.c: Likewise.
* testsuite/libgomp.c/thread-limit-2.c: Likewise.
* testsuite/libgomp.c/appendix-a/a.15.1.c: Include .
* testsuite/libgomp.c/omp-loop02.c: Fix defaulting to int.
* testsuite/libgomp.c/omp-parallel-for.c: Likewise.
* testsuite/libgomp.c/omp-parallel-if.c: Likewise.
* testsuite/libgomp.c/omp-single-1.c: Likewise.
* testsuite/libgomp.c/omp-single-2.c: Likewise.
* testsuite/libgomp.c/omp_matvec.c: Likewise.
* testsuite/libgomp.c/omp_workshare3.c: Likewise.
* testsuite/libgomp.c/omp_workshare4.c: Likewise.
* testsuite/libgomp.c/shared-1.c: Fix defaulting to int.  Fix implicit
declarations.

diff --git gcc/libgomp/testsuite/libgomp.c/affinity-1.c 
gcc/libgomp/testsuite/libgomp.c/affinity-1.c
index b3c1d0c..77efc49 100644
--- gcc/libgomp/testsuite/libgomp.c/affinity-1.c
+++ gcc/libgomp/testsuite/libgomp.c/affinity-1.c
@@ -31,6 +31,7 @@
 
 #ifdef DO_FORK
 #include 
+pid_t waitpid (pid_t, int *, int);
 #endif
 #ifdef HAVE_PTHREAD_AFFINITY_NP
 #include 
diff --git gcc/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c 
gcc/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c
index 276ac6c..c167dab 100644
--- gcc/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c
+++ gcc/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 
+#include 
 #include 
 
 void
diff --git gcc/libgomp/testsuite/libgomp.c/nqueens-1.c 
gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
index 1fdc67b..ed6c179 100644
--- gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
+++ gcc/libgomp/testsuite/libgomp.c/nqueens-1.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 
+unsigned long int strtoul(const char *, char **, int);
 int cnt;
 #pragma omp threadprivate (cnt)
 
diff --git gcc/libgomp/testsuite/libgomp.c/omp-loop02.c 
gcc/libgomp/testsuite/libgomp.c/omp-loop02.c
index 04aaea2..ae0d748 100644
--- gcc/libgomp/testsuite/libgomp.c/omp-loop02.c
+++ gcc/libgomp/testsuite/libgomp.c/omp-loop02.c
@@ -15,6 +15,7 @@ void parloop (int *a)
 a[i] = i + 3;
 }
 
+int
 main()
 {
   int i, a[N];
diff --git gcc/libgomp/testsuite/libgomp.c/omp-parallel-for.c 
gcc/libgomp/testsuite/libgomp.c/omp-parallel-for.c
index c6631a0..9246976 100644
--- gcc/libgomp/testsuite/libgomp.c/omp-parallel-for.c
+++ gcc/libgomp/testsuite/libgomp.c/omp-parallel-for.c
@@ -1,5 +1,6 @@
 extern void abort (void);
 
+int
 main()
 {
   int i, a;
diff --git gcc/libgomp/testsuite/libgomp.c/omp-parallel-if.c 
gcc/libgomp/testsuite/libgomp.c/omp-parallel-if.c
index 5e37835..b9c27fd 100644
--- gcc/libgomp/testsuite/libgomp.c/omp-parallel-if.c
+++ gcc/libgomp/testsuite/libgomp.c/omp-parallel-if.c
@@ -8,6 +8,7 @@ foo (void)
   return 10;
 }
 
+int
 main ()
 {
   int A = 0;
diff --git gcc/libgomp/testsuite/libgomp.c/omp-single-1.c 
gcc/libgomp/testsuite/libgomp.c/omp-single-1.c
index a44ca54..91555cb 100644
--- gcc/libgomp/testsuite/libgomp.c/omp-single-1.c
+++ gcc/libgomp/testsuite/libgomp.c/omp-single-1.c
@@ -1,5 +1,6 @@
 extern void abort (void);
 
+int
 main()
 {
   int i = 0;
diff --git gcc/libgomp/testsuite/libgomp.c/omp-single-2.c 
gcc/libgomp/testsuite/libgomp.c/omp-single-2.c
index 6878559..f16cbbe 100644
--- gcc/libgomp/testsuite/libgomp.c/omp-single-2.c
+++ gcc/libgomp/testsuite/libgomp.c/omp-single-2.c
@@ -9,6 +9,7 @@ struct X
   int c;
 };
 
+int
 main()
 {
   int i = 0;
diff --git gcc/libgomp/testsuite/libgomp.c/omp_matvec.c 
gcc/libgomp/testsuite/libgomp.c/omp_matvec.c
index 12b8c68..44547b6 100644
--- gcc/libgomp/testsuite/libgomp.c/omp_matvec.c
+++ gcc/libgomp/testsuite/libgomp.c/omp_matvec.c
@@ -16,6 +16,7 @@
 #define SIZE 10
 
 
+int
 main ()
 {
 
diff --git gcc/libgomp/testsuite/libgomp.c/omp_workshare3.c 
gcc/libgomp/testsuite/libgomp.c/omp_workshare3.c
index 913f1f7..4c55f13 100644
--- gcc/libgomp/testsuite/libgomp.c/omp_workshare3.c
+++ gcc/libgomp/testsuite/libgomp.c/omp_workshare3.c
@@ -16,6 +16,7 @@
 #define N   50
 #define CHUNKSIZE   5
 
+int
 main ()  {
 
 int i, chunk, tid;
diff --git gcc/libgomp/testsuite/libgomp.c/omp_workshare4.c 
gcc/libgomp/testsuite/libgomp.c/omp_workshare4.c
index 67605e3..4ebe68c 100644
--- gcc/libgomp/testsuite/libgomp.c/omp_workshare4.c
+++ gcc/libgomp/testsuite/libgomp.c/omp_workshare4.c
@@ -15,6 +15,7 @@
 #define N   50
 #define CHUNKSIZE   5
 
+int
 

[patch] Fix miscompilation of gnat1 in LTO bootstrap

[Eric Botcazou]

Hi,

this is a regression from GCC 4.8.x: gnat1 (uintp.adb:UI_Lt) is miscompiled 
during a LTO boostrap when Init_Operand is inlined into it.  A store is 
wrongly deleted by GIMPLE DSE because of a missed aliasing relationship 
between 2 array types with TYPE_NONALIASED_COMPONENT set, one being a derived 
of the other in Ada, hence the latter being allowed to alias the former.

Tested on x86_64-suse-linux, OK for the mainline and 4.9 branch?


2014-10-06  Eric Botcazou  

* gimple.c (gimple_get_alias_set): Return 0 for array types with non-
aliased component and that contain PLACEHOLDER_EXPRs.


-- 
Eric BotcazouIndex: gimple.c
===
--- gimple.c	(revision 215843)
+++ gimple.c	(working copy)
@@ -2336,6 +2336,16 @@ gimple_get_alias_set (tree t)
 	return get_alias_set (t1);
 }
 
+  /* For languages that distinguish array types from their component type
+ for aliasing purposes, some kind of "generic" arrays types might be
+ allowed to alias their "instantiated" derived types.  The original
+ relationship between them being lost, consider that the former ones
+ can alias everything.  */
+  if (TREE_CODE (t) == ARRAY_TYPE
+  && TYPE_NONALIASED_COMPONENT (t)
+  && type_contains_placeholder_p (t))
+return 0;
+
   return -1;
 }
 

[patch] Fix internal error in LTO mode on Ada code

[Eric Botcazou]

Hi,

LTO quickly breaks on Ada code involving floating-point comparisons because 
the Ada compiler defaults to -fnon-call-exceptions -fno-trapping-math (on most 
platforms) and only -fnon-call-exceptions is restored on the LTO side, so you 
can end up with the wrong number of edges on FP comparisons during LTRANS.

Tested on x86_64-suse-linux, OK for the mainline?


2014-10-06  Eric Botcazou  

* lto-opts.c (lto_write_options): Handle -fmath-errno, -fsigned-zeros
and -ftrapping-math.
* lto-wrapper.c (merge_and_complain): Likewise.
(run_gcc): Likewise.


2014-10-06  Eric Botcazou  

* gnat.dg/lto16.adb: New test.
* gnat.dg/lto16_pkg.adb: New helper.


-- 
Eric BotcazouIndex: lto-opts.c
===
--- lto-opts.c	(revision 215843)
+++ lto-opts.c	(working copy)
@@ -115,6 +115,24 @@ lto_write_options (void)
   default:
 	gcc_unreachable ();
   }
+  /* The default -fmath-errno, -fsigned-zeros and -ftrapping-math change
+ depending on the language (they can be disabled by the Ada and Java
+ front-ends).  Pass thru conservative standard settings.  */
+  if (!global_options_set.x_flag_errno_math)
+append_to_collect_gcc_options (&temporary_obstack, &first_p,
+   global_options.x_flag_errno_math
+   ? "-fmath-errno"
+   : "-fno-math-errno");
+  if (!global_options_set.x_flag_signed_zeros)
+append_to_collect_gcc_options (&temporary_obstack, &first_p,
+   global_options.x_flag_signed_zeros
+   ? "-fsigned-zeros"
+   : "-fno-signed-zeros");
+  if (!global_options_set.x_flag_trapping_math)
+append_to_collect_gcc_options (&temporary_obstack, &first_p,
+   global_options.x_flag_trapping_math
+   ? "-ftrapping-math"
+   : "-fno-trapping-math");
   /* We need to merge -f[no-]strict-overflow, -f[no-]wrapv and -f[no-]trapv
  conservatively, so stream out their defaults.  */
   if (!global_options_set.x_flag_wrapv
Index: lto-wrapper.c
===
--- lto-wrapper.c	(revision 215843)
+++ lto-wrapper.c	(working copy)
@@ -261,6 +261,9 @@ merge_and_complain (struct cl_decoded_op
 	(*decoded_options)[j] = *foption;
 	  break;
 
+	case OPT_fmath_errno:
+	case OPT_fsigned_zeros:
+	case OPT_ftrapping_math:
 	case OPT_fwrapv:
 	  /* For selected options we can merge conservatively.  */
 	  for (j = 0; j < *decoded_options_count; ++j)
@@ -268,7 +271,10 @@ merge_and_complain (struct cl_decoded_op
 	  break;
 	  if (j == *decoded_options_count)
 	append_option (decoded_options, decoded_options_count, foption);
-	  /* -fwrapv > -fno-wrapv.  */
+	  /* -fmath-errno > -fno-math-errno,
+	 -fsigned-zeros > -fno-signed-zeros,
+	 -ftrapping-math -> -fno-trapping-math,
+	 -fwrapv > -fno-wrapv.  */
 	  else if (foption->value > (*decoded_options)[j].value)
 	(*decoded_options)[j] = *foption;
 	  break;
@@ -502,6 +508,9 @@ run_gcc (unsigned argc, char *argv[])
 	case OPT_fpcc_struct_return:
 	case OPT_fshort_double:
 	case OPT_ffp_contract_:
+	case OPT_fmath_errno:
+	case OPT_fsigned_zeros:
+	case OPT_ftrapping_math:
 	case OPT_fwrapv:
 	case OPT_ftrapv:
 	case OPT_fstrict_overflow:
-- { dg-do link }
-- { dg-options "-O -flto" }
-- { dg-require-effective-target lto }

with Lto16_Pkg; use Lto16_Pkg;
with Text_IO; use Text_IO;

procedure Lto16 is
begin
  if F = 0.0 then
Put_Line ("zero");
  else
Put_Line ("non-zero");
  end if;
exception
  when others => Put_Line ("exception");
end;
with Ada.Calendar; use Ada.Calendar;

package body Lto16_Pkg is

  function F return Float is
F1 : Float := Float (Seconds (Clock));
F2 : Float := Float (Seconds (Clock));
F  : Float;
  begin
if F1 > F2 then
  F := (F2 - F1) / 2.0;
else
  F := (F1 - F2) / 2.0;
end if;
return F;
  end;

end Lto16_Pkg;
package Lto16_Pkg is

  function F return Float;

end Lto16_Pkg;

[patch] Turn 1 lra_assert into 1 gcc_assert

[Eric Botcazou]

Hi,

we have run into a case on the ARM where LRA silently generates wrong code in 
release mode, while reload (-mno-lra) would stop with the usual spill failure.

Tested on x86_64-suse-linux, OK for the mainline?


2014-10-06  Eric Botcazou  

* lra-assigns.c (assign_by_spills): Turn lra_assert into gcc_assert.


-- 
Eric BotcazouIndex: lra-assigns.c
===
--- lra-assigns.c	(revision 215843)
+++ lra-assigns.c	(working copy)
@@ -1332,7 +1332,7 @@ assign_by_spills (void)
 		}
 		}
 	}
-	  lra_assert (asm_p);
+	  gcc_assert (asm_p);
 	  break;
 	}
   /* This is a very rare event.  We can not assign a hard register

Fix trace numbering in .dwarf2 dump file

[Eric Botcazou]

The numbering of traces in the .dwarf2 dump file is broken, for example:

Creating trace 0 : start at note 1
Creating trace 1 : start at note 51
Creating trace 2 : start at code_label 16
Creating trace 3 : start at code_label 23
Creating trace 4 : start at code_label 38
Creating trace 5 : start at code_label 29
Processing trace 0 : start at note 1
   saw edge from trace 0 to 0 (via fallthru 0)
push trace 0 to worklist
Processing trace 0 : start at note 51
   saw edge from trace 0 to 1 (via jump_insn 11)
push trace 1 to worklist
   saw edge from trace 0 to 2 (via jump_insn 13)
push trace 2 to worklist
Processing trace 2 : start at code_label 23
   saw edge from trace 2 to 4 (via jump_insn 26)
push trace 4 to worklist
   saw edge from trace 2 to 3 (via fallthru 0)
push trace 3 to worklist
Processing trace 3 : start at code_label 38
   saw edge from trace 3 to 3 (via jump_insn 61)
Processing trace 4 : start at code_label 29
Processing trace 1 : start at code_label 16
   saw edge from trace 1 to 1 (via jump_insn 19)

Note the 2 "Processing trace 0" and the off-by-one discrepancy between the 
"Creating" and the "Processing" lines.

Tested on x86_64-suse-linux, applied on the mainline as obvious.


2014-10-06  Eric Botcazou  

* dwarf2cfi.c (create_pseudo_cfg): Fix trace numbering.


-- 
Eric BotcazouIndex: dwarf2cfi.c
===
--- dwarf2cfi.c	(revision 215843)
+++ dwarf2cfi.c	(working copy)
@@ -2763,7 +2763,7 @@ create_pseudo_cfg (void)
 	  memset (&ti, 0, sizeof (ti));
 	  ti.head = insn;
 	  ti.switch_sections = switch_sections;
-	  ti.id = trace_info.length () - 1;
+	  ti.id = trace_info.length ();
 	  trace_info.safe_push (ti);
 
 	  saw_barrier = false;
@@ -2781,7 +2781,7 @@ create_pseudo_cfg (void)
   dw_trace_info **slot;
 
   if (dump_file)
-	fprintf (dump_file, "Creating trace %u : start at %s %d%s\n", i,
+	fprintf (dump_file, "Creating trace %u : start at %s %d%s\n", tp->id,
 		 rtx_name[(int) GET_CODE (tp->head)], INSN_UID (tp->head),
 		 tp->switch_sections ? " (section switch)" : "");
 

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

[Bin.Cheng]

On Wed, Oct 1, 2014 at 5:06 AM, Mike Stump  wrote:
> On Sep 30, 2014, at 2:22 AM, Bin Cheng  wrote:
>> Then I decided to take one step forward to introduce a generic
>> instruction fusion infrastructure in GCC, because in essence, load/store
>> pair is nothing different with other instruction fusion, all these 
>> optimizations
>> want is to push instructions together in instruction flow.
>
> I like the step you took.  I had exactly this in mind when I wrote the 
> original.
>
>> N0 ~= 1300
>> N1/N2 ~= 5000
>> N3 ~= 7500
>
> Nice.  Would be nice to see metrics for time to ensure that the code isn't 
> actually worse (CSiBE and/or spec and/or some other).  I didn't have any 
> large scale benchmark runs with my code and I did worry about extending 
> lifetimes and register pressure.

Hi Mike,
I did collect spec2k performance after pairing load/store using this
patch on both aarch64 and cortex-a15.  The performance is improved
obviously, especially on cortex-a57.  There are some (though not many)
benchmarks are regressed a little.  There is no register pressure
problem here because this pass is put between register allocation and
sched2, I guess sched2 should resolve most pipeline hazards introduced
by this pass.

>
>> I cleared up Mike's patch and fixed some implementation bugs in it
>
> So, I'm wondering what the bugs or missed opportunities were?  And, if they 
> were of the type of problem that generated incorrect code or if they were of 
> the type that was merely a missed opportunity.
Just missed opportunity issues.

Thanks,
bin

[Java PATCH] Generate declarations in jvgenmain.c

[Marek Polacek]

Java testsuite breaks with -std=gnu11 as a default and/or with 
-Wimplicit-function-declaration on, since the jvgenmain.c program
that generates a C file containing 'main' function which calls either
'JvRunMainName' or 'JvRunMain' does not generate forward declarations
for these functions.  The fix is obvious IMHO.

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

2014-10-06  Marek Polacek  

* jvgenmain.c: Generate forward declarations for JvRunMain{,Name}.

diff --git gcc/gcc/java/jvgenmain.c gcc/gcc/java/jvgenmain.c
index 5b14258..a786d31 100644
--- gcc/gcc/java/jvgenmain.c
+++ gcc/gcc/java/jvgenmain.c
@@ -127,6 +127,8 @@ main (int argc, char **argv)
   /* At this point every element of ARGV from 1 to LAST_ARG is a `-D'
  option.  Process them appropriately.  */
   fprintf (stream, "extern const char **_Jv_Compiler_Properties;\n");
+  fprintf (stream, "extern void JvRunMain ();\n");
+  fprintf (stream, "extern void JvRunMainName ();\n");
   fprintf (stream, "static const char *props[] =\n{\n");
   for (i = 1; i < last_arg; ++i)
 {

Marek

[patch] Work harder to find DECL_STRUCT_FUNCTION

[Eric Botcazou]

Hi,

you can have chains of clone functions in the callgraph but can_inline_edge_p 
stops at the first clone when it is looking for DECL_STRUCT_FUNCTION, which 
can fool the following conditions in the predicate.

Tested on x86_64-suse-linux, OK for the mainline?


2014-10-06  Eric Botcazou  

* ipa-inline.c (can_inline_edge_p): Recurse on clones to find the
DECL_STRUCT_FUNCTION of the original node.


-- 
Eric BotcazouIndex: ipa-inline.c
===
--- ipa-inline.c	(revision 215843)
+++ ipa-inline.c	(working copy)
@@ -276,12 +276,24 @@ can_inline_edge_p (struct cgraph_edge *e
   struct function *caller_cfun = DECL_STRUCT_FUNCTION (e->caller->decl);
   struct function *callee_cfun
 = callee ? DECL_STRUCT_FUNCTION (callee->decl) : NULL;
+  struct cgraph_node *n;
 
-  if (!caller_cfun && e->caller->clone_of)
-caller_cfun = DECL_STRUCT_FUNCTION (e->caller->clone_of->decl);
+  n = e->caller;
+  while (!caller_cfun && n->clone_of)
+{
+  n = n->clone_of;
+  caller_cfun = DECL_STRUCT_FUNCTION (n->decl);
+}
 
-  if (!callee_cfun && callee && callee->clone_of)
-callee_cfun = DECL_STRUCT_FUNCTION (callee->clone_of->decl);
+  if (callee)
+{
+  n = callee;
+  while (!callee_cfun && n->clone_of)
+	{
+	  n = n->clone_of;
+	  callee_cfun = DECL_STRUCT_FUNCTION (n->decl);
+	}
+}
 
   gcc_assert (e->inline_failed);
 

[PATCH] gcc.dg/ipa/ cleanup

[Marek Polacek]

This patch is a cleanup of tests in gcc.dg/ipa/ directory.
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02656.html for more info.

Tested on x86_64-linux: vanilla results == results with this patch ==
results with this patch and gnu11 as a default.

Applying to trunk.

2014-10-06  Marek Polacek  

* gcc.dg/ipa/inline-2.c: Fix implicit declarations.
* gcc.dg/ipa/inline-4.c: Likewise.
* gcc.dg/ipa/inline-5.c: Likewise.
* gcc.dg/ipa/pr57539.c: Likewise.
* gcc.dg/ipa/inline-6.c: Fix implicit declarations.  Fix
defaulting to int.
* gcc.dg/ipa/inlinehint-1.c: Likewise.
* gcc.dg/ipa/inlinehint-3.c: Likewise.
* gcc.dg/ipa/inlinehint-2.c: Fix defaulting to int.
* gcc.dg/ipa/ipacost-1.c: Likewise.
* gcc.dg/ipa/ipacost-2.c: Likewise.
* gcc.dg/ipa/pure-const-1.c: Use -fgnu89-inline.  Fix defaulting
to int.

diff --git gcc/gcc/testsuite/gcc.dg/ipa/inline-2.c 
gcc/gcc/testsuite/gcc.dg/ipa/inline-2.c
index 376cf97..aa8eea3 100644
--- gcc/gcc/testsuite/gcc.dg/ipa/inline-2.c
+++ gcc/gcc/testsuite/gcc.dg/ipa/inline-2.c
@@ -3,6 +3,7 @@
 /* { dg-options "-O3 -c -fdump-ipa-inline -fno-early-inlining"  } */
 
 struct bah {int a,b,d;};
+void test3 (int, int, int, int, int);
 
 __attribute__ ((noinline))
 void test(int a,int b,int c,int d,int e)
diff --git gcc/gcc/testsuite/gcc.dg/ipa/inline-4.c 
gcc/gcc/testsuite/gcc.dg/ipa/inline-4.c
index 66019b3..af5c302 100644
--- gcc/gcc/testsuite/gcc.dg/ipa/inline-4.c
+++ gcc/gcc/testsuite/gcc.dg/ipa/inline-4.c
@@ -1,6 +1,8 @@
 /* { dg-do compile } */
 /* { dg-options "-Os -c -fdump-ipa-inline -fno-early-inlining 
-fno-partial-inlining -fno-ipa-cp"  } */
 
+void work_hard (void);
+
 void do_something (int shall_i_work)
 {
   if (shall_i_work)
diff --git gcc/gcc/testsuite/gcc.dg/ipa/inline-5.c 
gcc/gcc/testsuite/gcc.dg/ipa/inline-5.c
index d4b7410..f0ee25a 100644
--- gcc/gcc/testsuite/gcc.dg/ipa/inline-5.c
+++ gcc/gcc/testsuite/gcc.dg/ipa/inline-5.c
@@ -1,7 +1,10 @@
 /* Check statements that are eliminated by inlining.  */
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-ipa-inline-details -fno-early-inlining 
-fno-partial-inlining -fno-ipa-cp"  } */
+
 struct a {int a,b,c,d,e;};
+void t(int);
+void t2();
 
 void
 accessfield (struct a a)
diff --git gcc/gcc/testsuite/gcc.dg/ipa/inline-6.c 
gcc/gcc/testsuite/gcc.dg/ipa/inline-6.c
index d981bb0..5fb4084 100644
--- gcc/gcc/testsuite/gcc.dg/ipa/inline-6.c
+++ gcc/gcc/testsuite/gcc.dg/ipa/inline-6.c
@@ -1,7 +1,12 @@
 /* Check statements that are eliminated by inlining.  */
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-ipa-inline-details -fno-early-inlining 
-fno-partial-inlining -fno-ipa-cp"  } */
-static t(int a)
+
+void foo (void);
+void bar (void);
+void bagr (void);
+
+static int t(int a)
 {
   if (a==1)
 {
@@ -32,6 +37,7 @@ static t(int a)
   bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); bagr(); 
bagr(); bagr();
}
 }
+int
 main()
 {
   t(1);
diff --git gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-1.c 
gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-1.c
index 9810e25..1cc5bdd 100644
--- gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-1.c
+++ gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-1.c
@@ -1,4 +1,6 @@
 /* { dg-options "-O3 -c -fdump-ipa-inline-details -fno-early-inlining 
-fno-ipa-cp"  } */
+void test2 (int);
+int
 test (int a)
 {
int i;
@@ -8,6 +10,7 @@ test (int a)
  test2(a);
 }
 }
+int
 m()
 {
   test (10);
diff --git gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-2.c 
gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-2.c
index a06d725..1579c24 100644
--- gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-2.c
+++ gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-2.c
@@ -1,10 +1,12 @@
 /* { dg-options "-O3 -c -fdump-ipa-inline-details -fno-early-inlining 
-fno-ipa-cp"  } */
+int
 t(int s, void **p)
 {
   int i;
   for (i;i<1;i+=s)
 p[i]=0;
 }
+int
 m(void **p)
 {
   t (10, p);
diff --git gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-3.c 
gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-3.c
index 110ae44..f8d61a0 100644
--- gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-3.c
+++ gcc/gcc/testsuite/gcc.dg/ipa/inlinehint-3.c
@@ -1,5 +1,6 @@
 /* { dg-options "-O3 -c -fdump-ipa-inline-details -fno-early-inlining 
-fno-ipa-cp"  } */
 void abort (v

Re: [PATCH] SPARC: add mcpu=leon3v7 target

[Daniel Hellstrom]

On 10/06/2014 10:40 AM, Eric Botcazou wrote:

I have sent an updated patch just now. In case -Aleon does not exist it
should select -Av7 instead of -Av8.

No patch was attached to this message though.


I posted it with v2 in the subject. I have now attached it.


Yes, we have. Just verified that with the FSF. It would be a nice for us to
have write access to the sparc parts.

OK, but the granularity is limited so you'll have write access to the entire
SVN repository of GCC.  You'll have "Write after approval" status so you'll
still need to post patches on gcc-patches@ and wait for someone (usually me
for SPARC) to approve them before installing them.

Everything is explained on http://gcc.gnu.org/svnwrite.html, including how to
request write access (you can mention me as the sponsor).


Thanks, I will check it out.

Daniel
>From be3f52f6daaa15aeb52eba1eace3e4f01e8f9f53 Mon Sep 17 00:00:00 2001
From: Daniel Hellstrom 
Date: Wed, 20 Aug 2014 10:53:22 +0100
Subject: [PATCH v2] SPARC: add mcpu=leon3v7 target

The LEON3/4 soft-core CPU has support for both SPARCv7 and SPARCv8 that
is configurable at design time. The majority of the LEON3 ASICs are v8
compatible, however when designing an as small LEON3 as possible, v7
without FPU is frequently used.

The current GCC leon3 support implies the SPARCv8 instruction set
which is not compatible with SPARCv7. Relying on the standard SPARCv7
(-mcpu=v7) target for a LEON3-V7 is not feasible since the atomic
instruction (CAS) can not be generated by standard v7.

 * config.gcc (sparc*-*-*): Accept mcpu=leon3v7 processor
 * doc/invoke.texi (SPARC options): add mcpu=leon3v7 comment
 * config/sparc/leon.md (leon3_load, leon_store, leon_fp_*):
   handle leon3v7 as leon3
 * config/sparc/sparc-opts.h (enum processor_type): Add PROCESSOR_LEON3V7
 * config/sparc/sparc.c (sparc_option_override): add leon3v7 support
 * config/sparc/sparc.h (TARGET_CPU_leon3v7): new define
 * config/sparc/sparc.md (cpu): add leon3v7
 * config/sparc/sparc.opt (enum processor_type): Add leon3v7
---
 gcc/config.gcc|5 +++-
 gcc/config/sparc/leon.md  |   14 ++--
 gcc/config/sparc/sparc-opts.h |1 +
 gcc/config/sparc/sparc.c  |3 ++
 gcc/config/sparc/sparc.h  |   44 +++--
 gcc/config/sparc/sparc.md |1 +
 gcc/config/sparc/sparc.opt|3 ++
 gcc/doc/invoke.texi   |   16 +++---
 8 files changed, 56 insertions(+), 31 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 605efc0..199e387 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3065,6 +3065,9 @@ if test x$with_cpu = x ; then
 	*-leon[3-9]*)
 	  with_cpu=leon3
 	  ;;
+	*-leon[3-9]v7*)
+	  with_cpu=leon3v7
+	  ;;
 	*)
 	  with_cpu="`echo ${target} | sed 's/-.*$//'`"
 	  ;;
@@ -3749,7 +3752,7 @@ case "${target}" in
 			case ${val} in
 			"" | sparc | sparcv9 | sparc64 \
 			| v7 | cypress \
-			| v8 | supersparc | hypersparc | leon | leon3 \
+			| v8 | supersparc | hypersparc | leon | leon3 | leon3v7 \
 			| sparclite | f930 | f934 | sparclite86x \
 			| sparclet | tsc701 \
 			| v9 | ultrasparc | ultrasparc3 | niagara | niagara2 \
diff --git a/gcc/config/sparc/leon.md b/gcc/config/sparc/leon.md
index b511397..e8050fa 100644
--- a/gcc/config/sparc/leon.md
+++ b/gcc/config/sparc/leon.md
@@ -29,11 +29,11 @@
 
 ;; Use a double reservation to work around the load pipeline hazard on UT699.
 (define_insn_reservation "leon3_load" 1
-  (and (eq_attr "cpu" "leon3") (eq_attr "type" "load,sload"))
+  (and (eq_attr "cpu" "leon3,leon3v7") (eq_attr "type" "load,sload"))
   "leon_memory*2")
 
 (define_insn_reservation "leon_store" 2
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "store"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "store"))
   "leon_memory*2")
 
 ;; This describes Gaisler Research's FPU
@@ -44,21 +44,21 @@
 (define_cpu_unit "grfpu_ds" "grfpu")
 
 (define_insn_reservation "leon_fp_alu" 4
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fp,fpcmp,fpmul"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fp,fpcmp,fpmul"))
   "grfpu_alu, nothing*3")
 
 (define_insn_reservation "leon_fp_divs" 16
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivs"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivs"))
   "grfpu_ds*14, nothing*2")
 
 (define_insn_reservation "leon_fp_divd" 17
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivd"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivd"))
   "grfpu_ds*15, nothing*2")
 
 (define_insn_reservation "leon_fp_sqrts" 24
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpsqrts"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpsqrts"))
   "grfpu_ds*22, nothing*2")
 
 (define_insn_reservation "leon_fp_sqrtd" 25
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpsqrtd"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpsqrtd"))
   "grfpu_ds*23, nothing*2")
diff --

[patch] Fix unaligned access in function returning composite type

[Eric Botcazou]

Hi,

In Ada, we support all sorts of data structure layout, including on strict-
alignment targets, and the compiler must generate glue code if necessary.
The problem here is a function returning a structure by invisible reference 
into a field which is not sufficient aligned because the enclosing object is 
packed: in this case, the caller passes an address that is not correctly 
aligned to the callee, which can result in an unaligned access in the callee.

Tested on x86_64-suse-linux and SPARC/Solaris, OK for the mainline.


2014-10-06  Eric Botcazou  

* calls.c (expand_call): Do not use the target as the return slot if
it is not sufficiently aligned.


2014-10-06  Eric Botcazou  

* gnat.dg/return4.adb: New test.
* gnat.dg/return4_pkg.ad[sb]: New helper.


-- 
Eric BotcazouIndex: calls.c
===
--- calls.c	(revision 215843)
+++ calls.c	(working copy)
@@ -2377,7 +2377,14 @@ expand_call (tree exp, rtx target, int i
   {
 	struct_value_size = int_size_in_bytes (rettype);
 
-	if (target && MEM_P (target) && CALL_EXPR_RETURN_SLOT_OPT (exp))
+	/* Even if it is semantically safe to use the target as the return
+	   slot, it may be not sufficiently aligned for the return type.  */
+	if (CALL_EXPR_RETURN_SLOT_OPT (exp)
+	&& target
+	&& MEM_P (target)
+	&& !(MEM_ALIGN (target) < TYPE_ALIGN (rettype)
+		 && SLOW_UNALIGNED_ACCESS (TYPE_MODE (rettype),
+	   MEM_ALIGN (target
 	  structure_value_addr = XEXP (target, 0);
 	else
 	  {
package Return4_Pkg is

  type Rec is record
I1, I2, I3 : Integer;
  end record;

  function Get_Value (I : Integer) return Rec;

end Return4_Pkg;
package body Return4_Pkg  is

  function Get_Value (I : Integer) return Rec is
Value : Rec := (I1 => I, I2 => I, I3 => I);
  begin
return Value;
  end;

end Return4_Pkg;
-- { dg-do run }
-- { dg-options "-O" }

with Return4_Pkg; use Return4_Pkg;

procedure Return4 is

  type Local_Rec is record
C : Character;
R : Rec;
  end record;
  pragma Pack (Local_Rec);

  L : Local_Rec;
  for L'Alignment use 2;

begin
  L.R := Get_Value (0);
  if L.R.I1 /= 0 then
raise Program_Error;
  end if;
end;

[PATCH] lto.c: add ARG_UNUSED for an argument

[Martin Liška]

Hello.

In lto.c, if #ifdef HAVE_WORKING_FORK isn't defined, 'last' argument is unused 
and in that case GCC cannot bootstrap due to a warning.

Ready for trunk?
Built on x86_64-linux-gnu.

Thanks,
Martin
gcc/lto/ChangeLog:

2014-10-06  Martin Liska  

* lto.c (stream_out): ARG_UNUSED added for last argument.
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 6cbb178..bc53632 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -2495,7 +2495,8 @@ wait_for_child ()
Fork if that seems to help.  */
 
 static void
-stream_out (char *temp_filename, lto_symtab_encoder_t encoder, bool last)
+stream_out (char *temp_filename, lto_symtab_encoder_t encoder,
+	bool ARG_UNUSED (last))
 {
 #ifdef HAVE_WORKING_FORK
   static int nruns;

Re: Profile mode maintenance patch

[Jonathan Wakely]

On 04/10/14 22:54 +0200, François Dumont wrote:

On 23/09/2014 13:27, Jonathan Wakely wrote:


Yes, OK for trunk - thanks very much.


Hi

   There was in fact one last test failing, ext/profile/mh.cc, a 
profile mode specific test. It must have been failing for quite a 
while since malloc hooks has been deprecated.


I don't understand why that would make it fail, deprecated doesn't
mean it doesn't work.

However, the declaration of __malloc_initialize_hook has changed at
some point between glibc 2.11 and 2.18, so the test doesn't compile
for me on Fedora 20.

Secondly, the test is useless if it isn't actually run, so the
{ dg-do compile } must be removed.

Finally, the test returns 1, so even if it is executed it causes a
FAIL.

What a mess.

It is normally testing 
the profile mode protection against recursion if memory allocation 
functions are redefined. It was based on malloc but we use in fact new 
operator. So I rewrite the test using new/delete operators.


OK.

   This new test version is attached, I removed those 2 lines at the 
beginning:


// { dg-do compile { target *-*-linux* *-*-gnu* } }
// { dg-xfail-if "" { uclibc } { "*" } { "" } }

   I think that this test can now be executed and see no reason why 
it should fail with uclibc. Do you confirm ?


Yes, the test should be portable now, and should actually PASS.

The name of the test doesn't make much sense now though, maybe rename
it from mh.cc to replace_new.cc or something.

   I attached the full patch again. I also remove useless virtual 
destructor or methods, no need for polymorphism.


OK.

(I still think we should just remove the whole Profile Mode ...)

[C++ Patch] PR 55250

[Paolo Carlini]

Hi,

the second half of the bug report is about C++14 variable declarations 
in constexpr functions, an implementation request which should be 
already done by Jason's recent commit.


The first half is about us not rejecting in C++11 mode type declarations 
in constexpr functions outside, per 7.1.5/3/4:


"typedef declarations and alias-declarations that do not define 
classes or enumerations,"


In fact, however, while working on the issue, I noticed that conversely 
we reject *all* type declarations in constructors (actually we used to 
ICE on those, which a while ago I turned to reject valid), eg:


struct S
{
constexpr S() { typedef int T; }
};

Thus I prepared the below, which in C++11 mode checks the exact 
requirements above, both for constructors and all the other functions. I 
had to add handling of BIND_EXPRs to the main conditional of 
build_constexpr_constructor_member_initializers, otherwise we ICE 
immediately on something as simple as the snippet above: I think all is 
fine because we get to the conditional having checked the BIND_EXPR_VARS 
part with the new checking function. Tested x86_64-linux.


Thanks!
Paolo.

/
/cp
2014-10-06  Paolo Carlini  

PR c++/55250
* semantics.c (check_constexpr_bind_expr_vars): New.
(check_constexpr_ctor_body, massage_constexpr_body): Use it.
(build_constexpr_constructor_member_initializers): Handle
BIND_EXPR in the main conditional.

/testsuite
2014-10-06  Paolo Carlini  

PR c++/55250
* g++.dg/cpp0x/constexpr-type-decl1.C: New.
* g++.dg/cpp0x/constexpr-type-def1.C: Likewise.
* g++.dg/cpp1y/constexpr-type-def1.C: Likewise.
Index: cp/semantics.c
===
--- cp/semantics.c  (revision 215914)
+++ cp/semantics.c  (working copy)
@@ -7833,6 +7833,26 @@ build_data_member_initialization (tree t, vec= cxx14)
+return true;
+
+  for (tree var = BIND_EXPR_VARS (t); var; var = DECL_CHAIN (var))
+if (TREE_CODE (var) == TYPE_DECL
+   && ! is_typedef_decl (var)
+   && ! TYPE_DECL_ALIAS_P (var))
+  return false;
+  return true;
+}
+
 /* Make sure that there are no statements after LAST in the constructor
body represented by LIST.  */
 
@@ -7850,7 +7870,7 @@ check_constexpr_ctor_body (tree last, tree list)
break;
  if (TREE_CODE (t) == BIND_EXPR)
{
- if (BIND_EXPR_VARS (t))
+ if (!check_constexpr_bind_expr_vars (t))
{
  ok = false;
  break;
@@ -7860,8 +7880,6 @@ check_constexpr_ctor_body (tree last, tree list)
  else
continue;
}
- /* We currently allow typedefs and static_assert.
-FIXME allow them in the standard, too.  */
  if (TREE_CODE (t) != STATIC_ASSERT)
{
  ok = false;
@@ -7964,6 +7982,8 @@ build_constexpr_constructor_member_initializers (t
 "a function-try-block");
   return error_mark_node;
 }
+  else if (TREE_CODE (body) == BIND_EXPR)
+ok = build_data_member_initialization (BIND_EXPR_BODY (body), &vec);
   else if (EXPR_P (body))
 ok = build_data_member_initialization (body, &vec);
   else
@@ -8055,7 +8075,8 @@ massage_constexpr_body (tree fun, tree body)
 body = EH_SPEC_STMTS (body);
   if (TREE_CODE (body) == MUST_NOT_THROW_EXPR)
body = TREE_OPERAND (body, 0);
-  if (TREE_CODE (body) == BIND_EXPR)
+  if (TREE_CODE (body) == BIND_EXPR
+ && check_constexpr_bind_expr_vars (body))
body = BIND_EXPR_BODY (body);
   body = constexpr_fn_retval (body);
 }
Index: testsuite/g++.dg/cpp0x/constexpr-type-decl1.C
===
--- testsuite/g++.dg/cpp0x/constexpr-type-decl1.C   (revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-type-decl1.C   (working copy)
@@ -0,0 +1,58 @@
+// PR c++/55250
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert((X),#X)
+
+struct GS { constexpr operator int() { return 1; } };
+enum GE { y = 1 };
+
+constexpr int Test1(int x) { typedef int T; return T(x) + 1; }
+constexpr int Test2(int x) { using T = int; return T(x) + 1; }
+constexpr int Test3(int x) { typedef GS T; return x + T(); }
+constexpr int Test4(int x) { using T = GS; return x + T(); }
+constexpr int Test5(int x) { typedef GE T; return x + T::y; }
+constexpr int Test6(int x) { using T = GE; return x + T::y; }
+
+SA(Test1(2) == 3);
+SA(Test2(2) == 3);
+SA(Test3(2) == 3);
+SA(Test4(2) == 3);
+SA(Test5(2) == 3);
+SA(Test6(2) == 3);
+
+struct S1
+{
+  constexpr S1() { typedef int T; SA(T(1) == 1); }
+};
+
+struct S2
+{
+  constexpr S2() { using T = int; SA(T(1) == 1); }
+};
+
+struct S3
+{
+  constexpr S3() { typedef GS T; SA(T() == 1); }
+};
+
+struct S4
+{
+  constexpr S4() { using T = GS; SA(T() == 1); }
+};
+
+struct S5
+{
+  constexpr 

[PATCH] gcc.dg/debug/ cleanup

[Marek Polacek]

This patch is a cleanup of tests in gcc.dg/debug/ directory.
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02656.html for more info.

Tested on x86_64-linux: vanilla results == results with this patch ==
results with this patch and gnu11 as a default.

Applying to trunk.

2014-10-06  Marek Polacek  

* gcc.dg/debug/20010207-1.c: Use -fgnu89-inline.  Fix implicit
declarations.
* gcc.dg/debug/dwarf2-2.c: Fix defaulting to int.
* gcc.dg/debug/dwarf2/ipa-cp1.c: Likewise.
* gcc.dg/debug/pr42767.c: Likewise.
* gcc.dg/debug/dwarf2/dwarf-die3.c: Use -fgnu89-inline.
* gcc.dg/debug/dwarf2/inline1.c: Likewise.
* gcc.dg/debug/dwarf2/inline2.c: Likewise.
* gcc.dg/debug/pr49522.c: Fix implicit declarations.

diff --git gcc/gcc/testsuite/gcc.dg/debug/20010207-1.c 
gcc/gcc/testsuite/gcc.dg/debug/20010207-1.c
index 513d7a4..4dd92a8 100644
--- gcc/gcc/testsuite/gcc.dg/debug/20010207-1.c
+++ gcc/gcc/testsuite/gcc.dg/debug/20010207-1.c
@@ -1,4 +1,6 @@
 /* { dg-do compile } */
+/* { dg-options "-fgnu89-inline" } */
+int f2 (void);
 extern inline int f1 (void) {return f2();}
 int f3 (void) {return f1();}
 int f1 (void) {return 0;}
diff --git gcc/gcc/testsuite/gcc.dg/debug/dwarf2-2.c 
gcc/gcc/testsuite/gcc.dg/debug/dwarf2-2.c
index 0c3cee1..aa6778f 100644
--- gcc/gcc/testsuite/gcc.dg/debug/dwarf2-2.c
+++ gcc/gcc/testsuite/gcc.dg/debug/dwarf2-2.c
@@ -8,6 +8,7 @@ inline double fx (double x)
   return 3 * x;
 }
 
+int
 main ()
 {
   double a = 0, fx (double), foo ();
diff --git gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die3.c 
gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die3.c
index 2b071fc..6e1d73e 100644
--- gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die3.c
+++ gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die3.c
@@ -1,6 +1,6 @@
 /* Verify that extern inline function never actually inlined has no abstract 
DIE.  */
 /* { dg-do compile } */
-/* { dg-options "-O0 -gdwarf -dA" } */
+/* { dg-options "-O0 -gdwarf -dA -fgnu89-inline" } */
 /* { dg-final { scan-assembler-not "DW_AT_inline" } } */
 extern inline int t()
 {
diff --git gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline1.c 
gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline1.c
index bd7f7b9..3b4b004 100644
--- gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline1.c
+++ gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O0 -gdwarf -dA" } */
+/* { dg-options "-O0 -gdwarf -dA -fgnu89-inline" } */
 void e(int);
 __attribute__ ((always_inline)) inline int
 t(int function_parameter)
diff --git gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c 
gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
index b194769..b2ae111 100644
--- gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
+++ gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
@@ -14,7 +14,7 @@
   properly nested DW_TAG_inlined_subroutine DIEs for third, second and first.
 */
 
-/* { dg-options "-O -g3 -gdwarf -dA" } */
+/* { dg-options "-O -g3 -gdwarf -dA -fgnu89-inline" } */
 /* { dg-do compile } */
 
 /* There are 6 inlined subroutines:
diff --git gcc/gcc/testsuite/gcc.dg/debug/dwarf2/ipa-cp1.c 
gcc/gcc/testsuite/gcc.dg/debug/dwarf2/ipa-cp1.c
index 395c544..62a5323 100644
--- gcc/gcc/testsuite/gcc.dg/debug/dwarf2/ipa-cp1.c
+++ gcc/gcc/testsuite/gcc.dg/debug/dwarf2/ipa-cp1.c
@@ -17,6 +17,7 @@ t(int constant_propagated_par)
   q(local_var);
   q(local_var);
 }
+int
 main()
 {
   t(5);
diff --git gcc/gcc/testsuite/gcc.dg/debug/pr42767.c 
gcc/gcc/testsuite/gcc.dg/debug/pr42767.c
index 1f0e25f..ef7a5c3 100644
--- gcc/gcc/testsuite/gcc.dg/debug/pr42767.c
+++ gcc/gcc/testsuite/gcc.dg/debug/pr42767.c
@@ -6,6 +6,7 @@ struct lineno_cache_entry
 {
   unsigned long size;
 };
+int
 _bfd_link_section_stabs (struct lineno_cache_entry * stabsec)
 {
   unsigned long count;
diff --git gcc/gcc/testsuite/gcc.dg/debug/pr49522.c 
gcc/gcc/testsuite/gcc.dg/debug/pr49522.c
index 3fa3bfb..4a2d14d 100644
--- gcc/gcc/testsuite/gcc.dg/debug/pr49522.c
+++ gcc/gcc/testsuite/gcc.dg/debug/pr49522.c
@@ -7,6 +7,8 @@ volatile int val2 = 7L;
 long long val3;
 int *ptr = &val1;
 
+int foo (void);
+
 static int
 func1 ()
 {

Marek

RFA: fix mode confusion in caller-save.c:replace_reg_with_saved_mem

[Joern Rennecke]

Investigating an ICE while trying to compile libgcc2.c:__udivmoddi4 for
a new avr variant with different register set/allocation order, I found
replace_reg_with_saved_mem falling over its own nonsense.  The instruction:

(debug_insn 97 96 98 2 (var_location:SI __x2 (mult:SI (lshiftrt:SI
(reg/v:SI 18 r18 [orig:58 q0 ] [58])
(const_int 16 [0x10]))
(reg/v:SI 61 [ __vl ])))
../../gcc/gcc/testsuite/gcc.target/avr/tiny-caller-save.c:67 -1
 (nil))

would be transformed into:

(debug_insn 97 96 98 2 (var_location:SI __x2 (mult:SI (lshiftrt:SI (concatn:SI [
(reg:SI 18 r18)
(reg:SI 19 r19)
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 43 [0x2b])) [6  S1 A8])
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 44 [0x2c])) [6  S1 A8])
])
(const_int 16 [0x10]))
(reg/v:SI 61 [ __vl ])))
../../gcc/gcc/testsuite/gcc.target/avr/tiny-caller-save.c:67 -1

Note that r18 and r19 inside the concatn are supposed to be single hard
registers, but as the word size of this processor is 8 bit, SImode
extends actually
over four hard registers.  save_mode is SImode because four registers can be
saved/restored at once.

The attached patch fixes the failure by using word_mode if smode would cover
multiple hard registers.
bootstrapped & regtested on i686-pc-linux-gnu.

OK to apply?


caller-save-patch
Description: Binary data

Re: [PATCH] SPARC: add mcpu=leon3v7 target

[Eric Botcazou]

> I have sent an updated patch just now. In case -Aleon does not exist it
> should select -Av7 instead of -Av8.

No patch was attached to this message though.

> Yes, we have. Just verified that with the FSF. It would be a nice for us to
> have write access to the sparc parts.

OK, but the granularity is limited so you'll have write access to the entire 
SVN repository of GCC.  You'll have "Write after approval" status so you'll 
still need to post patches on gcc-patches@ and wait for someone (usually me 
for SPARC) to approve them before installing them.

Everything is explained on http://gcc.gnu.org/svnwrite.html, including how to 
request write access (you can mention me as the sponsor).

-- 
Eric Botcazou

Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Andrew Haley]

On 06/10/14 05:08, Chen Gang wrote:
> After try normal configure, get almost the same result, I guess, our
> testsuite under Darwin x86_64 is OK.
> 
> If no any additional reply within a week, I shall continue to try to
> analyze the libjava Throw_2 issue.

Throw_2 is a test specially contrived to detect segfaults that are
not being correctly detected and turned into NullPointerException()s.
A failure indicates that the segfault signal handler is broken.

Andrew.

[PATCH] gcc.dg/lto/ cleanup

[Marek Polacek]

This patch is a cleanup of tests in gcc.dg/lto/ directory.
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02656.html for more info.

I had to use gnu_inline attribute, because primary LTO files can't have
dg-options, and using dg-lto-options would reduce testing.

Tested on x86_64-linux: vanilla results == results with this patch ==
results with this patch and gnu11 as a default.

Applying to trunk.

2014-10-03  Marek Polacek  

* gcc.dg/lto/20080924_0.c: Fix defaulting to int.
* gcc.dg/lto/20090213_0.c: Likewise.
* gcc.dg/lto/20090706-2_0.c: Likewise.
* gcc.dg/lto/attr-weakref-1_1.c: Likewise.
* gcc.dg/lto/attr-weakref-1_2.c: Likewise.
* gcc.dg/lto/ipareference2_0.c: Likewise.
* gcc.dg/lto/ipareference_0.c: Likewise.
* gcc.dg/lto/ipareference_1.c: Likewise.
* gcc.dg/lto/pr55703_0.c: Likewise.
* gcc.dg/lto/resolutions_0.c: Likewise.
* gcc.dg/lto/trans-mem-3_1.c: Likewise.
* gcc.dg/lto/20081115_0.c: Fix defaulting to int.  Fix implicit
declarations.  Mark function as gnu_inline.
* gcc.dg/lto/20081118_0.c: Likewise.
* gcc.dg/lto/20081201-1_0.c: Likewise.
* gcc.dg/lto/20081115_1.c: Mark function as gnu_inline.
* gcc.dg/lto/20081118_1.c: Likewise.
* gcc.dg/lto/20081120-1_1.c: Likewise.
* gcc.dg/lto/20081201-1_1.c: Likewise.
* gcc.dg/lto/20081210-1_0.c: Likewise.
* gcc.dg/lto/20090218-1_0.c: Likewise.
* gcc.dg/lto/20091006-1_0.c: Likewise.
* gcc.dg/lto/20090218-1_1.c: Use -fgnu89-inline.
* gcc.dg/lto/20090218-2_1.c: Likewise.
* gcc.dg/lto/materialize-1_0.c: Likewise.
* gcc.dg/lto/20090218-2_0.c: Fix implicit declarations.
* gcc.dg/lto/20091013-1_1.c: Likewise.
* gcc.dg/lto/20091013-1_2.c: Likewise.
* gcc.dg/lto/20091015-1_2.c: Likewise.
* gcc.dg/lto/20091027-1_1.c: Likewise.
* gcc.dg/lto/pr48622_0.c: Likewise.
* gcc.dg/lto/attr-weakref-1_0.c: Fix implicit declarations. Fix
defaulting to int.
* gcc.dg/lto/pr47924_0.c: Return 0 instead of nothing.

diff --git gcc/gcc/testsuite/gcc.dg/lto/20080924_0.c 
gcc/gcc/testsuite/gcc.dg/lto/20080924_0.c
index db77450..86e22f0 100644
--- gcc/gcc/testsuite/gcc.dg/lto/20080924_0.c
+++ gcc/gcc/testsuite/gcc.dg/lto/20080924_0.c
@@ -1,6 +1,7 @@
 /* { dg-lto-do assemble }  */
 /* { dg-lto-options {{-O2 -flto -funsigned-char}} }  */ 
 typedef unsigned int size_t;
+void
 foo (const char *src, unsigned char *dst, size_t size)
 {
   int ch;
diff --git gcc/gcc/testsuite/gcc.dg/lto/20081115_0.c 
gcc/gcc/testsuite/gcc.dg/lto/20081115_0.c
index c9f4c80..2174cbb 100644
--- gcc/gcc/testsuite/gcc.dg/lto/20081115_0.c
+++ gcc/gcc/testsuite/gcc.dg/lto/20081115_0.c
@@ -1,13 +1,14 @@
 /* { dg-lto-options {{-O2 -DOPTIMIZE -flto -flto-partition=1to1} {-O0 -flto 
-flto-partition=1to1}} } */
 
 extern void abort (void);
+extern int foo (void);
 
 int f (void)
 {
   return 1;
 }
 
-extern inline int
+extern inline int __attribute__ ((gnu_inline))
 e_inline_baz (void)
 {
   return 1 + f();
@@ -19,6 +20,7 @@ bar (void)
   return e_inline_baz ();
 }
 
+int
 main ()
 {
 #ifdef OPTIMIZE
diff --git gcc/gcc/testsuite/gcc.dg/lto/20081115_1.c 
gcc/gcc/testsuite/gcc.dg/lto/20081115_1.c
index 62ffa52..bbde9ab 100644
--- gcc/gcc/testsuite/gcc.dg/lto/20081115_1.c
+++ gcc/gcc/testsuite/gcc.dg/lto/20081115_1.c
@@ -1,4 +1,4 @@
-extern inline int
+extern inline int __attribute__ ((gnu_inline))
 e_inline_baz (void)
 {
   return 2 + 1;
diff --git gcc/gcc/testsuite/gcc.dg/lto/20081118_0.c 
gcc/gcc/testsuite/gcc.dg/lto/20081118_0.c
index b37eb31..58e0dfd 100644
--- gcc/gcc/testsuite/gcc.dg/lto/20081118_0.c
+++ gcc/gcc/testsuite/gcc.dg/lto/20081118_0.c
@@ -2,8 +2,9 @@
 
 extern void abort (void);
 extern int f (void);
+extern int foo (void);
 
-extern inline int
+extern inline int __attribute__ ((gnu_inline))
 e_inline_baz (void)
 {
  return 1 + f();
@@ -15,6 +16,7 @@ bar (void)
  return e_inline_baz ();
 }
 
+int
 main ()
 {
 #ifdef OPTIMIZE
diff --git gcc/gcc/testsuite/gcc.dg/lto/20081118_1.c 
gcc/gcc/testsuite/gcc.dg/lto/20081118_1.c
index f0a8c3c..509c290 100644
--- gcc/gcc/testsuite/gcc.dg/lto/20081118_1.c
+++ gcc/gcc/testsuite/gcc.dg/lto/20081118_1.c
@@ -1,6 +1,6 @@
 extern int f (void);
 
-extern inline int
+extern inline int __attribute__ ((gnu_inline))
 e_inline_baz (void)
 {
  return 2 + f ();
diff --git gcc/gcc/testsuite/gcc.dg/lto/20081120-1_1.c 
gcc/gcc/testsuite/gcc.dg/lto/20081120-1_1.c
index 73d2500..f55eb48 100644
--- gcc/gcc/testsuite/gcc.dg/lto/20081120-1_1.c
+++ gcc/gcc/testsuite/gcc.dg/lto/20081120-1_1.c
@@ -1,3 +1,3 @@
 extern int stat(void) __asm__("" "stat64");
-extern inline int stat(void) { }
+extern inline __attribute__((gnu_inline)) int stat(void) { }
 static void foo(void) { stat(); }
diff --git gcc/gcc/testsuite/gcc.dg/lto/20081201-1_0.c 
gcc/gcc/testsuite/gcc.dg/lto/20081201-1_0.c
index b689644..bd3e251 100644
--- gcc/gcc/

Re: [PATCH 1/2] PR debug/63239 Add DWARF representation for C++11 deleted member function.

[Steven Bosscher]

On Mon, Oct 6, 2014 at 9:54 AM, Mark Wielaard wrote:
> Just removing the # prefix (but keeping the space) from
> scan-assembler-times should work for both our cases. I just don't know
> why our .s outputs look different.

Wild guess: different comment marker in the target's assembly language?

Ciao!
Steven

Re: [PATCH 1/2] PR debug/63239 Add DWARF representation for C++11 deleted member function.

[Mark Wielaard]

On Mon, 2014-10-06 at 09:38 +0200, Andreas Schwab wrote:
> Mark Wielaard  writes:
> 
> > diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/deleted-member-function.C 
> > b/gcc/testsuite/g++.dg/debug/dwarf2/deleted-member-function.C
> > new file mode 100644
> > index 000..4cc77e6
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/debug/dwarf2/deleted-member-function.C
> > @@ -0,0 +1,17 @@
> > +// { dg-do compile }
> > +// { dg-options "-O -std=c++11 -g -dA" }
> > +// { dg-final { scan-assembler-times "# DW_AT_GNU_deleted" 2 } }
> 
> $ grep DW_AT_GNU_deleted deleted-member-function.s
> // DW_AT_GNU_deleted
> // DW_AT_GNU_deleted
> .uleb128 0x211a // (DW_AT_GNU_deleted)
> .uleb128 0x211a // (DW_AT_GNU_deleted)

With gcc master this testcase gives:

$ grep DW_AT_GNU_deleted deleted-member-function.s
# DW_AT_GNU_deleted
# DW_AT_GNU_deleted
.uleb128 0x211a # (DW_AT_GNU_deleted)
.uleb128 0x211a # (DW_AT_GNU_deleted)

Somehow in your version the # comment turned into // ?

Just removing the # prefix (but keeping the space) from
scan-assembler-times should work for both our cases. I just don't know
why our .s outputs look different. If it is something that can be fixed
through setting a dg-options that would be preferable I think.

Cheers,

Mark