Re: [PATCH] LRA: Fix caller-save store/restore instruction for large mode

[Bin.Cheng]

On Mon, Jan 5, 2015 at 3:44 PM, Kito Cheng  wrote:
> Hi Vladimir:
>   This patch has a discusses with you in May 2014, this patch is about
> the caller-save register store and restore instruction generation, the
> current LRA implementation will miss caller-save store/restore
> instruction if need one more instruction.
>
> You said you will investigate for this on IRC, so I don't send the
> patch last year, however ARM guys seem got this problem too, so I
> think it's time to send this patch :)
>
> ChangeLog
>
> 2015-01-05  Kito Cheng  
>
> * lra-constraints.c (split_reg): Fix caller-save store/restore
> instruction generation.
Hi,
Thanks for saving my work, I was going to send this exact patch.
Note that we have PR64348 tracking the issue now.

Thanks,
bin

RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Bernd Edlinger]

Hi,

On Sun, 4 Jan 2015 14:18:59, Mike Stump wrote:
>
>> But tsan still gets at least 90% chance to spot that. As a matter of fact, 
>> the tsan runtime is just _incredibly_ fast,
>> and catches errors, with a very high reliability. But it is racy by design.
>
> You say by design. I’m skeptical of that. Can you quote the email or the code 
> were they said I wanted to design a system that wasn’t 100% reliable, because 
> the best they could do was 2% slower, and they didn’t want it to be 2% 
> slower? I tend to think someone didn’t figure out they could atomically, 
> locklessly do the update, or they didn’t understand the performance hit on 
> the lockless code was small, or worse, they had no clue it was racy. I’d be 
> curious to know. Maybe, there are other complications that prevent it from 
> being non-racy.
>

see for instance this thread "Is TSan an exact tool?":
https://groups.google.com/forum/#!topic/thread-sanitizer/mB73m6Nltaw

When I say "by design" I did not mean to say something negative on the code 
quality.

It is an excellent design.  One of the design principles is speed.
We are able to use TSan to successfully test complex communication
protocols.  If it would slow down the execution more than absolutely necessary
it would be useless.

> Using sleep goes back decades, and I think that style should have mostly died 
> around 1987 or so. It’s 2015, and I’d rather consider it an obsolete style, 
> exclusive of hard real-time. I bring it up, as I’ve been burned by sleep and 
> people that think sleep is a nice solution.

The sleep(1) is only in the positive test cases. That is obviously not the best 
possible solution.

... And it makes the test suite run at least 10 seconds longer... :-)

Nevertheless I would prefer to silence the test now with sleep(1),

And come back later with a follow-up patch to use a un-instrumented and
non-interceptable synchronization primitive in all tsan tests. As it is at least
not obvious how to do that in the test suite.  But it must be possible.


Bernd.
  

Re: [PATCH][PING] libobjc: Properly handle classes without instance variables in class_copyIvarList ().

[Dimitris Papavasiliou]

Ping!

On 12/24/2014 07:28 PM, Dimitris Papavasiliou wrote:

Hello,

The attached patch fixes an issue reported a couple of years ago in Bug
51891 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891).  The problem
is caused because classes without instance variables have no ivar list
at all, so that their ivars pointer is NULL, but the code in
class_copyIvarList () is unaware of this.

That this is in fact so can be easily verified by checking the code of
class_addIvar in the same source file, where the ivars list is allocated
when the first ivar is added.  The code there also checks for a NULL
ivars pointer.

The patch also adds a simple test-case for this issue.  I think that the
ChangeLog entry should be something along the lines of:

2014-12-24  Dimitris Papavasiliou  

  PR libobjc/51891
  * libobjc/ivars.c: Add a check for classes without instance
 variables, which have a NULL ivar list pointer.
  * gcc/testsuite/objc.dg/gnu-api-2-class.m: Add a test case
 for the above change.

I hope I got the formatting right.  I've run make -k check-objc and all
tests pass without problems.

Let me know if there are any problems, or if I can do anything else to
facilitate the acceptance of the patch.

Regards,
Dimitris

[committed] Better location for -Wchar-subscripts (PR c/64423)

[Marek Polacek]

warn_array_subscript_with_type_char wasn't getting a location,
so the caret location was off.  Thus fixed.

Bootstrapped/regtested on x86_64-linux, applying to trunk.

2015-01-05  Marek Polacek  

PR c/64423
c-family/
* c-common.c (warn_array_subscript_with_type_char): Add location_t
parameter.  Use it.
* c-common.h (warn_array_subscript_with_type_char): Update
declaration.
c/
* c-typeck.c (build_array_ref): Pass loc down to
warn_array_subscript_with_type_char.
cp/
* typeck.c (cp_build_array_ref): Pass loc down to
warn_array_subscript_with_type_char.
testsuite/
* gcc.dg/pr64423.c: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 1066c6b..af7a07e 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -11238,11 +11238,12 @@ check_missing_format_attribute (tree ltype, tree 
rtype)
warning only for non-constant value of type char.  */
 
 void
-warn_array_subscript_with_type_char (tree index)
+warn_array_subscript_with_type_char (location_t loc, tree index)
 {
   if (TYPE_MAIN_VARIANT (TREE_TYPE (index)) == char_type_node
   && TREE_CODE (index) != INTEGER_CST)
-warning (OPT_Wchar_subscripts, "array subscript has type %");
+warning_at (loc, OPT_Wchar_subscripts,
+   "array subscript has type %");
 }
 
 /* Implement -Wparentheses for the unexpected C precedence rules, to
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index c7eebcf..d1f09a6 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -1014,7 +1014,7 @@ extern tree builtin_type_for_size (int, bool);
 
 extern void c_common_mark_addressable_vec (tree);
 
-extern void warn_array_subscript_with_type_char (tree);
+extern void warn_array_subscript_with_type_char (location_t, tree);
 extern void warn_about_parentheses (location_t,
enum tree_code,
enum tree_code, tree,
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index abd452a..37beb64 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -2501,7 +2501,7 @@ build_array_ref (location_t loc, tree array, tree index)
   /* ??? Existing practice has been to warn only when the char
  index is syntactically the index, not for char[array].  */
   if (!swapped)
- warn_array_subscript_with_type_char (index);
+ warn_array_subscript_with_type_char (loc, index);
 
   /* Apply default promotions *after* noticing character types.  */
   index = default_conversion (index);
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 9368b49..fc85ec3 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -3081,7 +3081,7 @@ cp_build_array_ref (location_t loc, tree array, tree idx,
 {
   tree rval, type;
 
-  warn_array_subscript_with_type_char (idx);
+  warn_array_subscript_with_type_char (loc, idx);
 
   if (!INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (TREE_TYPE (idx)))
{
@@ -3191,7 +3191,7 @@ cp_build_array_ref (location_t loc, tree array, tree idx,
return error_mark_node;
   }
 
-warn_array_subscript_with_type_char (idx);
+warn_array_subscript_with_type_char (loc, idx);
 
 ret = cp_build_indirect_ref (cp_build_binary_op (input_location,
 PLUS_EXPR, ar, ind,
diff --git gcc/testsuite/gcc.dg/pr64423.c gcc/testsuite/gcc.dg/pr64423.c
index e69de29..c228acb 100644
--- gcc/testsuite/gcc.dg/pr64423.c
+++ gcc/testsuite/gcc.dg/pr64423.c
@@ -0,0 +1,13 @@
+/* PR c/64423 */
+/* { dg-do compile } */
+/* { dg-options "-Wchar-subscripts" } */
+
+int a[100];
+
+int
+f (char c)
+{
+  return a[c]  /* { dg-warning "11:array subscript has type .char." } 
*/
+  + a[c]   /* { dg-warning "14:array subscript has type .char." } 
*/
++ a[c];/* { dg-warning "16:array subscript has type .char." } 
*/
+}

Marek

[PATCH] Fix up 2 Copyright years lines

[Jakub Jelinek]

Hi!

I've committed following fix, update-copyright.py was complaining about
these.

2015-01-05  Jakub Jelinek  

* auto-profile.c, auto-profile.h: Fix up Copyright line.

--- gcc/auto-profile.c  (revision 219184)
+++ gcc/auto-profile.c  (working copy)
@@ -1,5 +1,5 @@
 /* Read and annotate call graph profile from the auto profile data file.
-   Copyright (C) 2014. Free Software Foundation, Inc.
+   Copyright (C) 2014 Free Software Foundation, Inc.
Contributed by Dehao Chen (de...@google.com)
 
 This file is part of GCC.
--- gcc/auto-profile.h  (revision 219184)
+++ gcc/auto-profile.h  (working copy)
@@ -1,5 +1,5 @@
 /* auto-profile.h - Defines data exported from auto-profile.c
-   Copyright (C) 2014. Free Software Foundation, Inc.
+   Copyright (C) 2014 Free Software Foundation, Inc.
Contributed by Dehao Chen (de...@google.com)
 
 This file is part of GCC.

Jakub

*ping* [patch, fortran] Fix for PR 47676

[Thomas Koenig]

Am 30.12.2014 um 01:25 schrieb Thomas Koenig:
> Hello world,
> 
> this patch fixes the long-standing bug.  A missing temporary
> causes an invalid read in realloc_on_assign_5.f03 which
> only becomes noticable when setting MALLOC_CHECK_ or when
> using valgrind.  The bug has three duplicates in the
> data base, so people keep stumbling across this.

Ping ?

https://gcc.gnu.org/ml/fortran/2014-12/msg00137.html

[committed] Update copyright years, part 1

[Jakub Jelinek]

Hi!

I've committed following patch to update the user visible copyright years
(and rolled new year of gcc/ada and libjava ChangeLogs).

2015-01-05  Jakub Jelinek  

gcc/
* gcc.c (process_command): Update copyright notice dates.
* gcov-dump.c: Ditto.
* gcov.c: Ditto.
* doc/cpp.texi: Bump @copying's copyright year.
* doc/cppinternals.texi: Ditto.
* doc/gcc.texi: Ditto.
* doc/gccint.texi: Ditto.
* doc/gcov.texi: Ditto.
* doc/install.texi: Ditto.
* doc/invoke.texi: Ditto.
gcc/fortran/
* gfortranspec.c (lang_specific_driver): Update copyright notice
dates.
* gfc-internals.texi: Bump @copying's copyright year.
* gfortran.texi: Ditto.
* intrinsic.texi: Ditto.
* invoke.texi: Ditto.
gcc/go/
* gccgo.texi: Bump @copyrights-go year.
gcc/java/
* jcf-dump.c (version): Update copyright notice dates.
libgomp/
* libgomp.texi: Bump @copying's copyright year.
libquadmath/
* libquadmath.texi: Bump @copying's copyright year.
libitm/
* libitm.texi: Bump @copying's copyright year.
gcc/ada/
* gnat_ugn.texi: Bump @copying's copyright year.
libjava/
* classpath/gnu/java/rmi/registry/RegistryImpl.java (version): Update
copyright notice dates.
* classpath/tools/gnu/classpath/tools/orbd/Main.java (run): Ditto.
* gnu/gcj/convert/Convert.java (version): Update copyright notice
dates.
* gnu/gcj/tools/gcj_dbtool/Main.java (main): Ditto.

--- gcc/ada/gnat_ugn.texi   (revision 219185)
+++ gcc/ada/gnat_ugn.texi   (working copy)
@@ -8,14 +8,14 @@
 @co
 @c G N A T _ U G No
 @co
-@c   Copyright (C) 1992-2014, Free Software Foundation, Inc.  o
+@c   Copyright (C) 1992-2015, Free Software Foundation, Inc.  o
 @co
 @c 
 
 @setfilename gnat_ugn.info
 
 @copying
-Copyright @copyright{} 1995-2014 Free Software Foundation,
+Copyright @copyright{} 1995-2015 Free Software Foundation,
 Inc.
 
 Permission is granted to copy, distribute and/or modify this document
--- gcc/doc/cpp.texi(revision 219185)
+++ gcc/doc/cpp.texi(working copy)
@@ -10,7 +10,7 @@
 
 @copying
 @c man begin COPYRIGHT
-Copyright @copyright{} 1987-2014 Free Software Foundation, Inc.
+Copyright @copyright{} 1987-2015 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
--- gcc/doc/cppinternals.texi   (revision 219185)
+++ gcc/doc/cppinternals.texi   (working copy)
@@ -18,7 +18,7 @@
 @ifinfo
 This file documents the internals of the GNU C Preprocessor.
 
-Copyright (C) 2000-2014 Free Software Foundation, Inc.
+Copyright (C) 2000-2015 Free Software Foundation, Inc.
 
 Permission is granted to make and distribute verbatim copies of
 this manual provided the copyright notice and this permission notice
@@ -47,7 +47,7 @@ into another language, under the above c
 @page
 @vskip 0pt plus 1filll
 @c man begin COPYRIGHT
-Copyright @copyright{} 2000-2014 Free Software Foundation, Inc.
+Copyright @copyright{} 2000-2015 Free Software Foundation, Inc.
 
 Permission is granted to make and distribute verbatim copies of
 this manual provided the copyright notice and this permission notice
--- gcc/doc/gcc.texi(revision 219185)
+++ gcc/doc/gcc.texi(working copy)
@@ -40,7 +40,7 @@
 @c %**end of header
 
 @copying
-Copyright @copyright{} 1988-2014 Free Software Foundation, Inc.
+Copyright @copyright{} 1988-2015 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
--- gcc/doc/gccint.texi (revision 219185)
+++ gcc/doc/gccint.texi (working copy)
@@ -26,7 +26,7 @@
 @c %**end of header
 
 @copying
-Copyright @copyright{} 1988-2014 Free Software Foundation, Inc.
+Copyright @copyright{} 1988-2015 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
--- gcc/doc/gcov.texi   (revision 219185)
+++ gcc/doc/gcov.texi   (working copy)
@@ -4,7 +4,7 @@
 
 @ignore
 @c man begin COPYRIGHT
-Copyright @copyright{} 1996-2014 Free Software Foundation, Inc.
+Copyright @copyright{} 1996-2015 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
--- gcc/doc/install.texi(revision 219185)
+++ gcc/doc/install.texi 

Re: [hsa] HSA: support for direct function call is introduced.

[Martin Liška]

On 12/13/2014 12:33 PM, Eric Botcazou wrote:

Martin,


gcc/c-family/ChangeLog:

2014-12-05  Martin Liska  

* c-common.c: New 'hsafunc' attribute is added.

2014-12-05  Martin Liska  

* hsa-brig.c (struct function_linkage_pair): New data structure.
(hsa_brig_section::get_ptr_by_offset): New function.
(emit_directive_variable): Linkage is retrieved by symbol.
(emit_function_directives): Emitted function is added to map
with offsets.


Would you mind writing ChangeLog entries in the standard form, please?


2014-12-05  Martin Liska  

 * c-common.c: Add 'hsafunc' attribute.


2014-12-05  Martin Liska  

 * hsa-brig.c (struct function_linkage_pair): New data structure.
 (hsa_brig_section::get_ptr_by_offset): New function.
 (emit_directive_variable): Retrieve the linkage by symbol.
 (emit_function_directives): Add emitted function to map with offsets.


Entries must (generally) start with either "New", "Likewise" or a verb.



Hello Eric.

Thank you for your notes, I'm just going to apply following patch
with changed ChangeLog entries.

Martin
>From 2692041290ac80f42004214f0864dddb877e6c10 Mon Sep 17 00:00:00 2001
From: mliska 
Date: Mon, 5 Jan 2015 13:44:50 +0100
Subject: [PATCH] ChangeLog.hsa: comments are rewritten in correct form.

---
 gcc/ChangeLog.hsa | 54 ++
 1 file changed, 26 insertions(+), 28 deletions(-)

diff --git a/gcc/ChangeLog.hsa b/gcc/ChangeLog.hsa
index 4897d40..8c85a3a 100644
--- a/gcc/ChangeLog.hsa
+++ b/gcc/ChangeLog.hsa
@@ -5,20 +5,20 @@
 
 2014-12-12  Martin Liska  
 
-* hsa-brig.c: Function comments are added.
+* hsa-brig.c: Add function comments.
 * hsa-gen.c: Likewise.
 
 2014-12-12  Martin Liska  
 
-	* hsa-brig.c (brig_string_slot_hasher::remove): Memory free is added.
-	* hsa-gen.c (hsa_deinit_data_for_cfun): Destructors are called for
+	* hsa-brig.c (brig_string_slot_hasher::remove): Free memory.
+	* hsa-gen.c (hsa_deinit_data_for_cfun): Call destructors for
 	operands and instructions that need to deallocate a data.
-	(hsa_alloc_reg_op): Object is added to list of items that are
+	(hsa_alloc_reg_op): Add object to list of items that are
 	destructed.
 	(hsa_alloc_code_list_op): Likewise.
 	(hsa_alloc_call_insn): Likewise.
 	(hsa_alloc_call_block_insn): Likewise.
-	(wrap_hsa): Products of asprintf are freed.
+	(wrap_hsa): Free products of asprintf.
 	* hsa.h (struct hsa_op_reg): New destructor.
 	(struct hsa_op_code_list): Likewise.
 	(struct hsa_insn_call): Likewise.
@@ -28,27 +28,26 @@
 
 	* hsa-brig.c (struct function_linkage_pair): New data structure.
 	(hsa_brig_section::get_ptr_by_offset): New function.
-	(emit_directive_variable): Linkage is retrieved by symbol.
-	(emit_function_directives): Emitted function is added to map
+	(emit_directive_variable): Retrieve the linkage by symbol.
+	(emit_function_directives): Add emitted function to map
 	with offsets.
-	(enqueue_op): New operand type handling added.
-	(emit_code_ref_operand): Created from emit_label_operand.
+	(enqueue_op): Handle new operand type.
+	(emit_code_ref_operand): New by renaming emit_label_operand.
 	(emit_code_list_operand): New function.
-	(emit_queued_operands): New operand type handling added.
-	(emit_segment_insn): BRIG_KIND_INST_SEG is changed
+	(emit_queued_operands): Handle new operand type.
+	(emit_segment_insn): Rename BRIG_KIND_INST_SEG to
 	to BRIG_KIND_INST_SEG_CVT.
-	(emit_cvt_insn): Undefined behavior fixed by wrong array bounds.
+	(emit_cvt_insn): Fix undefined behavior caused by wrong array bounds.
 	(emit_arg_block): New function.
 	(emit_call_insn): Likewise.
 	(emit_call_block_insn): Likewise.
-	(emit_insn): New instructions are handled.
-	(hsa_output_brig): Function offsets for call instructions
-	are resolved.
+	(emit_insn): Handle new instructions.
+	(hsa_output_brig): Resolve function offsets for call instructions.
 	* hsa-dump.c (static void indent_stream): New function.
-	(dump_hsa_insn): Added support for call instruction.
-	* hsa-gen.c (hsa_init_data_for_cfun): New flag for hsa_cfun is parsed.
-	(hsa_deinit_data_for_cfun): New pools are deallocated.
-	(get_symbol_for_decl): Symbol's linkage is set up.
+	(dump_hsa_insn): Support new call instruction.
+	* hsa-gen.c (hsa_init_data_for_cfun): Parse new flag for hsa_cfun.
+	(hsa_deinit_data_for_cfun): Deallocate new memory pools.
+	(get_symbol_for_decl): Set up symbol's linkage.
 	(hsa_get_spill_symbol): Likewise.
 	(hsa_alloc_code_list_op): New function.
 	(hsa_alloc_call_insn): Likewise.
@@ -57,24 +56,23 @@
 	(gen_hsa_insns_for_direct_call): Likewise.
 	(gen_hsa_insns_for_return): Likewise.
 	(gen_hsa_insns_for_call): Likewise.
-	(gen_hsa_insns_for_gimple_stmt): GIMPLE labels with non-taken address
-	are supported.
-	(gen_function_parameters): Linkage condition is introduced.
-	(generate_hsa): kern_p flag is parsed.
+	(gen_hsa_insns_for_gimple_stmt): Support GIMPLE l

Re: [PATCH] IPA ICF: refactoring + fix for PR ipa/63569

[Martin Liška]

On 12/19/2014 12:04 PM, Richard Biener wrote:

On Thu, Dec 18, 2014 at 6:38 PM, Martin Liška  wrote:

On 12/17/2014 04:23 PM, Richard Biener wrote:


On Wed, Dec 17, 2014 at 12:17 PM, Martin Liška  wrote:


On 12/11/2014 01:37 PM, Richard Biener wrote:



On Wed, Dec 10, 2014 at 1:18 PM, Martin Liška  wrote:



Hello.

As suggested by Richard, I split compare_operand functions to various
functions
related to a specific comparison. Apart from that I added fast check
for
volatility flag that caused miscompilation mentioned in PR63569.

Patch can bootstrap on x86_64-linux-pc without any regression seen and
I
was
able to build Firefox with LTO.

Ready for trunk?




Hmm, I don't think the dispatch to compare_memory_operand is at the
correct place.  It should be called from places where currently
compare_operand is called and it should recurse to compare_operand.
That is, it is more "high-level".

Can you please fix the volatile issue separately?  It's also not
necessary
to do that check on every operand but just on memory operands.




Hello Richard.

I hope the following patch is the finally the right approach we want to
do
;)
In the first patch, I did just refactoring for high-level memory operand
comparison and the second of fixes problem connected to missing volatile
attribute comparison.

Patch was retested and can bootstrap.

What do you think about it?



+bool
+func_checker::compare_cst_or_decl (tree t1, tree t2)
+{
...
+case INTEGER_CST:
+  {
+   ret = compatible_types_p (TREE_TYPE (t1), TREE_TYPE (t2))
+ && wi::to_offset  (t1) == wi::to_offset  (t2);
+
+   return return_with_debug (ret);
+  }
+case COMPLEX_CST:
+case VECTOR_CST:
+case STRING_CST:
+case REAL_CST:
+  {
+   ret = operand_equal_p (t1, t2, OEP_ONLY_CONST);
+   return return_with_debug (ret);

why does the type matter for INTEGER_CSTs but not for other constants?
Also comparing INTEGER_CSTs via to_offset is certainly wrong.  Please
use tree_int_cst_equal_p (t1, t2) instead, or operand_equal_p which would
end up calling tree_int_cst_equal_p.  That said, I'd have commonized all
_CST nodes by

ret = compatible_types_p () && operand_equal_p (...);

+case CONST_DECL:
+case BIT_FIELD_REF:
+  {

I'm quite sure BIT_FIELD_REF is spurious here.

Now to the "meat" ...

+  tree load1 = get_base_loadstore (t1, false);
+  tree load2 = get_base_loadstore (t2, false);
+
+  if (load1 && load2 && !compare_memory_operand (t1, t2))
+   return return_false_with_msg ("memory operands are different");
+  else if ((load1 && !load2) || (!load1 && load2))
+   return return_false_with_msg ("");
+

and the similar code for assigns.  The way you introduce the
unpack_handled_component flag to get_base_loadstore makes
it treat x.field as non-memory operand.  That's wrong.  I wonder
why you think you needed that.  Why does

tree load1= get_base_loadstore (t1);

not work?  Btw, I'd have avoided get_base_loadstore and simply did

ao_ref_init (&r1, t1);
ao_ref_init (&r2, t2);
tree base1 = ao_ref_base (&r1);
tree base2 = ao_ref_base (&r2);
if ((DECL_P (base1) || (TREE_CODE (base1) == MEM_REF || TREE_CODE
(base1) == TARGET_MEM_REF))
   && (DECL_P (base2) || (...))
 ...

or rather put this into compare_memory_operand and call that on all
operands
that may be memory (TREE_CODE () != SSA_NAME && !is_gimple_min_invariant
()).

I also miss where you handle memory operands on the LHS for calls
and for assignments.

The compare_ssa_name refactoring part is ok to install.

Can you please fix the volatile bug before the refactoring as it looks
like
we're going to iterate some more here unless I can find the time to give
it a quick try myself.

Thanks,
Richard.



Hi.

There's second part of the patch set.


It still has similar issues:

+/* Function compare for equality given memory operands T1 and T2.  */
+
+bool
+func_checker::compare_memory_operand (tree t1, tree t2)
+{
+  if (!t1 && !t2)
+return true;
+  else if (!t1 || !t2)
+return false;
+
+  if (TREE_THIS_VOLATILE (t1) != TREE_THIS_VOLATILE (t2))
+return return_false_with_msg ("different operand volatility");
+
+  bool source_is_memop = DECL_P (t1) || INDIRECT_REF_P (t1)
+|| TREE_CODE (t1) == MEM_REF
+|| TREE_CODE (t1) == TARGET_MEM_REF;
+
+  bool target_is_memop = DECL_P (t2) || INDIRECT_REF_P (t2)
+|| TREE_CODE (t2) == MEM_REF
+|| TREE_CODE (t2) == TARGET_MEM_REF;
+
+  /* Compare alias sets for memory operands.  */
+  if (source_is_memop && target_is_memop)
+{
+  ao_ref r1, r2;
+  ao_ref_init (&r1, t1);
+  ao_ref_init (&r2, t2);

the *_is_memop tests need to work on the memory reference base.  Thus
simply move the ao_ref_init's before those checks and do them on
the result of ao_ref_base ().

Similarly the volatile check can be put into the if (source_is_memop
&& target

[committed] Fix typo in docs

[Marek Polacek]

This patch adds a missing comma in the documentation.

Applying as obvious.

2015-01-05  Marek Polacek  

* doc/extend.texi (Arrays of Length Zero): Add missing comma.

diff --git gcc/doc/extend.texi gcc/doc/extend.texi
index ffefb67..7cd6a56 100644
--- gcc/doc/extend.texi
+++ gcc/doc/extend.texi
@@ -1544,7 +1544,7 @@ struct bar @{ struct foo z; @};
 struct foo a = @{ 1, @{ 2, 3, 4 @} @};// @r{Valid.}
 struct bar b = @{ @{ 1, @{ 2, 3, 4 @} @} @};// @r{Invalid.}
 struct bar c = @{ @{ 1, @{ @} @} @};// @r{Valid.}
-struct foo d[1] = @{ @{ 1 @{ 2, 3, 4 @} @} @};  // @r{Invalid.}
+struct foo d[1] = @{ @{ 1, @{ 2, 3, 4 @} @} @};  // @r{Invalid.}
 @end smallexample
 
 @node Empty Structures

Marek

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 patches:

http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html
  - PR64344 - -fsanitize=float-cast-overflow fix - the C FE part
is approved, but not the sanitizer bits outside of the FE

http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01271.html
  - PR64265 - tsan support for exceptions

http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html
  - -fsanitize=vptr support

Jakub

Re: [PATCH] Fix PR c++/59366 A friend function template defined in a class is found without ADL

[Jason Merrill]

On 12/30/2014 11:24 AM, Momchil Velikov wrote:

A function template enters the body of the if statement at line 1881,

   if (TREE_CODE (newdecl) == TEMPLATE_DECL)

and exits the function at line 1951 with

   return olddecl;


Ah, yes.  The patch is OK, then, but still needs ChangeLog and testcase.

Jason

Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c

[Jeff Law]

On 01/04/15 10:16, Richard Biener wrote:


But either your new hook or the original fix makes no sense.


All I want is to restore the old behavior on x86.  If the original fix
makes no sense, should it be reverted?


I think the original fix is too conservative
Perhaps.  Neither John nor I felt it was too conservative.  But 
disagreeing slightly on this isn't a big deal.



But I also think there is a target independent bug, thus a target hook to "fix" 
things for x86 makes no sense.

Agreed 100%.

Jeff

RE: [PATCH] Disable -fuse-caller-save when -pg is active

[Moore, Catherine]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Radovan Obradovic
> Sent: Thursday, December 18, 2014 11:01 AM
> To: Jeff Law; gcc-patches@gcc.gnu.org
> Cc: Petar Jovanovic
> Subject: RE: [PATCH] Disable -fuse-caller-save when -pg is active
> 
> 
> Patch has been tested with DejaGnu gcc test suite on mips32r2 cross
> compiler and bootstrapped and tested on
> x86_64 native compiler.
> 
Thanks for finishing up the testing.  Would you like me to check this in for 
you?

> 
> From: Jeff Law [l...@redhat.com]
> Sent: Monday, November 17, 2014 1:18 PM
> To: Radovan Obradovic; gcc-patches@gcc.gnu.org
> Cc: Petar Jovanovic
> Subject: Re: [PATCH] Disable -fuse-caller-save when -pg is active
> 
> On 11/14/14 10:10, Radovan Obradovic wrote:
> > Thank you for the quick reply.
> >
> >> Please repost after updating to test HAVE_prologue and HAVE_epilogue
> >> and adding a testcase.
> >
> > I have managed to reproduce the problem on the small test case on
> > mips32, but the test is architecture independent and should probably
> > fail on many other ports without this patch. The optimization is also
> > disabled if macros HAVE_prologue and HAVE_epilogue are not defined or
> > have false value.
> Thanks.  This looks good.  I forgot to ask in my prior message, has this patch
> been bootstrapped and regression tested?  If so, on what platform?
> 
> Jeff

RE: [PATCH] Don't check for optab for 16bit bswap

[Thomas Preud'homme]

> From: Oleg Endo [mailto:oleg.e...@t-online.de]
> Sent: Tuesday, December 30, 2014 4:25 PM
> 
> I've just tried disabling the 'rotlhi3' pattern and __builtin_bswap16
> expands into shift + and + or (as expected).
> Thus, I don't think the patch will make something worse (than it
> already
> 
> .L42:
> 
> is) on some backends.  If the bswap detection bails out at the tree
> level, the expanded ops will be shift + and + or -- as written in the
> original code.  So probably, that will be the same as the fallback
> expansion for __builtin_bswap16, and we're back to sqrt (1).
> 
> > OK, that is what I was asking - are there cases where using rot is worse
> (like forcing a libcall or so).
> 
> See also comment in expmed.c (expand_shift_1):
>  It is theoretically possible that the target machine might
>  not be able to perform either shift and hence we would
>  be making two libcalls rather than just the one for the
>  shift (similarly if IOR could not be done).  We will allow
>  this extremely unlikely lossage to avoid complicating the
>  code below.  */
> 
> then goto .L42  ;)

Yes and if the fallback expansion for a rot is actually worse than the
original set of stmt it means the fallback expansion should be improved.

Now I realize that said like this it sounds more like stage1 material.

Would it be fine for next stage1?

Best regards,

Thomas 

Re: [PATCH, libgo]: Double StackMin size for 64bit non-split-stack targets

[Ian Lance Taylor]

On Wed, Dec 24, 2014 at 3:44 AM, Uros Bizjak  wrote:
>
> The attached patch doubles StackMin size for 64bit non-split-stack
> targets. This patch fixes regexp libgo failure (tracked as gcc PR61871
> [1]) on alpha-linux-gnu.
>
> --cut here--
> Index: runtime/proc.c
> ===
> --- runtime/proc.c  (revision 219035)
> +++ runtime/proc.c  (working copy)
> @@ -51,7 +51,7 @@
>  #if defined(USING_SPLIT_STACK) && defined(LINKER_SUPPORTS_SPLIT_STACK)
>  # define StackMin PTHREAD_STACK_MIN
>  #else
> -# define StackMin 2 * 1024 * 1024
> +# define StackMin ((sizeof(char *) < 8) ? 2 * 1024 * 1024 : 4 * 1024 * 1024)
>  #endif
>
>  uintptr runtime_stacks_sys;
> --cut here--


Thanks.  Committed.  Sorry for the delay.

Ian

Re: [PATCH] Fix loop optimization when ZOL is not available in xtensa configuration

[augustine.sterl...@gmail.com]

On Mon, Dec 29, 2014 at 3:12 PM, Max Filippov  wrote:
> Currently building gcc for xtensa configuration with XCHAL_HAVE_LOOPS
> set to 0 fails with the following error:
>
>   xtensa.c:3952: undefined reference to `reorg_loops(bool, hw_doloop_hooks*)'
>
> Only compile target-specific zero-overhead loop optimization code when
> TARGET_LOOPS allows it.
>
> 2014-12-30  Max Filippov  
>
> * config/xtensa/xtensa.c (hwloop_optimize, hwloop_fail,
> hwloop_pattern_reg, xtensa_doloop_hooks, xtensa_reorg_loops):
> put under #if TARGET_LOOPS guard.

This is OK. Thanks.

Re: Fix streaming of target optimization/option nodes

[H.J. Lu]

On Mon, Dec 22, 2014 at 3:02 AM, Thomas Schwinge
 wrote:
> Hi!
>
> On Mon, 15 Dec 2014 23:36:11 +0100, Jan Hubicka  wrote:
>> this is final version I comitted.
>
>>   PR lto/64043
>
>>   * tree-streamer.c (preload_common_nodes): Skip preloading
>>   of main_identifier_node, pid_type and optimization/option nodes.
>

>
> This regresses offloading (tested Intel MIC emulation):
>
> FAIL: libgomp.c/examples-4/e.53.5.c (internal compiler error)
> FAIL: libgomp.c/for-3.c (internal compiler error)
> FAIL: libgomp.c++/for-11.C (internal compiler error)
> FAIL: libgomp.fortran/examples-4/e.53.3.f90   -O2  (internal compiler 
> error)
> FAIL: libgomp.fortran/examples-4/e.53.3.f90   -O3 -fomit-frame-pointer  
> (internal compiler error)
> FAIL: libgomp.fortran/examples-4/e.53.3.f90   -O3 -fomit-frame-pointer 
> -funroll-loops  (internal compiler error)
> FAIL: libgomp.fortran/examples-4/e.53.3.f90   -O3 -fomit-frame-pointer 
> -funroll-all-loops -finline-functions  (internal compiler error)
> FAIL: libgomp.fortran/examples-4/e.53.3.f90   -O3 -g  (internal compiler 
> error)
> FAIL: libgomp.fortran/examples-4/e.53.3.f90   -Os  (internal compiler 
> error)
> FAIL: libgomp.fortran/examples-4/e.53.4.f90   -O2  (test for excess 
> errors)
> FAIL: libgomp.fortran/examples-4/e.53.5.f90   -O0  (internal compiler 
> error)
> FAIL: libgomp.fortran/examples-4/e.53.5.f90   -O1  (internal compiler 
> error)
> FAIL: libgomp.fortran/examples-4/e.53.5.f90   -O2  (internal compiler 
> error)
> FAIL: libgomp.fortran/examples-4/e.53.5.f90   -O3 -fomit-frame-pointer  
> (internal compiler error)
> FAIL: libgomp.fortran/examples-4/e.53.5.f90   -O3 -fomit-frame-pointer 
> -funroll-loops  (internal compiler error)
> FAIL: libgomp.fortran/examples-4/e.53.5.f90   -O3 -fomit-frame-pointer 
> -funroll-all-loops -finline-functions  (internal compiler error)
> FAIL: libgomp.fortran/examples-4/e.53.5.f90   -O3 -g  (internal compiler 
> error)
> FAIL: libgomp.fortran/examples-4/e.53.5.f90   -Os  (internal compiler 
> error)
>
> FAIL: libgomp.c/examples-4/e.53.5.c (internal compiler error)
>
> [...]/source-gcc/libgomp/testsuite/libgomp.c/examples-4/e.53.5.c: In 
> function 'accum._omp_fn.1':
> [...]/source-gcc/libgomp/testsuite/libgomp.c/examples-4/e.53.5.c:53:13: 
> error: unrecognizable insn:
>  #pragma omp parallel for reduction(+:tmp)
>  ^
> (insn 176 66 177 4 (set (reg:DI 0 ax)
> (symbol_ref:DI ("Q") )) -1
>  (nil))
> [...]/source-gcc/libgomp/testsuite/libgomp.c/examples-4/e.53.5.c:53:13: 
> internal compiler error: in extract_insn, at recog.c:2327
> 0x9c124a _fatal_insn(char const*, rtx_def const*, char const*, int, char 
> const*)
> [...]/source-gcc/gcc/rtl-error.c:110
> 0x9c1279 _fatal_insn_not_found(rtx_def const*, char const*, int, char 
> const*)
> [...]/source-gcc/gcc/rtl-error.c:118
> 0x98f346 extract_insn(rtx_insn*)
> [...]/source-gcc/gcc/recog.c:2327
> 0x9902c8 extract_constrain_insn(rtx_insn*)
> [...]/source-gcc/gcc/recog.c:2228
> 0x998a16 copyprop_hardreg_forward_1
> [...]/source-gcc/gcc/regcprop.c:773
> 0x99978a execute
> [...]/source-gcc/gcc/regcprop.c:1279
>
> FAIL: libgomp.c/for-3.c (internal compiler error)
>
> [...]/source-gcc/libgomp/testsuite/libgomp.c/for-2.h: In function 
> 'f13_d_normal':
> [...]/source-gcc/libgomp/testsuite/libgomp.c/for-2.h:171:1: error: 
> unrecognizable insn:
>  }
>  ^
> (insn 73 72 55 5 (set (reg/f:DI 1 dx [orig:106 D.6870 ] [106])
> (plus:DI (reg:DI 0 ax [orig:105 D.6869 ] [105])
> (symbol_ref:DI ("a") ))) -1
>  (nil))
> [...]/source-gcc/libgomp/testsuite/libgomp.c/for-2.h:171:1: internal 
> compiler error: in extract_insn, at recog.c:2327
> 0x9c124a _fatal_insn(char const*, rtx_def const*, char const*, int, char 
> const*)
> [...]/source-gcc/gcc/rtl-error.c:110
> 0x9c1279 _fatal_insn_not_found(rtx_def const*, char const*, int, char 
> const*)
> [...]/source-gcc/gcc/rtl-error.c:118
> 0x98f346 extract_insn(rtx_insn*)
> [...]/source-gcc/gcc/recog.c:2327
> 0x98f3c4 extract_insn_cached(rtx_insn*)
> [...]/source-gcc/gcc/recog.c:2218
> 0x749cdd cleanup_subreg_operands(rtx_insn*)
> [...]/source-gcc/gcc/final.c:3124
> 0x98caf7 split_insn
> [...]/source-gcc/gcc/recog.c:2937
> 0x991657 split_all_insns()
> [...]/source-gcc/gcc/recog.c:2991
> 0x9916d8 rest_of_handle_split_after_reload
> [...]/source-gcc/gcc/recog.c:3938
> 0x9916d8 execute
> [...]/source-gcc/gcc/recog.c:3967
>
> Etc.
>
>
> There also are related issues still open:
> ,
> 

[PATCH] Fix SSA_NAME range info ICE (PR tree-optimization/64494)

[Jakub Jelinek]

Hi!

The SSA_NAME range info consists of two fields, SSA_NAME_RANGE_INFO pointer
and SSA_NAME_ANTI_RANGE_P flag, but the recently added clearing of range
info cleared just SSA_NAME_RANGE_INFO, leading to ICE on the following
testcase where we asserted that SSA_NAME_ANTI_RANGE_P flag is cleared
on a SSA_NAME that doesn't have SSA_NAME_RANGE_INFO non-NULL.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2015-01-05  Jakub Jelinek  

PR tree-optimization/64494
* tree-ssa-loop-im.c (move_computations_dom_walker::before_dom): Also
clear SSA_NAME_ANTI_RANGE_P flag.

* gcc.c-torture/compile/pr64494.c: New test.

--- gcc/tree-ssa-loop-im.c.jj   2014-12-10 20:57:54.0 +0100
+++ gcc/tree-ssa-loop-im.c  2015-01-05 10:34:26.294637773 +0100
@@ -1236,7 +1236,11 @@ move_computations_dom_walker::before_dom
  && (!ALWAYS_EXECUTED_IN (bb)
  || (ALWAYS_EXECUTED_IN (bb) != level
  && !flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level
-   SSA_NAME_RANGE_INFO (gimple_assign_lhs (new_stmt)) = NULL;
+   {
+ tree lhs = gimple_assign_lhs (new_stmt);
+ SSA_NAME_RANGE_INFO (lhs) = NULL;
+ SSA_NAME_ANTI_RANGE_P (lhs) = 0;
+   }
   gsi_insert_on_edge (loop_preheader_edge (level), new_stmt);
   remove_phi_node (&bsi, false);
 }
@@ -1302,7 +1306,11 @@ move_computations_dom_walker::before_dom
  && (!ALWAYS_EXECUTED_IN (bb)
  || !(ALWAYS_EXECUTED_IN (bb) == level
   || flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level
-   SSA_NAME_RANGE_INFO (gimple_get_lhs (stmt)) = NULL;
+   {
+ tree lhs = gimple_get_lhs (stmt);
+ SSA_NAME_RANGE_INFO (lhs) = NULL;
+ SSA_NAME_ANTI_RANGE_P (lhs) = 0;
+   }
   /* In case this is a stmt that is not unconditionally executed
  when the target loop header is executed and the stmt may
 invoke undefined integer or pointer overflow rewrite it to
--- gcc/testsuite/gcc.c-torture/compile/pr64494.c.jj2015-01-05 
10:38:11.766781507 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr64494.c   2015-01-05 
10:37:58.0 +0100
@@ -0,0 +1,18 @@
+/* PR tree-optimization/64494 */
+
+int a, b;
+unsigned char c;
+
+int
+main ()
+{
+  int d;
+  a = 0;
+  for (d = 0; d < 2; d++)
+{
+  a &= (b >= 1);
+  c = (204 > (((unsigned char) ~0) >> a)) ? 0 : 204 << a;
+  b = 0;
+}
+  return 0;
+}

Jakub

Re: [PATCH] Disable -fuse-caller-save when -pg is active

[Jeff Law]

On 01/05/15 07:48, Moore, Catherine wrote:




-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Radovan Obradovic
Sent: Thursday, December 18, 2014 11:01 AM
To: Jeff Law; gcc-patches@gcc.gnu.org
Cc: Petar Jovanovic
Subject: RE: [PATCH] Disable -fuse-caller-save when -pg is active


Patch has been tested with DejaGnu gcc test suite on mips32r2 cross
compiler and bootstrapped and tested on
x86_64 native compiler.


Thanks for finishing up the testing.  Would you like me to check this in for 
you?
Please do.  My recollection was that the patch itself looked fine, but 
that it needed to go through the usual testing cycle.


jeff

[PATCH] Fix einline ICE with EH (PR tree-optimization/64465)

[Jakub Jelinek]

Hi!

The early inliner ICEs on the following testcase, because redirect_all_calls
replaces a call to a function that could throw with __builtin_unreachable
(and, note, it still has the bug that it doesn't drop the function
arguments), but nothing cleans up the EH stuff for that change.

During function versioning fixup_cfg pass is supposed to handle that,
during IPA inlining there is explicit call to execute_fixup_cfg, but during
early inlining there is not.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?

Honza, will you take care of dropping the arguments when you redirect to
a function that takes no arguments (I believe only __builtin_unreachable
and __pure_virtual are the cases where we do that).

2015-01-05  Jakub Jelinek  

PR tree-optimization/64465
* tree-inline.c (redirect_all_calls): During inlining
clean up EH stmts and EH edges if redirect_call_stmt_to_callee
changed the stmt to a non-throwing call.

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

--- gcc/tree-inline.c.jj2015-01-05 13:07:15.186507607 +0100
+++ gcc/tree-inline.c   2015-01-05 15:30:33.715001491 +0100
@@ -2582,13 +2582,19 @@ void
 redirect_all_calls (copy_body_data * id, basic_block bb)
 {
   gimple_stmt_iterator si;
+  gimple last = last_stmt (bb);
   for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
 {
-  if (is_gimple_call (gsi_stmt (si)))
+  gimple stmt = gsi_stmt (si);
+  if (is_gimple_call (stmt))
{
- struct cgraph_edge *edge = id->dst_node->get_edge (gsi_stmt (si));
+ struct cgraph_edge *edge = id->dst_node->get_edge (stmt);
  if (edge)
-   edge->redirect_call_stmt_to_callee ();
+   {
+ edge->redirect_call_stmt_to_callee ();
+ if (stmt == last && id->call_stmt && maybe_clean_eh_stmt (stmt))
+   gimple_purge_dead_eh_edges (bb);
+   }
}
 }
 }
--- gcc/testsuite/gcc.dg/pr64465.c.jj   2015-01-05 15:06:31.369183163 +0100
+++ gcc/testsuite/gcc.dg/pr64465.c  2015-01-05 15:06:31.369183163 +0100
@@ -0,0 +1,22 @@
+/* PR tree-optimization/64465 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fexceptions" } */
+
+extern int foo (int *);
+extern int bar (int, int);
+static inline __attribute__ ((__always_inline__))
+int baz (int o)
+{
+  if (__builtin_constant_p (o))
+return bar (o, 1);
+  return bar (o, 0);
+}
+
+void
+test (void)
+{
+  int s;
+  foo (&s);
+  baz (4);
+  baz (s);
+}

Jakub

Re: [PATCH] LRA: Fix caller-save store/restore instruction for large mode

[Jeff Law]

On 01/05/15 00:44, Kito Cheng wrote:

Hi Vladimir:
   This patch has a discusses with you in May 2014, this patch is about
the caller-save register store and restore instruction generation, the
current LRA implementation will miss caller-save store/restore
instruction if need one more instruction.

You said you will investigate for this on IRC, so I don't send the
patch last year, however ARM guys seem got this problem too, so I
think it's time to send this patch :)

ChangeLog

2015-01-05  Kito Cheng  

 * lra-constraints.c (split_reg): Fix caller-save store/restore
instruction generation.

Please reference PR64348 in the ChangeLog entry.

Please include a testcase if there isn't one in the regression suite 
already.


Please indicate what platform this patch was bootstrapped and regression 
tested on.


The dumping code immediately after the assert you removed has code like 
this in both cases:




 fprintf (lra_dump_file,
   "Rejecting split %d->%d "
   "resulting in > 2 %s restore insns:\n",
   original_regno, REGNO (new_reg), call_save_p ? 
"call" : "");


Testing call_save_p here won't make any sense after your patch.

I'll let Vlad chime in on the correctness of allowing multi register 
saves/restores in this code.


Jeff

Re: [BUILDROBOT, PATCH] config-list.mk: Extract target name correctly

[Jeff Law]

On 12/29/14 13:02, Jan-Benedict Glaw wrote:

Hi!

With my last change, `sed' is used to cut out the target name from a listed
target. Since there may be additional OPTions encoded in the "target", I tried
to get only the first submatch before an `OPT'. However, `sed' uses longest
match, so I'm re-writing this using awk.

   If anybody is like using `gawk' or anything different, please feel free to
drop another patch. Since this is usually called by hand or by robots under
review, I don't see much of a problem here.

2014-12-29  Jan-Benedict Glaw  

contrib/
* config-list.mk: Use shortest match for OPT to find the actual
target name.

OK.

Jeff

Re: [PATCH] Fix einline ICE with EH (PR tree-optimization/64465)

[Jan Hubicka]

> Hi!
> 
> The early inliner ICEs on the following testcase, because redirect_all_calls
> replaces a call to a function that could throw with __builtin_unreachable
> (and, note, it still has the bug that it doesn't drop the function
> arguments), but nothing cleans up the EH stuff for that change.
> 
> During function versioning fixup_cfg pass is supposed to handle that,
> during IPA inlining there is explicit call to execute_fixup_cfg, but during
> early inlining there is not.

I am still confused why early inliner does any redirections? It should not.
Edge redirection is part of the IPA optimization machinery.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?
> 
> Honza, will you take care of dropping the arguments when you redirect to
> a function that takes no arguments (I believe only __builtin_unreachable
> and __pure_virtual are the cases where we do that).

Yep, i will try to find time for that after arriving to Calgary this weekend.
There are quite few places where substitution can happen, so I need to check
them curefuly.

Honza
> 
> 2015-01-05  Jakub Jelinek  
> 
>   PR tree-optimization/64465
>   * tree-inline.c (redirect_all_calls): During inlining
>   clean up EH stmts and EH edges if redirect_call_stmt_to_callee
>   changed the stmt to a non-throwing call.
> 
>   * gcc.dg/pr64465.c: New test.
> 
> --- gcc/tree-inline.c.jj  2015-01-05 13:07:15.186507607 +0100
> +++ gcc/tree-inline.c 2015-01-05 15:30:33.715001491 +0100
> @@ -2582,13 +2582,19 @@ void
>  redirect_all_calls (copy_body_data * id, basic_block bb)
>  {
>gimple_stmt_iterator si;
> +  gimple last = last_stmt (bb);
>for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
>  {
> -  if (is_gimple_call (gsi_stmt (si)))
> +  gimple stmt = gsi_stmt (si);
> +  if (is_gimple_call (stmt))
>   {
> -   struct cgraph_edge *edge = id->dst_node->get_edge (gsi_stmt (si));
> +   struct cgraph_edge *edge = id->dst_node->get_edge (stmt);
> if (edge)
> - edge->redirect_call_stmt_to_callee ();
> + {
> +   edge->redirect_call_stmt_to_callee ();
> +   if (stmt == last && id->call_stmt && maybe_clean_eh_stmt (stmt))
> + gimple_purge_dead_eh_edges (bb);
> + }
>   }
>  }
>  }
> --- gcc/testsuite/gcc.dg/pr64465.c.jj 2015-01-05 15:06:31.369183163 +0100
> +++ gcc/testsuite/gcc.dg/pr64465.c2015-01-05 15:06:31.369183163 +0100
> @@ -0,0 +1,22 @@
> +/* PR tree-optimization/64465 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fexceptions" } */
> +
> +extern int foo (int *);
> +extern int bar (int, int);
> +static inline __attribute__ ((__always_inline__))
> +int baz (int o)
> +{
> +  if (__builtin_constant_p (o))
> +return bar (o, 1);
> +  return bar (o, 0);
> +}
> +
> +void
> +test (void)
> +{
> +  int s;
> +  foo (&s);
> +  baz (4);
> +  baz (s);
> +}
> 
>   Jakub

[PATCH] -f{no-sanitize,{,no-}sanitize-recover}=all support

[Jakub Jelinek]

On Tue, Dec 23, 2014 at 04:47:06PM -0800, Alexey Samsonov wrote:
> Right, -fsanitize=all produces an error, while -fsanitize-recover=all
> enables recovery for all
> sanitizers, -fno-sanitize-recover=all disables recovery for everything.

Ok, here is a GCC patch for that.
-fno-sanitize=all is supported as a way to turn off all the sanitizers,
-f{,no-}sanitize-recover=all is supported too, and one can mix all
with other sanitizer names.

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

2015-01-05  Jakub Jelinek  

* opts.c (common_handle_option): Add support for
-fno-sanitize=all and -f{,no-}sanitize-recover=all.

* c-c++-common/asan/sanitize-all-1.c: New test.
* c-c++-common/ubsan/sanitize-all-1.c: New test.
* c-c++-common/ubsan/sanitize-all-2.c: New test.
* c-c++-common/ubsan/sanitize-all-3.c: New test.
* c-c++-common/ubsan/sanitize-all-4.c: New test.

--- gcc/opts.c.jj   2015-01-05 15:37:15.155023474 +0100
+++ gcc/opts.c  2015-01-05 16:05:18.659760976 +0100
@@ -1588,6 +1588,7 @@ common_handle_option (struct gcc_options
sizeof "returns-nonnull-attribute" - 1 },
  { "object-size", SANITIZE_OBJECT_SIZE,
sizeof "object-size" - 1 },
+ { "all", ~0, sizeof "all" - 1 },
  { NULL, 0, 0 }
};
const char *comma;
@@ -1611,7 +1612,15 @@ common_handle_option (struct gcc_options
  && memcmp (p, spec[i].name, len) == 0)
{
  /* Handle both -fsanitize and -fno-sanitize cases.  */
- if (value)
+ if (value && spec[i].flag == ~0U)
+   {
+ if (code == OPT_fsanitize_)
+   error_at (loc, "-fsanitize=all option is not valid");
+ else
+   *flag |= ~(SANITIZE_USER_ADDRESS | SANITIZE_THREAD
+  | SANITIZE_LEAK);
+   }
+ else if (value)
*flag |= spec[i].flag;
  else
*flag &= ~spec[i].flag;
--- gcc/testsuite/c-c++-common/asan/sanitize-all-1.c.jj 2015-01-05 
15:41:43.515357551 +0100
+++ gcc/testsuite/c-c++-common/asan/sanitize-all-1.c2015-01-05 
15:41:43.515357551 +0100
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-fno-sanitize=all" } */
+
+volatile int ten = 10;
+
+int main() {
+  volatile char x[10];
+  x[ten];
+  return 0;
+}
+
+/* { dg-final { scan-assembler-not "__asan_load" } } */
--- gcc/testsuite/c-c++-common/ubsan/sanitize-all-1.c.jj2015-01-05 
15:41:43.515357551 +0100
+++ gcc/testsuite/c-c++-common/ubsan/sanitize-all-1.c   2015-01-05 
15:41:43.515357551 +0100
@@ -0,0 +1,8 @@
+/* Test -f*sanitize*=all */
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "*" } { "-O2" } } */
+/* { dg-options "-fsanitize=all" } */
+
+int i;
+
+/* { dg-error "-fsanitize=all option is not valid" "" { target *-*-* } 0 } */
--- gcc/testsuite/c-c++-common/ubsan/sanitize-all-2.c.jj2015-01-05 
15:41:43.516357533 +0100
+++ gcc/testsuite/c-c++-common/ubsan/sanitize-all-2.c   2015-01-05 
17:46:57.634523012 +0100
@@ -0,0 +1,41 @@
+/* Test -f*sanitize*=all */
+/* { dg-do run } */
+/* { dg-skip-if "" { *-*-* } { "*" } { "-O2" } } */
+/* { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } } */
+/* { dg-options "-fsanitize=undefined,float-cast-overflow,float-divide-by-zero 
-fno-sanitize=all -fdump-tree-optimized" } */
+
+int a[4];
+
+int
+f1 (int x, int y, int z)
+{
+  return a[x] + (1 << y) + (100 / z);
+}
+
+char *
+f2 (int x)
+{
+  char *p = (char *) __builtin_calloc (64, 1);
+  p[x] = 3;
+  return p;
+}
+
+int
+f3 (int x, int *y, double z, double w)
+{
+  int a[*y];
+  if (x)
+__builtin_unreachable ();
+  asm volatile ("" : : "r" (&a[0]));
+  return z / w;
+}
+
+int
+main ()
+{
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-not "__ubsan_" "optimized" } } */
+/* { dg-final { scan-tree-dump-not "UBSAN_CHECK_" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
--- gcc/testsuite/c-c++-common/ubsan/sanitize-all-3.c.jj2015-01-05 
15:41:43.516357533 +0100
+++ gcc/testsuite/c-c++-common/ubsan/sanitize-all-3.c   2015-01-05 
17:47:03.768418951 +0100
@@ -0,0 +1,42 @@
+/* Test -f*sanitize*=all */
+/* { dg-do run } */
+/* { dg-skip-if "" { *-*-* } { "*" } { "-O2" } } */
+/* { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } } */
+/* { dg-options "-fsanitize=undefined -fsanitize-recover=all 
-fdump-tree-optimized" } */
+
+int a[4];
+
+int
+f1 (int x, int y, int z)
+{
+  return a[x] + (1 << y) + (100 / z);
+}
+
+char *
+f2 (int x)
+{
+  char *p = (char *) __builtin_calloc (64, 1);
+  p[x] = 3;
+  return p;
+}
+
+int
+f3 (int x, int *y, double z, double w)
+{
+  int a[*y];
+  if (x)
+__builtin_unreachable ();
+  asm volatile ("" : : "r" (&a[0]));
+  return z / w;
+}
+
+int
+main ()
+{
+  return 0;
+}
+
+/* { dg-fina

Re: *ping* [patch, fortran] Fix for PR 47676

[Marek Polacek]

On Mon, Jan 05, 2015 at 12:51:55PM +0100, Thomas Koenig wrote:
> Am 30.12.2014 um 01:25 schrieb Thomas Koenig:
> > Hello world,
> > 
> > this patch fixes the long-standing bug.  A missing temporary
> > causes an invalid read in realloc_on_assign_5.f03 which
> > only becomes noticable when setting MALLOC_CHECK_ or when
> > using valgrind.  The bug has three duplicates in the
> > data base, so people keep stumbling across this.
> 
> Ping ?
> 
> https://gcc.gnu.org/ml/fortran/2014-12/msg00137.html

This breaks the build because you haven't committed the
dependency.h part.

Marek

Re: [PATCH] Fix einline ICE with EH (PR tree-optimization/64465)

[Richard Biener]

On January 5, 2015 6:37:20 PM CET, Jan Hubicka  wrote:
>> Hi!
>> 
>> The early inliner ICEs on the following testcase, because
>redirect_all_calls
>> replaces a call to a function that could throw with
>__builtin_unreachable
>> (and, note, it still has the bug that it doesn't drop the function
>> arguments), but nothing cleans up the EH stuff for that change.
>> 
>> During function versioning fixup_cfg pass is supposed to handle that,
>> during IPA inlining there is explicit call to execute_fixup_cfg, but
>during
>> early inlining there is not.
>
>I am still confused why early inliner does any redirections? It should
>not.
>Edge redirection is part of the IPA optimization machinery.

Possibly through stmt folding.

Richard.

>> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
>> ok for trunk?
>> 
>> Honza, will you take care of dropping the arguments when you redirect
>to
>> a function that takes no arguments (I believe only
>__builtin_unreachable
>> and __pure_virtual are the cases where we do that).
>
>Yep, i will try to find time for that after arriving to Calgary this
>weekend.
>There are quite few places where substitution can happen, so I need to
>check
>them curefuly.
>
>Honza
>> 
>> 2015-01-05  Jakub Jelinek  
>> 
>>  PR tree-optimization/64465
>>  * tree-inline.c (redirect_all_calls): During inlining
>>  clean up EH stmts and EH edges if redirect_call_stmt_to_callee
>>  changed the stmt to a non-throwing call.
>> 
>>  * gcc.dg/pr64465.c: New test.
>> 
>> --- gcc/tree-inline.c.jj 2015-01-05 13:07:15.186507607 +0100
>> +++ gcc/tree-inline.c2015-01-05 15:30:33.715001491 +0100
>> @@ -2582,13 +2582,19 @@ void
>>  redirect_all_calls (copy_body_data * id, basic_block bb)
>>  {
>>gimple_stmt_iterator si;
>> +  gimple last = last_stmt (bb);
>>for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
>>  {
>> -  if (is_gimple_call (gsi_stmt (si)))
>> +  gimple stmt = gsi_stmt (si);
>> +  if (is_gimple_call (stmt))
>>  {
>> -  struct cgraph_edge *edge = id->dst_node->get_edge (gsi_stmt
>(si));
>> +  struct cgraph_edge *edge = id->dst_node->get_edge (stmt);
>>if (edge)
>> -edge->redirect_call_stmt_to_callee ();
>> +{
>> +  edge->redirect_call_stmt_to_callee ();
>> +  if (stmt == last && id->call_stmt && maybe_clean_eh_stmt
>(stmt))
>> +gimple_purge_dead_eh_edges (bb);
>> +}
>>  }
>>  }
>>  }
>> --- gcc/testsuite/gcc.dg/pr64465.c.jj2015-01-05 15:06:31.369183163
>+0100
>> +++ gcc/testsuite/gcc.dg/pr64465.c   2015-01-05 15:06:31.369183163
>+0100
>> @@ -0,0 +1,22 @@
>> +/* PR tree-optimization/64465 */
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -fexceptions" } */
>> +
>> +extern int foo (int *);
>> +extern int bar (int, int);
>> +static inline __attribute__ ((__always_inline__))
>> +int baz (int o)
>> +{
>> +  if (__builtin_constant_p (o))
>> +return bar (o, 1);
>> +  return bar (o, 0);
>> +}
>> +
>> +void
>> +test (void)
>> +{
>> +  int s;
>> +  foo (&s);
>> +  baz (4);
>> +  baz (s);
>> +}
>> 
>>  Jakub

Re: [PATCH] Fix SSA_NAME range info ICE (PR tree-optimization/64494)

[Richard Biener]

On January 5, 2015 6:01:41 PM CET, Jakub Jelinek  wrote:
>Hi!
>
>The SSA_NAME range info consists of two fields, SSA_NAME_RANGE_INFO
>pointer
>and SSA_NAME_ANTI_RANGE_P flag, but the recently added clearing of
>range
>info cleared just SSA_NAME_RANGE_INFO, leading to ICE on the following
>testcase where we asserted that SSA_NAME_ANTI_RANGE_P flag is cleared
>on a SSA_NAME that doesn't have SSA_NAME_RANGE_INFO non-NULL.
>
>Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
>for
>trunk?

OK.

Thanks
Richard.

>2015-01-05  Jakub Jelinek  
>
>   PR tree-optimization/64494
>   * tree-ssa-loop-im.c (move_computations_dom_walker::before_dom): Also
>   clear SSA_NAME_ANTI_RANGE_P flag.
>
>   * gcc.c-torture/compile/pr64494.c: New test.
>
>--- gcc/tree-ssa-loop-im.c.jj  2014-12-10 20:57:54.0 +0100
>+++ gcc/tree-ssa-loop-im.c 2015-01-05 10:34:26.294637773 +0100
>@@ -1236,7 +1236,11 @@ move_computations_dom_walker::before_dom
> && (!ALWAYS_EXECUTED_IN (bb)
> || (ALWAYS_EXECUTED_IN (bb) != level
> && !flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level
>-  SSA_NAME_RANGE_INFO (gimple_assign_lhs (new_stmt)) = NULL;
>+  {
>+tree lhs = gimple_assign_lhs (new_stmt);
>+SSA_NAME_RANGE_INFO (lhs) = NULL;
>+SSA_NAME_ANTI_RANGE_P (lhs) = 0;
>+  }
>   gsi_insert_on_edge (loop_preheader_edge (level), new_stmt);
>   remove_phi_node (&bsi, false);
> }
>@@ -1302,7 +1306,11 @@ move_computations_dom_walker::before_dom
> && (!ALWAYS_EXECUTED_IN (bb)
> || !(ALWAYS_EXECUTED_IN (bb) == level
>  || flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level
>-  SSA_NAME_RANGE_INFO (gimple_get_lhs (stmt)) = NULL;
>+  {
>+tree lhs = gimple_get_lhs (stmt);
>+SSA_NAME_RANGE_INFO (lhs) = NULL;
>+SSA_NAME_ANTI_RANGE_P (lhs) = 0;
>+  }
>   /* In case this is a stmt that is not unconditionally executed
>  when the target loop header is executed and the stmt may
>invoke undefined integer or pointer overflow rewrite it to
>--- gcc/testsuite/gcc.c-torture/compile/pr64494.c.jj   2015-01-05
>10:38:11.766781507 +0100
>+++ gcc/testsuite/gcc.c-torture/compile/pr64494.c  2015-01-05
>10:37:58.0 +0100
>@@ -0,0 +1,18 @@
>+/* PR tree-optimization/64494 */
>+
>+int a, b;
>+unsigned char c;
>+
>+int
>+main ()
>+{
>+  int d;
>+  a = 0;
>+  for (d = 0; d < 2; d++)
>+{
>+  a &= (b >= 1);
>+  c = (204 > (((unsigned char) ~0) >> a)) ? 0 : 204 << a;
>+  b = 0;
>+}
>+  return 0;
>+}
>
>   Jakub

Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 07:19:33AM -0700, Jeff Law wrote:
> On 01/04/15 10:16, Richard Biener wrote:
> >>>
> >>>But either your new hook or the original fix makes no sense.
> >>
> >>All I want is to restore the old behavior on x86.  If the original fix
> >>makes no sense, should it be reverted?
> >
> >I think the original fix is too conservative
> Perhaps.  Neither John nor I felt it was too conservative.  But disagreeing
> slightly on this isn't a big deal.
> 
> >But I also think there is a target independent bug, thus a target hook to 
> >"fix" things for x86 makes no sense.
> Agreed 100%.

So isn't the right replacement for the target hook H.J. wanted to add
the HARD_FRAME_POINTER_IS_ARG_POINTER macro?
If argp is not hfp, then the stores through argp are not considered
to be based on the frame pointer, if it is the same thing, such as on PA,
then indeed sibcall stack argument stores are frame related.
You could also add a !reload_completed to that, after RA frame_read is
how this is handled.

  /* Arguments for a sibling call that are pushed to memory are passed
 using the incoming argument pointer of the current function.  If
 argument pointer is the hard frame pointer, then treat sibling
 calls as wild reads before reload; after reload frame_read flag
 should take care of this.  */
  if (HARD_FRAME_POINTER_IS_ARG_POINTER
  && SIBLING_CALL_P (insn)
  && !reload_completed)
{
  add_wild_read (bb_info);
  return;
}

?

Jakub

Re: [patch, fortran] Fix for PR 47676

[H.J. Lu]

On Mon, Dec 29, 2014 at 4:25 PM, Thomas Koenig  wrote:
> Hello world,
>
> this patch fixes the long-standing bug.  A missing temporary
> causes an invalid read in realloc_on_assign_5.f03 which
> only becomes noticable when setting MALLOC_CHECK_ or when
> using valgrind.  The bug has three duplicates in the
> data base, so people keep stumbling across this.
>
> I have to confess I could not find the right way to put
> this into the normal dependency code; the assumption that
> the string copying will "do the right thing" is too deeply
> embedded in the code, or I have been looking at the wrong places.
>
> So I took the approach of using the big hammer of a frontend
> pass to fix this up.
>
> I would definitely like to see this bug fixed for 5.0.  If anybody
> has a better idea on how to tackle this in a timely manner, please
> let me know.
>
> Otherwise, OK for trunk?  What about the other branches?
>
> Regression-tested.
>
> 2014-12-29  Thomas Koenig  
>
> PR fortran/47674
> * dependency.c (gfc_discard_nops):  Add prototype.
> * dependency.c (discard_nops):  Rename to gfc_discard_nops,
> make non-static.
> (gfc_discard_nops):  Use gfc_discard_nops.
> (gfc_dep_difference):  Likewise.
> * frontend-passes.c (realloc_strings):  New function.
> Add prototype.
> (gfc_run_passes):  Call realloc_strings.
> (realloc_string_callback):  New function.
> (create_var):  Add prototype.  Handle case of a
> scalar character variable.
> (optimize_trim):  Do not handle allocatable variables.
>

On Linux/x86, I got

../../src-trunk/gcc/fortran/frontend-passes.c: In function ‘int
realloc_string_callback(gfc_code**, int*, void*)’:
../../src-trunk/gcc/fortran/frontend-passes.c:152:38: error:
‘gfc_discard_nops’ was not declared in this scope
   expr2 = gfc_discard_nops (co->expr2);
  ^
make[6]: *** [fortran/frontend-passes.o] Error 1


-- 
H.J.

Re: [PATCH] Fix einline ICE with EH (PR tree-optimization/64465)

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 07:38:20PM +0100, Richard Biener wrote:
> >> During function versioning fixup_cfg pass is supposed to handle that,
> >> during IPA inlining there is explicit call to execute_fixup_cfg, but
> >during
> >> early inlining there is not.
> >
> >I am still confused why early inliner does any redirections? It should
> >not.
> >Edge redirection is part of the IPA optimization machinery.
> 
> Possibly through stmt folding.

Generally yes, in this case, I doubt it, it isn't a builtin function.
But it is guarded by a false condition (__builtin_constant_p test), so
supposedly the early inliner figures out that it doesn't need to bother
with the dead call and replaces it with __builtin_unreachable anyway.

Jakub

[debug-early] remove unused argument from check_die

[Aldy Hernandez]

Committed to branch.
commit d176e84cc283bb0505e487341128b6f48599199d
Author: Aldy Hernandez 
Date:   Mon Jan 5 11:06:44 2015 -0800

* dwarf2out.c (check_die): Remove level argument.
(dwarf2out_decl): Remove level argument to check_die.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 8e0886c..9d60d88 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -5619,7 +5619,7 @@ check_die_inline (dw_die_ref die)
earlier in the compilation process.  */
 
 static void
-check_die (dw_die_ref die, unsigned level)
+check_die (dw_die_ref die)
 {
   static unsigned long mark = 1;
   dw_die_ref c, p;
@@ -5653,11 +5653,6 @@ check_die (dw_die_ref die, unsigned level)
c->die_abbrev = mark;
   } while (1);
 }
-
-  if (!level)
-return;
-
-  FOR_EACH_CHILD (die, c, check_die (c, level - 1));
 }
 
 
@@ -21656,7 +21651,7 @@ dwarf2out_decl (tree decl)
 
   dw_die_ref die = lookup_decl_die (decl);
   if (die)
-check_die (die, 0);
+check_die (die);
 #ifdef ENABLE_CHECKING
   /* If we early created a DIE, make sure it didn't get re-created by
  mistake.  */

Re: [PATCH, libgo] Backport fix for compiler flags in mksysinfo.sh to gcc 4.9

[Lynn A. Boger]

This one should not be backported.  It was submitted but not added 
upstream.  Sorry for the confusion.


On 12/30/2014 01:33 PM, Lynn A. Boger wrote:

Hi,

Please backport the change from 
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00713.html to gcc 4.9.


2014-12-30  Lynn Boger 

* libgo/mksysinfo.sh:  Add the same compiler flags used by 
configure to detect whether off64_t is present
   when generating the go structures for C types.  Otherwise the 
go type for off64_t might not be

   generated.

Re: [patch, fortran] Fix for PR 47676

[Thomas Koenig]

Am 05.01.2015 um 19:55 schrieb H.J. Lu:

> On Linux/x86, I got
> 
> ../../src-trunk/gcc/fortran/frontend-passes.c: In function ‘int
> realloc_string_callback(gfc_code**, int*, void*)’:
> ../../src-trunk/gcc/fortran/frontend-passes.c:152:38: error:
> ‘gfc_discard_nops’ was not declared in this scope
>expr2 = gfc_discard_nops (co->expr2);
>   ^
> make[6]: *** [fortran/frontend-passes.o] Error 1

Fixed, sorry for the breakage.

Thomas

[C++ PATCH] PR c++/64489

[Ville Voutilainen]

Tested on Linux-x64.

/cp
2015-01-05  Ville Voutilainen  

PR c++/64489
* class.c (check_field_decls): Make copy assignment operators
complex only in c++98 mode.

/testsuite
2015-01-05  Ville Voutilainen  

PR c++/64489
* g++.dg/ext/is_trivially_constructible1.C: Add tests for trivially
copyable classes that contain const members and reference members.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 07bbc69..421dae3 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -3606,13 +3606,15 @@ check_field_decls (tree t, tree *access_decls,
  CLASSTYPE_NON_STD_LAYOUT (t) = 1;
  if (DECL_INITIAL (x) == NULL_TREE)
SET_CLASSTYPE_REF_FIELDS_NEED_INIT (t, 1);
-
- /* ARM $12.6.2: [A member initializer list] (or, for an
-aggregate, initialization by a brace-enclosed list) is the
-only way to initialize nonstatic const and reference
-members.  */
- TYPE_HAS_COMPLEX_COPY_ASSIGN (t) = 1;
- TYPE_HAS_COMPLEX_MOVE_ASSIGN (t) = 1;
+ if (cxx_dialect < cxx11)
+   {
+ /* ARM $12.6.2: [A member initializer list] (or, for an
+aggregate, initialization by a brace-enclosed list) is the
+only way to initialize nonstatic const and reference
+members.  */
+ TYPE_HAS_COMPLEX_COPY_ASSIGN (t) = 1;
+ TYPE_HAS_COMPLEX_MOVE_ASSIGN (t) = 1;
+   }
}
 
   type = strip_array_types (type);
@@ -3714,13 +3716,15 @@ check_field_decls (tree t, tree *access_decls,
  C_TYPE_FIELDS_READONLY (t) = 1;
  if (DECL_INITIAL (x) == NULL_TREE)
SET_CLASSTYPE_READONLY_FIELDS_NEED_INIT (t, 1);
-
- /* ARM $12.6.2: [A member initializer list] (or, for an
-aggregate, initialization by a brace-enclosed list) is the
-only way to initialize nonstatic const and reference
-members.  */
- TYPE_HAS_COMPLEX_COPY_ASSIGN (t) = 1;
- TYPE_HAS_COMPLEX_MOVE_ASSIGN (t) = 1;
+ if (cxx_dialect < cxx11)
+   {
+ /* ARM $12.6.2: [A member initializer list] (or, for an
+aggregate, initialization by a brace-enclosed list) is the
+only way to initialize nonstatic const and reference
+members.  */
+ TYPE_HAS_COMPLEX_COPY_ASSIGN (t) = 1;
+ TYPE_HAS_COMPLEX_MOVE_ASSIGN (t) = 1;
+   }
}
   /* A field that is pseudo-const makes the structure likewise.  */
   else if (CLASS_TYPE_P (type))
diff --git a/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C 
b/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
index c866373..a5bac7b 100644
--- a/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
+++ b/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
@@ -36,3 +36,8 @@ SA(!__is_trivially_constructible(D));
 
 SA(__is_trivially_copyable(int));
 SA(!__is_trivially_copyable(volatile int));
+
+struct E1 {const int val;};
+SA(__is_trivially_copyable(E1));
+struct E2 {int& val;};
+SA(__is_trivially_copyable(E2));

Re: [PATCH] Fix PR c++/59366 A friend function template defined in a class is found without ADL

[Momchil Velikov]

On  5.01.2015 15:55, Jason Merrill wrote:

On 12/30/2014 11:24 AM, Momchil Velikov wrote:

A function template enters the body of the if statement at line 1881,

   if (TREE_CODE (newdecl) == TEMPLATE_DECL)

and exits the function at line 1951 with

   return olddecl;


Ah, yes.  The patch is OK, then, but still needs ChangeLog and testcase.

Jason



Bootstrapped/tested again with:

Target: x86_64-unknown-linux-gnu
Configured with: /home/chill/src/gcc-master/configure 
--prefix=/home/chill/opt/gcc-master --enable-languages=c,c++

Thread model: posix
gcc version 5.0.0 20150105 (experimental) [master revision 
113a5d9:4b40b3c:c1fd77316d75af1122efb4b8b2988a86599558dc] (GCC)





diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 2fea106..82401ab 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1865,6 +1865,19 @@ duplicate_decls (tree newdecl, tree olddecl, bool newdecl_is_friend)
   DECL_ATTRIBUTES (newdecl)
 = (*targetm.merge_decl_attributes) (olddecl, newdecl);
 
+  if (DECL_DECLARES_FUNCTION_P (olddecl) && DECL_DECLARES_FUNCTION_P (newdecl))
+{
+  olddecl_friend = DECL_FRIEND_P (olddecl);
+  hidden_friend = (DECL_ANTICIPATED (olddecl)
+		   && DECL_HIDDEN_FRIEND_P (olddecl)
+		   && newdecl_is_friend);
+  if (!hidden_friend)
+	{
+	  DECL_ANTICIPATED (olddecl) = 0;
+	  DECL_HIDDEN_FRIEND_P (olddecl) = 0;
+	}
+}
+
   if (TREE_CODE (newdecl) == TEMPLATE_DECL)
 {
   tree old_result;
@@ -2147,10 +2160,6 @@ duplicate_decls (tree newdecl, tree olddecl, bool newdecl_is_friend)
   if (DECL_DECLARES_FUNCTION_P (newdecl))
 	{
 	  DECL_NONCONVERTING_P (newdecl) = DECL_NONCONVERTING_P (olddecl);
-	  olddecl_friend = DECL_FRIEND_P (olddecl);
-	  hidden_friend = (DECL_ANTICIPATED (olddecl)
-			   && DECL_HIDDEN_FRIEND_P (olddecl)
-			   && newdecl_is_friend);
 	  DECL_BEFRIENDING_CLASSES (newdecl)
 	= chainon (DECL_BEFRIENDING_CLASSES (newdecl),
 		   DECL_BEFRIENDING_CLASSES (olddecl));
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 2dfb00d..d92a2cd 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -925,7 +925,18 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend)
 	}
 
   if (DECL_DECLARES_FUNCTION_P (t))
-	check_default_args (t);
+	{
+	  check_default_args (t);
+
+	  if (is_friend && t == x && !flag_friend_injection)
+	{
+	  /* This is a new friend declaration of a function or a
+		 function template, so hide it from ordinary function
+		 lookup.  */
+	  DECL_ANTICIPATED (t) = 1;
+	  DECL_HIDDEN_FRIEND_P (t) = 1;
+	}
+	}
 
   if (t != x || DECL_FUNCTION_TEMPLATE_P (t))
 	return t;
@@ -987,16 +998,6 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend)
 	}
 	}
 
-  if (TREE_CODE (x) == FUNCTION_DECL
-	  && is_friend
-	  && !flag_friend_injection)
-	{
-	  /* This is a new declaration of a friend function, so hide
-	 it from ordinary function lookup.  */
-	  DECL_ANTICIPATED (x) = 1;
-	  DECL_HIDDEN_FRIEND_P (x) = 1;
-	}
-
   /* This name is new in its binding level.
 	 Install the new declaration and return it.  */
   if (namespace_bindings_p ())
diff --git a/gcc/testsuite/g++.dg/template/friend57.C b/gcc/testsuite/g++.dg/template/friend57.C
new file mode 100644
index 000..7077d5e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/friend57.C
@@ -0,0 +1,21 @@
+// PR c++/59366
+// { dg-do compile }
+template void f(T);
+
+struct S
+{
+  template friend void f(T) {}
+  template friend void g(T) {}
+  template friend void h(T) {}
+};
+
+template void h(T);
+
+int
+main ()
+{
+  f(1);
+  g(1); // { dg-error "'g' was not declared in this scope" }
+  g(S());
+  h(1);
+}
diff --git a/gcc/testsuite/g++.old-deja/g++.pt/friend5.C b/gcc/testsuite/g++.old-deja/g++.pt/friend5.C
index 3feeb68..edb9d62 100644
--- a/gcc/testsuite/g++.old-deja/g++.pt/friend5.C
+++ b/gcc/testsuite/g++.old-deja/g++.pt/friend5.C
@@ -14,5 +14,5 @@ class C
 
 int main()
 {
-  f(7);
+  f(C());
 }


/cp
2015-01-05  Momchil Velikov  

PR c++/59366
* name-lookup.c (pushdecl_maybe_friend_1): Hide friend functions
and function templates, declared only in the class.
* decl.c (duplicate_decls): Reveal hidden friend functions or
function templates, if they are redeclared outside the class.

/testsuite
2015-01-05  Momchil Velikov  

PR c++/59366
* g++.dg/template/friend57.C: New
* g++.old-deja/g++.pt/friend5.C (main): Fix testcase. The friend
function `f` should be found only by ADL.

Re: [PATCH 3/4] Add Visium support to gcc

[Jeff Law]

On 01/03/15 08:16, Eric Botcazou wrote:



I'm a little concerned about the MODES_TIEABLE_P definition, but if it's
working, I wouldn't mess with it.


Could you elaborate?  Do you find it too restrictive?
I'm a little concerned it's too loose.  Basically it says that if both 
modes are integer modes, then they're tieable.  However, 
HARD_REGNO_MODE_OK may return different values for MODE1 and MODE2, even 
if both are integer modes.


My recollection is if MODES_TIEABLE_P returns true for mode1 and mode2, 
then HARD_REGNO_MODE_OK must return the same value when passed mode1 and 
mode2 regardless of the hard register and it's not obvious if 
HARD_REGNO_MODE_OK fits that criteria for this port.


Looking at the current docs, the language has been watered down from my 
recollection.  So.


If it's working, then I'd leave it as-is.





Any thoughts on using LRA for this port?  Ideally we want to be moving
away from reload as much as we can.


I can only promise to start experimenting with it and report issues, if any.
The port is quite mature and the performances are closely monitored so bold
changes need to be made with extra caution.

Understood.

FWIW, I suspect this is the last port I'll approve that doesn't use LRA 
instead of reload.





Yes, I'm going to be the maintainer for now.
Given you're already maintaining other parts of GCC, I really just 
consider appointing you as the maintainer for the port a formality. 
I'll start that process, but go ahead and list yourself as the 
maintainer in the MAINTAINERS file.


jeff

Re: [PING] Add refers_to_regno_p overload to simplify callers

[Jeff Law]

On 01/03/15 05:18, Oleg Endo wrote:

https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01730.html

On Sun, 2014-12-21 at 23:02 +0100, Oleg Endo wrote:

Hi,

It seems that quite some callers of refers_to_regno_p are interested in
testing a single register number only.  The caller code can be
simplified by adding an overload for refers_to_regno_p.  This is what
the patch does.  No functional changes.  Tested with 'make all-gcc' on
sh-elf cross config and bootstrapped on i686-pc-linux-gnu.
OK for trunk?

Cheers,
Oleg

gcc/ChangeLog:
* rtlanal.c (refers_to_regno_p): Change return value from int to
bool.
* rtl.h (refers_to_regno_p): Add overload.
* cse.c: Use it.
* bt-load.c: Likewise.
* combine.c: Likewise.
* df-scan.c: Likewise.
* sched-deps.c: Likewise.
* config/s390/s390.c: Likewise.
* config/m32r/m32r.c: Likewise.
* config/rs6000/spe.md: Likewise.
* config/rs6000/rs6000.c: Likewise.
* config/pa/pa.c: Likewise.
* config/stormy16/stormy16.c: Likewise.
* config/cris/cris.c: Likewise.
* config/arc/arc.md: Likewise.
* config/arc/arc.c: Likewise.
* config/sh/sh.md: Likewise.
* config/sh/sh.c: Likewise.
* config/frv/frv.c: Likewise.
OK for the trunk.  Though I think further patches of this nature should 
probably wait until stage1 reopens.


jeff

Re: [PATCH] Enable experimental TSAN support for Ada

[Jeff Law]

On 01/03/15 06:49, Bernd Edlinger wrote:

Hi,

I was experimenting with enabling TSAN for Ada recently.
I think this gives rather interesting results.

The Instrumentation worked almost out of the box, we just have
the problem that it is not gimple-OK to fold something like
"& VIEW_CONVERT_EXPR(x)", and this happens in Ada all the time.

Boot-Strapped and regression-tested on x86_64-linux-gnu.
OK for trunk?


Thanks
Bernd.



changelog-tsan-ada.txt


gcc/ChangeLog:
2015-01-03  Bernd Edlinger

Enable experimental TSAN support for Ada.
* tsan.c (instrument_expr): Handle VIEW_CONVERT_EXPR.
OK for the trunk with a comment before the new block of code indicating 
why we need to handle VIEW_CONVERT_EXPR specially here (specifically we 
can't call build_fold_addr_expr on the VIEW_CONVERT_EXPR).


Jeff

Re: [PATCH] toplev.c: Process the failure when read fails for random_seed

[Jeff Law]

On 12/28/14 21:04, Chen Gang S wrote:

When failure occurs, random_seed may not be 0, so need reset it to 0
manually, or will let the next call init_random_seed() incorrect.  The
related warning:

   g++ -c  -DTARGET_NAME=\"parisc-gchen-linux\" -g -O2 -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include 
-I../../gcc/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber 
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace   
-o toplev.o -MT toplev.o -MMD -MP -MF ./.deps/toplev.TPo ../../gcc/gcc/toplev.c
   ../../gcc/gcc/toplev.c: In function 'void init_local_tick()':
   ../../gcc/gcc/toplev.c:276:56: warning: ignoring return value of 'ssize_t 
read(int, void*, size_t)', declared with attribute warn_unused_result 
[-Wunused-result]

It passes testsuite under x86_64-apple-darwin14.0.0

/gcc
2014-12-27  Chen Gang  

* toplev.c (init_local_tick): Process the failure when read
fails for random_seed.

This is fine for the trunk.  Please install.

jeff

Re: [PATCH] Cleaning up incomplete type warning.

[Jeff Law]

On 12/24/14 11:07, Luis Felipe Strano Moraes wrote:

This removes an unnecessary static variable from the code and also makes it a 
single
warning instead of two. Patch originally proposed by Manuel López-Ibáñez.

Luis Strano


clean_incomplete_warning.log


gcc/c/ChangeLog:

2014-12-24  Luis Felipe Strano Moraes

* c-decl.c (get_parm_info): cleaning up incomplete type warning.

OK for the trunk assuming it passed bootstrap and regression testing.

Jeff

ps.  I'm sure someone will complain that we've changed this warning 
message ever-so-slightly mucking up whatever code out there that parses 
warning/error messages.

Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c

[John David Anglin]

On 1/5/2015 1:51 PM, Jakub Jelinek wrote:

So isn't the right replacement for the target hook H.J. wanted to add
the HARD_FRAME_POINTER_IS_ARG_POINTER macro?
If argp is not hfp, then the stores through argp are not considered
to be based on the frame pointer, if it is the same thing, such as on PA,
then indeed sibcall stack argument stores are frame related.
You could also add a !reload_completed to that, after RA frame_read is
how this is handled.

   /* Arguments for a sibling call that are pushed to memory are passed
  using the incoming argument pointer of the current function.  If
 argument pointer is the hard frame pointer, then treat sibling
 calls as wild reads before reload; after reload frame_read flag
 should take care of this.  */
   if (HARD_FRAME_POINTER_IS_ARG_POINTER
  && SIBLING_CALL_P (insn)
  && !reload_completed)
 {
   add_wild_read (bb_info);
   return;
 }

?

I think there may be one situation after reload that's not handled
by the above.  frame_read is only used for const calls.  What about
the situation where we have a non const sibcall and the frame pointer
isn't eliminated?

Dave

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

Re: libsanitizer merge from upstream r221802

[Christophe Lyon]

On 31 December 2014 at 13:29, David Abdurachmanov
 wrote:
>
> On Dec 30, 2014, at 11:48 PM, Andrew Pinski wrote:
>>> If we have 64-bit kernel and 64-bit application is executed sys_getresuid is
>>> used for getresuid syscall, otherwise if 32-bit application is executed --
>>> sys_getresuid16 is used. Thus 64-bit application will never call
>>> sys_getresuid16 implemenation. Then
>>> getresuid16/getresgid16/getgroups16/setgroups16/etc only needs to in 32-bit
>>> binary of libsanitizer. Same should apply for x86_64/i*86.
>>>
>>> Is that correct?
>>
>> Kinda.  It only applies for aarch32 and not for AARCH64:ILP32.
>> AARCH64:ILP32 uses the standard system calls here too.
>
>
> I am attaching an updated patch, bootstrapped trunk on arrch64 with kernels 
> 3.12 and 3.17 (QEMU).
>
> I looked at kernel source. If CONFIG_COMPAT is set then CONFIG_HAVE_UID16 is 
> set.

Thanks for taking care of this.

>
> From include/linux/syscalls.h
>
> 523 #ifdef CONFIG_UID16
> 524 asmlinkage long sys_chown16(const char __user *filename,
> 525 old_uid_t user, old_gid_t group);
> 526 asmlinkage long sys_lchown16(const char __user *filename,
> 527 old_uid_t user, old_gid_t group);
> 528 asmlinkage long sys_fchown16(unsigned int fd, old_uid_t user, old_gid_t 
> group);
> 529 asmlinkage long sys_setregid16(old_gid_t rgid, old_gid_t egid);
> 530 asmlinkage long sys_setgid16(old_gid_t gid);
> 531 asmlinkage long sys_setreuid16(old_uid_t ruid, old_uid_t euid);
> 532 asmlinkage long sys_setuid16(old_uid_t uid);
> 533 asmlinkage long sys_setresuid16(old_uid_t ruid, old_uid_t euid, old_uid_t 
> suid);
> 534 asmlinkage long sys_getresuid16(old_uid_t __user *ruid,
> 535 old_uid_t __user *euid, old_uid_t __user 
> *suid);
> 536 asmlinkage long sys_setresgid16(old_gid_t rgid, old_gid_t egid, old_gid_t 
> sgid);
> 537 asmlinkage long sys_getresgid16(old_gid_t __user *rgid,
> 538 old_gid_t __user *egid, old_gid_t __user 
> *sgid);
> 539 asmlinkage long sys_setfsuid16(old_uid_t uid);
> 540 asmlinkage long sys_setfsgid16(old_gid_t gid);
> 541 asmlinkage long sys_getgroups16(int gidsetsize, old_gid_t __user 
> *grouplist);
> 542 asmlinkage long sys_setgroups16(int gidsetsize, old_gid_t __user 
> *grouplist);
> 543 asmlinkage long sys_getuid16(void);
> 544 asmlinkage long sys_geteuid16(void);
> 545 asmlinkage long sys_getgid16(void);
> 546 asmlinkage long sys_getegid16(void);
> 547 #endif
>
> Thus I disabled such syscalls in libsanitizer with SANITIZER_WORDSIZE macro 
> and disabled
> type checks for __kernel_old_{uid,gid}_t. Did not touch the fragment which 
> sets
> __kernel_old_{uid,gid}_t.
>
> SANITIZER_WORDSIZE is set based on _LP64 macro.
>
> If patch is acceptable I could do more tests after holidays.
>

As it seems you are not aware of it, and the llvm guys haven't yet
told you: these patches need to be approved in the upstream
sanitizer/llvm repo, and they will be merge into gcc later. So I
believe you need to send your patches to llvm first.

Thanks,

Christophe.

> Thanks,
> david
>

Re: [x86, PATCH] operand reordering for commutative operations

[Jeff Law]

On 12/29/14 06:30, Yuri Rumyantsev wrote:

Hi All,

Here is a patch which fixed several performance degradation after
operand canonicalization (r216728). Very simple approach is used - if
operation is commutative and its second operand required more
operations (statements) for computation, swap operands.
Currently this is done under special option which is set-up to true
only for x86 32-bit targets ( we have not  seen any performance
improvements on 64-bit).

Is it OK for trunk?

2014-12-26  Yuri Rumyantsev  

* cfgexpand.c (count_num_stmt): New function.
(reorder_operands): Likewise.
(expand_gimple_basic_block): Insert call of reorder_operands.
* common.opt(flag_reorder_operands): Add new flag.
* config/i386/i386.c (ix86_option_override_internal): Add setup of
flag_reorder_operands for 32-bit target only.
* (doc/invoke.texi: Add new optimization option -freorder-operands.

gcc/testsuite/ChangeLog
* gcc.target/i386/swap_opnd.c: New test.
I'd do this unconditionally -- I don't think there's a compelling reason 
to add another flag here.


Could you use estimate_num_insns rather than rolling your own estimate 
code here?  All you have to do is setup the weights structure and call 
the estimation code.  I wouldn't be surprised if ultimately the existing 
insn estimator is better than the one you're adding.


Make sure to reference the PR in the ChangeLog.

Please update and resubmit.

Thanks,
Jeff

Re: [PATCH] simplify-rtx: Generalize (and X (ior (not X) Y) -> (and X Y)

[Jeff Law]

On 12/24/14 10:05, Segher Boessenkool wrote:

The existing transform

   (and X (ior (not X) Y) -> (and X Y)

has two shortcomings: it only handles identical RTX for X, i.e. registers,
not e.g. subregs of registers; and it only handles the case where the NOT
is the first arm of the IOR (it can be the second arm e.g. if the first
arm is a NOT as well).  Fix both.  This fixes gcc.dg/and-1.c on powerpc64.

Bootstrapped and tested on powerpc64-linux; okay for mainline?


Segher


2014-12-24  Segher Boessenkool  

gcc/
* simplify-rtx.c (simplify_binary_operation_1): Handle more cases
for the "(and X (ior (not X) Y) -> (and X Y)" transform.

OK.
jeff

Re: [PATCH] combine: Correct cost calculation and display for split I2

[Jeff Law]

On 12/24/14 10:04, Segher Boessenkool wrote:

If we have split a parallel I2 to two insns, we will count its RTL cost
twice.  This currently does not matter since the cost is 0 always (it is
not a single set insn), but let's fix it anyway.

Also do not display the fake I1 in the cost calculation in the dump file.

Tested on powerpc64-linux.  Okay for mainline?


Segher


2014-12-24  Segher Boessenkool  

gcc/
* combine.c (combine_validate_cost): Do not count the cost of a
split I2 twice.  Do not display it twice in the dump, either.

OK.
Jeff

Patch committed: Go backports to gcc 4.9 branch

[Ian Lance Taylor]

I've backported a few Go-specific patches to the GCC 4.9 branch.

https://codereview.appspot.com/154800044

compiler: Recognize 64-bit symbol tables in archives.

By Dominik Vogt.

2014-11-21  Lynn Boger  

* go.test/go-test.exp (go-set-goarch): Add case for ppc64le goarch
value for go testing.

https://codereview.appspot.com/168710043

runtime: GOARCH values for ppc64 BE & LE

ppc64 for BE
ppc64le for LE
issue 8654

https://codereview.appspot.com/167780044

debug/elf: add power64 support along with relocation test

Backport of https://codereview.appspot.com/125910043 from the
dev.power64 branch of the master repository.


Ian
Index: gcc/go/gofrontend/import-archive.cc
===
--- gcc/go/gofrontend/import-archive.cc (revision 219119)
+++ gcc/go/gofrontend/import-archive.cc (working copy)
@@ -295,6 +295,15 @@ Archive_file::interpret_header(const Arc
   // This is the symbol table.
   pname->clear();
 }
+  else if (hdr->ar_name[1] == 'S' && hdr->ar_name[2] == 'Y'
+  && hdr->ar_name[3] == 'M' && hdr->ar_name[4] == '6'
+  && hdr->ar_name[5] == '4' && hdr->ar_name[6] == '/'
+  && hdr->ar_name[7] == ' '
+ )
+{
+  // 64-bit symbol table.
+  pname->clear();
+}
   else if (hdr->ar_name[1] == '/')
 {
   // This is the extended name table.
Index: gcc/testsuite/go.test/go-test.exp
===
--- gcc/testsuite/go.test/go-test.exp   (revision 219119)
+++ gcc/testsuite/go.test/go-test.exp   (working copy)
@@ -241,7 +241,11 @@ proc go-set-goarch { } {
if [check_effective_target_ilp32] {
set goarch "ppc"
} else {
-   set goarch "ppc64"
+   if [istarget "powerpc64le-*-*"] {
+   set goarch "ppc64le"
+   } else {
+   set goarch "ppc64"
+   }
}
}
"sparc*-*-*" {
Index: libgo/configure.ac
===
--- libgo/configure.ac  (revision 219119)
+++ libgo/configure.ac  (working copy)
@@ -179,6 +179,7 @@ is_m68k=no
 mips_abi=unknown
 is_ppc=no
 is_ppc64=no
+is_ppc64le=no
 is_sparc=no
 is_sparc64=no
 is_x86_64=no
@@ -249,11 +250,18 @@ changequote([,])dnl
 #ifdef _ARCH_PPC64
 #error 64-bit
 #endif],
-[is_ppc=yes], [is_ppc64=yes])
+[is_ppc=yes],
+[AC_COMPILE_IFELSE([
+#if defined(_BIG_ENDIAN) || defined(__BIG_ENDIAN__)
+#error 64be
+#endif],
+[is_ppc64le=yes],[is_ppc64=yes])])
 if test "$is_ppc" = "yes"; then
   GOARCH=ppc
-else
+elif test "$is_ppc64" = "yes"; then
   GOARCH=ppc64
+else
+  GOARCH=ppc64le
 fi
 ;;
   sparc*-*-*)
@@ -281,6 +289,7 @@ AM_CONDITIONAL(LIBGO_IS_MIPSN64, test $m
 AM_CONDITIONAL(LIBGO_IS_MIPSO64, test $mips_abi = o64)
 AM_CONDITIONAL(LIBGO_IS_PPC, test $is_ppc = yes)
 AM_CONDITIONAL(LIBGO_IS_PPC64, test $is_ppc64 = yes)
+AM_CONDITIONAL(LIBGO_IS_PPC64LE, test $is_ppc64le = yes)
 AM_CONDITIONAL(LIBGO_IS_SPARC, test $is_sparc = yes)
 AM_CONDITIONAL(LIBGO_IS_SPARC64, test $is_sparc64 = yes)
 AM_CONDITIONAL(LIBGO_IS_X86_64, test $is_x86_64 = yes)
Index: libgo/go/debug/elf/file.go
===
--- libgo/go/debug/elf/file.go  (revision 219119)
+++ libgo/go/debug/elf/file.go  (working copy)
@@ -681,7 +681,7 @@ func (f *File) DWARF() (*dwarf.Data, err
// If there's a relocation table for .debug_info, we have to process it
// now otherwise the data in .debug_info is invalid for x86-64 objects.
rela := f.Section(".rela.debug_info")
-   if rela != nil && rela.Type == SHT_RELA && (f.Machine == EM_X86_64 || 
f.Machine == EM_AARCH64) {
+   if rela != nil && rela.Type == SHT_RELA && (f.Machine == EM_X86_64 || 
f.Machine == EM_AARCH64 || f.Machine == EM_PPC64) {
data, err := rela.Data()
if err != nil {
return nil, err
Index: libgo/go/go/build/syslist.go
===
--- libgo/go/go/build/syslist.go(revision 219119)
+++ libgo/go/go/build/syslist.go(working copy)
@@ -5,4 +5,4 @@
 package build
 
 const goosList = "darwin dragonfly freebsd linux netbsd openbsd plan9 windows 
solaris "
-const goarchList = "386 amd64 arm arm64 alpha m68k mipso32 mipsn32 mipsn64 
mipso64 ppc ppc64 sparc sparc64 "
+const goarchList = "386 amd64 arm arm64 alpha m68k mipso32 mipsn32 mipsn64 
mipso64 ppc ppc64 ppc64le sparc sparc64 "

Re: [PATCH] Fix einline ICE with EH (PR tree-optimization/64465)

[Jan Hubicka]

> On Mon, Jan 05, 2015 at 07:38:20PM +0100, Richard Biener wrote:
> > >> During function versioning fixup_cfg pass is supposed to handle that,
> > >> during IPA inlining there is explicit call to execute_fixup_cfg, but
> > >during
> > >> early inlining there is not.
> > >
> > >I am still confused why early inliner does any redirections? It should
> > >not.
> > >Edge redirection is part of the IPA optimization machinery.
> > 
> > Possibly through stmt folding.
> 
> Generally yes, in this case, I doubt it, it isn't a builtin function.
> But it is guarded by a false condition (__builtin_constant_p test), so
> supposedly the early inliner figures out that it doesn't need to bother
> with the dead call and replaces it with __builtin_unreachable anyway.

Ah, I see,  this is resonable explanation - this one changed with enabling
the predicates early.
The patch is OK. Thanks.

Honza
> 
>   Jakub

Re: [PATCH] -f{no-sanitize,{,no-}sanitize-recover}=all support

[Jeff Law]

On 01/05/15 09:58, Jakub Jelinek wrote:

On Tue, Dec 23, 2014 at 04:47:06PM -0800, Alexey Samsonov wrote:

Right, -fsanitize=all produces an error, while -fsanitize-recover=all
enables recovery for all
sanitizers, -fno-sanitize-recover=all disables recovery for everything.


Ok, here is a GCC patch for that.
-fno-sanitize=all is supported as a way to turn off all the sanitizers,
-f{,no-}sanitize-recover=all is supported too, and one can mix all
with other sanitizer names.

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

2015-01-05  Jakub Jelinek  

* opts.c (common_handle_option): Add support for
-fno-sanitize=all and -f{,no-}sanitize-recover=all.

* c-c++-common/asan/sanitize-all-1.c: New test.
* c-c++-common/ubsan/sanitize-all-1.c: New test.
* c-c++-common/ubsan/sanitize-all-2.c: New test.
* c-c++-common/ubsan/sanitize-all-3.c: New test.
* c-c++-common/ubsan/sanitize-all-4.c: New test.
Are there any doc updates that need to happen as a result of this patch? 
 Patch itself is fine for the trunk, just want to make sure the doc 
side is good too.


jeff

Re: [PATCH, i386] Remove EBX usage from asm code

[Jeff Law]

On 12/28/14 09:46, Evgeny Stupachenko wrote:

Hi,

The patch removes EBX usage from asm code used in libgcc/crtstuff.c
It is safe now, but potentially buggy when glibc is rebuild with GCC
5.0 as EBX is not GOT register any more.

x86 bootstrap, make check passed.

Is it ok?

Evgeny

2014-12-28  Evgeny Stupachenko  

 * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage.
 * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto.

I don't understand the glibc reference above.

Ultimately what matters here, AFAICT is the value assigned to the 
parameter to CRT_GET_RFIB_DATA which should be the base of the data 
relative relocations.  So the comment "It is safe now" seems wrong as well.


ISTM this is a critical fix as it would be possible for the PIC pseudo 
to be assigned to something other than %ebx when compiling 
libgcc/crtstuff.c.  And if that happens, we'll pass in a junk value to 
register_frame_info_bases.


Evgeny, can you clarify why you think things are safe now, but would not 
be safe if glibc were to be built with the current GCC trunk?


Jeff

Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Mike Stump]

On Jan 5, 2015, at 12:49 AM, Bernd Edlinger  wrote:
> On Sun, 4 Jan 2015 14:18:59, Mike Stump wrote:
>> 
>>> But tsan still gets at least 90% chance to spot that. As a matter of fact, 
>>> the tsan runtime is just _incredibly_ fast,
>>> and catches errors, with a very high reliability. But it is racy by design.
>> 
>> You say by design. I’m skeptical of that. Can you quote the email or the 
>> code were they said I wanted to design a system that wasn’t 100% reliable, 
>> because the best they could do was 2% slower, and they didn’t want it to be 
>> 2% slower? I tend to think someone didn’t figure out they could atomically, 
>> locklessly do the update, or they didn’t understand the performance hit on 
>> the lockless code was small, or worse, they had no clue it was racy. I’d be 
>> curious to know. Maybe, there are other complications that prevent it from 
>> being non-racy.
> 
> see for instance this thread "Is TSan an exact tool?":
> https://groups.google.com/forum/#!topic/thread-sanitizer/mB73m6Nltaw

Yeah, that’s not the issue.  The issue is, in this one narrow case, was is 
possible to use a lockless method of updating the data so that the tool would 
be slightly better.  That post doesn’t address this question.  For example, if 
a patch were submitted to locklessly update so both can notice who is first, 
was it rejected and why?  Anyway, that’s a side issue, and we can safely ignore 
it.  I’m fine with making testing reliable with how it works today.

> Nevertheless I would prefer to silence the test now with sleep(1),

> And come back later with a follow-up patch to use a un-instrumented and
> non-interceptable synchronization primitive in all tsan tests. As it is at 
> least
> not obvious how to do that in the test suite.  But it must be possible.

I thought the code was posted, I thought how to put it in a file was posted.  I 
think it is a 2 minute endeavor to put all those pieces together and run a test 
case?  You do know how to run just 1 tsan test case with make 
RUNTESTFLAGS=tsan.exp=aligned_vs_unaligned_race.C check-g++ sort of thing?  
This can shorten the testing time from hours per iteration to seconds per 
iteration.  Slightly non-obvious, but very handy when developing some types of 
test cases.

So, to help you out, I tried my hand at wiring up the extra library code:

gcc/gcc/testsuite/gcc.dg/tsan$ cat test1.c
/* { dg-additional-options "-O2" } */
/* { dg-additional-sources "lib.c" } */

void sync(int);

int main(int argc, char**argv) {
  sync(1);
  sync(2);
  sync(3);
}
gcc/gcc/testsuite/gcc.dg/tsan$ cat lib.c
/* { dg-do compile } */
#include 

volatile int serial;

__attribute__((no_sanitize_address))
void sync(int i) {
  while (serial != i-1) ;
  while (1) {
if (++serial == i)
  return;
--serial;
sleep ();
  }
}

and it ran just fine.  The options are for both files.  I read some of the tsan 
documentation, and they seem to claim you can have tsan not process a function 
by merely asking.  I did that.  I don’t know if that is enough to hide all the 
semantics that need to be hidden.

In the above code, the ++ and -- should be an atomic increment/decrement.

The idea is that can can introduce a deterministic ordering to the execution of 
the code by adding sync(n), where n is the step number, whose range starts at 1.

So, for example, here is the test case, with the bits added, so you can see how 
I transformed what would have been the sleep into the use of the synchronizing 
primitive from the library.

/* { dg-additional-sources "lib.c" } */
/* { dg-shouldfail "tsan" } */

#include 
#include 
#include 
#include 

void sync(int);

uint64_t Global[2];

void *Thread1(void *x) {
  sync (2);
  Global[1]++;
  return NULL;
}

void *Thread2(void *x) {
  char *p1 = reinterpret_cast(&Global[0]);
  struct __attribute__((packed, aligned(1))) u_uint64_t { uint64_t val; };
  u_uint64_t *p4 = reinterpret_cast(p1 + 1);
  (*p4).val++;
  sync (1);
  return NULL;
}

int main() {
  pthread_t t[2];
  pthread_create(&t[0], NULL, Thread1, NULL);
  pthread_create(&t[1], NULL, Thread2, NULL);
  pthread_join(t[0], NULL);
  pthread_join(t[1], NULL);
  printf("Pass\n");
  /* { dg-output "WARNING: ThreadSanitizer: data race.*(\n|\r\n|\r)" } */
  /* { dg-output "Pass.*" } */
  return 0;
}

The question is, does this 100% reliably solve the problem?

RE: [PATCH] Don't check for optab for 16bit bswap

[Oleg Endo]

On Mon, 2015-01-05 at 14:54 +, Thomas Preud'homme wrote:
> > From: Oleg Endo [mailto:oleg.e...@t-online.de]
> > Sent: Tuesday, December 30, 2014 4:25 PM
> > 
> > I've just tried disabling the 'rotlhi3' pattern and __builtin_bswap16
> > expands into shift + and + or (as expected).
> > Thus, I don't think the patch will make something worse (than it
> > already
> > 
> > .L42:
> > 
> > is) on some backends.  If the bswap detection bails out at the tree
> > level, the expanded ops will be shift + and + or -- as written in the
> > original code.  So probably, that will be the same as the fallback
> > expansion for __builtin_bswap16, and we're back to sqrt (1).
> > 
> > > OK, that is what I was asking - are there cases where using rot is worse
> > (like forcing a libcall or so).
> > 
> > See also comment in expmed.c (expand_shift_1):
> >  It is theoretically possible that the target machine might
> >  not be able to perform either shift and hence we would
> >  be making two libcalls rather than just the one for the
> >  shift (similarly if IOR could not be done).  We will allow
> >  this extremely unlikely lossage to avoid complicating the
> >  code below.  */
> > 
> > then goto .L42  ;)
> 
> Yes and if the fallback expansion for a rot is actually worse than the
> original set of stmt it means the fallback expansion should be improved.

I might be missing something, but how can the original shift/and/or
statements (which eventually are translated to shift/and/or insns) be
any better than the shift/and/or insns that are expanded by the rot
fallback?  In both cases the insns have to go through the backend
expanders, and if those are absent/unsupported libcalls will be
expanded.

> Now I realize that said like this it sounds more like stage1 material.
> 
> Would it be fine for next stage1?

Or maybe just leave everything as it is and I add a bswaphi expander in
the SH backend ;)

Cheers,
Oleg

Re: [PATCH 3/4] Add Visium support to gcc

[Eric Botcazou]

> I'm a little concerned it's too loose.  Basically it says that if both
> modes are integer modes, then they're tieable.  However,
> HARD_REGNO_MODE_OK may return different values for MODE1 and MODE2, even
> if both are integer modes.
> 
> My recollection is if MODES_TIEABLE_P returns true for mode1 and mode2,
> then HARD_REGNO_MODE_OK must return the same value when passed mode1 and
> mode2 regardless of the hard register and it's not obvious if
> HARD_REGNO_MODE_OK fits that criteria for this port.

I see, thanks for explaining.  I didn't write these macros and I agree that 
HARD_REGNO_MODE_OK is a little convoluted, but MODES_TIEABLE_P is correct as 
far as the arch is concerned so I'd rather tweak the former if need be.

> Given you're already maintaining other parts of GCC, I really just
> consider appointing you as the maintainer for the port a formality.
> I'll start that process, but go ahead and list yourself as the
> maintainer in the MAINTAINERS file.

Will do.

-- 
Eric Botcazou

RE: [PATCH] Don't check for optab for 16bit bswap

[Richard Biener]

On January 5, 2015 3:54:40 PM CET, Thomas Preud'homme 
 wrote:
>> From: Oleg Endo [mailto:oleg.e...@t-online.de]
>> Sent: Tuesday, December 30, 2014 4:25 PM
>> 
>> I've just tried disabling the 'rotlhi3' pattern and __builtin_bswap16
>> expands into shift + and + or (as expected).
>> Thus, I don't think the patch will make something worse (than it
>> already
>> 
>> .L42:
>> 
>> is) on some backends.  If the bswap detection bails out at the tree
>> level, the expanded ops will be shift + and + or -- as written in the
>> original code.  So probably, that will be the same as the fallback
>> expansion for __builtin_bswap16, and we're back to sqrt (1).
>> 
>> > OK, that is what I was asking - are there cases where using rot is
>worse
>> (like forcing a libcall or so).
>> 
>> See also comment in expmed.c (expand_shift_1):
>>  It is theoretically possible that the target machine might
>>  not be able to perform either shift and hence we would
>>  be making two libcalls rather than just the one for the
>>  shift (similarly if IOR could not be done).  We will allow
>>  this extremely unlikely lossage to avoid complicating the
>>  code below.  */
>> 
>> then goto .L42  ;)
>
>Yes and if the fallback expansion for a rot is actually worse than the
>original set of stmt it means the fallback expansion should be
>improved.
>
>Now I realize that said like this it sounds more like stage1 material.
>
>Would it be fine for next stage1?

No, I think the patch is fine as-is now.

Thanks,
Richard.

>Best regards,
>
>Thomas 

Re: [PATCH] gcc/testsuite/gcc.dg/typeof-2.c

[Jeff Law]

On 12/15/14 00:26, Sebastian Huber wrote:

gcc/testsuite/ChangeLog
2014-12-15  Sebastian Huber  

* gcc.dg/typeof-2.c: Add checks for non-atomic types.

OK for the trunk.  Please install.

Thanks,
Jeff

Re: [PATCH] libobjc: Properly handle classes without instance variables in class_copyIvarList ().

[Mike Stump]

On Dec 24, 2014, at 9:28 AM, Dimitris Papavasiliou  wrote:
> The attached patch fixes an issue reported a couple of years ago in Bug 51891 
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891).  The problem is caused 
> because classes without instance variables have no ivar list at all, so that 
> their ivars pointer is NULL, but the code in class_copyIvarList () is unaware 
> of this.
> 
> That this is in fact so can be easily verified by checking the code of 
> class_addIvar in the same source file, where the ivars list is allocated when 
> the first ivar is added.  The code there also checks for a NULL ivars pointer.
> 
> The patch also adds a simple test-case for this issue.  I think that the 
> ChangeLog entry should be something along the lines of:
> 
>   2014-12-24  Dimitris Papavasiliou  
> 
> PR libobjc/51891
> * libobjc/ivars.c: Add a check for classes without instance
>   variables, which have a NULL ivar list pointer.
> * gcc/testsuite/objc.dg/gnu-api-2-class.m: Add a test case
>   for the above change.
> 
> I hope I got the formatting right.  I've run make -k check-objc and all tests 
> pass without problems.
> 
> Let me know if there are any problems, or if I can do anything else to 
> facilitate the acceptance of the patch.
> 
> Regards,
> Dimitris

So, Andrew is the reviewer for libobjc.  I’m not.  I don’t have any issue with 
it.

Andrew?



class_copyIvarList_bugfix.diff
Description: Binary data

Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 03:16:46PM -0500, John David Anglin wrote:
> I think there may be one situation after reload that's not handled
> by the above.  frame_read is only used for const calls.  What about
> the situation where we have a non const sibcall and the frame pointer
> isn't eliminated?

After reload DSE is run after threading prologues/epilogues, end
the prologue/epilogue sequences usually contain wild reads, e.g.
(mem:BLK (scratch)) in some insn etc.
Do you have some particular testcase in mind?

That said, DSE after reload is much more limited than the DSE before reload,
so is less important, so perhaps even
  if ((HARD_FRAME_POINTER_IS_ARG_POINTER || reload_completed)
  && SIBLING_CALL_P (insn))
{
  add_wild_read (bb_info);  
   
  return;   
   
}
might be good enough.

Jakub

Re: Patch ping

[Jeff Law]

On 01/05/15 06:53, Jakub Jelinek wrote:

Hi!

I'd like to ping 3 patches:

http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html
   - PR64344 - -fsanitize=float-cast-overflow fix - the C FE part
 is approved, but not the sanitizer bits outside of the FE

OK.



http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01271.html
   - PR64265 - tsan support for exceptions

OK.



http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html
   - -fsanitize=vptr support
How is this different from vtable pointer verification that we already 
support?  Is there some reason we can't just use that instead?


jeff

Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 10:23:57PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 05, 2015 at 03:16:46PM -0500, John David Anglin wrote:
> > I think there may be one situation after reload that's not handled
> > by the above.  frame_read is only used for const calls.  What about
> > the situation where we have a non const sibcall and the frame pointer
> > isn't eliminated?
> 
> After reload DSE is run after threading prologues/epilogues, end
> the prologue/epilogue sequences usually contain wild reads, e.g.
> (mem:BLK (scratch)) in some insn etc.
> Do you have some particular testcase in mind?
> 
> That said, DSE after reload is much more limited than the DSE before reload,
> so is less important, so perhaps even
>   if ((HARD_FRAME_POINTER_IS_ARG_POINTER || reload_completed)
>   && SIBLING_CALL_P (insn))
> {
>   add_wild_read (bb_info);
>  
>   return; 
>  
> }
> might be good enough.

Or you could e.g. do the
  if (HARD_FRAME_POINTER_IS_ARG_POINTER
  && !reload_completed
  && SIBLING_CALL_P (insn))
{ add_wild_read (bb_info); return; }
case first, then compute const_call and memset_call,
  if (const_call || memset_call)
{ current_big_block }
  else if (reload_completed && SIBLING_CALL_P (insn))
add_wild_read (bb_info);
  else
add_non_frame_wild_read (bb_info);

That way, you would not punish const/memset calls unnecessarily after reload
when they are sibling calls.

Jakub

Re: Patch ping

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 02:27:41PM -0700, Jeff Law wrote:
> On 01/05/15 06:53, Jakub Jelinek wrote:
> >Hi!
> >
> >I'd like to ping 3 patches:
> >
> >http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html
> >   - PR64344 - -fsanitize=float-cast-overflow fix - the C FE part
> > is approved, but not the sanitizer bits outside of the FE
> OK.
> 
> >
> >http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01271.html
> >   - PR64265 - tsan support for exceptions
> OK.
> 
> >
> >http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html
> >   - -fsanitize=vptr support
> How is this different from vtable pointer verification that we already
> support?  Is there some reason we can't just use that instead?

I don't now the current vtable pointer verification too much, but my
understanding of it is that it is hardly usable, because e.g. it requires
libstdc++ to be rebuilt with the verification enabled, otherwise you can't
verify stuff, and that means a performance penalty even for code you don't
want to verify.  Unlike that, -fsanitize=vptr is lightweight, and you only
rebuild with it what you want and can have other code kept as is, not
recompiled.

Jakub

Re: [Patch][testsuite] Fix a few test cases

[Jeff Law]

On 12/12/14 12:38, Ryan Mansfield wrote:

Hi,

Here are a few test tweaks. In 921202-1.c, if STACK_SIZE is used then
VLEN will blow the stack with 64bit longs. e.g. if STACK_SIZE == 512K
then 3 arrays of 32767 longs means at a minimum 767K of stack will be
used at -O0. In pr51447.c, the rbx global register is clobbering the rbx
of main's caller, which can cause test case crashes on return.

2014-12-12  Ryan Mansfield  

 * gcc.c-torture/execute/921202-1.c: Adjust VLEN.
 * gcc.c-torture/execute/pr51447.c: Restore rbx for x86-64.
 * gcc.dg/cpp/trad/include.c: Exclude QNX targets.

OK for the trunk.  Please install.

Thanks,
Jeff

Re: [PATCH] -f{no-sanitize,{,no-}sanitize-recover}=all support

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 01:32:42PM -0700, Jeff Law wrote:
> On 01/05/15 09:58, Jakub Jelinek wrote:
> >On Tue, Dec 23, 2014 at 04:47:06PM -0800, Alexey Samsonov wrote:
> >>Right, -fsanitize=all produces an error, while -fsanitize-recover=all
> >>enables recovery for all
> >>sanitizers, -fno-sanitize-recover=all disables recovery for everything.
> >
> >Ok, here is a GCC patch for that.
> >-fno-sanitize=all is supported as a way to turn off all the sanitizers,
> >-f{,no-}sanitize-recover=all is supported too, and one can mix all
> >with other sanitizer names.
> >
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> >2015-01-05  Jakub Jelinek  
> >
> > * opts.c (common_handle_option): Add support for
> > -fno-sanitize=all and -f{,no-}sanitize-recover=all.
> >
> > * c-c++-common/asan/sanitize-all-1.c: New test.
> > * c-c++-common/ubsan/sanitize-all-1.c: New test.
> > * c-c++-common/ubsan/sanitize-all-2.c: New test.
> > * c-c++-common/ubsan/sanitize-all-3.c: New test.
> > * c-c++-common/ubsan/sanitize-all-4.c: New test.
> Are there any doc updates that need to happen as a result of this patch?
> Patch itself is fine for the trunk, just want to make sure the doc side is
> good too.

You're right, I'll add documentation tomorrow and repost the patch.

Jakub

Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Mike Stump]

On Jan 5, 2015, at 12:58 PM, Mike Stump  wrote:
> So, to help you out, I tried my hand at wiring up the extra library code:

So, my tsan build finally finished, and I could try this with a real test case. 
 I ran it 20 times, and got 11 fails with:

$ i=20; while let i--; do make 
RUNTESTFLAGS=tsan.exp=aligned_vs_unaligned_race.C check-g++ | grep FAIL; done
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O2  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O0  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O2  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O2  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O2  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O0  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O0  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O2  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O2  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O2  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O0  execution test
$ 

When I fixed the problem, I ran it 20 times:

$ i=20; while let i--; do make 
RUNTESTFLAGS=tsan.exp=aligned_vs_unaligned_race.C check-g++ | grep FAIL; done
$ 

and got 0 failures.

So, it seems to work.  I’d like a tsan person to review it and we can go from 
there.

The only thing I would add to it would be a huge comment that explains that the 
tsan run time isn’t thread safe and they should use a lock free update to the 
shadow bits, but, they don’t.  We introduce the step primitive to work around 
that bug.  Ideally, the the problem should be filed into a bug database for the 
tsan code gen and when closed as not to be fixed, we can then change the word 
bug to design, but leave the bug reference so that others that want to 
completely understand the issue can go read up on it.  If they actually fix the 
codegen to be thread safe, then we can simply remove all the step code.

To make this clang friendly, if one turns off inlining and obscures the 
semantics with weak from the optimizer and puts it into a header files and then 
#includes that header files, I think it would work.  I’ll leave this to someone 
that might want to do that.  If not, I’m fine with #ifdef clang/gcc and have 
the gcc test cases use step and the clang test cases, well, be unreliable.

$ svn diff
Index: g++.dg/tsan/aligned_vs_unaligned_race.C
===
--- g++.dg/tsan/aligned_vs_unaligned_race.C (revision 219198)
+++ g++.dg/tsan/aligned_vs_unaligned_race.C (working copy)
@@ -1,11 +1,17 @@
+/* { dg-additional-sources "lib.c" } */
 /* { dg-shouldfail "tsan" } */
+
 #include 
 #include 
 #include 
+#include 
+
+void step(int);
 
 uint64_t Global[2];
 
 void *Thread1(void *x) {
+  step (2);
   Global[1]++;
   return NULL;
 }
@@ -15,6 +21,7 @@ void *Thread2(void *x) {
   struct __attribute__((packed, aligned(1))) u_uint64_t { uint64_t val; };
   u_uint64_t *p4 = reinterpret_cast(p1 + 1);
   (*p4).val++;
+  step (1);
   return NULL;
 }
 
$ cat g++.dg/tsan/lib.c 
/* { dg-do compile } */
#include 

volatile int serial;

__attribute__((no_sanitize_address))
void step(int i) {
  while (serial != i-1) ;
  while (1) {
if (++serial == i)
  return;
--serial;
sleep (1);
  }
}

Re: [PATCH] -f{no-sanitize,{,no-}sanitize-recover}=all support

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 10:40:37PM +0100, Jakub Jelinek wrote:
> > Are there any doc updates that need to happen as a result of this patch?
> > Patch itself is fine for the trunk, just want to make sure the doc side is
> > good too.
> 
> You're right, I'll add documentation tomorrow and repost the patch.

Make that tonight ;), here it is.  I also found a bug in the
-fsanitize=float-cast-overflow documentation and -f{,no-}sanitize-recover
and fixed that too to much the implementation.

Ok?

2015-01-05  Jakub Jelinek  

* opts.c (common_handle_option): Add support for
-fno-sanitize=all and -f{,no-}sanitize-recover=all.
* doc/invoke.texi: Document -fno-sanitize=all,
-f{,no-}sanitize-recover=all.  Document that
-fsanitize=float-cast-overflow is not enabled
by -fsanitize=undefined.  Fix up documentation
of -f{,no-}sanitize-recover.

* c-c++-common/asan/sanitize-all-1.c: New test.
* c-c++-common/ubsan/sanitize-all-1.c: New test.
* c-c++-common/ubsan/sanitize-all-2.c: New test.
* c-c++-common/ubsan/sanitize-all-3.c: New test.
* c-c++-common/ubsan/sanitize-all-4.c: New test.

--- gcc/opts.c.jj   2015-01-05 19:52:17.151813267 +0100
+++ gcc/opts.c  2015-01-05 22:48:11.738814380 +0100
@@ -1588,6 +1588,7 @@ common_handle_option (struct gcc_options
sizeof "returns-nonnull-attribute" - 1 },
  { "object-size", SANITIZE_OBJECT_SIZE,
sizeof "object-size" - 1 },
+ { "all", ~0, sizeof "all" - 1 },
  { NULL, 0, 0 }
};
const char *comma;
@@ -1611,7 +1612,15 @@ common_handle_option (struct gcc_options
  && memcmp (p, spec[i].name, len) == 0)
{
  /* Handle both -fsanitize and -fno-sanitize cases.  */
- if (value)
+ if (value && spec[i].flag == ~0U)
+   {
+ if (code == OPT_fsanitize_)
+   error_at (loc, "-fsanitize=all option is not valid");
+ else
+   *flag |= ~(SANITIZE_USER_ADDRESS | SANITIZE_THREAD
+  | SANITIZE_LEAK);
+   }
+ else if (value)
*flag |= spec[i].flag;
  else
*flag &= ~spec[i].flag;
--- gcc/doc/invoke.texi.jj  2015-01-05 22:44:36.0 +0100
+++ gcc/doc/invoke.texi 2015-01-05 22:58:23.600292158 +0100
@@ -5683,6 +5683,8 @@ be a legitimate way of obtaining infinit
 @opindex fsanitize=float-cast-overflow
 This option enables floating-point type to integer conversion checking.
 We check that the result of the conversion does not overflow.
+Unlike other similar options, @option{-fsanitize=float-cast-overflow} is
+not enabled by @option{-fsanitize=undefined}.
 This option does not work well with @code{FE_INVALID} exceptions enabled.
 
 @item -fsanitize=nonnull-attribute
@@ -5718,6 +5720,13 @@ While @option{-ftrapv} causes traps for
 @option{-fsanitize=undefined} gives a diagnostic message.
 This currently works only for the C family of languages.
 
+@item -fno-sanitize=all
+@opindex fno-sanitize=all
+
+This option disables all previously enabled sanitizers.
+@option{-fsanitize=all} is not allowed, as some sanitizers cannot be used
+together.
+
 @item -fasan-shadow-offset=@var{number}
 @opindex fasan-shadow-offset
 This option forces GCC to use custom shadow offset in AddressSanitizer checks.
@@ -5741,11 +5750,14 @@ Currently this feature only works for @o
 except for @option{-fsanitize=unreachable} and @option{-fsanitize=return}),
 @option{-fsanitize=float-cast-overflow}, 
@option{-fsanitize=float-divide-by-zero} and
 @option{-fsanitize=kernel-address}.  For these sanitizers error recovery is 
turned on by default.
+@option{-fsanitize-recover=all} and @option{-fno-sanitize-recover=all} is also
+accepted, the former enables recovery for all sanitizers that support it,
+the latter disables recovery for all sanitizers that support it.
 
 Syntax without explicit @var{opts} parameter is deprecated.  It is equivalent 
to
-@option{-fsanitize-recover=undefined,float-cast-overflow,float-divide-by-zero,kernel-address}.
+@option{-fsanitize-recover=undefined,float-cast-overflow,float-divide-by-zero}.
 Similarly @option{-fno-sanitize-recover} is equivalent to
-@option{-fno-sanitize-recover=undefined,float-cast-overflow,float-divide-by-zero,kernel-address}.
+@option{-fno-sanitize-recover=undefined,float-cast-overflow,float-divide-by-zero}.
 
 @item -fsanitize-undefined-trap-on-error
 @opindex fsanitize-undefined-trap-on-error
--- gcc/testsuite/c-c++-common/asan/sanitize-all-1.c.jj 2015-01-05 
22:48:11.739814363 +0100
+++ gcc/testsuite/c-c++-common/asan/sanitize-all-1.c2015-01-05 
22:48:11.739814363 +0100
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-fno-sanitize=all" } */
+
+volatile int ten = 10;
+
+int main() {
+  volatile ch

Re: [PING] Add refers_to_regno_p overload to simplify callers

[Oleg Endo]

On Mon, 2015-01-05 at 12:48 -0700, Jeff Law wrote:
> On 01/03/15 05:18, Oleg Endo wrote:
> > https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01730.html
> >
> > On Sun, 2014-12-21 at 23:02 +0100, Oleg Endo wrote:
> >> Hi,
> >>
> >> It seems that quite some callers of refers_to_regno_p are interested in
> >> testing a single register number only.  The caller code can be
> >> simplified by adding an overload for refers_to_regno_p.  This is what
> >> the patch does.  No functional changes.  Tested with 'make all-gcc' on
> >> sh-elf cross config and bootstrapped on i686-pc-linux-gnu.
> >> OK for trunk?
> >>
> >> Cheers,
> >> Oleg
> >>
> >> gcc/ChangeLog:
> >>* rtlanal.c (refers_to_regno_p): Change return value from int to
> >>bool.
> >>* rtl.h (refers_to_regno_p): Add overload.
> >>* cse.c: Use it.
> >>* bt-load.c: Likewise.
> >>* combine.c: Likewise.
> >>* df-scan.c: Likewise.
> >>* sched-deps.c: Likewise.
> >>* config/s390/s390.c: Likewise.
> >>* config/m32r/m32r.c: Likewise.
> >>* config/rs6000/spe.md: Likewise.
> >>* config/rs6000/rs6000.c: Likewise.
> >>* config/pa/pa.c: Likewise.
> >>* config/stormy16/stormy16.c: Likewise.
> >>* config/cris/cris.c: Likewise.
> >>* config/arc/arc.md: Likewise.
> >>* config/arc/arc.c: Likewise.
> >>* config/sh/sh.md: Likewise.
> >>* config/sh/sh.c: Likewise.
> >>* config/frv/frv.c: Likewise.
> OK for the trunk.  

Thanks, committed as r219203.

> Though I think further patches of this nature should 
> probably wait until stage1 reopens.

Also for non-functional stuff like changing more return values / args
from int to bool where it's obvious?

Cheers,
Oleg

[doc, committed] invoke.texi markup fixes

[Sandra Loosemore]

This is another one of my boring tech-writer-ish patches to the GCC user 
documentation.


I noticed that there were numerous places in invoke.texi using @code 
markup instead of the more specific @option, @file, or @command markup, 
or in contexts where most other places in the manual use @samp.  I made 
a pass through the whole file to try to address these problems.  I know 
this isn't complete; I deliberately skipped over a few sections that 
need more substantial rewriting, and it needs another pass to correct 
places that currently use e.g. @samp where some other markup is 
preferred.  But, at least this is an incremental improvement.


The conventions I tried to apply are:

Option names get @option markup.

@file is used for file names.

@command is used for command names.

Option keywords get @samp markup -- e.g. the keywords for 
-fvect-cost-model= or -mcpu=.


@code is used for function names, macro names, instruction/register 
names, etc as well as random code fragments outside an example environment.


Most places in the manual already follow these conventions, so this 
really isn't anything new.


I've checked this in under the "obvious fix" rule.

-Sandra

2015-01-05  Sandra Loosemore  

gcc/
* doc/invoke.texi: Fix incorrect uses of @code, @option, @samp,
etc markup throughout the file.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 219176)
+++ gcc/doc/invoke.texi	(working copy)
@@ -2032,7 +2032,7 @@ basic integer types such as @code{int} a
 This section describes the command-line options that are only meaningful
 for C++ programs.  You can also use most of the GNU compiler options
 regardless of what language your program is in.  For example, you
-might compile a file @code{firstClass.C} like this:
+might compile a file @file{firstClass.C} like this:
 
 @smallexample
 g++ -g -frepo -O -c firstClass.C
@@ -2318,7 +2318,7 @@ void operator delete[] (void *, std::siz
 as introduced in C++14.  This is useful for user-defined replacement
 deallocation functions that, for example, use the size of the object
 to make deallocation faster.  Enabled by default under
-@samp{-std=c++14} and above.  The flag @option{-Wsized-deallocation}
+@option{-std=c++14} and above.  The flag @option{-Wsized-deallocation}
 warns about places that might want to add a definition.
 
 @item -fstats
@@ -2628,7 +2628,8 @@ by @option{-Wall}.
 Warn when a string or character literal is followed by a ud-suffix which does
 not begin with an underscore.  As a conforming extension, GCC treats such
 suffixes as separate preprocessing tokens in order to maintain backwards
-compatibility with code that uses formatting macros from @code{}.
+compatibility with code that uses formatting macros from
+the standard header file @file{inttypes.h}.
 For example:
 
 @smallexample
@@ -2847,7 +2848,7 @@ Supported by GCC}, for references.)
 This section describes the command-line options that are only meaningful
 for Objective-C and Objective-C++ programs.  You can also use most of
 the language-independent GNU compiler options.
-For example, you might compile a file @code{some_class.m} like this:
+For example, you might compile a file @file{some_class.m} like this:
 
 @smallexample
 gcc -g -fgnu-runtime -O -c some_class.m
@@ -4017,7 +4018,7 @@ either specify @option{-Wextra -Wunused}
 @opindex Wno-uninitialized
 Warn if an automatic variable is used without first being initialized
 or if a variable may be clobbered by a @code{setjmp} call. In C++,
-warn if a non-static reference or non-static @samp{const} member
+warn if a non-static reference or non-static @code{const} member
 appears in a class without constructors.
 
 If you want to warn about code that uses the uninitialized value of the
@@ -4416,7 +4417,8 @@ The unary plus operator.
 The @samp{U} integer constant suffix, or the @samp{F} or @samp{L} floating-point
 constant suffixes.  (Traditional C does support the @samp{L} suffix on integer
 constants.)  Note, these suffixes appear in macros defined in the system
-headers of most modern systems, e.g.@: the @samp{_MIN}/@samp{_MAX} macros in @code{}.
+headers of most modern systems, e.g.@: the @samp{_MIN}/@samp{_MAX} macros in 
+@file{limits.h}.
 Use of these macros in user code might normally lead to spurious
 warnings, however GCC's integrated preprocessor has enough context to
 avoid warning in these cases.
@@ -5506,8 +5508,8 @@ Allow using extensions of later DWARF st
 Produce compressed debug sections in DWARF format, if that is supported.
 If @var{type} is not given, the default type depends on the capabilities
 of the assembler and linker used.  @var{type} may be one of
-@option{none} (don't compress debug sections), @option{zlib} (use zlib
-compression in ELF gABI format), or @option{zlib-gnu} (use zlib
+@samp{none} (don't compress debug sections), @samp{zlib} (use zlib
+compression in ELF gABI format), or @samp{zlib-gnu} (use zli

Re: [PATCH] Fix loop optimization when ZOL is not available in xtensa configuration

[Max Filippov]

On Mon, Jan 5, 2015 at 7:21 PM, augustine.sterl...@gmail.com
 wrote:
> [Adding Felix]
>
> On Mon, Dec 29, 2014 at 3:12 PM, Max Filippov  wrote:
>>
>> Currently building gcc for xtensa configuration with XCHAL_HAVE_LOOPS
>> set to 0 fails with the following error:
>>
>>   xtensa.c:3952: undefined reference to `reorg_loops(bool,
>> hw_doloop_hooks*)'
>>
>> Only compile target-specific zero-overhead loop optimization code when
>> TARGET_LOOPS allows it.
>>
>> 2014-12-30  Max Filippov  
>>
>> * config/xtensa/xtensa.c (hwloop_optimize, hwloop_fail,
>> hwloop_pattern_reg, xtensa_doloop_hooks, xtensa_reorg_loops):
>> put under #if TARGET_LOOPS guard.
>
>
> This is OK. Thanks.

Applied to trunk. Thanks!

-- Max

Re: [hsa] HSA: support for direct function call is introduced.

[Eric Botcazou]

> Thank you for your notes, I'm just going to apply following patch
> with changed ChangeLog entries.

Thanks!

-- 
Eric Botcazou

Re: [doc, committed] invoke.texi markup fixes

[Joseph Myers]

On Mon, 5 Jan 2015, Sandra Loosemore wrote:

> @file is used for file names.

For standard headers, the use of @code{} (inttypes.h and 
limits.h, in this patch) is deliberate, reflecting that the C standard 
does not require headers to correspond to files and that the use of files 
to implement those headers is an implementation detail.

(Thus, for example, GCC provides @file{stdint-gcc.h} and 
@file{stdint-wrap.h}, which may be used as part of the implementation of 
the standard header @code{}; GCC installs a file @file{limits.h} 
which implements the standard @code{} in a complicated 
interaction with any @file{limits.h} installed by the system C library.)

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

[MIPS] Re-enable ABI->ISA inference

[Matthew Fortune]

The R6 patch introduced MIPS_ISA_LEVEL_SPEC into DRIVER_SELF_SPECS
for all configurations. One part of MIPS_ISA_LEVEL_SPEC is however
incompatible with those configurations which infer an ISA from an
ABI without specifically setting the default ISAs using
--with-arch-[32|64].

I.e. a generic mips-linux (--enable-targets=all) and
mips64-linux would fail to build the n32/n64 multilibs as -mips1
would be introduced by DRIVER_SELF_SPECS.

I have therefore split MIPS_ISA_LEVEL_SPEC into two. One part is
suitable for all confgurations and one part is only suitable for
configurations that infer an ABI from an ISA (these tend to be
cross-compiler vendor configurations)

I have built and checked the driver generated options for all
relevant configurations and everything appears to work.

Let me know if you can see any problems with this?

Thanks,
Matthew

gcc/

 * config/mips/mips.h (MIPS_ISA_LEVEL_SPEC): Only infer an ISA
 level from an ARCH; do not inject the default.
 (MIPS_DEFAULT_ISA_LEVEL_SPEC): New macro split out from
 MIPS_ISA_LEVEL_SPEC.
 (MIPS_ISA_NAN2008_SPEC): Update comment.
 (BASE_DRIVER_SELF_SPECS): Likewise.
 * config/mips/elfoabi.h (DRIVER_SELF_SPECS): Add
 MIPS_DEFAULT_ISA_LEVEL_SPEC.
 * config/mips/mti-elf.h (DRIVER_SELF_SPECS): Likewise.
 * config/mips/mti-linux.h (DRIVER_SELF_SPECS): Likewise.
 * config/mips/sde.h (DRIVER_SELF_SPECS): Likewise.
---
gcc/config/mips/elfoabi.h   |  3 +++
gcc/config/mips/mips.h  | 16 
gcc/config/mips/mti-elf.h   |  3 +++
gcc/config/mips/mti-linux.h |  3 +++
gcc/config/mips/sde.h   |  3 +++
5 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/gcc/config/mips/elfoabi.h b/gcc/config/mips/elfoabi.h
index d88a79c..1e775c0 100644
--- a/gcc/config/mips/elfoabi.h
+++ b/gcc/config/mips/elfoabi.h
@@ -20,6 +20,9 @@ along with GCC; see the file COPYING3.  If not see

 #undef DRIVER_SELF_SPECS
#define DRIVER_SELF_SPECS   \
+  /* Set the ISA for the default multilib.  */ \
+  MIPS_DEFAULT_ISA_LEVEL_SPEC,    \
+   \
   /* Make sure a -mips option is present.  This helps us to pick    \
  the right multilib, and also makes the later specs easier  \
  to write.  */  \
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 4da256d..9dad480 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -704,8 +704,7 @@ struct mips_cpu_info {
#define MIPS_ARCH_OPTION_SPEC \
   MIPS_ISA_LEVEL_OPTION_SPEC "|march=*"

-/* A spec that infers a -mips argument from an -march argument,
-   or injects the default if no architecture is specified.  */
+/* A spec that infers a -mips argument from an -march argument.  */

 #define MIPS_ISA_LEVEL_SPEC \
   "%{" MIPS_ISA_LEVEL_OPTION_SPEC ":;: \
@@ -725,7 +724,13 @@ struct mips_cpu_info {
      %{march=mips64r2|march=loongson3a|march=octeon|march=xlp: -mips64r2} \
  %{march=mips64r3: -mips64r3} \
  %{march=mips64r5: -mips64r5} \
- %{march=mips64r6: -mips64r6} \
+ %{march=mips64r6: -mips64r6}}"
+
+/* A spec that injects the default multilib ISA if no architecture is
+   specified.  */
+
+#define MIPS_DEFAULT_ISA_LEVEL_SPEC \
+  "%{" MIPS_ISA_LEVEL_OPTION_SPEC ":;: \
  %{!march=*: -" MULTILIB_ISA_DEFAULT "}}"

 /* A spec that infers a -mhard-float or -msoft-float setting from an
@@ -757,6 +762,7 @@ struct mips_cpu_info {
   "%{msynci|mno-synci:;:%{mips32r2|mips32r3|mips32r5|mips32r6|mips64r2 \
     |mips64r3|mips64r5|mips64r6:-msynci;:-mno-synci}}"

+/* Infer a -mnan=2008 setting from a -mips argument.  */
#define MIPS_ISA_NAN2008_SPEC \
   "%{mnan*:;mips32r6|mips64r6:-mnan=2008}"

@@ -806,7 +812,9 @@ struct mips_cpu_info {
   {"mips-plt", "%{!mplt:%{!mno-plt:-m%(VALUE)}}" }, \
   {"synci", "%{!msynci:%{!mno-synci:-m%(VALUE)}}" }

-/* A spec that infers the -mdsp setting from an -march argument.  */
+/* A spec that infers the:
+   -mnan=2008 setting from a -mips argument,
+   -mdsp setting from a -march argument.  */
#define BASE_DRIVER_SELF_SPECS \
   MIPS_ISA_NAN2008_SPEC,   \
   "%{!mno-dsp: \
diff --git a/gcc/config/mips/mti-elf.h b/gcc/config/mips/mti-elf.h
index d6dc1bb..45cffd5 100644
--- a/gcc/config/mips/mti-elf.h
+++ b/gcc/config/mips/mti-elf.h
@@ -19,6 +19,9 @@ along with GCC; see the file COPYING3.  If not see

 #undef DRIVER_SELF_SPECS
#define DRIVER_SELF_SPECS   \
+  /* Set the ISA for the default multilib.  */ \
+  MIPS_DEFAULT_ISA_LEVEL_SPEC,    \
+   \
   /* Make sure a -mips option is present.  This helps us to pick    \
  the right multilib, and also makes the later specs easier  \
  to write.  */  \
diff --git a/gcc/config/mips/mti-linux.h b/gcc/config/mips/mti-linux.h
index 5761ab7..9ea9ce5 100644
---

Housekeeping work in backends.html

[Eric Botcazou]

Hi,

the attached patch removes obsolete ports (c4x, m68hc11 and ms1), toggles the 
'p' letter and adjust accordingly (only avr, fr30, m68k, mcore, rs6000 and sh 
still use define_peephole) and removes trailing spaces.

OK to commit?

Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant 
maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).

-- 
Eric BotcazouIndex: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.51
diff -u -r1.51 backends.html
--- backends.html	22 Sep 2014 13:46:25 -	1.51
+++ backends.html	5 Jan 2015 23:07:09 -
@@ -47,7 +47,7 @@
 r   Port can switch between ILP32 and LP64 at runtime.
 (Not necessarily supported by all subtargets.)
 c   Port uses cc0.
-p   Port does not use define_peephole.
+p   Port uses define_peephole (as opposed to define_peephole2).
 f   Port does not define prologue and/or epilogue RTL expanders.
 g   Port does not define TARGET_ASM_FUNCTION_(PRO|EPI)LOGUE.
 m   Port does not use define_constants.
@@ -66,49 +66,46 @@
  | Characteristics
 Target   | HMSLQNFICBD lqrcpfgmbdates
 -+---
-aarch64  | Qq  p g  da  s
-alpha|  ?? Q   Cq  p g bda e 
-arc  |  B  p g  da
+aarch64  | Qqg  da  s
+alpha|  ?? Q   Cqg bda e
+arc  |  Bg  da
 arm  |  da  s
-avr  |L  FIl  c  g b
-bfin |   F p g  da
-c4x  |  ??  N I BD   g  d  e 
-c6x  |   S CB  p g bda 
+avr  |L  FIl  cp g b
+bfin |   F   g  da
+c6x  |   S CBg bda
 cr16 |L  F C g  s
-cris |   F  B cp g b a  s
-epiphany | C   p g bda  s
-fr30 | ??FI Bgm s
-frv  | ??   B  pda  s
-h8300|   FI   cp g  s
-i386 |   ? Qq  pda   
-ia64 |   ? Q   Cqr pda   
-iq2000   | ???   FICB  p g  d t  
-m32c |L  FIl   p g  s
+cris |   F  B c  g b a  s
+epiphany | C g bda  s
+fr30 | ??FI B  p gm s
+frv  | ??   B   da  s
+h8300|   FI   c  g  s
+i386 |   ? Qq   da
+ia64 |   ? Q   Cqr  da
+iq2000   | ???   FICBg  d t
+m32c |L  FIl g  s
 m32r |   FI d   s
-m68hc11  |L  FIl  c s
-m68k |   ?c  a   
-mcore|  ?FI  gm d   s
-mep  |   F C   p g  d t s
+m68k |   ?cp a
+mcore|  ?FIp gm d   s
+mep  |   F C g  d t s
 microblaze CB  bd   s
-mips | Q   CB   qr p   bda  s
-mmix | HM  Q   Cq  p   b a e 
+mips | Q   CB   qr bda  s
+mmix | HM  Q   Cq  b a e
 mn10300  | ?? c  g  s
-ms1  |   S   F  B  p g bd
-msp430   |L  FIl   p g  s
-nds32|   F C   pda  s
-pa   |   ? Q   CBD  qrm da e 
-pdp11|L   ICqrcp   e 
-rs6000   | Q   Cqr  da   
-s390 |   ? Qqr p g bda e 
-sh   | Q   CB   qr bda   
-sparc| Q   CB   qr pda   
-spu  |   ? Q  *C   p g bd
-stormy16 | ???L  FIC D l   p  m  a
-tilegx   |   S Q   Cq  p g bda e
-tilepro  |   S   F C   p g bda e
-v850 | ??FI   cp gm d   s
-vax  |  M?I   cp a e 
-xtensa   |   ? C   p   bd
+msp430   |L  FIl g  s
+nds32|   F Cda  s
+pa   |   ? Q   CBD  qrm da e
+pdp11|L   ICqrce
+rs6000   | Q   Cqr pda
+s390 |   ? Qqr   g bda e
+sh   | Q   CB   qr p   bda
+sparc| Q   CB   qr  da
+spu  |   ? Q  *C g bd
+stormy16 | ???L  FIC D l  m  a
+tilegx   |   S Q   Cqg bda e
+tilepro  |   S   F C g bda e
+v850 | ??FI   c  gm d   s
+vax  |  M?I   c  a e
+xtensa   |   ? C   bd
 
 
 For AVR simulator, see 

Minor comment tweak in config/nds32/nds32-peephole2.md

[Eric Botcazou]

I think that we don't want new define_peephole's at this point.

Applied on the mainline as obvious.


2015-01-05  Eric Botcazou  

* config/nds32/nds32-peephole2.md: Do not mention define_peephole.


-- 
Eric BotcazouIndex: config/nds32/nds32-peephole2.md
===
--- config/nds32/nds32-peephole2.md	(revision 219206)
+++ config/nds32/nds32-peephole2.md	(working copy)
@@ -19,7 +19,6 @@
 ;; .
 
 
-;; Use define_peephole and define_peephole2 to handle possible
-;; target-specific optimization in this file.
+;; Use define_peephole2 to handle possible target-specific optimization.
 
 ;; 

Re: [PATCH] LRA: Fix caller-save store/restore instruction for large mode

[Vladimir Makarov]

On 2015-01-05 12:31 PM, Jeff Law wrote:

On 01/05/15 00:44, Kito Cheng wrote:

Hi Vladimir:
   This patch has a discusses with you in May 2014, this patch is about
the caller-save register store and restore instruction generation, the
current LRA implementation will miss caller-save store/restore
instruction if need one more instruction.

You said you will investigate for this on IRC, so I don't send the
patch last year, however ARM guys seem got this problem too, so I
think it's time to send this patch :)

ChangeLog

2015-01-05  Kito Cheng  

 * lra-constraints.c (split_reg): Fix caller-save store/restore
instruction generation.

Please reference PR64348 in the ChangeLog entry.

Please include a testcase if there isn't one in the regression suite 
already.


Please indicate what platform this patch was bootstrapped and 
regression tested on.


The dumping code immediately after the assert you removed has code 
like this in both cases:




 fprintf (lra_dump_file,
   "Rejecting split %d->%d "
   "resulting in > 2 %s restore insns:\n",
   original_regno, REGNO (new_reg), call_save_p ? 
"call" : "");


Testing call_save_p here won't make any sense after your patch.

I'll let Vlad chime in on the correctness of allowing multi register 
saves/restores in this code.


The solution itself is ok.  Prohibiting generation of more one insn was 
intended for inheritance only as inheritance transformation can be 
undone when the inheritance pseudo does not get a hard register. Undoing 
multi-register splitting is difficult and also such splitting is 
doubtedly profitable.


Splitting for save/restore is never undone.  So it is ok for this case 
to generate multi-register saves/restores.


Kito, Jeff wrote reasonable changes for the patch.  Please, do them and 
you can commit the patch.


Thanks.

RE: [PATCH] Disable -fuse-caller-save when -pg is active

[Moore, Catherine]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Monday, January 05, 2015 12:07 PM
> To: Moore, Catherine; Radovan Obradovic; gcc-patches@gcc.gnu.org
> Cc: Petar Jovanovic
> Subject: Re: [PATCH] Disable -fuse-caller-save when -pg is active
> 
> On 01/05/15 07:48, Moore, Catherine wrote:
> >
> >
> >> -Original Message-
> >> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> >> ow...@gcc.gnu.org] On Behalf Of Radovan Obradovic
> >> Sent: Thursday, December 18, 2014 11:01 AM
> >> To: Jeff Law; gcc-patches@gcc.gnu.org
> >> Cc: Petar Jovanovic
> >> Subject: RE: [PATCH] Disable -fuse-caller-save when -pg is active
> >>
> >>
> >> Patch has been tested with DejaGnu gcc test suite on mips32r2 cross
> >> compiler and bootstrapped and tested on
> >> x86_64 native compiler.
> >>
> > Thanks for finishing up the testing.  Would you like me to check this in for
> you?
> Please do.  My recollection was that the patch itself looked fine, but that it
> needed to go through the usual testing cycle.
> 

This patch had bit-rotted slightl since the original posting.  The 
-fuse-caller-save option has been changed to  -fipa-ra.
I committed this updated version of the patch.
Catherine


Index: toplev.c
===
--- toplev.c(revision 219188)
+++ toplev.c(revision 219208)
@@ -113,6 +113,13 @@
   declarations for e.g. AIX 4.x.  */
 #endif

+#ifndef HAVE_epilogue
+#define HAVE_epilogue 0
+#endif
+#ifndef HAVE_prologue
+#define HAVE_prologue 0
+#endif
+
 #include 

 static void general_init (const char *);
@@ -1634,6 +1641,11 @@
   /* Save the current optimization options.  */
   optimization_default_node = build_optimization_node (&global_options);
   optimization_current_node = optimization_default_node;
+
+ /* Disable use caller save optimization if profiler is active or port
+does not emit prologue and epilogue as RTL.  */
+  if (profile_flag || !HAVE_prologue || !HAVE_epilogue)
+flag_ipa_ra = 0;
 }

Patch ping and question about copyright assignment

[Mikhail Maltsev]

Hi, all!
I'm pinging about this patch:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html (PR c/48956)
I know that maybe it's too early for sending a ping (less than 2
weeks), but I also have a question regarding my patch:
Is this patch considered small enough to be accepted without copyright
assignment? If it is not, I need some instructions about signing such
an assignment.
Anyway, I hope, I will be able to contribute more to the GCC project, so
I'm sending this message to ass...@gnu.org also.

-- 
Regards,
Mikhail Maltsev

[PATCH], rs6000, PR 64505 -- Fix issue with -m32 -mpowerpc64

[Michael Meissner]

This patch fixes PR 64505, which is an issue that one of the users of the
Advance Toolchain found where -m32 -mpowerpc64 generated an insn not found
message in some cases.  I traced this down to rs6000_secondary_reload
generating a reload helper that uses a DImode scratch register, when in this
case, it should use a SImode scratch register.

The attached patch fixes the problem, and causes no regressions under a PowerPC
64-bit big endian Linux system (which also tests the 32-bit code).  Is it ok
to install in the trunk?  Since the change occurs within code that I recently
modified for the upper register support, a companion patch will need to be
developed for the 4.8/4.9 branches.

I think the patch is safe, but -m32 -mpowerpc64 is not legitimate for the Linux
environment.  As I recall, Darwin running on PowerPC's is the only system that
allowed that combination.  I have added several people to the To: list of this
mail whom David says may have done something with Darwin and PowerPC.  If so,
and if you still have a system, it would be appreciated to see if these patches
are ok.

[gcc]
2015-01-05  Michael Meissner  

PR target/64505
* config/rs6000/rs6000.c (rs6000_secondary_reload): Return the
correct reload handler if -m32 -mpowerpc64 is used.

[gcc/testsuite]
2015-01-05  Michael Meissner  

PR target/64505
* gcc.target/powerpc/pr64505.c: New file to test -m32 -mpowerpc64
fix is correct.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 219195)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -17081,10 +17081,13 @@ rs6000_secondary_reload (bool in_p,
  : (offset + 0x8000 < 0x1 - extra /* legitimate_address_p */
 && (offset & 3) != 0))
{
+ /* -m32 -mpowerpc64 needs to use a 32-bit scratch register.  */
  if (in_p)
-   sri->icode = CODE_FOR_reload_di_load;
+   sri->icode = ((TARGET_32BIT) ? CODE_FOR_reload_si_load
+ : CODE_FOR_reload_di_load);
  else
-   sri->icode = CODE_FOR_reload_di_store;
+   sri->icode = ((TARGET_32BIT) ? CODE_FOR_reload_si_store
+ : CODE_FOR_reload_di_store);
  sri->extra_cost = 2;
  ret = NO_REGS;
  done_p = true;
Index: gcc/testsuite/gcc.target/powerpc/pr64505.c
===
--- gcc/testsuite/gcc.target/powerpc/pr64505.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr64505.c  (revision 0)
@@ -0,0 +1,230 @@
+/* { dg-do compile { target { powerpc*-*-* && ilp32 } } } */
+/* { dg-options "-O2 -mpowerpc64" } */
+
+/*
+ * (below is inlined and simplified from previously included headers)
+ */
+
+struct fltcom_st {
+short fltbuf[950];
+} fltcom_  __attribute__((common))  ;
+#define CM_PLIBOR (*(((double *)&fltcom_ + 1)))
+#define CM_QMRG (*(((double *)&fltcom_ + 2)))
+
+struct fltcom2_st {
+short fltbuf2[56];
+} fltcom2_  __attribute__((common))  ;
+#define CM_FLPRV ((short *)&fltcom2_ + 17)
+#define CM_FLNXT ((short *)&fltcom2_ + 20)
+#define CM_FLCPN (*(((double *)&fltcom2_)))
+#define CM_FLCNT (*(((short *)&fltcom2_ + 12)))
+
+struct aidatcm_st {
+double cm_aid, cm_ext, cm_basis;
+short cm_aiday, cm_exday, cm_dperd, cm_aiexf, cm_aidex, cm_aiok,
+cm_aigdo, cm_aildo, cm_prev[3], cm_next[3], cm_aid_pad[2];
+double cm_rvgfact, cm_ai1st, cm_ai2nd;
+int cm_aieurok;
+} aidatcm_  __attribute__((common))  ;
+#define CM_EXDAY aidatcm_.cm_exday
+#define CM_BASIS aidatcm_.cm_basis
+#define CM_PREV aidatcm_.cm_prev
+
+struct cshfcm_st {
+short bufff[10862];
+} cshfcm_  __attribute__((common))  ;
+#define CM_FNUM (*(((short *)&cshfcm_ + 9038)))
+#define CM_FIFLX ((double *)&cshfcm_ + 1)
+#define CM_FEXTX ((double *)&cshfcm_ + 1201)
+#define CM_FSHDT ((short *)&cshfcm_ + 7230)
+
+struct calctsdb_st {
+short calctsdbbuff[115];
+} calctsdb_  __attribute__((common))  ;
+#define CM_CTUP_GOOD_TO_GO (*(((short *)&calctsdb_ + 16)))
+#define CM_PAYMENT_FREQUENCY (*(((short *)&calctsdb_ + 61)))
+#define CM_DISCOUNTING_DAYTYP (*(((short *)&calctsdb_ + 59)))
+
+struct cf600cm_st {
+short bufcf[14404];
+} cf600cm_  __attribute__((common)) ;
+#define CM_FLT_RFIXRATES ((double *)&cf600cm_ + 600)
+
+typedef struct { int id; int type; const char *name; } bregdb_bitinfo_t;
+
+int
+bregdb_eval_bbitcxt_bool_rv(const bregdb_bitinfo_t * const bbit,
+const int bbit_default,
+const void * const bregucxt);
+
+static const bregdb_bitinfo_t bbit_calc_dr_d33 =
+  { 160667, 5, "bbit_calc_dr_d33" };
+#define bbit_calc_dr_d33__value() \
+  bregdb_eval_bbitcxt_bool

RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Bernd Edlinger]

Hi Mike,


On Mon, 5 Jan 2015 14:01:42, Mike Stump wrote:
>
> On Jan 5, 2015, at 12:58 PM, Mike Stump  wrote:
>> So, to help you out, I tried my hand at wiring up the extra library code:
>
> So, my tsan build finally finished, and I could try this with a real test 
> case. I ran it 20 times, and got 11 fails with:
>
> $ i=20; while let i--; do make 
> RUNTESTFLAGS=tsan.exp=aligned_vs_unaligned_race.C check-g++ | grep FAIL; done
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O0 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O0 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O0 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O0 execution test
> $
>
> When I fixed the problem, I ran it 20 times:
>
> $ i=20; while let i--; do make 
> RUNTESTFLAGS=tsan.exp=aligned_vs_unaligned_race.C check-g++ | grep FAIL; done
> $
>
> and got 0 failures.
>
> So, it seems to work. I’d like a tsan person to review it and we can go from 
> there.
>
> The only thing I would add to it would be a huge comment that explains that 
> the tsan run time isn’t thread safe and they should use a lock free update to 
> the shadow bits, but, they don’t. We introduce the step primitive to work 
> around that bug. Ideally, the the problem should be filed into a bug database 
> for the tsan code gen and when closed as not to be fixed, we can then change 
> the word bug to design, but leave the bug reference so that others that want 
> to completely understand the issue can go read up on it. If they actually fix 
> the codegen to be thread safe, then we can simply remove all the step code.
>
> To make this clang friendly, if one turns off inlining and obscures the 
> semantics with weak from the optimizer and puts it into a header files and 
> then #includes that header files, I think it would work. I’ll leave this to 
> someone that might want to do that. If not, I’m fine with #ifdef clang/gcc 
> and have the gcc test cases use step and the clang test cases, well, be 
> unreliable.
>
> $ svn diff
> Index: g++.dg/tsan/aligned_vs_unaligned_race.C
> ===
> --- g++.dg/tsan/aligned_vs_unaligned_race.C (revision 219198)
> +++ g++.dg/tsan/aligned_vs_unaligned_race.C (working copy)
> @@ -1,11 +1,17 @@
> +/* { dg-additional-sources "lib.c" } */
> /* { dg-shouldfail "tsan" } */
> +
> #include 
> #include 
> #include 
> +#include 
> +
> +void step(int);
>
> uint64_t Global[2];
>
> void *Thread1(void *x) {
> + step (2);
> Global[1]++;
> return NULL;
> }
> @@ -15,6 +21,7 @@ void *Thread2(void *x) {
> struct __attribute__((packed, aligned(1))) u_uint64_t { uint64_t val; };
> u_uint64_t *p4 = reinterpret_cast(p1 + 1);
> (*p4).val++;
> + step (1);
> return NULL;
> }
>
> $ cat g++.dg/tsan/lib.c
> /* { dg-do compile } */
> #include 
>
> volatile int serial;
>
> __attribute__((no_sanitize_address))
> void step(int i) {
> while (serial != i-1) ;
> while (1) {
> if (++serial == i)
> return;
> --serial;
> sleep (1);
> }
> }


I tried to elaborate your idea a bit, and used proper atomics.
It is necessary that the logic of the step function is completely invisible to 
tsan.
Therefore it should not call sleep, because that can be intercepted, even
if the code is not instrumented.  And if this is the right solution for 
aligned_vs_unaligned.C it should be the used in all other tests as well.

Unfortunately there is no __attribute__((no_sanitize_thread)) just
no_sanitize_address, and no_sanitize_undefined.  So I need to call
the gcc compiler driver a second time with different options to compile
lib.c and link that together with the test case.  If done by hand, the tests
work very reliable, even without any sleep.

I did not know about the dg-additional-sources, that was new to me.
But it does not quite do what I need.  Unfortunately it just adds lib.c
to the gcc command line, and both sources use the same options.
But that instruments the atomics in lib.c and thus tsan figures out,
that there is really no race condition at all.
So some tests start to fail.


make check-gcc-c++ RUNTESTFLAGS="tsan.exp=*"
...
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O0  execution test
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O2  execution test
FAIL: g++.dg/tsan/atomic_free.C   -O0  execution test
FAIL: g++.dg/tsan/atomic_free.C   -O2  execution test


That is of course only a technical problem, but one that is beyond my scope.
And OTOH I doubt that these race-free tests look very realistic.


Bernd.
   

Re: [PATCH] Cleaning up incomplete type warning.

[Manuel López-Ibáñez]

On 5 January 2015 at 21:14, Jeff Law  wrote:
>
> ps.  I'm sure someone will complain that we've changed this warning message
> ever-so-slightly mucking up whatever code out there that parses
> warning/error messages.

I honestly wonder what could be the purpose of parsing specific
warning/error messages outside of GCC's own testsuite.

Cheers,

Manuel.

Re: [PATCH] LRA: Fix caller-save store/restore instruction for large mode

[Bin.Cheng]

On Tue, Jan 6, 2015 at 7:36 AM, Vladimir Makarov  wrote:
>
> On 2015-01-05 12:31 PM, Jeff Law wrote:
>>
>> On 01/05/15 00:44, Kito Cheng wrote:
>>>
>>> Hi Vladimir:
>>>This patch has a discusses with you in May 2014, this patch is about
>>> the caller-save register store and restore instruction generation, the
>>> current LRA implementation will miss caller-save store/restore
>>> instruction if need one more instruction.
>>>
>>> You said you will investigate for this on IRC, so I don't send the
>>> patch last year, however ARM guys seem got this problem too, so I
>>> think it's time to send this patch :)
>>>
>>> ChangeLog
>>>
>>> 2015-01-05  Kito Cheng  
>>>
>>>  * lra-constraints.c (split_reg): Fix caller-save store/restore
>>> instruction generation.
>>
>> Please reference PR64348 in the ChangeLog entry.
>>
>> Please include a testcase if there isn't one in the regression suite
>> already.
>>
>> Please indicate what platform this patch was bootstrapped and regression
>> tested on.
>>
>> The dumping code immediately after the assert you removed has code like
>> this in both cases:
>>
>>
>>
>>  fprintf (lra_dump_file,
>>"Rejecting split %d->%d "
>>"resulting in > 2 %s restore insns:\n",
>>original_regno, REGNO (new_reg), call_save_p ? "call" :
>> "");
>>
>> Testing call_save_p here won't make any sense after your patch.
>>
>> I'll let Vlad chime in on the correctness of allowing multi register
>> saves/restores in this code.
>>
> The solution itself is ok.  Prohibiting generation of more one insn was
> intended for inheritance only as inheritance transformation can be undone
> when the inheritance pseudo does not get a hard register. Undoing
> multi-register splitting is difficult and also such splitting is doubtedly
> profitable.
>
> Splitting for save/restore is never undone.  So it is ok for this case to
> generate multi-register saves/restores.
>
> Kito, Jeff wrote reasonable changes for the patch.  Please, do them and you
> can commit the patch.

Hi Vlad,
As for this specific case in PR64348, dump IR crossing function call
is as below:

  430: [sfp:SI-0x30]=r989:TI#0
  432: [r1706:SI+0x4]=r989:TI#4
  434: [r1706:SI+0x8]=r989:TI#8
  436: [r1706:SI+0xc]=r989:TI#12
  441: r0:DI=call [`__aeabi_idivmod'] argc:0
  REG_UNUSED r0:SI
  REG_CALL_DECL `__aeabi_idivmod'
  REG_EH_REGION 0x8000
  437: r1007:SI=sign_extend(r989:TI#0)
  REG_DEAD r989:TI

Save/restore are introduced because of use of r989:#0 in insn 437.
Register r989 is TImode register and assigned to r2/r3/r4/r5.  I can
think about two possible improvements to LRA splitter.  1) According
to ARM EABI, only r2/r3 need to be saved/restored; 2) In this case, we
only need to save/restore r989:TI#0, which is r2.  In fact, it has
already been saved to stack in insn 430, what we need is to restore
r989:TI#0 after function call.

What do you think about these?

Thanks,
bin

>
> Thanks.
>

Re: [PATCH] toplev.c: Process the failure when read fails for random_seed

[Chen Gang S]

On 1/6/15 04:07, Jeff Law wrote:
> On 12/28/14 21:04, Chen Gang S wrote:
>> When failure occurs, random_seed may not be 0, so need reset it to 0
>> manually, or will let the next call init_random_seed() incorrect.  The
>> related warning:
>>
>>g++ -c  -DTARGET_NAME=\"parisc-gchen-linux\" -g -O2 -DIN_GCC  
>> -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti 
>> -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual 
>> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
>> -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H 
>> -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include 
>> -I../../gcc/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber 
>> -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
>> -I../../gcc/gcc/../libbacktrace   -o toplev.o -MT toplev.o -MMD -MP -MF 
>> ./.deps/toplev.TPo ../../gcc/gcc/toplev.c
>>../../gcc/gcc/toplev.c: In function 'void init_local_tick()':
>>../../gcc/gcc/toplev.c:276:56: warning: ignoring return value of 'ssize_t 
>> read(int, void*, size_t)', declared with attribute warn_unused_result 
>> [-Wunused-result]
>>
>> It passes testsuite under x86_64-apple-darwin14.0.0
>>
>> /gcc
>> 2014-12-27  Chen Gang  
>>
>> * toplev.c (init_local_tick): Process the failure when read
>> fails for random_seed.
> This is fine for the trunk.  Please install.
> 

Thank you for your work.

This year, I shall try the Bugzilla for the existing issues, firstly, I
should try to continue to analyze the old issues for h8300 which I
reported in 2013 (1.5 years ago).

Thanks.
-- 
Chen Gang

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

Go patch committed: Use receiver type name in type descriptor name

[Ian Lance Taylor]

If different named types have methods with the same name, and the
methods with the same name define nested types with the same name, the
type descriptors for those nested types could collide at link time.
This patch by Chris Manghane fixes the problem.  This is issue 33 in
the gofrontend issue tracker.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian
diff -r 3196a4d08deb go/types.cc
--- a/go/types.cc   Mon Jan 05 08:12:31 2015 -0800
+++ b/go/types.cc   Mon Jan 05 18:23:58 2015 -0800
@@ -1296,6 +1296,14 @@
   ret.append(1, '.');
   if (in_function != NULL)
{
+ const Typed_identifier* rcvr =
+   in_function->func_value()->type()->receiver();
+ if (rcvr != NULL)
+   {
+ Named_type* rcvr_type = rcvr->type()->deref()->named_type();
+ ret.append(Gogo::unpack_hidden_name(rcvr_type->name()));
+ ret.append(1, '.');
+   }
  ret.append(Gogo::unpack_hidden_name(in_function->name()));
  ret.append(1, '.');
  if (index > 0)
@@ -9170,6 +9178,14 @@
   name.append(1, '.');
   if (this->in_function_ != NULL)
{
+ const Typed_identifier* rcvr =
+   this->in_function_->func_value()->type()->receiver();
+ if (rcvr != NULL)
+   {
+ Named_type* rcvr_type = rcvr->type()->deref()->named_type();
+ name.append(Gogo::unpack_hidden_name(rcvr_type->name()));
+ name.append(1, '.');
+   }
  name.append(Gogo::unpack_hidden_name(this->in_function_->name()));
  name.append(1, '$');
  if (this->in_function_index_ > 0)

Re: [doc, committed] invoke.texi markup fixes

[Sandra Loosemore]

On 01/05/2015 03:57 PM, Joseph Myers wrote:

On Mon, 5 Jan 2015, Sandra Loosemore wrote:


@file is used for file names.


For standard headers, the use of @code{} (inttypes.h and
limits.h, in this patch) is deliberate, reflecting that the C standard
does not require headers to correspond to files and that the use of files
to implement those headers is an implementation detail.


Oh, thanks!  I didn't realize that was a deliberate convention.  I've 
reverted the two offending patch hunks.


(I'm actually surprised that anybody even bothered to look at the 
patch  If the doc maintainers would prefer me to post these kinds of 
copy-editing changes for review rather than just commit them, please let 
me know.)


-Sandra

2015-01-05  Sandra Loosemore  

Revert parts of r219199.

gcc/
* doc/invoke.texi ([-Wliteral-suffix]): Restore markup on
.
([-Wtraditional]): Restore markup on .


Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 219199)
+++ gcc/doc/invoke.texi	(working copy)
@@ -2628,8 +2628,7 @@ by @option{-Wall}.
 Warn when a string or character literal is followed by a ud-suffix which does
 not begin with an underscore.  As a conforming extension, GCC treats such
 suffixes as separate preprocessing tokens in order to maintain backwards
-compatibility with code that uses formatting macros from
-the standard header file @file{inttypes.h}.
+compatibility with code that uses formatting macros from @code{}.
 For example:
 
 @smallexample
@@ -4417,8 +4416,7 @@ The unary plus operator.
 The @samp{U} integer constant suffix, or the @samp{F} or @samp{L} floating-point
 constant suffixes.  (Traditional C does support the @samp{L} suffix on integer
 constants.)  Note, these suffixes appear in macros defined in the system
-headers of most modern systems, e.g.@: the @samp{_MIN}/@samp{_MAX} macros in 
-@file{limits.h}.
+headers of most modern systems, e.g.@: the @samp{_MIN}/@samp{_MAX} macros in @code{}.
 Use of these macros in user code might normally lead to spurious
 warnings, however GCC's integrated preprocessor has enough context to
 avoid warning in these cases.

Re: [PATCH], rs6000, PR 64505 -- Fix issue with -m32 -mpowerpc64

[Segher Boessenkool]

On Mon, Jan 05, 2015 at 07:50:33PM -0500, Michael Meissner wrote:
> This patch fixes PR 64505, which is an issue that one of the users of the
> Advance Toolchain found where -m32 -mpowerpc64 generated an insn not found
> message in some cases.  I traced this down to rs6000_secondary_reload
> generating a reload helper that uses a DImode scratch register, when in this
> case, it should use a SImode scratch register.

That looks correct.

> I think the patch is safe, but -m32 -mpowerpc64 is not legitimate for the 
> Linux
> environment.

The high halves of the registers are clobbered by some signal things.
It works without problems otherwise; you can run the testsuite just fine
with -m32 -mpowerpc64.

> +   /* -m32 -mpowerpc64 needs to use a 32-bit scratch register.  */
> if (in_p)
> - sri->icode = CODE_FOR_reload_di_load;
> + sri->icode = ((TARGET_32BIT) ? CODE_FOR_reload_si_load
> +   : CODE_FOR_reload_di_load);
> else
> - sri->icode = CODE_FOR_reload_di_store;
> + sri->icode = ((TARGET_32BIT) ? CODE_FOR_reload_si_store
> +   : CODE_FOR_reload_di_store);

You really like parentheses do you?  :-)  You could drop them all...


Segher

RE: [PATCH] Disable -fuse-caller-save when -pg is active

[Hans-Peter Nilsson]

On Fri, 14 Nov 2014, Radovan Obradovic wrote:
> index eb37bfe..ddaf8e0 100644
> --- a/gcc/toplev.c
> +++ b/gcc/toplev.c

> @@ -1605,6 +1612,11 @@ process_options (void)
>/* Save the current optimization options.  */
>optimization_default_node = build_optimization_node (&global_options);
>optimization_current_node = optimization_default_node;
> +
> +  /* Disable use caller save optimization if profiler is active or port
> + does not emit prologue and epilogue as RTL.  */
> +  if (profile_flag || !HAVE_prologue || !HAVE_epilogue)
> +flag_use_caller_save = 0;
>  }

This seems wrong.  Why disable caller-save regardless of
profile_flag; is there some long-standing bug in caller-save for
"old" targets?  I guess you want:

> +  if (profile_flag && (!HAVE_prologue || !HAVE_epilogue))


Not that it matter too much, I don't think we care about such
targets.  I don't even bother to grep if there is any. :)

brgds, H-P

Re: Minor comment tweak in config/nds32/nds32-peephole2.md

[Chung-Ju Wu]

2015-01-06 7:27 GMT+08:00 Eric Botcazou :
> I think that we don't want new define_peephole's at this point.
>
> Applied on the mainline as obvious.
>
>
> 2015-01-05  Eric Botcazou  
>
> * config/nds32/nds32-peephole2.md: Do not mention define_peephole.
>

Thank you for the comment refinement on nds32 port. :)


Best regards,
jasonwucj


>
> --
> Eric Botcazou