Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Andrew Sadek]

Change logs below.
There is a problem in attaching the bundle. I get permanent error from
sourceware.org

GCC ChangeLog:
Microblaze Target: PIC data text relative
* gcc/config/microblaze/microblaze.opt: add new option -mpic-data-text-rel.

* gcc/config/microblaze/microblaze-protos.h (microblaze_constant_address_p
):
Add microblaze_constant_address_p function instead of the macro in
microblaze.h
* gcc/config/microblaze/microblaze.c (TARGET_PIC_DATA_TEXT_REL): New
addressing mode
for data-text relative position indepenedent code.
(microblaze_classify_unspec): add 'UNSPEC_TEXT' case ->
'ADDRESS_SYMBOLIC_TXT_REL'.
(microblaze_classify_address): add handling for UNSPEC + CONST_INT.
(microblaze_legitimate_pic_operand): exclude function calls from pic
operands
in case of TARGET_PIC_DATA_TEXT_REL option.
(microblaze_legitimize_address): generate 'UNSPEC_TEXT' for all possible
addresses cases.
(microblaze_address_insns): add 'ADDRESS_SYMBOLIC_TXT_REL' case.
(print_operand): add 'ADDRESS_SYMBOLIC_TXT_REL' case.
(print_operand_address): add 'ADDRESS_SYMBOLIC_TXT_REL' case + handling for
'address + offset'.
(microblaze_expand_prologue): add new function prologue call for 'r20'
assignation.
(microblaze_asm_generate_pic_addr_dif_vec): override new target hook
'TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC' to disable address diff vector
table in case of TARGET_PIC_DATA_TEXT_REL.
(expand_pic_symbol_ref): add handling for 'UNSPEC_TEXT'.
* gcc/config/microblaze/microblaze.md (TARGET_PIC_DATA_TEXT_REL): Add new
macros 'UNSPEC_TEXT',
'UNSPEC_SET_TEXT' + add rule for setting r20 in function prologue + exclude
function calls
from 'UNSPEC_PLT' in case of data text relative mode.
* gcc/doc/tm.texi.in (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC): Add new
target hook for generating
address diff vector tables in case of flag_pic.
* gcc/doc/tm.texi : Regenerate.
* gcc/stmt.c (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC): append new condition
'targetm.asm_out.generate_pic_addr_diff_vec' to flag_pic in case of addr
diff vector generation.
* gcc/target.def (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC): add target hook
definition.
* gcc/targhooks.h, gcc/targhooks.c (TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC):
add default function for generate_pic_addr_diff_vec -> flag_pic.

Binutils ChangeLog:
Microblaze Target: PIC data text relative
* include/elf/microblaze.h (Add 3 new relocations):
'R_MICROBLAZE_TEXTPCREL_64', 'R_MICROBLAZE_TEXTREL_64'
and 'R_MICROBLAZE_TEXTREL_32_LO' for relax function.
* bfd/bfd-in2.h, bfd/libbfd.h (2 new BFD relocations):
'BFD_RELOC_MICROBLAZE_64_TEXTPCREL' + 'BFD_RELOC_MICROBLAZE_64_TEXTPCREL'
* bfd/elf32-microblaze.c (Handle new relocs): define 'HOWTO' of 3 new
relocs and handle them in both relocate
and relax functions.
(microblaze_elf_reloc_type_lookup): add mapping between for new bfd relocs.
(microblaze_bfd_write_branch_absolute_value_64): replace relative branch
with absolute in case 'adjust_insn_abs_refs' is true
(microblaze_bfd_revert_base_reg_value_64): revert base register from r20 to
r0 in case 'adjust_insn_abs_refs' is true
(microblaze_elf_relocate_section): Handle new relocs in case of elf
relocation.
(microblaze_elf_relax_section): Handle new relocs for elf relaxation.
* gas/config/tc-microblaze.c (Handle new relocs directives in assembler):
Handle new relocs from compiler output.
(imm_types): add new imm types for data text relative addressing
'TEXT_OFFSET', 'TEXT_PC_OFFSET'
(md_convert_frag): conversion for 'BFD_RELOC_MICROBLAZE_64_TEXTPCREL' ,
'BFD_RELOC_MICROBLAZE_64_TEXTPCREL'
(md_apply_fix): apply fix for 'BFD_RELOC_MICROBLAZE_64_TEXTPCREL' ,
'BFD_RELOC_MICROBLAZE_64_TEXTPCREL'
(md_estimate_size_before_relax): estimate size for
'BFD_RELOC_MICROBLAZE_64_TEXTPCREL' , 'BFD_RELOC_MICROBLAZE_64_TEXTPCREL'
(tc_gen_reloc): generate relocations for 'BFD_RELOC_MICROBLAZE_64_TEXTPCREL'
, 'BFD_RELOC_MICROBLAZE_64_TEXTPCREL'
Add new linker options for static linking: adjust-insn-abs-refs,
disable-multiple-abs-defs
* ld/lexsup.c (Add 2 ld options):
(ld_options): add adjust-insn-abs-refs, disable-multiple-abs-defs @
'ld_options' array
(parse_args): parse options and pass flags to 'link_info' struct.
* ld/ldlex.h (Add 2 enums): add new enums @ 'option_values' enum.
* include/bfdlink.h (Add 2 flags): Add new flags @ 'bfd_link_info' struct.
* ld/main.c: Initialize flags with false @ 'main'. Handle
disable-multiple-abs-defs
@ 'mutiple_definition'.


On Mon, Feb 26, 2018 at 9:56 AM, Andrew Guirguis 
wrote:

> Dears,
>
> Kindly find the patch bundle for Microblaze '-mpic-data-text-relative'
> feature at the following link:
> https://github.com/andrewsadek/microblaze-pic-data-text-rel/
> tree/pic_data_text_rel/PATCH%20BUNDLE
>
> Description of the feature:
> https://github.com/andrewsadek/microblaze-pic-data-text-rel/
> blob/pic_data_text_rel/README.md
>
> Bundle includes:
> 1) Change logs for GCC, binutils
> 2) GCC Test results and comparison with the original.
> 3) New Test case (picdtr.c)
> 4) The Patches (against current heads)
>
> Thank

Re: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs

[Tom de Vries]

On 01/08/2018 05:32 PM, Tom de Vries wrote:

On 12/18/2017 05:57 PM, Vladimir Makarov wrote:



On 12/15/2017 06:25 AM, Tom de Vries wrote:


Proposed Solution:

The patch addresses the problem, by:
- marking the hard regs that have been used in lra_spill in
  hard_regs_spilled_into
- using hard_regs_spilled_into in lra_create_live_ranges to
  make sure those registers are marked in the conflict_hard_regs
  of pseudos that overlap with the spill register usage

[ I've also tried an approach where I didn't use 
hard_regs_spilled_into, but tried to propagate all hard regs. I 
figured out that I needed to mask out eliminable_regset.  Also I 
needed to masked out lra_no_alloc_regs, but that could be due to 
gcn-specific problems (pointers take 2 hard regs), I'm not yet sure. 
Anyway, in the submitted patch I tried to avoid these problems and 
went for the more minimal approach. ]


Tom, thank you for the detail explanation of the problem and solutions 
you considered.  It helped me a lot.  Your simple solution is adequate 
as the most transformations and allocation are done on the 1st LRA 
subpasses iteration.

In order to get the patch accepted for trunk, I think we need:
- bootstrap and reg-test on x86_64
- build and reg-test on mips (the only primary platform that has the
  spill_class hook enabled)

Any comments?


The patch looks ok to me.  You can commit it after successful testing 
on x86-64 and mips but I am sure there will be no problems with x86-64 
as it does not use spill_class currently (actually your patch might 
help to switch it on again for x86-64.  spill_class was quite useful 
for x86-64 performance on Intel processors).




Hi Matthew,

there's an lra optimization that is currently enabled for MIPS, and not 
for any other primary or secondary target.


This (already approved) patch fixes a bug in that optimization, and 
needs to be tested on MIPS.


Unfortunately, the optimization is only enabled for MIPS16, and we don't 
have a current setup to test this.


Could you help us out here and test this patch for MIPS16 on trunk?


Hi Matthew,

is this something you can help us out with?

Thanks,
- Tom

C++ PATCH to fix ICE with suggestions (PR c++/84537)

[Marek Polacek]

Here error_mark_node leaks all the way to edit_distance_traits::get_string
which crashed, so let's not try to give a suggestion for an error node in
the first place.

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

2018-02-26  Marek Polacek  

PR c++/84537
* name-lookup.c (suggest_alternative_in_explicit_scope): Return false
if name is error node.

* g++.dg/parse/error60.C: New test.

diff --git gcc/cp/name-lookup.c gcc/cp/name-lookup.c
index 9117e0b30eb..0f00328e96e 100644
--- gcc/cp/name-lookup.c
+++ gcc/cp/name-lookup.c
@@ -5541,6 +5541,10 @@ bool
 suggest_alternative_in_explicit_scope (location_t location, tree name,
   tree scope)
 {
+  /* Something went very wrong; don't suggest anything.  */
+  if (name == error_mark_node)
+return false;
+
   /* Resolve any namespace aliases.  */
   scope = ORIGINAL_NAMESPACE (scope);
 
diff --git gcc/testsuite/g++.dg/parse/error60.C 
gcc/testsuite/g++.dg/parse/error60.C
index e69de29bb2d..38f4e34c59d 100644
--- gcc/testsuite/g++.dg/parse/error60.C
+++ gcc/testsuite/g++.dg/parse/error60.C
@@ -0,0 +1,9 @@
+// PR c++/84537
+// { dg-do compile }
+
+namespace N
+{
+  template struct A {};
+}
+
+N::template A<> a; // { dg-error "" }

Marek

Re: [PATCH] Fix up compound literal handling in C FE (PR sanitizer/84307)

[Martin Liška]

On 02/14/2018 11:03 PM, Joseph Myers wrote:
> On Wed, 14 Feb 2018, Jakub Jelinek wrote:
> 
>> 2018-02-13  Jakub Jelinek  
>>
>>  PR sanitizer/84340
>>  * c-decl.c (build_compound_literal): Call pushdecl (decl) even when
>>  it is not TREE_STATIC.
>>  * c-typeck.c (c_mark_addressable) : Mark
>>  not just the COMPOUND_LITERAL_EXPR node itself addressable, but also
>>  its COMPOUND_LITERAL_EXPR_DECL.
> 
> OK.
> 

Jakub you probably forgot to install the patch. Can you please do it?
Should I create a new test-case which you mentioned in previous email?

Martin

Re: [PATCH] i386: Update -mfunction-return= for return with pop

[Martin Liška]

On 02/25/2018 02:37 AM, H.J. Lu wrote:
>   PR target/r84530

Just a nit I've noticed:

s/r84530/84530

Martin

Re: [PATCH] Fix up compound literal handling in C FE (PR sanitizer/84307)

[Martin Liška]

On 02/26/2018 11:04 AM, Jakub Jelinek wrote:
> On Mon, Feb 26, 2018 at 11:00:48AM +0100, Martin Liška wrote:
>> On 02/14/2018 11:03 PM, Joseph Myers wrote:
>>> On Wed, 14 Feb 2018, Jakub Jelinek wrote:
>>>
 2018-02-13  Jakub Jelinek  

PR sanitizer/84340
* c-decl.c (build_compound_literal): Call pushdecl (decl) even when
it is not TREE_STATIC.
* c-typeck.c (c_mark_addressable) : Mark
not just the COMPOUND_LITERAL_EXPR node itself addressable, but also
its COMPOUND_LITERAL_EXPR_DECL.
>>>
>>> OK.
>>>
>>
>> Jakub you probably forgot to install the patch. Can you please do it?
> 
> No, I was asking for ack for stage1, so it is waiting for GCC9.
> This isn't really a regression and feels risky for GCC8 at this stage, might
> break invalid programs that try to use compound literals after they go out
> of scope.
> 
>   Jakub
> 

Ah, I see!

Thanks,
Martin

Re: Mising Patch #2 from the RISC-V v3 Submission

[Andreas Schwab]

On Feb 15 2018, Palmer Dabbelt  wrote:

> On Mon, 12 Feb 2018 15:18:39 PST (-0800), Jim Wilson wrote:
>> On 02/12/2018 03:23 AM, Andreas Schwab wrote:
>>> On Feb 06 2017, Palmer Dabbelt  wrote:
>>>
 +/* Because RISC-V only has word-sized atomics, it requries libatomic where
 +   others do not.  So link libatomic by default, as needed.  */
 +#undef LIB_SPEC
 +#ifdef LD_AS_NEEDED_OPTION
 +#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
 +  " %{pthread:" LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION 
 "}"
 +#else
 +#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC " -latomic "
 +#endif
>>>
>>> Why is -latomic added only with -pthread if --as-needed is supported,
>>> but unconditionally if not?  Wouldn't it make sense to add it
>>> unconditionally in both cases?
>>
>> I don't know the history here, but I do know that the most common atomic
>> related bug report we get is for people using pthread, so we were
>> probably thinking about that when this was written.
>
> IIRC that's why it's done this way.

This is a problem for gcc itself, libstdc++-v3 is failing its atomic
checks due to this (PR84568):

checking for atomic builtins for bool... no
checking for atomic builtins for short... no
checking for atomic builtins for int... yes
checking for atomic builtins for long long... yes
configure: WARNING: No native atomic operations are provided for this platform.
configure: WARNING: They will be faked using a mutex.
configure: WARNING: Performance of certain classes will degrade as a result.

But it wouldn't have found -latomic anyway.  There needs to be a generic
solution for that.

Another affected package is mariadb.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] i386: Update -mfunction-return= for return with pop

[H.J. Lu]

On Mon, Feb 26, 2018 at 2:05 AM, Martin Liška  wrote:
> On 02/25/2018 02:37 AM, H.J. Lu wrote:
>>   PR target/r84530
>
> Just a nit I've noticed:
>
> s/r84530/84530

Fixed.

-- 
H.J.
From f08b8721ed038cefcee5a0bb1329b90a2d322269 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Sat, 24 Feb 2018 05:05:49 -0800
Subject: [PATCH] i386: Update -mfunction-return= for return with pop

When -mfunction-return= is used, simple_return_pop_internal should pop
return address into ECX register, adjust stack by bytes to pop from stack
and jump to the return thunk via ECX register.

Tested on i686 and x86-64.

	PR target/84530
	* config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove
	the bool argument.
	(ix86_output_indirect_function_return): New prototype.
	(ix86_split_simple_return_pop_internal): Likewise.
	* config/i386/i386.c (indirect_return_via_cx): New.
	(indirect_return_via_cx_bnd): Likewise.
	(indirect_thunk_name): Handle return va CX_REG.
	(output_indirect_thunk_function): Create alias for
	__x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd.
	(ix86_output_indirect_jmp): Remove the bool argument.
	(ix86_output_indirect_function_return): New function.
	(ix86_split_simple_return_pop_internal): Likewise.
	* config/i386/i386.md (*indirect_jump): Don't pass false
	to ix86_output_indirect_jmp.
	(*tablejump_1): Likewise.
	(simple_return_pop_internal): Change it to define_insn_and_split.
	Call ix86_split_simple_return_pop_internal to split it for
	-mfunction-return=.
	(simple_return_indirect_internal): Call
	ix86_output_indirect_function_return instead of
	ix86_output_indirect_jmp.

gcc/testsuite/

	PR target/84530
	* gcc.target/i386/ret-thunk-22.c: New test.
	* gcc.target/i386/ret-thunk-23.c: Likewise.
	* gcc.target/i386/ret-thunk-24.c: Likewise.
	* gcc.target/i386/ret-thunk-25.c: Likewise.
	* gcc.target/i386/ret-thunk-26.c: Likewise.
---
 gcc/config/i386/i386-protos.h|   4 +-
 gcc/config/i386/i386.c   | 126 ---
 gcc/config/i386/i386.md  |  11 ++-
 gcc/testsuite/gcc.target/i386/ret-thunk-22.c |  15 
 gcc/testsuite/gcc.target/i386/ret-thunk-23.c |  15 
 gcc/testsuite/gcc.target/i386/ret-thunk-24.c |  15 
 gcc/testsuite/gcc.target/i386/ret-thunk-25.c |  15 
 gcc/testsuite/gcc.target/i386/ret-thunk-26.c |  40 +
 8 files changed, 223 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/ret-thunk-22.c
 create mode 100644 gcc/testsuite/gcc.target/i386/ret-thunk-23.c
 create mode 100644 gcc/testsuite/gcc.target/i386/ret-thunk-24.c
 create mode 100644 gcc/testsuite/gcc.target/i386/ret-thunk-25.c
 create mode 100644 gcc/testsuite/gcc.target/i386/ret-thunk-26.c

diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index fb86f00b3a6..79b96c0f80b 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -305,8 +305,10 @@ extern enum attr_cpu ix86_schedule;
 #endif
 
 extern const char * ix86_output_call_insn (rtx_insn *insn, rtx call_op);
-extern const char * ix86_output_indirect_jmp (rtx call_op, bool ret_p);
+extern const char * ix86_output_indirect_jmp (rtx call_op);
 extern const char * ix86_output_function_return (bool long_p);
+extern const char * ix86_output_indirect_function_return (rtx ret_op);
+extern void ix86_split_simple_return_pop_internal (rtx);
 extern bool ix86_operands_ok_for_move_multiple (rtx *operands, bool load,
 		machine_mode mode);
 extern int ix86_min_insn_size (rtx_insn *);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 640c5921863..98075ad42c7 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -10812,6 +10812,12 @@ static int indirect_thunks_used;
by call and return thunks functions with the BND prefix.  */
 static int indirect_thunks_bnd_used;
 
+/* True if return thunk function via CX is needed.  */
+static bool indirect_return_via_cx;
+/* True if return thunk function via CX with the BND prefix is
+   needed.  */
+static bool indirect_return_via_cx_bnd;
+
 #ifndef INDIRECT_LABEL
 # define INDIRECT_LABEL "LIND"
 #endif
@@ -10852,7 +10858,7 @@ indirect_thunk_name (char name[32], unsigned int regno,
 		 enum indirect_thunk_prefix need_prefix,
 		 bool ret_p)
 {
-  if (regno != INVALID_REGNUM && ret_p)
+  if (regno != INVALID_REGNUM && regno != CX_REG && ret_p)
 gcc_unreachable ();
 
   if (USE_HIDDEN_LINKONCE)
@@ -10872,6 +10878,8 @@ indirect_thunk_name (char name[32], unsigned int regno,
   else
 	prefix = "";
 
+  const char *ret = ret_p ? "return" : "indirect";
+
   if (regno != INVALID_REGNUM)
 	{
 	  const char *reg_prefix;
@@ -10879,14 +10887,11 @@ indirect_thunk_name (char name[32], unsigned int regno,
 	reg_prefix = TARGET_64BIT ? "r" : "e";
 	  else
 	reg_prefix = "";
-	  sprintf (name, "__x86_indirect_thunk%s_%s%s",
-		   prefix, reg_prefix, reg_names[regno]);
+	  sprintf (name, "__x86_%s_thunk%s_%s%s",
+		   ret, prefix, reg_

[C++ Patch] PR 84533 ("[7/8 Regression] ICE with duplicate enum value")

[Paolo Carlini]

Hi,

this ICE on invalid happens only in c++17 mode, when 
redeclaration_error_message performs an additional check which only 
makes sense for data members. Thus the fix is easy: avoid checking 
DECL_DECLARED_CONSTEXPR_P on CONST_DECLs.


Tested x86_64-linux.

Thanks, Paolo.

//

/cp
2018-02-26  Paolo Carlini  

PR c++/84533
* decl.c (redeclaration_error_message): Don't try to use
DECL_DECLARED_CONSTEXPR_P on CONST_DECLs.

/testsuite
2018-02-26  Paolo Carlini  

PR c++/84533
* g++.dg/cpp1z/pr84533.C: New.
Index: cp/decl.c
===
--- cp/decl.c   (revision 257983)
+++ cp/decl.c   (working copy)
@@ -2919,6 +2919,7 @@ redeclaration_error_message (tree newdecl, tree ol
 specifier is declaration rather than definition (and
 deprecated).  */
   if (cxx_dialect >= cxx17
+ && VAR_P (olddecl)
  && DECL_CLASS_SCOPE_P (olddecl)
  && DECL_DECLARED_CONSTEXPR_P (olddecl)
  && !DECL_INITIAL (newdecl))
Index: testsuite/g++.dg/cpp1z/pr84533.C
===
--- testsuite/g++.dg/cpp1z/pr84533.C(nonexistent)
+++ testsuite/g++.dg/cpp1z/pr84533.C(working copy)
@@ -0,0 +1,3 @@
+// { dg-options "-std=c++17" }
+
+enum E { e, e };  // { dg-error "redefinition" }

[C++ Patch] Define build_capture_proxy as static

[Paolo Carlini]

Hi,

today noticed this straightforward nit trivial enough for this stage?

Thanks, Paolo.

/

2018-02-26  Paolo Carlini  

* lambda.c (build_capture_proxy): Define static.
* cp-tree.h (build_capture_proxy): Remove.
Index: cp-tree.h
===
--- cp-tree.h   (revision 257983)
+++ cp-tree.h   (working copy)
@@ -6890,7 +6890,6 @@ extern tree lambda_function   (tree);
 extern void apply_deduced_return_type   (tree, tree);
 extern tree add_capture (tree, tree, tree, bool, bool);
 extern tree add_default_capture (tree, tree, tree);
-extern tree build_capture_proxy(tree, tree);
 extern void insert_capture_proxy   (tree);
 extern void insert_pending_capture_proxies (void);
 extern bool is_capture_proxy   (tree);
Index: lambda.c
===
--- lambda.c(revision 257983)
+++ lambda.c(working copy)
@@ -388,7 +388,7 @@ lambda_proxy_type (tree ref)
inside the operator(), build a placeholder var for future lookups and
debugging.  */
 
-tree
+static tree
 build_capture_proxy (tree member, tree init)
 {
   tree var, object, fn, closure, name, lam, type;

Re: [PATCH] Fix up compound literal handling in C FE (PR sanitizer/84307)

[Jakub Jelinek]

On Mon, Feb 26, 2018 at 11:00:48AM +0100, Martin Liška wrote:
> On 02/14/2018 11:03 PM, Joseph Myers wrote:
> > On Wed, 14 Feb 2018, Jakub Jelinek wrote:
> > 
> >> 2018-02-13  Jakub Jelinek  
> >>
> >>PR sanitizer/84340
> >>* c-decl.c (build_compound_literal): Call pushdecl (decl) even when
> >>it is not TREE_STATIC.
> >>* c-typeck.c (c_mark_addressable) : Mark
> >>not just the COMPOUND_LITERAL_EXPR node itself addressable, but also
> >>its COMPOUND_LITERAL_EXPR_DECL.
> > 
> > OK.
> > 
> 
> Jakub you probably forgot to install the patch. Can you please do it?

No, I was asking for ack for stage1, so it is waiting for GCC9.
This isn't really a regression and feels risky for GCC8 at this stage, might
break invalid programs that try to use compound literals after they go out
of scope.

Jakub

Re: [PATCH] Correct debug for -mcall-ms2sysv-xlogues stubs (PR target/83917, take 2)

[Jakub Jelinek]

On Sun, Feb 25, 2018 at 05:56:28PM -0600, Daniel Santos wrote:
> > --- libgcc/config/i386/i386-asm.h.jj2018-01-03 10:42:56.317763517 
> > +0100
> > +++ libgcc/config/i386/i386-asm.h   2018-02-22 15:33:43.812922298 +0100
> > @@ -27,8 +27,47 @@ see the files COPYING3 and COPYING.RUNTI
> >  #define I386_ASM_H
> >  
> >  #include "auto-target.h"
> > +#undef PACKAGE_VERSION
> > +#undef PACKAGE_NAME
> > +#undef PACKAGE_STRING
> > +#undef PACKAGE_TARNAME
> > +#undef PACKAGE_URL
> 
> This is a beautiful, temporary(?) fix to an ugly problem!
> 
> >  #include "auto-host.h"

> > --- libgcc/config/i386/cygwin.S.jj  2018-01-03 10:42:56.309763515 +0100
> > +++ libgcc/config/i386/cygwin.S 2018-02-22 15:30:34.597925496 +0100
> > @@ -23,31 +23,13 @@
> >   * .
> >   */
> >  
> > -#include "auto-host.h"
> 
> The following include should be here.
> 
> +#include "i386-asm.h"

I don't understand this.  i386-asm.h needs (both before my patch and after
it) both auto-host.h and auto-target.h, as it tests
HAVE_GAS_SECTIONS_DIRECTIVE (this one newly, comes from cygwin.S)
HAVE_GAS_HIDDEN
macros defined in auto-host.h
and
HAVE_AS_AVX
macro defined in auto-target.h.
Including auto-host.h when i386-asm.h will include it again just doesn't
work, these headers don't have multiple inclusion guards.  And only including
auto-target.h will work only if the
.hidden
and
.cfi_sections .debug_frame
tests are duplicated from gcc/configure.ac to libgcc/configure.ac, then we
could include just auto-target.h in i386-asm.h.
I've just followed what i386-asm.h has been doing.

Jakub

Re: [PATCH] i386: Update -mfunction-return= for return with pop

[Jan Hubicka]

> On Mon, Feb 26, 2018 at 2:05 AM, Martin Liška  wrote:
> > On 02/25/2018 02:37 AM, H.J. Lu wrote:
> >>   PR target/r84530
> >
> > Just a nit I've noticed:
> >
> > s/r84530/84530
> 
> Fixed.
> 
> -- 
> H.J.

> From f08b8721ed038cefcee5a0bb1329b90a2d322269 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" 
> Date: Sat, 24 Feb 2018 05:05:49 -0800
> Subject: [PATCH] i386: Update -mfunction-return= for return with pop
> 
> When -mfunction-return= is used, simple_return_pop_internal should pop
> return address into ECX register, adjust stack by bytes to pop from stack
> and jump to the return thunk via ECX register.
> 
> Tested on i686 and x86-64.
> 
>   PR target/84530
>   * config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove
>   the bool argument.
>   (ix86_output_indirect_function_return): New prototype.
>   (ix86_split_simple_return_pop_internal): Likewise.
>   * config/i386/i386.c (indirect_return_via_cx): New.
>   (indirect_return_via_cx_bnd): Likewise.
>   (indirect_thunk_name): Handle return va CX_REG.
>   (output_indirect_thunk_function): Create alias for
>   __x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd.
>   (ix86_output_indirect_jmp): Remove the bool argument.
>   (ix86_output_indirect_function_return): New function.
>   (ix86_split_simple_return_pop_internal): Likewise.
>   * config/i386/i386.md (*indirect_jump): Don't pass false
>   to ix86_output_indirect_jmp.
>   (*tablejump_1): Likewise.
>   (simple_return_pop_internal): Change it to define_insn_and_split.
>   Call ix86_split_simple_return_pop_internal to split it for
>   -mfunction-return=.
>   (simple_return_indirect_internal): Call
>   ix86_output_indirect_function_return instead of
>   ix86_output_indirect_jmp.

It seems to make sense. Since LLVM has picked up our thunk names now,
I wonder if they have same bug or someohow already assigned a name
to this thunk. In the second case we probably ought to match it. Do
you know what LLVM uses?

Honza

Re: [Patch] Fix lto-wrapper link flags

[Richard Biener]

On Mon, Feb 19, 2018 at 11:11 AM, Christophe Lyon
 wrote:
> Hi,
>
> I think there's a typo in gcc/Makefile.in, where lto-wrapper is linked
> using $(ALL_COMPILERFLAGS) while it should be $(ALL_LINKERFLAGS).
>
> I noticed this while playing with linker flags, and not seeing them
> when linking lto-wrapper.
> It seems obvious, but maybe I'm missing something?
>
> OK for trunk?

Ok.

Richard.

> Thanks,
>
> Christophe

Re: [Patch fortran] PR32957 - C/Fortran interoperability and -fdefault-integer-8

[Dominique d'Humières]

Thanks for the quick review, committed as r257985. I have spotted a few similar 
issues in my recent testing and I have problem with 
gfortran.dg/bind_c_usage_10.f03 when using -fdefault-integer-8:

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:66:31:

   integer(c_int) function func4()
   1
Error: FUNCTION result func4 can't be of type INTEGER(4) in FUNCTION func4 at 
(1)
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:59:31:

   integer(c_int) function func3() bind(c, name="myFunc3")
   1
Error: FUNCTION result func3 can't be of type INTEGER(4) in FUNCTION func3 at 
(1)
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:52:31:

   integer(c_int) function func2()
   1
Error: FUNCTION result func2 can't be of type INTEGER(4) in FUNCTION func2 at 
(1)
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:45:31:

   integer(c_int) function func1() bind(c, name="myFunc1")
   1
Error: FUNCTION result func1 can't be of type INTEGER(4) in FUNCTION func1 at 
(1)

AFAIU the code func* are integer(c_int), then why these errors?

TIA

Dominique

> Le 26 févr. 2018 à 00:34, Thomas Koenig  a écrit :
> 
> Hi Dominique,
> 
>> OK for trunk? back port?
> 
> OK for trunk.
> 
> The tests were non-conforming before, so this is also a
> step in making our testsuite better.
> 
> For gcc-7, I'm not sure I would bother, but OK if
> you want to do it.
> 
> Regards
> 
>   Thomas

RE: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs

[Matthew Fortune]

Tom de Vries  writes:
> On 01/08/2018 05:32 PM, Tom de Vries wrote:
> > On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
> >>
> >>
> >> On 12/15/2017 06:25 AM, Tom de Vries wrote:
> >>>
> >>> Proposed Solution:
> >>>
> >>> The patch addresses the problem, by:
> >>> - marking the hard regs that have been used in lra_spill in
> >>>   hard_regs_spilled_into
> >>> - using hard_regs_spilled_into in lra_create_live_ranges to
> >>>   make sure those registers are marked in the conflict_hard_regs
> >>>   of pseudos that overlap with the spill register usage
> >>>
> >>> [ I've also tried an approach where I didn't use
> >>> hard_regs_spilled_into, but tried to propagate all hard regs. I
> >>> figured out that I needed to mask out eliminable_regset.  Also I
> >>> needed to masked out lra_no_alloc_regs, but that could be due to
> >>> gcn-specific problems (pointers take 2 hard regs), I'm not yet sure.
> >>> Anyway, in the submitted patch I tried to avoid these problems and
> >>> went for the more minimal approach. ]
> >>>
> >> Tom, thank you for the detail explanation of the problem and
> >> solutions you considered.  It helped me a lot.  Your simple solution
> >> is adequate as the most transformations and allocation are done on
> >> the 1st LRA subpasses iteration.
> >>> In order to get the patch accepted for trunk, I think we need:
> >>> - bootstrap and reg-test on x86_64
> >>> - build and reg-test on mips (the only primary platform that has the
> >>>   spill_class hook enabled)
> >>>
> >>> Any comments?
> >>
> >> The patch looks ok to me.  You can commit it after successful testing
> >> on x86-64 and mips but I am sure there will be no problems with
> >> x86-64 as it does not use spill_class currently (actually your patch
> >> might help to switch it on again for x86-64.  spill_class was quite
> >> useful for x86-64 performance on Intel processors).
> >>
> >
> > Hi Matthew,
> >
> > there's an lra optimization that is currently enabled for MIPS, and
> > not for any other primary or secondary target.
> >
> > This (already approved) patch fixes a bug in that optimization, and
> > needs to be tested on MIPS.
> >
> > Unfortunately, the optimization is only enabled for MIPS16, and we
> > don't have a current setup to test this.
> >
> > Could you help us out here and test this patch for MIPS16 on trunk?
> 
> Hi Matthew,
> 
> is this something you can help us out with?

Hi Tom,

I've just commented on the bug report that I've set of some builds to try
and give some assurance. It is far from comprehensive but it is as good as
the normal testing I do for MIPS16.

Thanks,
Matthew

Fix slow value range hash

[Jan Hubicka]

Hi,
this is patch Jakub posted to IRC while discussing slow ipa-cp jump function
streaming. The problem is that hash hashes types as iterative types but later
compares them as pointers.  Iterative hash is trying to make semantically
equivalent types really equivalent.

Alternatively we may try to unify types that are semantically equivalent
but it seems bit slopy to do at stage4.

Bootstrapped/regtested x86_64-linux, OK?

Honza

patch by Jakub Jelinek
* ipa-prop.c (ipa_vr_ggc_hash_traits::hash): Hash pointers rather
than iterative types.
Index: ipa-prop.c
===
--- ipa-prop.c  (revision 257931)
+++ ipa-prop.c  (working copy)
@@ -113,9 +113,10 @@ struct ipa_vr_ggc_hash_traits : public g
   hash (const value_range *p)
   {
 gcc_checking_assert (!p->equiv);
-hashval_t t = (hashval_t) p->type;
-t = iterative_hash_expr (p->min, t);
-return iterative_hash_expr (p->max, t);
+inchash::hash hstate (p->type);
+hstate.add_ptr (p->min);
+hstate.add_ptr (p->max);
+return hstate.end ();
   }
   static bool
   equal (const value_range *a, const value_range *b)

Re: [PATCH] PR gcc/68256 Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

[Richard Biener]

On Fri, Feb 16, 2018 at 6:18 PM,   wrote:
> From: Vladimir Mezentsev 
>
> Ramana Radhakrishnan made a workaround in gcc/config/aarch64/aarch64.c to 
> resolve
> bootstrap comparison failure (2015-11-10, commit 
> bc443a71dafa2e707bae4b2fa74f83b05dea37ab).
> The real bug is in gcc/varasm.c.
> hash_section() returns an unstable value.
> As result, two blocks are created in get_block_for_section() for one unnamed 
> section.
> A list of objects in these blocks depends on the -gtoggle option.
> I removed Ramana's workaround in gcc/config/aarch64/aarch64.c and
> I fixed hash_section() in gcc/varasm.c
>
> Bootstrapped on aarch64-unknown-linux-gnu including (c,c++ and go).
> Testing finished ok.

Ok.

Thanks,
Richard.

> ChangeLog:
> 2018-02-15  Vladimir Mezentsev  
>
> PR gcc/68256
> * varasm.c (hash_section): Return an unchangeble hash value
> * config/aarch64/aarch64.c (aarch64_use_blocks_for_constant_p):
> Return !aarch64_can_use_per_function_literal_pools_p ();
> ---
>  gcc/config/aarch64/aarch64.c | 8 +++-
>  gcc/varasm.c | 2 +-
>  2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 174310c..a0a495d 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -7596,11 +7596,9 @@ aarch64_can_use_per_function_literal_pools_p (void)
>  static bool
>  aarch64_use_blocks_for_constant_p (machine_mode, const_rtx)
>  {
> -  /* Fixme:: In an ideal world this would work similar
> - to the logic in aarch64_select_rtx_section but this
> - breaks bootstrap in gcc go.  For now we workaround
> - this by returning false here.  */
> -  return false;
> +  /* We can't use blocks for constants when we're using a per-function
> + constant pool.  */
> +  return !aarch64_can_use_per_function_literal_pools_p ();
>  }
>
>  /* Select appropriate section for constants depending
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index b045efa..5aae5b4 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -225,7 +225,7 @@ hash_section (section *sect)
>  {
>if (sect->common.flags & SECTION_NAMED)
>  return htab_hash_string (sect->named.name);
> -  return sect->common.flags;
> +  return sect->common.flags & ~SECTION_DECLARED;
>  }
>
>  /* Helper routines for maintaining object_block_htab.  */
> --
> 1.8.3.1
>

Re: Fix slow value range hash

[Jan Hubicka]

> On Mon, Feb 26, 2018 at 12:04:53PM +0100, Jan Hubicka wrote:
> > Hi,
> > this is patch Jakub posted to IRC while discussing slow ipa-cp jump function
> > streaming. The problem is that hash hashes types as iterative types but 
> > later
> > compares them as pointers.  Iterative hash is trying to make semantically
> > equivalent types really equivalent.
> > 
> > Alternatively we may try to unify types that are semantically equivalent
> > but it seems bit slopy to do at stage4.
> > 
> > Bootstrapped/regtested x86_64-linux, OK?
> 
> Please see http://gcc.gnu.org/r257940 , it is already committed.
Good, can you please backport it to gcc 7?

Thanks,
Honza
> 
>   Jakub

Re: Fix slow value range hash

[Jakub Jelinek]

On Mon, Feb 26, 2018 at 12:12:21PM +0100, Jan Hubicka wrote:
> > On Mon, Feb 26, 2018 at 12:04:53PM +0100, Jan Hubicka wrote:
> > > Hi,
> > > this is patch Jakub posted to IRC while discussing slow ipa-cp jump 
> > > function
> > > streaming. The problem is that hash hashes types as iterative types but 
> > > later
> > > compares them as pointers.  Iterative hash is trying to make semantically
> > > equivalent types really equivalent.
> > > 
> > > Alternatively we may try to unify types that are semantically equivalent
> > > but it seems bit slopy to do at stage4.
> > > 
> > > Bootstrapped/regtested x86_64-linux, OK?
> > 
> > Please see http://gcc.gnu.org/r257940 , it is already committed.
> Good, can you please backport it to gcc 7?

Will do within a week, I have dozens of other commits that need backporting.

Jakub

Re: [PATCH] i386: Update -mfunction-return= for return with pop

[H.J. Lu]

On Mon, Feb 26, 2018 at 2:58 AM, Jan Hubicka  wrote:
>> On Mon, Feb 26, 2018 at 2:05 AM, Martin Liška  wrote:
>> > On 02/25/2018 02:37 AM, H.J. Lu wrote:
>> >>   PR target/r84530
>> >
>> > Just a nit I've noticed:
>> >
>> > s/r84530/84530
>>
>> Fixed.
>>
>> --
>> H.J.
>
>> From f08b8721ed038cefcee5a0bb1329b90a2d322269 Mon Sep 17 00:00:00 2001
>> From: "H.J. Lu" 
>> Date: Sat, 24 Feb 2018 05:05:49 -0800
>> Subject: [PATCH] i386: Update -mfunction-return= for return with pop
>>
>> When -mfunction-return= is used, simple_return_pop_internal should pop
>> return address into ECX register, adjust stack by bytes to pop from stack
>> and jump to the return thunk via ECX register.
>>
>> Tested on i686 and x86-64.
>>
>>   PR target/84530
>>   * config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove
>>   the bool argument.
>>   (ix86_output_indirect_function_return): New prototype.
>>   (ix86_split_simple_return_pop_internal): Likewise.
>>   * config/i386/i386.c (indirect_return_via_cx): New.
>>   (indirect_return_via_cx_bnd): Likewise.
>>   (indirect_thunk_name): Handle return va CX_REG.
>>   (output_indirect_thunk_function): Create alias for
>>   __x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd.
>>   (ix86_output_indirect_jmp): Remove the bool argument.
>>   (ix86_output_indirect_function_return): New function.
>>   (ix86_split_simple_return_pop_internal): Likewise.
>>   * config/i386/i386.md (*indirect_jump): Don't pass false
>>   to ix86_output_indirect_jmp.
>>   (*tablejump_1): Likewise.
>>   (simple_return_pop_internal): Change it to define_insn_and_split.
>>   Call ix86_split_simple_return_pop_internal to split it for
>>   -mfunction-return=.
>>   (simple_return_indirect_internal): Call
>>   ix86_output_indirect_function_return instead of
>>   ix86_output_indirect_jmp.
>
> It seems to make sense. Since LLVM has picked up our thunk names now,
> I wonder if they have same bug or someohow already assigned a name
> to this thunk. In the second case we probably ought to match it. Do
> you know what LLVM uses?
>

I don't think LLVM has implemented -mfunction-return=.   I disclosed
my -mindirect-branch= approach to LLVM last year.  At the time, they
wanted freedom in their implementation and didn't want to be compatible
with mine.   Later they added GCC compatibility so that LLVM may be
used to compile Linux kernel.  I believe it will be the same case if this
option is used to compile Linux kernel.

BTW, is my patch:

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html

OK for trunk?  The review died at

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01355.html

Thanks.

-- 
H.J.

[committed] Add testcase for already fixed PR c++/84556

[Jakub Jelinek]

Hi!

This ICE got fixed already in r257820, but more testsuite coverage doesn't
hurt.

2018-02-26  Jakub Jelinek  

PR c++/84556
* g++.dg/gomp/pr84556.C: New test.
* g++.dg/vect/pr84556.cc: New test.

--- gcc/testsuite/g++.dg/gomp/pr84556.C.jj  2018-02-26 11:13:36.848451757 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr84556.C 2018-02-26 11:13:20.463451315 +0100
@@ -0,0 +1,14 @@
+// PR c++/84556
+// { dg-do compile }
+// { dg-options "-std=c++17 -fopenmp-simd" }
+
+void
+foo ()
+{
+  auto x = [] ()
+  {
+#pragma omp simd
+for (int i = 0; i < 8; ++i)
+  ;
+  };
+}
--- gcc/testsuite/g++.dg/vect/pr84556.cc.jj 2018-02-26 11:12:01.488449209 
+0100
+++ gcc/testsuite/g++.dg/vect/pr84556.cc2018-02-26 11:10:59.77561 
+0100
@@ -0,0 +1,21 @@
+// PR c++/84556
+// { dg-do run { target c++11 } }
+// { dg-options "-O2 -fopenmp-simd" }
+// { dg-additional-options "-mavx" { target avx_runtime } }
+
+int
+main ()
+{
+  int y[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
+  auto x = [&y] ()
+  {
+#pragma omp simd
+for (int i = 0; i < 8; ++i)
+  y[i]++;
+  };
+  x ();
+  x ();
+  for (int i = 0; i < 8; ++i)
+if (y[i] != i + 3)
+  __builtin_abort ();
+}

Jakub

Re: Patch ping (Re: [PATCH PR82965/PR83991]Fix invalid profile count in vectorization peeling)

[Bin.Cheng]

Ping^2

Thanks,
bin

On Mon, Feb 19, 2018 at 5:14 PM, Jakub Jelinek  wrote:
> Hi!
>
> Honza, do you think you could have a look at this P1 fix?
>
> Thanks.
>
> On Wed, Jan 31, 2018 at 10:03:51AM +, Bin Cheng wrote:
>> Hi,
>> This patch fixes invalid profile count information in vectorization peeling.
>> Current implementation is a bit confusing for me since it tries to compute
>> an overall probability based on scaling probability and change of estimated
>> niters.  This patch does it in two steps.  Firstly it does the scaling, then
>> it adjusts to new estimated niters by simply adjusting loop's latch count
>> information; scaling the loop's count information by the proportion
>> new_estimated_niters/old_estimate_niters.  Of course we have to adjust loop
>> latch's count information back after scaling.
>>
>> Bootstrap and test on x86_64 and AArch64.  gcc.dg/vect/pr79347.c is fixed
>> for both PR82965 and PR83991.  Is this OK?
>>
>> Thanks,
>> bin
>>
>> 2018-01-30  Bin Cheng  
>>
>>   PR tree-optimization/82965
>>   PR tree-optimization/83991
>>   * cfgloopmanip.c (scale_loop_profile): Further scale loop's profile
>>   information if the loop was predicted to iterate too many times.
>
>> diff --git a/gcc/cfgloopmanip.c b/gcc/cfgloopmanip.c
>> index b9b76d8..1f560b8 100644
>> --- a/gcc/cfgloopmanip.c
>> +++ b/gcc/cfgloopmanip.c
>> @@ -509,7 +509,7 @@ scale_loop_profile (struct loop *loop, 
>> profile_probability p,
>>   gcov_type iteration_bound)
>>  {
>>gcov_type iterations = expected_loop_iterations_unbounded (loop);
>> -  edge e;
>> +  edge e, preheader_e;
>>edge_iterator ei;
>>
>>if (dump_file && (dump_flags & TDF_DETAILS))
>> @@ -521,77 +521,66 @@ scale_loop_profile (struct loop *loop, 
>> profile_probability p,
>>  (int)iteration_bound, (int)iterations);
>>  }
>>
>> +  /* Scale the probabilities.  */
>> +  scale_loop_frequencies (loop, p);
>> +
>>/* See if loop is predicted to iterate too many times.  */
>> -  if (iteration_bound && iterations > 0
>> -  && p.apply (iterations) > iteration_bound)
>> +  if (iteration_bound == 0 || iterations <= 0
>> +  || p.apply (iterations) <= iteration_bound)
>> +return;
>> +
>> +  e = single_exit (loop);
>> +  preheader_e = loop_preheader_edge (loop);
>> +  profile_count count_in = preheader_e->count ();
>> +  if (e && preheader_e
>> +  && count_in > profile_count::zero ()
>> +  && loop->header->count.initialized_p ())
>>  {
>> -  /* Fixing loop profile for different trip count is not trivial; the 
>> exit
>> -  probabilities has to be updated to match and frequencies propagated 
>> down
>> -  to the loop body.
>> -
>> -  We fully update only the simple case of loop with single exit that is
>> -  either from the latch or BB just before latch and leads from BB with
>> -  simple conditional jump.   This is OK for use in vectorizer.  */
>> -  e = single_exit (loop);
>> -  if (e)
>> - {
>> -   edge other_e;
>> -   profile_count count_delta;
>> +  edge other_e;
>> +  profile_count count_delta;
>>
>> -  FOR_EACH_EDGE (other_e, ei, e->src->succs)
>> - if (!(other_e->flags & (EDGE_ABNORMAL | EDGE_FAKE))
>> - && e != other_e)
>> -   break;
>> +  FOR_EACH_EDGE (other_e, ei, e->src->succs)
>> + if (!(other_e->flags & (EDGE_ABNORMAL | EDGE_FAKE))
>> + && e != other_e)
>> +   break;
>>
>> -   /* Probability of exit must be 1/iterations.  */
>> -   count_delta = e->count ();
>> -   e->probability = profile_probability::always ()
>> +  /* Probability of exit must be 1/iterations.  */
>> +  count_delta = e->count ();
>> +  e->probability = profile_probability::always ()
>>   .apply_scale (1, iteration_bound);
>> -   other_e->probability = e->probability.invert ();
>> -   count_delta -= e->count ();
>> -
>> -   /* If latch exists, change its count, since we changed
>> -  probability of exit.  Theoretically we should update everything 
>> from
>> -  source of exit edge to latch, but for vectorizer this is enough.  
>> */
>> -   if (loop->latch
>> -   && loop->latch != e->src)
>> - {
>> -   loop->latch->count += count_delta;
>> - }
>> - }
>> +  other_e->probability = e->probability.invert ();
>>
>>/* Roughly speaking we want to reduce the loop body profile by the
>>difference of loop iterations.  We however can do better if
>>we look at the actual profile, if it is available.  */
>> -  p = p.apply_scale (iteration_bound, iterations);
>> -
>> -  if (loop->header->count.initialized_p ())
>> - {
>> -   profile_count count_in = profile_count::zero ();
>> +  p = profile_probability::always ();
>>
>> -   FOR_EACH_EDGE (e, ei, loop->header->preds)
>> - if (e->src != loop->latch)
>> -   count_in += e->count ();

Re: [PATCH] Fix bootstrap with GCC 3.4 (and likely anything < 4.4 except 4.2.[0-3]) (PR bootstrap/84405)

[Richard Biener]

On Mon, 26 Feb 2018, Jakub Jelinek wrote:

> Hi!
> 
> On Sat, Feb 17, 2018 at 10:08:48AM +0100, Jakub Jelinek wrote:
> > Note, this doesn't work, as G++ <= 4.2 rejects:
> > template 
> > struct S
> > {
> >   char __attribute__ ((__aligned__ (__alignof__ (value_type buf[sizeof 
> > (value_type)];
> > };
> > 
> > S s;
> > 
> > with:
> > error: requested alignment is not a constant
> > 
> > The following works though, and has been successfully bootstrapped/regtested
> > on x86_64-linux and i686-linux.  It will fail if we use hash_table on
> > overaligned value_type type with alignment > 64, but that is not completely
> > unlikely on any target I'm aware of.  It uses __alignof__ which should be
> > supported by the system GCC's we support for which
> > BROKEN_VALUE_INITIALIZATION is true (i.e. >= 3.4 and <= 4.3), non-GCC
> > compilers shouldn't get here due to GCC_VERSION != 0 unless they pretend to
> > be GCC compatible.
> > 
> > Bootstrapped with system gcc34/g++34 on x86_64-linux, ok for trunk?
> > 
> > 2018-02-17  Jakub Jelinek  
> > 
> > PR bootstrap/84405
> > * vec.h (vec_default_construct): For BROKEN_VALUE_INITIALIZATION use
> > memset and value initialization afterwards.
> > * hash-table.h (hash_table::empty_slow): For
> > BROKEN_VALUE_INITIALIZATION use placement new into a previously
> > cleared appropriately aligned buffer.
> 
> I'd like to ping this patch, or if it isn't acceptable, at least the vec.h
> part of it which isn't really more complex than what we have right now.

So BROKEN_VALUE_INITIALIZATION doesn't really mean it's "broken" but
that is has certain behavior that doesn't invalidate the clearing
done earlier?  That said, I wonder if first doing the regular
construction and memset afterwards in case of
BROKEN_VALUE_INITIALIZATION wouldn't be more reliable and "easier"?

> > --- gcc/vec.h.jj2018-02-16 19:39:03.637058918 +0100
> > +++ gcc/vec.h   2018-02-16 23:51:55.389582056 +0100
> > @@ -490,12 +490,11 @@ template 
> >  inline void
> >  vec_default_construct (T *dst, unsigned n)
> >  {
> > -#ifndef BROKEN_VALUE_INITIALIZATION
> > -  for ( ; n; ++dst, --n)
> > -::new (static_cast(dst)) T ();
> > -#else
> > +#ifdef BROKEN_VALUE_INITIALIZATION
> >memset (dst, '\0', sizeof (T) * n);
> >  #endif
> > +  for ( ; n; ++dst, --n)
> > +::new (static_cast(dst)) T ();
> >  }
> >  
> >  /* Copy-construct N elements in DST from *SRC.  */
> > --- gcc/hash-table.h.jj 2018-02-16 19:39:03.660058934 +0100
> > +++ gcc/hash-table.h2018-02-17 00:01:24.207723925 +0100
> > @@ -808,7 +808,18 @@ hash_table::empty
> >for ( ; size; ++entries, --size)
> > *entries = value_type ();
> >  #else
> > -  memset (entries, 0, size * sizeof (value_type));
> > +  /* To workaround older GCC versions which don't handle value
> > +initialization right, use a placement new into previously
> > +cleared buffer.  */
> > +  char buf[2 * sizeof (value_type) + 64];
> > +  gcc_assert (__alignof__ (value_type) <= sizeof (value_type) + 64);
> > +  char *q = (buf + sizeof (value_type) + 64
> > +- ((uintptr_t) buf % __alignof__ (value_type)));
> > +  memset (q, '\0', sizeof (value_type));
> > +  value_type *p = ::new (q) value_type ();
> > +  for ( ; size; ++entries, --size)
> > +   *entries = *p;
> > +  p->~value_type ();
> >  #endif
> >  }
> >m_n_deleted = 0;
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: Make fix for PR 83965 handle SLP reduction chains

[Richard Biener]

On Tue, Feb 20, 2018 at 5:53 PM, Richard Sandiford
 wrote:
> This patch prevents pattern-matching of fold-left SLP reduction chains,
> which the previous patch for 83965 didn't handle properly.  It only
> stops the last statement in the group from being matched, but that's
> enough to cause the group to be dissolved later.
>
> A better fix would be to put all the information about the reduction
> on the the first statement in the reduction chain, so that every
> statement in the group can tell what the group is doing.  That doesn't
> seem like stage 4 material though.
>
> As it stands, things seem to be a bit of a mess.  In
> vect_force_simple_reduction we attach the reduction type and
> phi pointer to the last statement in a reduction chain:
>
>   reduc_def_info = vinfo_for_stmt (def);
>   STMT_VINFO_REDUC_TYPE (reduc_def_info) = v_reduc_type;
>   STMT_VINFO_REDUC_DEF (reduc_def_info) = phi;
>
> and mark it as vect_reduction_type in vect_analyze_scalar_cycles_1:
>
>   STMT_VINFO_DEF_TYPE (vinfo_for_stmt (reduc_stmt)) =
>vect_reduction_def;
>
> This code in vectorizable_reduction gave the impression that
> everything really is keyed off the last statement:
>
>   /* In case of reduction chain we switch to the first stmt in the chain, but
>  we don't update STMT_INFO, since only the last stmt is marked as 
> reduction
>  and has reduction properties.  */
>   if (GROUP_FIRST_ELEMENT (stmt_info)
>   && GROUP_FIRST_ELEMENT (stmt_info) != stmt)
> {
>   stmt = GROUP_FIRST_ELEMENT (stmt_info);
>   first_p = false;
> }
>
> But this code is dead these days.  GROUP_FIRST_ELEMENT is only nonnull
> for SLP reduction chains, since we dissolve the group if SLP fails.
> And SLP only analyses the first statement in the group, not the last:
>
>   stmt = SLP_TREE_SCALAR_STMTS (node)[0];
>   stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
>   [...]
>   bool res = vect_analyze_stmt (stmt, &dummy, node, node_instance);
>
> So from that point of view the DEF_TYPE, REDUC_TYPE and REDUC_DEF
> are being attached to the wrong statement, since we only analyse
> the first one.  But it turns out that REDUC_TYPE and REDUC_DEF
> don't matter for the first statement in the group, since that
> takes the phi as an input, and when the phi is a direct input,
> we use *its* REDUC_TYPE and REDUC_DEF instead of the statement's
> own info.  The DEF_TYPE problem is handled by:
>
>   /* Mark the first element of the reduction chain as reduction to 
> properly
>  transform the node.  In the reduction analysis phase only the last
>  element of the chain is marked as reduction.  */
>   if (!STMT_VINFO_GROUPED_ACCESS (vinfo_for_stmt (stmt)))
> STMT_VINFO_DEF_TYPE (vinfo_for_stmt (stmt)) = vect_reduction_def;
>
> in vect_analyze_slp_instance (cancelled by:
>
> STMT_VINFO_DEF_TYPE (vinfo_for_stmt (first_element))
>   = vect_internal_def;
>
> in vect_analyze_slp on failure), with the operation being repeated
> in vect_schedule_slp_instance (redundantly AFAICT):
>
>   /* Mark the first element of the reduction chain as reduction to properly
>  transform the node.  In the analysis phase only the last element of the
>  chain is marked as reduction.  */
>   if (GROUP_FIRST_ELEMENT (stmt_info) && !STMT_VINFO_GROUPED_ACCESS 
> (stmt_info)
>   && GROUP_FIRST_ELEMENT (stmt_info) == stmt)
> {
>   STMT_VINFO_DEF_TYPE (stmt_info) = vect_reduction_def;
>   STMT_VINFO_TYPE (stmt_info) = reduc_vec_info_type;
> }
>
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64-linux-gnu.
> OK to install?

Ok for stage1.

Richard.

> Richard
>
>
> 2018-02-20  Richard Sandiford  
>
> gcc/
> PR tree-optimization/83965
> * tree-vect-patterns.c (vect_reassociating_reduction_p): Assume
> that grouped statements are part of a reduction chain.  Return
> true if the statement is not marked as a reduction itself but
> is part of a group.
> (vect_recog_dot_prod_pattern): Don't check whether the statement
> is part of a group here.
> (vect_recog_sad_pattern): Likewise.
> (vect_recog_widen_sum_pattern): Likewise.
>
> gcc/testsuite/
> PR tree-optimization/83965
> * gcc.dg/vect/pr83965-2.c: New test.
>
> Index: gcc/tree-vect-patterns.c
> ===
> --- gcc/tree-vect-patterns.c2018-02-20 09:40:41.843451227 +
> +++ gcc/tree-vect-patterns.c2018-02-20 16:28:55.636762056 +
> @@ -222,13 +222,16 @@ vect_recog_temp_ssa_var (tree type, gimp
>  }
>
>  /* Return true if STMT_VINFO describes a reduction for which reassociation
> -   is allowed.  */
> +   is allowed.  If STMT_INFO is part of a group, assume that it's part of
> +   a reduction chain and optimistically assume that all statements
> +   except the last allow reassociatio

Re: [PATCH][committed][PR tree-optimization/82123] 01/06 Do nothing in EVRP analyzer is not optimizing

[Richard Biener]

On Tue, Feb 20, 2018 at 7:49 PM, Jeff Law  wrote:
> This is part #1 of the patches to fix 81592/82123.  The changes aren't
> particularly large or invasive, but I already had them broken down
> internally into distinct chunks, so I'm going to send them out that way.
>
> This patch allows the EVRP range analyzer to be safely called even when
> not optimizing.  It does no analysis in that case.   This prevents
> problems if we were to ask for sprintf warnings but not have the
> optimizer enabled.

I don't really understand the issue -- when called from sprintf warnings
the evrp analyzer shouldn't "optimize" anything, it only does analysis.
How is that ever a problem when not optimizing?

You're basically saying that with !optimize you don't want value-ranges
to be analyzed but you still use the evrp analyzing domwalk to drive
sprintf warnings?  Then that is the problem.  Don't use evrp analysis
if you don't want it.  So instead guard the evrp_range_analyzer.enter/leave ()
calls in sprintf_dom_walker?

The sprinkled !optimize tests in analysis infrastructure look bad.

Richard.

> Bootstrapped and regression tested on x86_64-linux-gnu.
>
> Jeff
>
> * gimple-ssa-evrp-analyze.c (evrp_range_analyzer::enter): Do nothing
> if not optimizing.
> (evrp_range_analyzer::record_ranges_from_stmt): Likewise.
> (evrp_range_analyzer::pop_to_marker): Likewise.
>
> diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
> index 2eb2769..b9dcf90 100644
> --- a/gcc/gimple-ssa-evrp-analyze.c
> +++ b/gcc/gimple-ssa-evrp-analyze.c
> @@ -69,6 +69,8 @@ evrp_range_analyzer::push_marker ()
>  void
>  evrp_range_analyzer::enter (basic_block bb)
>  {
> +  if (!optimize)
> +return;
>push_marker ();
>record_ranges_from_incoming_edge (bb);
>record_ranges_from_phis (bb);
> @@ -279,6 +281,9 @@ evrp_range_analyzer::record_ranges_from_stmt (gimple 
> *stmt, bool temporary)
>  {
>tree output = NULL_TREE;
>
> +  if (!optimize)
> +return;
> +
>if (dyn_cast  (stmt))
>  ;
>else if (stmt_interesting_for_vrp (stmt))
> @@ -390,6 +395,8 @@ evrp_range_analyzer::pop_to_marker (void)
>  void
>  evrp_range_analyzer::leave (basic_block bb ATTRIBUTE_UNUSED)
>  {
> +  if (!optimize)
> +return;
>pop_to_marker ();
>  }
>
>

Re: [PATCH] Fix bootstrap with GCC 3.4 (and likely anything < 4.4 except 4.2.[0-3]) (PR bootstrap/84405)

[Richard Biener]

On Mon, 26 Feb 2018, Jakub Jelinek wrote:

> On Mon, Feb 26, 2018 at 01:15:45PM +0100, Richard Biener wrote:
> > > I'd like to ping this patch, or if it isn't acceptable, at least the vec.h
> > > part of it which isn't really more complex than what we have right now.
> > 
> > So BROKEN_VALUE_INITIALIZATION doesn't really mean it's "broken" but
> > that is has certain behavior that doesn't invalidate the clearing
> > done earlier?  That said, I wonder if first doing the regular
> > construction and memset afterwards in case of
> > BROKEN_VALUE_INITIALIZATION wouldn't be more reliable and "easier"?
> 
> BROKEN_VALUE_INITIALIZATION means the value initialization is broken,
> where broken means that for certain cases (for 4.2.[0-3] more than others)
> it doesn't initialize the object or some subobjects at all.
> memset after wouldn't make any sense, that is equivalent to just memset.
> What the patch is meant to fix are cases where even the broken value
> initialization invokes a ctor (when T has user defined default ctor).
> 
> There are several cases of
> vec where ipa_polymorphic_call_context
> has user defined default ctor that doesn't clear the object, but instead
> sets a bunch of bool flags in it to true.  If we do just memset when
> built with older system G++ we get different behavior.
> 
> Even with the patch if BROKEN_VALUE_INITIALIZATION we won't handle e.g.
> cases where we'd have vec of a struct without user defined default ctor,
> but where one of the fields has ipa_polymorphic_call_context type or
> some other with non-trivial user defined default ctor that doesn't
> clear everything.  We don't have anything like that in the codebase
> right now, and if we would, a workaround would be to provide user defined
> default ctor for such types if we want to put them into vec.
> 
> Unlike the vec.h case, the hash-table.h is just for hypothetical case
> where we'd have a hash table with such types.

Ok, I see.  So the vec.h change is ok but please put a comment there
reflecting the above.

IMHO we should wait for the hypothetical case to happen for hash-table.h.

I still hope we can stop caring about too old GCC in a few years ;)

Richard.

> > > > --- gcc/vec.h.jj2018-02-16 19:39:03.637058918 +0100
> > > > +++ gcc/vec.h   2018-02-16 23:51:55.389582056 +0100
> > > > @@ -490,12 +490,11 @@ template 
> > > >  inline void
> > > >  vec_default_construct (T *dst, unsigned n)
> > > >  {
> > > > -#ifndef BROKEN_VALUE_INITIALIZATION
> > > > -  for ( ; n; ++dst, --n)
> > > > -::new (static_cast(dst)) T ();
> > > > -#else
> > > > +#ifdef BROKEN_VALUE_INITIALIZATION
> > > >memset (dst, '\0', sizeof (T) * n);
> > > >  #endif
> > > > +  for ( ; n; ++dst, --n)
> > > > +::new (static_cast(dst)) T ();
> > > >  }
> > > >  
> > > >  /* Copy-construct N elements in DST from *SRC.  */
> > > > --- gcc/hash-table.h.jj 2018-02-16 19:39:03.660058934 +0100
> > > > +++ gcc/hash-table.h2018-02-17 00:01:24.207723925 +0100
> > > > @@ -808,7 +808,18 @@ hash_table::empty
> > > >for ( ; size; ++entries, --size)
> > > > *entries = value_type ();
> > > >  #else
> > > > -  memset (entries, 0, size * sizeof (value_type));
> > > > +  /* To workaround older GCC versions which don't handle value
> > > > +initialization right, use a placement new into previously
> > > > +cleared buffer.  */
> > > > +  char buf[2 * sizeof (value_type) + 64];
> > > > +  gcc_assert (__alignof__ (value_type) <= sizeof (value_type) + 
> > > > 64);
> > > > +  char *q = (buf + sizeof (value_type) + 64
> > > > +- ((uintptr_t) buf % __alignof__ (value_type)));
> > > > +  memset (q, '\0', sizeof (value_type));
> > > > +  value_type *p = ::new (q) value_type ();
> > > > +  for ( ; size; ++entries, --size)
> > > > +   *entries = *p;
> > > > +  p->~value_type ();
> > > >  #endif
> > > >  }
> > > >m_n_deleted = 0;
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Richard Biener]

On Wed, Feb 21, 2018 at 11:32 AM, Alexandre Oliva  wrote:
> On Jan 24, 2018, Jakub Jelinek  wrote:
>
>>> --- a/gcc/tree-ssa-live.c
>>> +++ b/gcc/tree-ssa-live.c
>>> @@ -520,6 +520,11 @@ remove_unused_scope_block_p (tree scope, bool 
>>> in_ctor_dtor_block)
>>> else if (!BLOCK_SUPERCONTEXT (scope)
>>> || TREE_CODE (BLOCK_SUPERCONTEXT (scope)) == FUNCTION_DECL)
>>> unused = false;
>>> +   /* Preserve the block, it is referenced by at least the inline
>>> +  entry point marker.  */
>>> +   else if (debug_nonbind_markers_p
>>> +&& inlined_function_outer_scope_p (scope))
>>> + unused = false;
>>> /* Innermost blocks with no live variables nor statements can be always
>>> eliminated.  */
>>> else if (!nsubblocks)
>>> @@ -548,11 +553,13 @@ remove_unused_scope_block_p (tree scope, bool 
>>> in_ctor_dtor_block)
>>> }
>>> else if (BLOCK_VARS (scope) || BLOCK_NUM_NONLOCALIZED_VARS (scope))
>>> unused = false;
>>> -   /* See if this block is important for representation of inlined 
>>> function.
>>> -  Inlined functions are always represented by block with
>>> -  block_ultimate_origin being set to FUNCTION_DECL and 
>>> DECL_SOURCE_LOCATION
>>> -  set...  */
>>> -   else if (inlined_function_outer_scope_p (scope))
>>> +   /* See if this block is important for representation of inlined
>>> +  function.  Inlined functions are always represented by block
>>> +  with block_ultimate_origin being set to FUNCTION_DECL and
>>> +  DECL_SOURCE_LOCATION set, unless they expand to nothing...  But
>>> +  see above for the case of statement frontiers.  */
>>> +   else if (!debug_nonbind_markers_p
>>> +&& inlined_function_outer_scope_p (scope))
>>> unused = false;
>
>> Wonder what the above hunks will do for LTO memory consumption.  We'll see.
>
>
> [IEPM] don't preserve lexical blocks just for debug inline markers
>
> This patch stops preserving scope blocks just because they are inlined
> function scopes, when cleaning up unused scope blocks.  This change
> was introduced along with IEPM, but it preserved lots of blocks, and
> output debug information for them, although no code from the inlined
> function remained after optimization.
>
> The additional preserved blocks took up compile-time memory, and
> significant disk space and link time, in some cases more than 25%.
> This is deemed excessive, compared with the reasonably small benefit
> of allowing one to single-step into an inlined function using a
> view-capable debugger.
>
> There was another way of marking inlined function scopes as unused,
> based on the markers referencing them during stmt scanning, but that
> still preserved too much.
>
> So, this patch restores the pre-IEPM logic of preservation of scopes.
> Should a scope block referenced by an inline entry marker be found to
> be unused in remove_unused_scope_block_p, the marker will be cleaned
> up right after that, in clear_unused_block_pointer, so we won't keep
> a dangling reference to a dropped block.
>
> Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?

Ok.

Thanks,
Richard.

> for  gcc/ChangeLog
>
> * tree-ssa-live.c (remove_unused_scope_block_p): Do not
> preserve inline entry blocks for the sake of debug inline
> entry point markers alone.
> (remove_unused_locals): Suggest in comments a better place to
> force the preservation of inline entry blocks that are
> otherwise unused, but do not preserve them.
> ---
>  gcc/tree-ssa-live.c |   15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c
> index 62bb3c5de659..62316bac7929 100644
> --- a/gcc/tree-ssa-live.c
> +++ b/gcc/tree-ssa-live.c
> @@ -520,11 +520,6 @@ remove_unused_scope_block_p (tree scope, bool 
> in_ctor_dtor_block)
> else if (!BLOCK_SUPERCONTEXT (scope)
>  || TREE_CODE (BLOCK_SUPERCONTEXT (scope)) == FUNCTION_DECL)
>   unused = false;
> -   /* Preserve the block, it is referenced by at least the inline
> -  entry point marker.  */
> -   else if (debug_inline_points
> -   && inlined_function_outer_scope_p (scope))
> - unused = false;
> /* Innermost blocks with no live variables nor statements can be always
>eliminated.  */
> else if (!nsubblocks)
> @@ -556,10 +551,8 @@ remove_unused_scope_block_p (tree scope, bool 
> in_ctor_dtor_block)
> /* See if this block is important for representation of inlined
>function.  Inlined functions are always represented by block
>with block_ultimate_origin being set to FUNCTION_DECL and
> -  DECL_SOURCE_LOCATION set, unless they expand to nothing...  But
> -  see above for the case of statement frontiers.  */
> -   else if (!debug_inline_points
> -   && inlined_function_outer_scope_p (scope))
> +  DECL_SOURCE_LOCATION set, unless they expand to nothing...  */
> +   else if (inlined_function_outer_scope_p (scope))
>   unused = false;
> e

Re: Fix slow value range hash

[Jakub Jelinek]

On Mon, Feb 26, 2018 at 12:04:53PM +0100, Jan Hubicka wrote:
> Hi,
> this is patch Jakub posted to IRC while discussing slow ipa-cp jump function
> streaming. The problem is that hash hashes types as iterative types but later
> compares them as pointers.  Iterative hash is trying to make semantically
> equivalent types really equivalent.
> 
> Alternatively we may try to unify types that are semantically equivalent
> but it seems bit slopy to do at stage4.
> 
> Bootstrapped/regtested x86_64-linux, OK?

Please see http://gcc.gnu.org/r257940 , it is already committed.

Jakub

Re: [PATCH] Fix bootstrap with GCC 3.4 (and likely anything < 4.4 except 4.2.[0-3]) (PR bootstrap/84405)

[Jakub Jelinek]

On Mon, Feb 26, 2018 at 01:15:45PM +0100, Richard Biener wrote:
> > I'd like to ping this patch, or if it isn't acceptable, at least the vec.h
> > part of it which isn't really more complex than what we have right now.
> 
> So BROKEN_VALUE_INITIALIZATION doesn't really mean it's "broken" but
> that is has certain behavior that doesn't invalidate the clearing
> done earlier?  That said, I wonder if first doing the regular
> construction and memset afterwards in case of
> BROKEN_VALUE_INITIALIZATION wouldn't be more reliable and "easier"?

BROKEN_VALUE_INITIALIZATION means the value initialization is broken,
where broken means that for certain cases (for 4.2.[0-3] more than others)
it doesn't initialize the object or some subobjects at all.
memset after wouldn't make any sense, that is equivalent to just memset.
What the patch is meant to fix are cases where even the broken value
initialization invokes a ctor (when T has user defined default ctor).

There are several cases of
vec where ipa_polymorphic_call_context
has user defined default ctor that doesn't clear the object, but instead
sets a bunch of bool flags in it to true.  If we do just memset when
built with older system G++ we get different behavior.

Even with the patch if BROKEN_VALUE_INITIALIZATION we won't handle e.g.
cases where we'd have vec of a struct without user defined default ctor,
but where one of the fields has ipa_polymorphic_call_context type or
some other with non-trivial user defined default ctor that doesn't
clear everything.  We don't have anything like that in the codebase
right now, and if we would, a workaround would be to provide user defined
default ctor for such types if we want to put them into vec.

Unlike the vec.h case, the hash-table.h is just for hypothetical case
where we'd have a hash table with such types.

> > > --- gcc/vec.h.jj  2018-02-16 19:39:03.637058918 +0100
> > > +++ gcc/vec.h 2018-02-16 23:51:55.389582056 +0100
> > > @@ -490,12 +490,11 @@ template 
> > >  inline void
> > >  vec_default_construct (T *dst, unsigned n)
> > >  {
> > > -#ifndef BROKEN_VALUE_INITIALIZATION
> > > -  for ( ; n; ++dst, --n)
> > > -::new (static_cast(dst)) T ();
> > > -#else
> > > +#ifdef BROKEN_VALUE_INITIALIZATION
> > >memset (dst, '\0', sizeof (T) * n);
> > >  #endif
> > > +  for ( ; n; ++dst, --n)
> > > +::new (static_cast(dst)) T ();
> > >  }
> > >  
> > >  /* Copy-construct N elements in DST from *SRC.  */
> > > --- gcc/hash-table.h.jj   2018-02-16 19:39:03.660058934 +0100
> > > +++ gcc/hash-table.h  2018-02-17 00:01:24.207723925 +0100
> > > @@ -808,7 +808,18 @@ hash_table::empty
> > >for ( ; size; ++entries, --size)
> > >   *entries = value_type ();
> > >  #else
> > > -  memset (entries, 0, size * sizeof (value_type));
> > > +  /* To workaround older GCC versions which don't handle value
> > > +  initialization right, use a placement new into previously
> > > +  cleared buffer.  */
> > > +  char buf[2 * sizeof (value_type) + 64];
> > > +  gcc_assert (__alignof__ (value_type) <= sizeof (value_type) + 64);
> > > +  char *q = (buf + sizeof (value_type) + 64
> > > +  - ((uintptr_t) buf % __alignof__ (value_type)));
> > > +  memset (q, '\0', sizeof (value_type));
> > > +  value_type *p = ::new (q) value_type ();
> > > +  for ( ; size; ++entries, --size)
> > > + *entries = *p;
> > > +  p->~value_type ();
> > >  #endif
> > >  }
> > >m_n_deleted = 0;

Jakub

Re: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs

[Tom de Vries]

On 02/26/2018 12:00 PM, Matthew Fortune wrote:

Tom de Vries  writes:

On 01/08/2018 05:32 PM, Tom de Vries wrote:

On 12/18/2017 05:57 PM, Vladimir Makarov wrote:



On 12/15/2017 06:25 AM, Tom de Vries wrote:


Proposed Solution:

The patch addresses the problem, by:
- marking the hard regs that have been used in lra_spill in
   hard_regs_spilled_into
- using hard_regs_spilled_into in lra_create_live_ranges to
   make sure those registers are marked in the conflict_hard_regs
   of pseudos that overlap with the spill register usage

[ I've also tried an approach where I didn't use
hard_regs_spilled_into, but tried to propagate all hard regs. I
figured out that I needed to mask out eliminable_regset.  Also I
needed to masked out lra_no_alloc_regs, but that could be due to
gcn-specific problems (pointers take 2 hard regs), I'm not yet sure.
Anyway, in the submitted patch I tried to avoid these problems and
went for the more minimal approach. ]


Tom, thank you for the detail explanation of the problem and
solutions you considered.  It helped me a lot.  Your simple solution
is adequate as the most transformations and allocation are done on
the 1st LRA subpasses iteration.

In order to get the patch accepted for trunk, I think we need:
- bootstrap and reg-test on x86_64
- build and reg-test on mips (the only primary platform that has the
   spill_class hook enabled)

Any comments?


The patch looks ok to me.  You can commit it after successful testing
on x86-64 and mips but I am sure there will be no problems with
x86-64 as it does not use spill_class currently (actually your patch
might help to switch it on again for x86-64.  spill_class was quite
useful for x86-64 performance on Intel processors).



Hi Matthew,

there's an lra optimization that is currently enabled for MIPS, and
not for any other primary or secondary target.

This (already approved) patch fixes a bug in that optimization, and
needs to be tested on MIPS.

Unfortunately, the optimization is only enabled for MIPS16, and we
don't have a current setup to test this.

Could you help us out here and test this patch for MIPS16 on trunk?


Hi Matthew,

is this something you can help us out with?


Hi Tom,

I've just commented on the bug report that I've set of some builds to try
and give some assurance. It is far from comprehensive but it is as good as
the normal testing I do for MIPS16.



Hi Matthew,

Awesome, thanks for the help.

- Tom

Re: C++ PATCH to fix ICE with suggestions (PR c++/84537)

[Jason Merrill]

OK.

On Mon, Feb 26, 2018 at 4:44 AM, Marek Polacek  wrote:
> Here error_mark_node leaks all the way to edit_distance_traits::get_string
> which crashed, so let's not try to give a suggestion for an error node in
> the first place.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-02-26  Marek Polacek  
>
> PR c++/84537
> * name-lookup.c (suggest_alternative_in_explicit_scope): Return false
> if name is error node.
>
> * g++.dg/parse/error60.C: New test.
>
> diff --git gcc/cp/name-lookup.c gcc/cp/name-lookup.c
> index 9117e0b30eb..0f00328e96e 100644
> --- gcc/cp/name-lookup.c
> +++ gcc/cp/name-lookup.c
> @@ -5541,6 +5541,10 @@ bool
>  suggest_alternative_in_explicit_scope (location_t location, tree name,
>tree scope)
>  {
> +  /* Something went very wrong; don't suggest anything.  */
> +  if (name == error_mark_node)
> +return false;
> +
>/* Resolve any namespace aliases.  */
>scope = ORIGINAL_NAMESPACE (scope);
>
> diff --git gcc/testsuite/g++.dg/parse/error60.C 
> gcc/testsuite/g++.dg/parse/error60.C
> index e69de29bb2d..38f4e34c59d 100644
> --- gcc/testsuite/g++.dg/parse/error60.C
> +++ gcc/testsuite/g++.dg/parse/error60.C
> @@ -0,0 +1,9 @@
> +// PR c++/84537
> +// { dg-do compile }
> +
> +namespace N
> +{
> +  template struct A {};
> +}
> +
> +N::template A<> a; // { dg-error "" }
>
> Marek

Re: [C++ Patch] Define build_capture_proxy as static

[Jason Merrill]

OK.

On Mon, Feb 26, 2018 at 5:22 AM, Paolo Carlini  wrote:
> Hi,
>
> today noticed this straightforward nit trivial enough for this stage?
>
> Thanks, Paolo.
>
> /
>

Re: [C++ Patch] PR 84533 ("[7/8 Regression] ICE with duplicate enum value")

[Jason Merrill]

OK.

On Mon, Feb 26, 2018 at 5:19 AM, Paolo Carlini  wrote:
> Hi,
>
> this ICE on invalid happens only in c++17 mode, when
> redeclaration_error_message performs an additional check which only makes
> sense for data members. Thus the fix is easy: avoid checking
> DECL_DECLARED_CONSTEXPR_P on CONST_DECLs.
>
> Tested x86_64-linux.
>
> Thanks, Paolo.
>
> //
>

RE: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs

[Matthew Fortune]

Tom de Vries  writes:
> On 02/26/2018 12:00 PM, Matthew Fortune wrote:
> > Tom de Vries  writes:
> >> On 01/08/2018 05:32 PM, Tom de Vries wrote:
> >>> On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
> 
> 
>  On 12/15/2017 06:25 AM, Tom de Vries wrote:
> >
> > Proposed Solution:
> >
> > The patch addresses the problem, by:
> > - marking the hard regs that have been used in lra_spill in
> >    hard_regs_spilled_into
> > - using hard_regs_spilled_into in lra_create_live_ranges to
> >    make sure those registers are marked in the conflict_hard_regs
> >    of pseudos that overlap with the spill register usage
> >
> > [ I've also tried an approach where I didn't use
> > hard_regs_spilled_into, but tried to propagate all hard regs. I
> > figured out that I needed to mask out eliminable_regset.  Also I
> > needed to masked out lra_no_alloc_regs, but that could be due to
> > gcn-specific problems (pointers take 2 hard regs), I'm not yet
> sure.
> > Anyway, in the submitted patch I tried to avoid these problems and
> > went for the more minimal approach. ]
> >
>  Tom, thank you for the detail explanation of the problem and
>  solutions you considered.  It helped me a lot.  Your simple
>  solution is adequate as the most transformations and allocation are
>  done on the 1st LRA subpasses iteration.
> > In order to get the patch accepted for trunk, I think we need:
> > - bootstrap and reg-test on x86_64
> > - build and reg-test on mips (the only primary platform that has
> > the
> >    spill_class hook enabled)
> >
> > Any comments?
> 
>  The patch looks ok to me.  You can commit it after successful
>  testing on x86-64 and mips but I am sure there will be no problems
>  with
>  x86-64 as it does not use spill_class currently (actually your
>  patch might help to switch it on again for x86-64.  spill_class was
>  quite useful for x86-64 performance on Intel processors).
> 
> >>>
> >>> Hi Matthew,
> >>>
> >>> there's an lra optimization that is currently enabled for MIPS, and
> >>> not for any other primary or secondary target.
> >>>
> >>> This (already approved) patch fixes a bug in that optimization, and
> >>> needs to be tested on MIPS.
> >>>
> >>> Unfortunately, the optimization is only enabled for MIPS16, and we
> >>> don't have a current setup to test this.
> >>>
> >>> Could you help us out here and test this patch for MIPS16 on trunk?
> >>
> >> Hi Matthew,
> >>
> >> is this something you can help us out with?
> >
> > Hi Tom,
> >
> > I've just commented on the bug report that I've set of some builds to
> > try and give some assurance. It is far from comprehensive but it is as
> > good as the normal testing I do for MIPS16.
> >
> 
> Hi Matthew,
> 
> Awesome, thanks for the help.

I'm afraid my lack of attention has shown that there appears to be a
bug preventing libstdc++ building with MIPS16 that was introduced
somewhere between Oct 9th and Oct 10th. 47 commits left to bisect.

Matthew

Re: Make fix for PR 83965 handle SLP reduction chains

[Richard Sandiford]

Richard Biener  writes:
> On Tue, Feb 20, 2018 at 5:53 PM, Richard Sandiford
>  wrote:
>> This patch prevents pattern-matching of fold-left SLP reduction chains,
>> which the previous patch for 83965 didn't handle properly.  It only
>> stops the last statement in the group from being matched, but that's
>> enough to cause the group to be dissolved later.
>>
>> A better fix would be to put all the information about the reduction
>> on the the first statement in the reduction chain, so that every
>> statement in the group can tell what the group is doing.  That doesn't
>> seem like stage 4 material though.
>>
>> As it stands, things seem to be a bit of a mess.  In
>> vect_force_simple_reduction we attach the reduction type and
>> phi pointer to the last statement in a reduction chain:
>>
>>   reduc_def_info = vinfo_for_stmt (def);
>>   STMT_VINFO_REDUC_TYPE (reduc_def_info) = v_reduc_type;
>>   STMT_VINFO_REDUC_DEF (reduc_def_info) = phi;
>>
>> and mark it as vect_reduction_type in vect_analyze_scalar_cycles_1:
>>
>>   STMT_VINFO_DEF_TYPE (vinfo_for_stmt (reduc_stmt)) =
>>
>> vect_reduction_def;
>>
>> This code in vectorizable_reduction gave the impression that
>> everything really is keyed off the last statement:
>>
>>   /* In case of reduction chain we switch to the first stmt in the chain, but
>>  we don't update STMT_INFO, since only the last stmt is marked as 
>> reduction
>>  and has reduction properties.  */
>>   if (GROUP_FIRST_ELEMENT (stmt_info)
>>   && GROUP_FIRST_ELEMENT (stmt_info) != stmt)
>> {
>>   stmt = GROUP_FIRST_ELEMENT (stmt_info);
>>   first_p = false;
>> }
>>
>> But this code is dead these days.  GROUP_FIRST_ELEMENT is only nonnull
>> for SLP reduction chains, since we dissolve the group if SLP fails.
>> And SLP only analyses the first statement in the group, not the last:
>>
>>   stmt = SLP_TREE_SCALAR_STMTS (node)[0];
>>   stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
>>   [...]
>>   bool res = vect_analyze_stmt (stmt, &dummy, node, node_instance);
>>
>> So from that point of view the DEF_TYPE, REDUC_TYPE and REDUC_DEF
>> are being attached to the wrong statement, since we only analyse
>> the first one.  But it turns out that REDUC_TYPE and REDUC_DEF
>> don't matter for the first statement in the group, since that
>> takes the phi as an input, and when the phi is a direct input,
>> we use *its* REDUC_TYPE and REDUC_DEF instead of the statement's
>> own info.  The DEF_TYPE problem is handled by:
>>
>>   /* Mark the first element of the reduction chain as reduction to 
>> properly
>>  transform the node.  In the reduction analysis phase only the last
>>  element of the chain is marked as reduction.  */
>>   if (!STMT_VINFO_GROUPED_ACCESS (vinfo_for_stmt (stmt)))
>> STMT_VINFO_DEF_TYPE (vinfo_for_stmt (stmt)) = vect_reduction_def;
>>
>> in vect_analyze_slp_instance (cancelled by:
>>
>> STMT_VINFO_DEF_TYPE (vinfo_for_stmt (first_element))
>>   = vect_internal_def;
>>
>> in vect_analyze_slp on failure), with the operation being repeated
>> in vect_schedule_slp_instance (redundantly AFAICT):
>>
>>   /* Mark the first element of the reduction chain as reduction to properly
>>  transform the node.  In the analysis phase only the last element of the
>>  chain is marked as reduction.  */
>>   if (GROUP_FIRST_ELEMENT (stmt_info) && !STMT_VINFO_GROUPED_ACCESS 
>> (stmt_info)
>>   && GROUP_FIRST_ELEMENT (stmt_info) == stmt)
>> {
>>   STMT_VINFO_DEF_TYPE (stmt_info) = vect_reduction_def;
>>   STMT_VINFO_TYPE (stmt_info) = reduc_vec_info_type;
>> }
>>
>> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64-linux-gnu.
>> OK to install?
>
> Ok for stage1.

It's a GCC 8 regression, so OK for stage4?

Richard

> Richard.
>
>> Richard
>>
>>
>> 2018-02-20  Richard Sandiford  
>>
>> gcc/
>> PR tree-optimization/83965
>> * tree-vect-patterns.c (vect_reassociating_reduction_p): Assume
>> that grouped statements are part of a reduction chain.  Return
>> true if the statement is not marked as a reduction itself but
>> is part of a group.
>> (vect_recog_dot_prod_pattern): Don't check whether the statement
>> is part of a group here.
>> (vect_recog_sad_pattern): Likewise.
>> (vect_recog_widen_sum_pattern): Likewise.
>>
>> gcc/testsuite/
>> PR tree-optimization/83965
>> * gcc.dg/vect/pr83965-2.c: New test.
>>
>> Index: gcc/tree-vect-patterns.c
>> ===
>> --- gcc/tree-vect-patterns.c2018-02-20 09:40:41.843451227 +
>> +++ gcc/tree-vect-patterns.c2018-02-20 16:28:55.636762056 +
>> @@ -222,13 +222,16 @@ vect_recog_temp_ssa_var (tree type, gimp
>>  }
>>
>>  /* Return true if STMT_VINFO describes a reduction for which reassociation
>> -   i

Re: Make fix for PR 83965 handle SLP reduction chains

[Richard Biener]

On Mon, Feb 26, 2018 at 3:37 PM, Richard Sandiford
 wrote:
> Richard Biener  writes:
>> On Tue, Feb 20, 2018 at 5:53 PM, Richard Sandiford
>>  wrote:
>>> This patch prevents pattern-matching of fold-left SLP reduction chains,
>>> which the previous patch for 83965 didn't handle properly.  It only
>>> stops the last statement in the group from being matched, but that's
>>> enough to cause the group to be dissolved later.
>>>
>>> A better fix would be to put all the information about the reduction
>>> on the the first statement in the reduction chain, so that every
>>> statement in the group can tell what the group is doing.  That doesn't
>>> seem like stage 4 material though.
>>>
>>> As it stands, things seem to be a bit of a mess.  In
>>> vect_force_simple_reduction we attach the reduction type and
>>> phi pointer to the last statement in a reduction chain:
>>>
>>>   reduc_def_info = vinfo_for_stmt (def);
>>>   STMT_VINFO_REDUC_TYPE (reduc_def_info) = v_reduc_type;
>>>   STMT_VINFO_REDUC_DEF (reduc_def_info) = phi;
>>>
>>> and mark it as vect_reduction_type in vect_analyze_scalar_cycles_1:
>>>
>>>   STMT_VINFO_DEF_TYPE (vinfo_for_stmt (reduc_stmt)) =
>>>
>>> vect_reduction_def;
>>>
>>> This code in vectorizable_reduction gave the impression that
>>> everything really is keyed off the last statement:
>>>
>>>   /* In case of reduction chain we switch to the first stmt in the chain, 
>>> but
>>>  we don't update STMT_INFO, since only the last stmt is marked as 
>>> reduction
>>>  and has reduction properties.  */
>>>   if (GROUP_FIRST_ELEMENT (stmt_info)
>>>   && GROUP_FIRST_ELEMENT (stmt_info) != stmt)
>>> {
>>>   stmt = GROUP_FIRST_ELEMENT (stmt_info);
>>>   first_p = false;
>>> }
>>>
>>> But this code is dead these days.  GROUP_FIRST_ELEMENT is only nonnull
>>> for SLP reduction chains, since we dissolve the group if SLP fails.
>>> And SLP only analyses the first statement in the group, not the last:
>>>
>>>   stmt = SLP_TREE_SCALAR_STMTS (node)[0];
>>>   stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
>>>   [...]
>>>   bool res = vect_analyze_stmt (stmt, &dummy, node, node_instance);
>>>
>>> So from that point of view the DEF_TYPE, REDUC_TYPE and REDUC_DEF
>>> are being attached to the wrong statement, since we only analyse
>>> the first one.  But it turns out that REDUC_TYPE and REDUC_DEF
>>> don't matter for the first statement in the group, since that
>>> takes the phi as an input, and when the phi is a direct input,
>>> we use *its* REDUC_TYPE and REDUC_DEF instead of the statement's
>>> own info.  The DEF_TYPE problem is handled by:
>>>
>>>   /* Mark the first element of the reduction chain as reduction to 
>>> properly
>>>  transform the node.  In the reduction analysis phase only the last
>>>  element of the chain is marked as reduction.  */
>>>   if (!STMT_VINFO_GROUPED_ACCESS (vinfo_for_stmt (stmt)))
>>> STMT_VINFO_DEF_TYPE (vinfo_for_stmt (stmt)) = vect_reduction_def;
>>>
>>> in vect_analyze_slp_instance (cancelled by:
>>>
>>> STMT_VINFO_DEF_TYPE (vinfo_for_stmt (first_element))
>>>   = vect_internal_def;
>>>
>>> in vect_analyze_slp on failure), with the operation being repeated
>>> in vect_schedule_slp_instance (redundantly AFAICT):
>>>
>>>   /* Mark the first element of the reduction chain as reduction to properly
>>>  transform the node.  In the analysis phase only the last element of the
>>>  chain is marked as reduction.  */
>>>   if (GROUP_FIRST_ELEMENT (stmt_info) && !STMT_VINFO_GROUPED_ACCESS 
>>> (stmt_info)
>>>   && GROUP_FIRST_ELEMENT (stmt_info) == stmt)
>>> {
>>>   STMT_VINFO_DEF_TYPE (stmt_info) = vect_reduction_def;
>>>   STMT_VINFO_TYPE (stmt_info) = reduc_vec_info_type;
>>> }
>>>
>>> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64-linux-gnu.
>>> OK to install?
>>
>> Ok for stage1.
>
> It's a GCC 8 regression, so OK for stage4?

Oh, ok then.

Richard.

> Richard
>
>> Richard.
>>
>>> Richard
>>>
>>>
>>> 2018-02-20  Richard Sandiford  
>>>
>>> gcc/
>>> PR tree-optimization/83965
>>> * tree-vect-patterns.c (vect_reassociating_reduction_p): Assume
>>> that grouped statements are part of a reduction chain.  Return
>>> true if the statement is not marked as a reduction itself but
>>> is part of a group.
>>> (vect_recog_dot_prod_pattern): Don't check whether the statement
>>> is part of a group here.
>>> (vect_recog_sad_pattern): Likewise.
>>> (vect_recog_widen_sum_pattern): Likewise.
>>>
>>> gcc/testsuite/
>>> PR tree-optimization/83965
>>> * gcc.dg/vect/pr83965-2.c: New test.
>>>
>>> Index: gcc/tree-vect-patterns.c
>>> ===
>>> --- gcc/tree-vect-patterns.c2018-02-20 09:40:41.843451227 +
>>> +++ gcc/tree-vect-pat

Re: [PATCH] i386: Update -mfunction-return= for return with pop

[Jan Hubicka]

> On Mon, Feb 26, 2018 at 2:58 AM, Jan Hubicka  wrote:
> >> On Mon, Feb 26, 2018 at 2:05 AM, Martin Liška  wrote:
> >> > On 02/25/2018 02:37 AM, H.J. Lu wrote:
> >> >>   PR target/r84530
> >> >
> >> > Just a nit I've noticed:
> >> >
> >> > s/r84530/84530
> >>
> >> Fixed.
> >>
> >> --
> >> H.J.
> >
> >> From f08b8721ed038cefcee5a0bb1329b90a2d322269 Mon Sep 17 00:00:00 2001
> >> From: "H.J. Lu" 
> >> Date: Sat, 24 Feb 2018 05:05:49 -0800
> >> Subject: [PATCH] i386: Update -mfunction-return= for return with pop
> >>
> >> When -mfunction-return= is used, simple_return_pop_internal should pop
> >> return address into ECX register, adjust stack by bytes to pop from stack
> >> and jump to the return thunk via ECX register.
> >>
> >> Tested on i686 and x86-64.
> >>
> >>   PR target/84530
> >>   * config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove
> >>   the bool argument.
> >>   (ix86_output_indirect_function_return): New prototype.
> >>   (ix86_split_simple_return_pop_internal): Likewise.
> >>   * config/i386/i386.c (indirect_return_via_cx): New.
> >>   (indirect_return_via_cx_bnd): Likewise.
> >>   (indirect_thunk_name): Handle return va CX_REG.
> >>   (output_indirect_thunk_function): Create alias for
> >>   __x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd.
> >>   (ix86_output_indirect_jmp): Remove the bool argument.
> >>   (ix86_output_indirect_function_return): New function.
> >>   (ix86_split_simple_return_pop_internal): Likewise.
> >>   * config/i386/i386.md (*indirect_jump): Don't pass false
> >>   to ix86_output_indirect_jmp.
> >>   (*tablejump_1): Likewise.
> >>   (simple_return_pop_internal): Change it to define_insn_and_split.
> >>   Call ix86_split_simple_return_pop_internal to split it for
> >>   -mfunction-return=.
> >>   (simple_return_indirect_internal): Call
> >>   ix86_output_indirect_function_return instead of
> >>   ix86_output_indirect_jmp.
> >
> > It seems to make sense. Since LLVM has picked up our thunk names now,
> > I wonder if they have same bug or someohow already assigned a name
> > to this thunk. In the second case we probably ought to match it. Do
> > you know what LLVM uses?
> >
> 
> I don't think LLVM has implemented -mfunction-return=.   I disclosed
> my -mindirect-branch= approach to LLVM last year.  At the time, they
> wanted freedom in their implementation and didn't want to be compatible
> with mine.   Later they added GCC compatibility so that LLVM may be
> used to compile Linux kernel.  I believe it will be the same case if this
> option is used to compile Linux kernel.

Patch is OK then, thanks!

Honza
> 
> BTW, is my patch:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html
> 
> OK for trunk?  The review died at
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01355.html
> 
> Thanks.
> 
> -- 
> H.J.

Re: [PATCH] i386: Update -mfunction-return= for return with pop

[H.J. Lu]

On Mon, Feb 26, 2018 at 7:06 AM, Jan Hubicka  wrote:
>> On Mon, Feb 26, 2018 at 2:58 AM, Jan Hubicka  wrote:
>> >> On Mon, Feb 26, 2018 at 2:05 AM, Martin Liška  wrote:
>> >> > On 02/25/2018 02:37 AM, H.J. Lu wrote:
>> >> >>   PR target/r84530
>> >> >
>> >> > Just a nit I've noticed:
>> >> >
>> >> > s/r84530/84530
>> >>
>> >> Fixed.
>> >>
>> >> --
>> >> H.J.
>> >
>> >> From f08b8721ed038cefcee5a0bb1329b90a2d322269 Mon Sep 17 00:00:00 2001
>> >> From: "H.J. Lu" 
>> >> Date: Sat, 24 Feb 2018 05:05:49 -0800
>> >> Subject: [PATCH] i386: Update -mfunction-return= for return with pop
>> >>
>> >> When -mfunction-return= is used, simple_return_pop_internal should pop
>> >> return address into ECX register, adjust stack by bytes to pop from stack
>> >> and jump to the return thunk via ECX register.
>> >>
>> >> Tested on i686 and x86-64.
>> >>
>> >>   PR target/84530
>> >>   * config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove
>> >>   the bool argument.
>> >>   (ix86_output_indirect_function_return): New prototype.
>> >>   (ix86_split_simple_return_pop_internal): Likewise.
>> >>   * config/i386/i386.c (indirect_return_via_cx): New.
>> >>   (indirect_return_via_cx_bnd): Likewise.
>> >>   (indirect_thunk_name): Handle return va CX_REG.
>> >>   (output_indirect_thunk_function): Create alias for
>> >>   __x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd.
>> >>   (ix86_output_indirect_jmp): Remove the bool argument.
>> >>   (ix86_output_indirect_function_return): New function.
>> >>   (ix86_split_simple_return_pop_internal): Likewise.
>> >>   * config/i386/i386.md (*indirect_jump): Don't pass false
>> >>   to ix86_output_indirect_jmp.
>> >>   (*tablejump_1): Likewise.
>> >>   (simple_return_pop_internal): Change it to define_insn_and_split.
>> >>   Call ix86_split_simple_return_pop_internal to split it for
>> >>   -mfunction-return=.
>> >>   (simple_return_indirect_internal): Call
>> >>   ix86_output_indirect_function_return instead of
>> >>   ix86_output_indirect_jmp.
>> >
>> > It seems to make sense. Since LLVM has picked up our thunk names now,
>> > I wonder if they have same bug or someohow already assigned a name
>> > to this thunk. In the second case we probably ought to match it. Do
>> > you know what LLVM uses?
>> >
>>
>> I don't think LLVM has implemented -mfunction-return=.   I disclosed
>> my -mindirect-branch= approach to LLVM last year.  At the time, they
>> wanted freedom in their implementation and didn't want to be compatible
>> with mine.   Later they added GCC compatibility so that LLVM may be
>> used to compile Linux kernel.  I believe it will be the same case if this
>> option is used to compile Linux kernel.
>
> Patch is OK then, thanks!
>

Checked into trunk.  OK for backport to GCC 7 branch after a few days?


-- 
H.J.

Fix PR debug/84545

[Eric Botcazou]

This fixes the slew of -fcompare-debug regressions present in the testsuite 
for targets with delay slots and caused by REG_CALL_ARG_LOCATION notes still 
present in the .final dumps.

Tested on SPARC64/Linux and x86-64/Linux, applied on the mainline as obvious.


2018-02-26  Eric Botcazou  

PR debug/84545
* final.c (rest_of_clean_state): Also look for calls inside sequences.

-- 
Eric BotcazouIndex: final.c
===
--- final.c	(revision 257983)
+++ final.c	(working copy)
@@ -4845,11 +4845,19 @@ rest_of_clean_state (void)
   SET_NEXT_INSN (insn) = NULL;
   SET_PREV_INSN (insn) = NULL;
 
-  if (CALL_P (insn))
+  rtx_insn *call_insn = insn;
+  if (NONJUMP_INSN_P (call_insn)
+	  && GET_CODE (PATTERN (call_insn)) == SEQUENCE)
 	{
-	  rtx note = find_reg_note (insn, REG_CALL_ARG_LOCATION, NULL_RTX);
+	  rtx_sequence *seq = as_a  (PATTERN (call_insn));
+	  call_insn = seq->insn (0);
+	}
+  if (CALL_P (call_insn))
+	{
+	  rtx note
+	= find_reg_note (call_insn, REG_CALL_ARG_LOCATION, NULL_RTX);
 	  if (note)
-	remove_note (insn, note);
+	remove_note (call_insn, note);
 	}
 
   if (final_output

Re: [PATCH] i386: Update -mfunction-return= for return with pop

[Jan Hubicka]

> On Mon, Feb 26, 2018 at 7:06 AM, Jan Hubicka  wrote:
> >> On Mon, Feb 26, 2018 at 2:58 AM, Jan Hubicka  wrote:
> >> >> On Mon, Feb 26, 2018 at 2:05 AM, Martin Liška  wrote:
> >> >> > On 02/25/2018 02:37 AM, H.J. Lu wrote:
> >> >> >>   PR target/r84530
> >> >> >
> >> >> > Just a nit I've noticed:
> >> >> >
> >> >> > s/r84530/84530
> >> >>
> >> >> Fixed.
> >> >>
> >> >> --
> >> >> H.J.
> >> >
> >> >> From f08b8721ed038cefcee5a0bb1329b90a2d322269 Mon Sep 17 00:00:00 2001
> >> >> From: "H.J. Lu" 
> >> >> Date: Sat, 24 Feb 2018 05:05:49 -0800
> >> >> Subject: [PATCH] i386: Update -mfunction-return= for return with pop
> >> >>
> >> >> When -mfunction-return= is used, simple_return_pop_internal should pop
> >> >> return address into ECX register, adjust stack by bytes to pop from 
> >> >> stack
> >> >> and jump to the return thunk via ECX register.
> >> >>
> >> >> Tested on i686 and x86-64.
> >> >>
> >> >>   PR target/84530
> >> >>   * config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove
> >> >>   the bool argument.
> >> >>   (ix86_output_indirect_function_return): New prototype.
> >> >>   (ix86_split_simple_return_pop_internal): Likewise.
> >> >>   * config/i386/i386.c (indirect_return_via_cx): New.
> >> >>   (indirect_return_via_cx_bnd): Likewise.
> >> >>   (indirect_thunk_name): Handle return va CX_REG.
> >> >>   (output_indirect_thunk_function): Create alias for
> >> >>   __x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd.
> >> >>   (ix86_output_indirect_jmp): Remove the bool argument.
> >> >>   (ix86_output_indirect_function_return): New function.
> >> >>   (ix86_split_simple_return_pop_internal): Likewise.
> >> >>   * config/i386/i386.md (*indirect_jump): Don't pass false
> >> >>   to ix86_output_indirect_jmp.
> >> >>   (*tablejump_1): Likewise.
> >> >>   (simple_return_pop_internal): Change it to define_insn_and_split.
> >> >>   Call ix86_split_simple_return_pop_internal to split it for
> >> >>   -mfunction-return=.
> >> >>   (simple_return_indirect_internal): Call
> >> >>   ix86_output_indirect_function_return instead of
> >> >>   ix86_output_indirect_jmp.
> >> >
> >> > It seems to make sense. Since LLVM has picked up our thunk names now,
> >> > I wonder if they have same bug or someohow already assigned a name
> >> > to this thunk. In the second case we probably ought to match it. Do
> >> > you know what LLVM uses?
> >> >
> >>
> >> I don't think LLVM has implemented -mfunction-return=.   I disclosed
> >> my -mindirect-branch= approach to LLVM last year.  At the time, they
> >> wanted freedom in their implementation and didn't want to be compatible
> >> with mine.   Later they added GCC compatibility so that LLVM may be
> >> used to compile Linux kernel.  I believe it will be the same case if this
> >> option is used to compile Linux kernel.
> >
> > Patch is OK then, thanks!
> >
> 
> Checked into trunk.  OK for backport to GCC 7 branch after a few days?
OK,
thanks!
Honza
> 
> 
> -- 
> H.J.

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[Jan Hubicka]

Hi,
my main concern about the patch is that we now have 
-mindirect-branch=thunk-extern
which is intended to work well and is used by kernel, but we also have other 
modes
that are documented and as such they should work but they may lead to invalid
unwind info (or did I miss anything imporant here?).
Why we can't fix the others as well? 

Honza

Re: [PATCH][committed] Fix ICE in maybe_record_trace_start

[Tom de Vries]

On 02/23/2018 04:59 PM, Jeff Law wrote:

On 02/22/2018 03:59 AM, Tom de Vries wrote:

On 02/12/2018 07:32 PM, Jeff Law wrote:

diff --git a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
new file mode 100644
index 000..0ca0b9f034b
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
@@ -0,0 +1,36 @@
+int foo;
+typedef long unsigned int size_t;
+typedef short unsigned int wchar_t;
+struct tm
+{
+  int tm_mday;
+  int tm_mon;
+  int tm_year;
+};
+size_t
+__strftime (wchar_t * s, size_t maxsize, const wchar_t * format,
const struct tm *tim_p)
+{
+  size_t count = 0;
+  int len = 0;
+  size_t i, ctloclen;
+  unsigned long width;
+  {
+    if (foo)
+  {
+    {
+  wchar_t *fmt = L"%s%.*d";
+  len = swprintf (&s[count], maxsize, fmt, "-", width, 0);
+    }
+    if ((count) >= maxsize)
+  return 0;
+  }
+    else
+  {
+    len =
+  swprintf (&s[count], maxsize - count, L"%.2d/%.2d/%.2d", 42,
99, 0);
+    if ((count) >= maxsize)
+  return 0;
+
+  }
+  }
+}


Hi,

when compiling this test for nvptx, the missing declaration for swprintf
results in this default declaration in the .s file based on the
arguments of the first call:
...
     .extern .func (.param.u32 %value_out) swprintf (.param.u64
%in_ar0, .param.u64 %in_ar1, .param.u64 %in_ar2, .param.u64 %in_ar3,
.param.u64 %in_ar4, .param.u32 %in_ar5);
...

and this error message when ptxas process the second call:
...
ptxas regs-arg-size.o, line 97; error   : Type or alignment of argument
does not match formal parameter '%in_ar3'
ptxas regs-arg-size.o, line 97; error   : Type or alignment of argument
does not match formal parameter '%in_ar4'
ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
...

When adding a declaration in the source like so:
...
diff --git a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
index 0ca0b9f034b..81943a2c459 100644
--- a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
+++ b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
@@ -1,6 +1,7 @@
  int foo;
  typedef long unsigned int size_t;
  typedef short unsigned int wchar_t;
+extern int swprintf(wchar_t *wcs, size_t maxlen, const wchar_t *format,
...);
  struct tm
  {
    int tm_mday;
...

the declaration changes to:
...
.extern .func (.param.u32 %value_out) swprintf (.param.u64 %in_ar0,
.param.u64 %in_ar1, .param.u64 %in_ar2, .param.u64 %in_ar3);
...
and test test-case passes.

Is it ok to update the test-case like this, or should it require
effective target 'untyped_assembly' (which is false for nvptx).

It's OK to update the test in either way -- I don't think either change
would compromise the test.  Adding the prototype seems like the better
choice to me.



Done.


I need to remember that PTX (and the PA) are much more sensitive to
these issues than any other port and once a testcase minimization is
complete to go back and make sure we have suitable prototypes.


I think the root cause here is that compile.exp uses "-w". Without that, 
a warning triggers:

...
regs-arg-size.c:22:10: warning: implicit declaration of function 
'swprintf' [-Wimplicit-function-declaration]...

...
and the test for excess errors fails.

Thanks,
- Tom
[testsuite] Add missing function decl to regs-arg-size.c

2018-02-26  Tom de Vries  

	* gcc.c-torture/compile/regs-arg-size.c (swprintf): Declare.

---
 gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
index 0ca0b9f..f5f0111 100644
--- a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
+++ b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
@@ -1,6 +1,7 @@
 int foo;
 typedef long unsigned int size_t;
 typedef short unsigned int wchar_t;
+extern int swprintf (wchar_t *wcs, size_t maxlen, const wchar_t *format, ...);
 struct tm
 {
   int tm_mday;

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[H.J. Lu]

On Mon, Feb 26, 2018 at 7:47 AM, Jan Hubicka  wrote:
> Hi,
> my main concern about the patch is that we now have 
> -mindirect-branch=thunk-extern
> which is intended to work well and is used by kernel, but we also have other 
> modes
> that are documented and as such they should work but they may lead to invalid
> unwind info (or did I miss anything imporant here?).
> Why we can't fix the others as well?
>

I took a closer look at my commit message.  It does leave an impression that
only  -mindirect-branch=thunk-extern is fixed.  But in fact, all
-mindirect-branch=
choices are fixed.

1.  -mindirect-branch=thunk generates:

   .cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq(%rdi), %rax
movq%rdi, %rbx
movq16(%rax), %rax
call__x86_indirect_thunk_rax
movq(%rbx), %rax
movq%rbx, %rdi
popq%rbx
.cfi_def_cfa_offset 8
movq16(%rax), %rax
jmp __x86_indirect_thunk_rax
.cfi_endproc

2.  -mindirect-branch=thunk-inline generates:

   .cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq(%rdi), %rax
movq%rdi, %rbx
movq16(%rax), %rax
jmp .LIND1
.LIND0:
call.LIND3
.LIND2:
pause
lfence
jmp .LIND2
.LIND3:
mov %rax, (%rsp)
ret
.LIND1:
call.LIND0
movq(%rbx), %rax
movq%rbx, %rdi
popq%rbx
.cfi_def_cfa_offset 8
movq16(%rax), %rax
call.LIND5
.LIND4:
pause
lfence
jmp .LIND4
.LIND5:
mov %rax, (%rsp)
ret
.cfi_endproc

I updated the commit message with

This patch adds TARGET_INDIRECT_BRANCH_REGISTER to force indirect
branch via register whenever -mindirect-branch= is used.

OK for trunk?

Thanks.

-- 
H.J.
From bd0672bd070da6fa4ff630540c1d87df3e8fdd53 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Fri, 26 Jan 2018 15:54:25 -0800
Subject: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

For

---
struct C {
  virtual ~C();
  virtual void f();
};

void
f (C *p)
{
  p->f();
  p->f();
}
---

-mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:

_Z1fP1C:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq(%rdi), %rax
movq%rdi, %rbx
jmp .LIND1
.LIND0:
pushq   16(%rax)
jmp __x86_indirect_thunk
.LIND1:
call.LIND0
movq(%rbx), %rax
movq%rbx, %rdi
popq%rbx
.cfi_def_cfa_offset 8
movq16(%rax), %rax
jmp __x86_indirect_thunk_rax
.cfi_endproc

x86-64 is supposed to have asynchronous unwind tables by default, but
there is nothing that reflects the change in the (relative) frame
address after .LIND0.  That region really has to be moved outside of
the .cfi_startproc/.cfi_endproc bracket.

This patch adds TARGET_INDIRECT_BRANCH_REGISTER to force indirect
branch via register whenever -mindirect-branch= is used.  Now,
-mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:

_Z1fP1C:
.LFB0:
	.cfi_startproc
	pushq	%rbx
	.cfi_def_cfa_offset 16
	.cfi_offset 3, -16
	movq	(%rdi), %rax
	movq	%rdi, %rbx
	movq	16(%rax), %rax
	call	__x86_indirect_thunk_rax
	movq	(%rbx), %rax
	movq	%rbx, %rdi
	popq	%rbx
	.cfi_def_cfa_offset 8
	movq	16(%rax), %rax
	jmp	__x86_indirect_thunk_rax
	.cfi_endproc

so that "-mindirect-branch=thunk-extern" is equivalent to
"-mindirect-branch=thunk-extern -mindirect-branch-register", which is
used by Linux kernel.

gcc/

	PR target/84039
	* config/i386/constraints.md (Bs): Replace
	ix86_indirect_branch_register with
	TARGET_INDIRECT_BRANCH_REGISTER.
	(Bw): Likewise.
	* config/i386/i386.md (indirect_jump): Likewise.
	(tablejump): Likewise.
	(*sibcall_memory): Likewise.
	(*sibcall_value_memory): Likewise.
	Peepholes of indirect call and jump via memory: Likewise.
	(*sibcall_GOT_32): Disallowed for TARGET_INDIRECT_BRANCH_REGISTER.
	(*sibcall_value_GOT_32): Likewise.
	* config/i386/i386.opt: Likewise.
	* config/i386/predicates.md (indirect_branch_operand): Likewise.
	(GOT_memory_operand): Likewise.
	(call_insn_operand): Likewise.
	(sibcall_insn_operand): Likewise.
	(GOT32_symbol_operand): Likewise.
	* config/i386/i386.h (TARGET_INDIRECT_BRANCH_REGISTER): New.

gcc/testsuite/

	PR target/84039
	* gcc.target/i386/indirect-thunk-1.c: Updated.
	* gcc.target/i386/indirect-thunk-2.c: Likewise.
	* gcc.target/i386/indirect-thunk-3.c: Likewise.
	* gcc.target/i386/indirect-thunk-4.c: Likewise.
	* gcc.target/i386/indirect-thunk-5.c: Likewise.
	* gcc.target/i386/indirect-thunk-6.c: Likewise.
	* gcc.target/i386/indirect-thunk-7.c: Likewise.
	* gcc.target/i386/indirect-thunk-attr-1.c: Likewise.
	* gcc.target/i386/indirect-thunk-attr-2.c: Likewise.
	* gcc.target/i386/indi

[PATCH, rs6000] GCC 7 backport for vec_insert4b, vec_extract4b support

[Carl Love]

GCC maintainers:

The following patch is a back port for the GCC 7 branch of mainline
commit 257747. The mainline commit added support for builtins
vec_insert4b and vec_extract4b.  This is the first of two patches. 
This patch adds the ABI specified builtin instances.  A second patch to
be posted shortly will remove the non ABI instances of these builtins.

This patch has been tested on GCC 7:

  powerpc64le-unknown-linux-gnu (Power 8 LE)
  powerpc64-unknown-linux-gnu (Power 8 BE)

with no regressions.

Let me know if the patch looks OK or not. Thanks.

   Carl Love
-

gcc/ChangeLog

2018-02-26  Carl Love  

* config/rs6000/altivec.h: Add builtin names vec_extract4b
vec_insert4b.
* config/rs6000/rs6000-builtin.def: Add INSERT4B and EXTRACT4B
definitions.
* config/rs6000/rs6000-c.c: Add the definitions for
P9V_BUILTIN_VEC_EXTRACT4B and P9V_BUILTIN_VEC_INSERT4B.
* config/rs6000/rs6000.c (altivec_expand_builtin): Add
P9V_BUILTIN_EXTRACT4B and P9V_BUILTIN_INSERT4B case statements.
* config/rs6000/vsx.md: Add define_insn extract4b.  Add define_expand
definition for insert4b and define insn *insert3b_internal.
* doc/extend.texi: Add documentation for vec_extract4b.

gcc/testsuite/ChangeLog

2018-02-26  Carl Love  

*gcc.target/powerpc/builtins-7-p9-runnable.c: New runnable test file
for the ABI definitions for vec_extract4b and vec_insert4b.
---
 gcc/config/rs6000/altivec.h|   2 +
 gcc/config/rs6000/rs6000-builtin.def   |   4 +
 gcc/config/rs6000/rs6000-c.c   |   8 +
 gcc/config/rs6000/rs6000.c |   2 +
 gcc/config/rs6000/vsx.md   |  41 +
 gcc/doc/extend.texi|   7 +
 .../gcc.target/powerpc/builtins-7-p9-runnable.c| 169 +
 7 files changed, 233 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/builtins-7-p9-runnable.c

diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
index b9de05a..3011a87 100644
--- a/gcc/config/rs6000/altivec.h
+++ b/gcc/config/rs6000/altivec.h
@@ -400,6 +400,8 @@
 #define vec_vctzw __builtin_vec_vctzw
 #define vec_vextract4b __builtin_vec_vextract4b
 #define vec_vinsert4b __builtin_vec_vinsert4b
+#define vec_extract4b __builtin_vec_extract4b
+#define vec_insert4b __builtin_vec_insert4b
 #define vec_vprtyb __builtin_vec_vprtyb
 #define vec_vprtybd __builtin_vec_vprtybd
 #define vec_vprtybw __builtin_vec_vprtybw
diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index a39f936..46ae21a 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -2036,6 +2036,8 @@ BU_P9V_AV_2 (VEXTUWRX, "vextuwrx",CONST,  
vextuwrx)
 BU_P9V_VSX_2 (VEXTRACT4B,   "vextract4b",  CONST,  vextract4b)
 BU_P9V_VSX_3 (VINSERT4B,"vinsert4b",   CONST,  vinsert4b)
 BU_P9V_VSX_3 (VINSERT4B_DI, "vinsert4b_di",CONST,  vinsert4b_di)
+BU_P9V_VSX_3 (INSERT4B,"insert4b", CONST,  insert4b)
+BU_P9V_VSX_2 (EXTRACT4B,   "extract4b",CONST,  extract4b)
 
 /* 3 argument vector functions returning void, treated as SPECIAL,
added in ISA 3.0 (power9).  */
@@ -2084,10 +2086,12 @@ BU_P9V_OVERLOAD_2 (LXVL,"lxvl")
 BU_P9V_OVERLOAD_2 (VEXTULX,"vextulx")
 BU_P9V_OVERLOAD_2 (VEXTURX,"vexturx")
 BU_P9V_OVERLOAD_2 (VEXTRACT4B, "vextract4b")
+BU_P9V_OVERLOAD_2 (EXTRACT4B,  "extract4b")
 
 /* ISA 3.0 Vector scalar overloaded 3 argument functions */
 BU_P9V_OVERLOAD_3 (STXVL,  "stxvl")
 BU_P9V_OVERLOAD_3 (VINSERT4B,  "vinsert4b")
+BU_P9V_OVERLOAD_3 (INSERT4B,"insert4b")
 
 /* Overloaded CMPNE support was implemented prior to Power 9,
so is not mentioned here.  */
diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index d9905f7..c3134fc 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -5047,6 +5047,8 @@ const struct altivec_builtin_types 
altivec_overloaded_builtins[] = {
 RS6000_BTI_INTDI, RS6000_BTI_V16QI, RS6000_BTI_UINTSI, 0 },
   { P9V_BUILTIN_VEC_VEXTRACT4B, P9V_BUILTIN_VEXTRACT4B,
 RS6000_BTI_INTDI, RS6000_BTI_unsigned_V16QI, RS6000_BTI_UINTSI, 0 },
+  { P9V_BUILTIN_VEC_EXTRACT4B, P9V_BUILTIN_EXTRACT4B,
+RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V16QI, RS6000_BTI_INTSI, 0 },
 
   { P9V_BUILTIN_VEC_VEXTULX, P9V_BUILTIN_VEXTUBLX,
 RS6000_BTI_INTQI, RS6000_BTI_UINTSI,
@@ -5101,6 +5103,12 @@ const struct altivec_builtin_types 
altivec_overloaded_builtins[] = {
   { P8V_BUILTIN_VEC_VGBBD, P8V_BUILTIN_VGBBD,
 RS6000_BTI_unsigned_V16QI, RS6000_BTI_unsigned_V16QI, 0, 0 },
 
+  { P9V_BUILTIN_VEC_INSERT4B, P9V_BUILTIN_INSERT4B,
+RS6000_BTI_unsigned_V16QI, RS6000_BTI_V4SI,
+RS6000_BTI_unsigned_V16QI, RS6000_BTI_INTSI },
+  { P9V_BUILTIN_VEC_INSE

Fix PR rtl-optimization/83496

[Eric Botcazou]

This is a regression present on the mainline and 7 branch for MIPS in the form 
of a miscompilation caused by the dbr pass.  The scenario is as follows: the 
function contains a pair of insn+jump sequences (insn 8 and 9) which are the 
targets of a pair of jumps (insn 15 and 19).  Both insn 8 and insn 9 are first 
put into the delay slot of their following jumps.  

Then jump 19 "steals" the insn that is in the delay slot of the second jump,
i.e. insn 9, and is threaded to its target.  But the stolen insn is seen as 
"redundant" with insn 14 so dropped from the delay slot.

Then jump 15 "steals" the insn that is in the delay slot of the first jump,
i.e. insn 8, and is threaded to its target.  But the stolen insn clobbers the 
value of r2 set in insn 14 just above.

This second stealing is done because r2 is not considered as live at jump 19
by find_dead_or_set_registers because of a stale REG_DEAD note on jump 15,
so the fix is to call fix_reg_dead_note in more places where redundant insns
are dropped from delay slots.

Tested on SPARC64/Linux, applied on the mainline and 7 branch.


2018-02-26  Eric Botcazou  

PR rtl-optimization/83496
* reorg.c (steal_delay_list_from_target): Change REDUNDANT array from
booleans to RTXes.  Call fix_reg_dead_note on every non-null element.
(steal_delay_list_from_fallthrough): Call fix_reg_dead_note on a
redundant insn, if any.
(relax_delay_slots): Likewise.
(update_reg_unused_notes): Rename REDUNDANT_INSN to OTHER_INSN.


2018-02-26  Eric Botcazou  

    * gcc.c-torture/execute/20180226-1.c: New test.

-- 
Eric Botcazou/* PR rtl-optimization/83496 */
/* Reported by Hauke Mehrtens  */

extern void abort (void);

typedef unsigned long mp_digit;

typedef struct { int used, alloc, sign; mp_digit *dp; } mp_int;

int mytest(mp_int *a, mp_digit b) __attribute__((noclone, noinline));

int mytest(mp_int *a, mp_digit b)
{
  if (a->sign == 1)
return -1;
  if (a->used > 1)
return 1;
  if (a->dp[0] > b)
return 1;
  if (a->dp[0] < b)
return -1;
  return 0;
}

int main (void)
{
  mp_int i = { 2, 0, -1 };
  if (mytest (&i, 0) != 1)
abort ();
  return 0;
}
Index: reorg.c
===
--- reorg.c	(revision 257983)
+++ reorg.c	(working copy)
@@ -1036,7 +1036,8 @@ check_annul_list_true_false (int annul_true_p,
 
 static void
 steal_delay_list_from_target (rtx_insn *insn, rtx condition, rtx_sequence *seq,
-			  vec *delay_list, resources *sets,
+			  vec *delay_list,
+			  struct resources *sets,
 			  struct resources *needed,
 			  struct resources *other_needed,
 			  int slots_to_fill, int *pslots_filled,
@@ -1049,7 +1050,7 @@ steal_delay_list_from_target (rtx_insn *insn, rtx
   int used_annul = 0;
   int i;
   struct resources cc_set;
-  bool *redundant;
+  rtx_insn **redundant;
 
   /* We can't do anything if there are more delay slots in SEQ than we
  can handle, or if we don't know that it will be a taken branch.
@@ -1088,7 +1089,7 @@ steal_delay_list_from_target (rtx_insn *insn, rtx
   if (! targetm.can_follow_jump (insn, seq->insn (0)))
 return;
 
-  redundant = XALLOCAVEC (bool, XVECLEN (seq, 0));
+  redundant = XALLOCAVEC (rtx_insn *, XVECLEN (seq, 0));
   for (i = 1; i < seq->len (); i++)
 {
   rtx_insn *trial = seq->insn (i);
@@ -1152,7 +1153,10 @@ steal_delay_list_from_target (rtx_insn *insn, rtx
  we therefore decided not to copy.  */
   for (i = 1; i < seq->len (); i++)
 if (redundant[i])
-  update_block (seq->insn (i), insn);
+  {
+	fix_reg_dead_note (redundant[i], insn);
+	update_block (seq->insn (i), insn);
+  }
 
   /* Show the place to which we will be branching.  */
   *pnew_thread = first_active_target_insn (JUMP_LABEL (seq->insn (0)));
@@ -1199,6 +1203,7 @@ steal_delay_list_from_fallthrough (rtx_insn *insn,
   for (i = 1; i < seq->len (); i++)
 {
   rtx_insn *trial = seq->insn (i);
+  rtx_insn *prior_insn;
 
   /* If TRIAL sets CC0, stealing it will move it too far from the use
 	 of CC0.  */
@@ -1210,8 +1215,9 @@ steal_delay_list_from_fallthrough (rtx_insn *insn,
 	break;
 
   /* If this insn was already done, we don't need it.  */
-  if (redundant_insn (trial, insn, *delay_list))
+  if ((prior_insn = redundant_insn (trial, insn, *delay_list)))
 	{
+	  fix_reg_dead_note (prior_insn, insn);
 	  update_block (trial, insn);
 	  delete_from_delay_slot (trial);
 	  continue;
@@ -1791,15 +1797,14 @@ fix_reg_dead_note (rtx_insn *start_insn, rtx stop_
   }
 }
 
-/* Delete any REG_UNUSED notes that exist on INSN but not on REDUNDANT_INSN.
+/* Delete any REG_UNUSED notes that exist on INSN but not on OTHER_INSN.
 
This handles the case of udivmodXi4 instructions which optimize their
-   output depending on whether any REG_UNUSED notes are pres

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[Jan Hubicka]

> On Mon, Feb 26, 2018 at 7:47 AM, Jan Hubicka  wrote:
> > Hi,
> > my main concern about the patch is that we now have 
> > -mindirect-branch=thunk-extern
> > which is intended to work well and is used by kernel, but we also have 
> > other modes
> > that are documented and as such they should work but they may lead to 
> > invalid
> > unwind info (or did I miss anything imporant here?).
> > Why we can't fix the others as well?
> >
> 
> I took a closer look at my commit message.  It does leave an impression that
> only  -mindirect-branch=thunk-extern is fixed.  But in fact, all
> -mindirect-branch=
> choices are fixed.

I see, sorry for confussion!
> 
> 1.  -mindirect-branch=thunk generates:
> 
>.cfi_startproc
> pushq   %rbx
> .cfi_def_cfa_offset 16
> .cfi_offset 3, -16
> movq(%rdi), %rax
> movq%rdi, %rbx
> movq16(%rax), %rax
> call__x86_indirect_thunk_rax
> movq(%rbx), %rax
> movq%rbx, %rdi
> popq%rbx
> .cfi_def_cfa_offset 8
> movq16(%rax), %rax
> jmp __x86_indirect_thunk_rax
> .cfi_endproc
> 
> 2.  -mindirect-branch=thunk-inline generates:
> 
>.cfi_startproc
> pushq   %rbx
> .cfi_def_cfa_offset 16
> .cfi_offset 3, -16
> movq(%rdi), %rax
> movq%rdi, %rbx
> movq16(%rax), %rax
> jmp .LIND1
> .LIND0:
> call.LIND3
> .LIND2:
> pause
> lfence
> jmp .LIND2
> .LIND3:
> mov %rax, (%rsp)
> ret
> .LIND1:
> call.LIND0
> movq(%rbx), %rax
> movq%rbx, %rdi
> popq%rbx
> .cfi_def_cfa_offset 8
> movq16(%rax), %rax
> call.LIND5
> .LIND4:
> pause
> lfence
> jmp .LIND4
> .LIND5:
> mov %rax, (%rsp)
> ret
> .cfi_endproc
> 
> I updated the commit message with
> 
> This patch adds TARGET_INDIRECT_BRANCH_REGISTER to force indirect
> branch via register whenever -mindirect-branch= is used.
> 
> OK for trunk?
> 
> Thanks.
> 
> -- 
> H.J.

> From bd0672bd070da6fa4ff630540c1d87df3e8fdd53 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" 
> Date: Fri, 26 Jan 2018 15:54:25 -0800
> Subject: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER
> 
> For
> 
> ---
> struct C {
>   virtual ~C();
>   virtual void f();
> };
> 
> void
> f (C *p)
> {
>   p->f();
>   p->f();
> }
> ---
> 
> -mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
> 
> _Z1fP1C:
> .LFB0:
> .cfi_startproc
> pushq   %rbx
> .cfi_def_cfa_offset 16
> .cfi_offset 3, -16
> movq(%rdi), %rax
> movq%rdi, %rbx
> jmp .LIND1
> .LIND0:
> pushq   16(%rax)
> jmp __x86_indirect_thunk
> .LIND1:
> call.LIND0
> movq(%rbx), %rax
> movq%rbx, %rdi
> popq%rbx
> .cfi_def_cfa_offset 8
> movq16(%rax), %rax
> jmp __x86_indirect_thunk_rax
> .cfi_endproc
> 
> x86-64 is supposed to have asynchronous unwind tables by default, but
> there is nothing that reflects the change in the (relative) frame
> address after .LIND0.  That region really has to be moved outside of
> the .cfi_startproc/.cfi_endproc bracket.
> 
> This patch adds TARGET_INDIRECT_BRANCH_REGISTER to force indirect
> branch via register whenever -mindirect-branch= is used.  Now,
> -mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
> 
> _Z1fP1C:
> .LFB0:
>   .cfi_startproc
>   pushq   %rbx
>   .cfi_def_cfa_offset 16
>   .cfi_offset 3, -16
>   movq(%rdi), %rax
>   movq%rdi, %rbx
>   movq16(%rax), %rax
>   call__x86_indirect_thunk_rax
>   movq(%rbx), %rax
>   movq%rbx, %rdi
>   popq%rbx
>   .cfi_def_cfa_offset 8
>   movq16(%rax), %rax
>   jmp __x86_indirect_thunk_rax
>   .cfi_endproc
> 
> so that "-mindirect-branch=thunk-extern" is equivalent to
> "-mindirect-branch=thunk-extern -mindirect-branch-register", which is
> used by Linux kernel.
> 
> gcc/
> 
>   PR target/84039
>   * config/i386/constraints.md (Bs): Replace
>   ix86_indirect_branch_register with
>   TARGET_INDIRECT_BRANCH_REGISTER.
>   (Bw): Likewise.
>   * config/i386/i386.md (indirect_jump): Likewise.
>   (tablejump): Likewise.
>   (*sibcall_memory): Likewise.
>   (*sibcall_value_memory): Likewise.
>   Peepholes of indirect call and jump via memory: Likewise.
>   (*sibcall_GOT_32): Disallowed for TARGET_INDIRECT_BRANCH_REGISTER.
>   (*sibcall_value_GOT_32): Likewise.
>   * config/i386/i386.opt: Likewise.
>   * config/i386/predicates.md (indirect_branch_operand): Likewise.
>   (GOT_memory_operand): Likewise.
>   (call_insn_operand): Likewise.
>   (sibcall_insn_operand): Likewise.
>   (GOT32_symbol_oper

[C++ Patch] PR 84540 ("[6/7/8 Regression] ICE with alignas in variadic template")

[Paolo Carlini]

Hi,

this regression is an ICE on valid, and seems rather easy to analyze: 
both apply_late_template_attributes and tsubst_attributes don't appear 
to cope correctly with tsubst_attribute returning NULL_TREE. That, in 
turn, seems normal for an empty pack - as in the testcases - given the 
structure of the last part of the latter, handling PACK_EXPANSION_P 
(val). I'm finishing testing on x86_64-linux (in libstdc++-v3, so far so 
good).


Thanks, Paolo.

///

/cp
2018-02-26  Paolo Carlini  

PR c++/84540
* pt.c (tsubst_attributes): Handle correctly tsubst_attribute
returning NULL_TREE.
(apply_late_template_attributes): Likewise.

/testsuite
2018-02-26  Paolo Carlini  

PR c++/84540
* g++.dg/cpp0x/alignas14.C: New.
* g++.dg/cpp0x/alignas15.C: Likewise.
Index: cp/pt.c
===
--- cp/pt.c (revision 257989)
+++ cp/pt.c (working copy)
@@ -10245,9 +10245,8 @@ tsubst_attributes (tree attributes, tree args,
if (subst != t)
  {
*p = subst;
-   do
+   while (*p)
  p = &TREE_CHAIN (*p);
-   while (*p);
*p = TREE_CHAIN (t);
continue;
  }
@@ -10314,9 +10313,8 @@ apply_late_template_attributes (tree *decl_p, tree
  *p = TREE_CHAIN (t);
  TREE_CHAIN (t) = NULL_TREE;
  *q = tsubst_attribute (t, decl_p, args, complain, in_decl);
- do
+ while (*q)
q = &TREE_CHAIN (*q);
- while (*q);
}
  else
p = &TREE_CHAIN (t);
Index: testsuite/g++.dg/cpp0x/alignas14.C
===
--- testsuite/g++.dg/cpp0x/alignas14.C  (nonexistent)
+++ testsuite/g++.dg/cpp0x/alignas14.C  (working copy)
@@ -0,0 +1,6 @@
+// PR c++/84540
+// { dg-do compile { target c++11 } }
+
+template struct alignas(alignof(T)...) A {};
+
+A<> a;
Index: testsuite/g++.dg/cpp0x/alignas15.C
===
--- testsuite/g++.dg/cpp0x/alignas15.C  (nonexistent)
+++ testsuite/g++.dg/cpp0x/alignas15.C  (working copy)
@@ -0,0 +1,6 @@
+// PR c++/84540
+// { dg-do compile { target c++11 } }
+
+template struct A { enum alignas(alignof(T)...) E {}; };
+
+A<> a;

C++ PATCH for c++/84447, ICE with deleted inherited ctor and default arg

[Jason Merrill]

Normally, when we call an inherited constructor we determine which
base constructor it actually calls, and then use that information for
instantiating the default arguments later.  But if the base
constructor is deleted, that process breaks down: the simulated call
fails, so we don't update the base constructor, so we don't have the
template arguments, so instantiating the default arguments blows up.

A simple solution is to avoid trying to instantiate default arguments
for a deleted function; if we already know it's deleted, the call is
going to fail, we don't need to mess with argument conversions at all.
So this patch simplifies build_over_call by handling deleted functions
in one place, where we were already handling them in SFINAE context.
I'm puzzled why I didn't do this before.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit f5f375a2108ec9f1d7d76ef4cdad961a8bd72c07
Author: Jason Merrill 
Date:   Mon Feb 26 11:30:39 2018 -0500

PR c++/84447 - ICE with deleted inherited ctor with default arg.

* call.c (build_over_call): Handle deleted functions in one place.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 7c93c6d8290..c47befdbf7f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7665,8 +7665,12 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
 deduce_inheriting_ctor (fn);
 
   /* Make =delete work with SFINAE.  */
-  if (DECL_DELETED_FN (fn) && !(complain & tf_error))
-return error_mark_node;
+  if (DECL_DELETED_FN (fn))
+{
+  if (complain & tf_error)
+   mark_used (fn);
+  return error_mark_node;
+}
 
   if (DECL_FUNCTION_MEMBER_P (fn))
 {
@@ -7710,12 +7714,6 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
  conversions.  */
   if (flags & LOOKUP_SPECULATIVE)
 {
-  if (DECL_DELETED_FN (fn))
-   {
- if (complain & tf_error)
-   mark_used (fn);
- return error_mark_node;
-   }
   if (cand->viable == 1)
return fn;
   else if (!(complain & tf_error))
@@ -8090,7 +8088,7 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
 
   /* [class.copy]: the copy constructor is implicitly defined even if
 the implementation elided its use.  */
-  if (!trivial || DECL_DELETED_FN (fn))
+  if (!trivial)
{
  if (!mark_used (fn, complain) && !(complain & tf_error))
return error_mark_node;
@@ -8121,8 +8119,7 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
 }
   else if (DECL_ASSIGNMENT_OPERATOR_P (fn)
   && DECL_OVERLOADED_OPERATOR_IS (fn, NOP_EXPR)
-  && trivial_fn_p (fn)
-  && !DECL_DELETED_FN (fn))
+  && trivial_fn_p (fn))
 {
   tree to = cp_stabilize_reference
(cp_build_fold_indirect_ref (argarray[0]));
@@ -8166,8 +8163,7 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
 
   return val;
 }
-  else if (!DECL_DELETED_FN (fn)
-  && trivial_fn_p (fn))
+  else if (trivial_fn_p (fn))
 {
   if (DECL_DESTRUCTOR_P (fn))
return fold_convert (void_type_node, argarray[0]);
diff --git a/gcc/testsuite/g++.dg/cpp0x/inh-ctor31.C 
b/gcc/testsuite/g++.dg/cpp0x/inh-ctor31.C
new file mode 100644
index 000..071f1789a3b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/inh-ctor31.C
@@ -0,0 +1,14 @@
+// PR c++/84447
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+  template A(T, T = 0) = delete;
+};
+
+struct B : A
+{
+  using A::A;  // { dg-error "deleted" }
+};
+
+B b(0);// { dg-error "deleted" }

Re: [PATCH, rs6000] Tests for builtin vec_neg updated

[Segher Boessenkool]

Hi Carl,

On Thu, Feb 22, 2018 at 07:41:10AM -0800, Carl Love wrote:
>   * gcc.target/powerpc/builtins-3.c: Move vec_neg builtin tests to
>   Power 8 test file.
>   * gcc.target/powerpc/builtins-3-p8.c: Add vec_neg builtin tests.
>   * gcc.target/powerpc/fold-vec-neg-char.c(dg-options): Add -mcpu=power8.
>   * gcc.target/powerpc/fold-vec-neg-floatdouble.c(dg-options): Add
>   -mcpu=power8.
>   * gcc.target/powerpc/fold-vec-neg-int.c(dg-options): Remove file.
>   * gcc.target/powerpc/fold-vec-neg-short.c(dg-options): Add
>   -mcpu=power8.

You should use a space before ( there.

> + test_neg_char 1 vspltisw, 1 vsububm
> + test_neg_short1 vspltisw, 1 vsubuhm
> + test_neg_int  1 vspltisw, 1 vsubuwm

All these are p6 already (so needs just -maltivec).

> + test_neg_float1 xvnegsp
> + test_neg_float1 xvnegdp

... and these are p7 (so needs just -mvsx).  I don't understand why you
move them to a p8 file?  Or ah, this is because the builtin is not
defined before p8?  Okay for trunk if so :-)

Thanks,


Segher

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Martin Sebor]

That attached revision updates the pass to directly convert
the poly64_int into offset_int using the API suggested by
Richard (thanks again).  As discussed below, I've made no
other changes.

Jakub, if you still have concerns that the false positive
suppression logic isn't sufficiently effective please post
a test case (or open a new bug).  I will look into it when
I get a chance.

Until then, I'd like to get the ICE fix committed. Please
confirm that the attached patch is good to go in.

Martin

On 02/23/2018 02:46 PM, Martin Sebor wrote:

On 02/23/2018 01:13 PM, Jakub Jelinek wrote:

On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:

+  /* get_inner_reference is not expected to return null.  */
+  gcc_assert (base != NULL);
+
   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);

-  HOST_WIDE_INT const_off;
-  if (!base || !bytepos.is_constant (&const_off))
-{
-  base = get_base_address (TREE_OPERAND (expr, 0));
-  return;
-}
-
+  /* There is no conversion from poly_int64 to offset_int even
+ though the latter is wider, so go through HOST_WIDE_INT.
+ The offset is expected to always be constant.  */
+  HOST_WIDE_INT const_off = bytepos.to_constant ();


The assert is ok, but removing the bytepos.is_constant (&const_off)
is wrong, I'm sure Richard S. can come up with some SVE testcase
where it will not be constant.  If it is not constant, you can handle
it like var_off (which as I said on IRC or in the PR also seems to be
incorrect, because if the base is not a decl the variable offset could be
negative).


That's what I did at first.  I took it out because it sounded
to me like you were saying it was a hypothetical possibility,
not something that would ever happen in practice, and because
I have no way of testing that code.  I have put it back in
the attached update.

Since you added Richard: can you please explain how to convert
a poly64_int to offset_int without converting it to HOST_WIDE_INT,
or if it can't be done, why not?  It's cumbersome and error-prone
to have to go through HWI, and doing so defeats the main goal of
using offset_int in the gimple-ssa-warn-restrict pass.  Should
the pass (and others like it) be changed to store offsets and
sizes in some flavor of poly_int instead of offset_int?


   offrange[0] += const_off;
   offrange[1] += const_off;

@@ -923,7 +923,11 @@ builtin_access::generic_overlap ()
   /* There's no way to distinguish an access to the same member
  of a structure from one to two distinct members of the same
  structure.  Give up to avoid excessive false positives.  */
-  tree basetype = TREE_TYPE (TREE_TYPE (dstref->base));
+  tree basetype = TREE_TYPE (dstref->base);
+  if (POINTER_TYPE_P (basetype)
+  || TREE_CODE (basetype) == ARRAY_TYPE)
+basetype = TREE_TYPE (basetype);


This doesn't address any of my concerns that it is completely random
what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer
(e.g. the argument of the function), sometimes the ADDR_EXPR operand,
sometimes the base of the reference, sometimes again address (if the
base of the reference is MEM_REF).  By the lack of consistency in what
it is, just deciding on its type whether you take TREE_TYPE or
TREE_TYPE (TREE_TYPE ()) of it also gives useless result.  You could e.g
call the memcpy etc. function with ADDR_EXPR of a VAR_DECL that has
pointer
type, then if dstref->base is that VAR_DECL, POINTER_TYPE_P (basetype)
would be true.


I think I understand what you're saying but this block is only
used for string functions (not for memcpy), and only as a stopgap
to avoid false positives.  Being limited to (a subset of) string
functions the case I think you're concerned about, namely calling
strcpy with a pointer to a pointer, shouldn't come up in valid
code.  It's not bullet-proof but I don't think there is
a fundamental problem, either with this patch or with the one
that introduced it.  The fundamental problem is that MEM_REF
can be ambiguous and that's what this code is trying to combat.
See the example I gave here:
https://gcc.gnu.org/ml/gcc/2018-02/msg00136.html

If you think I'm missing something please put together a small
test case to help me see the problem.  I'm not nearly as
comfortable thinking in terms of the internal representation
to visualize all the possibilities here.

Martin


PR tree-optimization/84526 - ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

gcc/ChangeLog:

	PR tree-optimization/84526
	* gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
	Remove dead code.
	(builtin_access::generic_overlap): Be prepared to handle non-array
	base objects.

gcc/testsuite/ChangeLog:

	PR tree-optimization/84526
	* gcc.dg/Wrestrict-10.c: New test.

Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c	(revision 257963)
+++ gcc/gimple-ssa-warn-restrict.c	(working copy)
@@ -396,6 +3

Re: [PATCH, rs6000] Update altivec-7 testcase(s).

[Segher Boessenkool]

On Fri, Feb 23, 2018 at 10:35:43AM -0600, Will Schmidt wrote:
> On Thu, 2018-02-22 at 12:06 -0600, Segher Boessenkool wrote:
> > On Wed, Feb 21, 2018 at 11:33:14AM -0600, Will Schmidt wrote:
> > >   This patch moves the vsx related content from the altivec-7-be test into
> > > a new vsx-7-be test.
> > > This fixes up some test failures as seen on older power systems.
> > 
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> > > @@ -0,0 +1,42 @@
> > > +/* { dg-do compile { target powerpc64-*-* } } */
> > 
> > powerpc*-*-* please, and if you need 64-bit use lp64.
> 
> Thats an existing thing to help indicate 'be' versus 'le'.

But it does not really work.

> altivec-7-be.c:/* { dg-do compile { target powerpc64-*-* } } */
> altivec-7-le.c:/* { dg-do compile { target powerpc64le-*-* } } */
> 
> but yeah, we are potentially missing coverage for -m32. 
> 
> Should I instead try to combine the le,be tests, and set target markers
> on any le/be unique scan-assembler stanzas?

We really want "we're compiling for BE / LE" targets selectors.  I'll
look into it, I guess.


Segher

Re: [PATCH] Fix formatting of -ftime-report.

[Jeff Law]

On 02/22/2018 05:13 AM, Martin Liška wrote:
> Hi.
> 
> It fixes column formatting of time report. Please take a look at attached
> samples. Hope it can go in even though we are in stage4?
> 
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-02-22  Martin Liska  
> 
>   * timevar.c (timer::print_row): Remove 'usr', 'sys', 'wall' and
>   'ggc' suffixes.  Change first column width.
>   (timer::print): Fix formatting of the column.
Yea, this seems reasonable, even for stage4.

OK.
jeff

C++ PATCH to fix ICE with constexpr operator"" (PR c++/84325)

[Marek Polacek]

The original testcase was invalid but I added seconds's constructor and made
time_to_wait inline and now the testcase is accepted by clang++.

But we ICE in replace_placeholders_r because we were checking TREE_CONSTANT
on a type.  With this patch we accept the code without crashing.  (We require
time_to_wait to be inline but clang++ does not.)

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

2018-02-26  Marek Polacek  

PR c++/84325
* tree.c (replace_placeholders_r): Only check TREE_CONSTANT on
non-types.

* g++.dg/cpp1z/pr84325.C: New test.

diff --git gcc/cp/tree.c gcc/cp/tree.c
index 39c1ef28b2d..298517ff83a 100644
--- gcc/cp/tree.c
+++ gcc/cp/tree.c
@@ -3091,7 +3091,7 @@ replace_placeholders_r (tree* t, int* walk_subtrees, 
void* data_)
   replace_placeholders_t *d = static_cast(data_);
   tree obj = d->obj;
 
-  if (TREE_CONSTANT (*t))
+  if (!TYPE_P (*t) && TREE_CONSTANT (*t))
 {
   *walk_subtrees = false;
   return NULL_TREE;
diff --git gcc/testsuite/g++.dg/cpp1z/pr84325.C 
gcc/testsuite/g++.dg/cpp1z/pr84325.C
index e69de29bb2d..dddadc32692 100644
--- gcc/testsuite/g++.dg/cpp1z/pr84325.C
+++ gcc/testsuite/g++.dg/cpp1z/pr84325.C
@@ -0,0 +1,17 @@
+// PR c++/84325
+// { dg-do compile }
+// { dg-options "-std=c++17" }
+
+struct seconds { int i_{0}; constexpr seconds (int) {} };
+template  constexpr seconds operator""_s() {
+  return seconds(0);
+}
+constexpr seconds operator""_s(long double i) {
+  return seconds(0);
+}
+template
+struct Param {
+  constexpr static inline seconds time_to_wait{10_s};
+};
+struct Empty {};
+Param p;

Marek

Re: [PATCH, rs6000] GCC 7 backport for vec_insert4b, vec_extract4b support

[Segher Boessenkool]

On Mon, Feb 26, 2018 at 08:26:43AM -0800, Carl Love wrote:
> 
> 2018-02-26  Carl Love  
> 
>   *gcc.target/powerpc/builtins-7-p9-runnable.c: New runnable test file
>   for the ABI definitions for vec_extract4b and vec_insert4b.

(Space after the asterisk).

This is just the same as the trunk version, right?  If so: okay for all
release branches.  Thanks!


Segher

Re: [PATCH] Fix bootstrap with GCC 3.4 (and likely anything < 4.4 except 4.2.[0-3]) (PR bootstrap/84405)

[Jakub Jelinek]

Hi!

On Sat, Feb 17, 2018 at 10:08:48AM +0100, Jakub Jelinek wrote:
> Note, this doesn't work, as G++ <= 4.2 rejects:
> template 
> struct S
> {
>   char __attribute__ ((__aligned__ (__alignof__ (value_type buf[sizeof 
> (value_type)];
> };
> 
> S s;
> 
> with:
> error: requested alignment is not a constant
> 
> The following works though, and has been successfully bootstrapped/regtested
> on x86_64-linux and i686-linux.  It will fail if we use hash_table on
> overaligned value_type type with alignment > 64, but that is not completely
> unlikely on any target I'm aware of.  It uses __alignof__ which should be
> supported by the system GCC's we support for which
> BROKEN_VALUE_INITIALIZATION is true (i.e. >= 3.4 and <= 4.3), non-GCC
> compilers shouldn't get here due to GCC_VERSION != 0 unless they pretend to
> be GCC compatible.
> 
> Bootstrapped with system gcc34/g++34 on x86_64-linux, ok for trunk?
> 
> 2018-02-17  Jakub Jelinek  
> 
>   PR bootstrap/84405
>   * vec.h (vec_default_construct): For BROKEN_VALUE_INITIALIZATION use
>   memset and value initialization afterwards.
>   * hash-table.h (hash_table::empty_slow): For
>   BROKEN_VALUE_INITIALIZATION use placement new into a previously
>   cleared appropriately aligned buffer.

I'd like to ping this patch, or if it isn't acceptable, at least the vec.h
part of it which isn't really more complex than what we have right now.

> --- gcc/vec.h.jj  2018-02-16 19:39:03.637058918 +0100
> +++ gcc/vec.h 2018-02-16 23:51:55.389582056 +0100
> @@ -490,12 +490,11 @@ template 
>  inline void
>  vec_default_construct (T *dst, unsigned n)
>  {
> -#ifndef BROKEN_VALUE_INITIALIZATION
> -  for ( ; n; ++dst, --n)
> -::new (static_cast(dst)) T ();
> -#else
> +#ifdef BROKEN_VALUE_INITIALIZATION
>memset (dst, '\0', sizeof (T) * n);
>  #endif
> +  for ( ; n; ++dst, --n)
> +::new (static_cast(dst)) T ();
>  }
>  
>  /* Copy-construct N elements in DST from *SRC.  */
> --- gcc/hash-table.h.jj   2018-02-16 19:39:03.660058934 +0100
> +++ gcc/hash-table.h  2018-02-17 00:01:24.207723925 +0100
> @@ -808,7 +808,18 @@ hash_table::empty
>for ( ; size; ++entries, --size)
>   *entries = value_type ();
>  #else
> -  memset (entries, 0, size * sizeof (value_type));
> +  /* To workaround older GCC versions which don't handle value
> +  initialization right, use a placement new into previously
> +  cleared buffer.  */
> +  char buf[2 * sizeof (value_type) + 64];
> +  gcc_assert (__alignof__ (value_type) <= sizeof (value_type) + 64);
> +  char *q = (buf + sizeof (value_type) + 64
> +  - ((uintptr_t) buf % __alignof__ (value_type)));
> +  memset (q, '\0', sizeof (value_type));
> +  value_type *p = ::new (q) value_type ();
> +  for ( ; size; ++entries, --size)
> + *entries = *p;
> +  p->~value_type ();
>  #endif
>  }
>m_n_deleted = 0;

Jakub

Re: C++ PATCH to fix ICE with constexpr operator"" (PR c++/84325)

[Jason Merrill]

On Mon, Feb 26, 2018 at 12:42 PM, Marek Polacek  wrote:
> The original testcase was invalid but I added seconds's constructor and made
> time_to_wait inline and now the testcase is accepted by clang++.
>
> But we ICE in replace_placeholders_r because we were checking TREE_CONSTANT
> on a type.  With this patch we accept the code without crashing.  (We require
> time_to_wait to be inline but clang++ does not.)
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-02-26  Marek Polacek  
>
> PR c++/84325
> * tree.c (replace_placeholders_r): Only check TREE_CONSTANT on
> non-types.
>
> * g++.dg/cpp1z/pr84325.C: New test.
>
> diff --git gcc/cp/tree.c gcc/cp/tree.c
> index 39c1ef28b2d..298517ff83a 100644
> --- gcc/cp/tree.c
> +++ gcc/cp/tree.c
> @@ -3091,7 +3091,7 @@ replace_placeholders_r (tree* t, int* walk_subtrees, 
> void* data_)
>replace_placeholders_t *d = static_cast(data_);
>tree obj = d->obj;
>
> -  if (TREE_CONSTANT (*t))
> +  if (!TYPE_P (*t) && TREE_CONSTANT (*t))

I'd make this

if (TYPE_P (*t) || TREE_CONSTANT (*t))

so we don't keep walking into types.  OK with that change.

Jason

Re: [C++ Patch] PR 84540 ("[6/7/8 Regression] ICE with alignas in variadic template")

[Jason Merrill]

OK.

On Mon, Feb 26, 2018 at 11:56 AM, Paolo Carlini
 wrote:
> Hi,
>
> this regression is an ICE on valid, and seems rather easy to analyze: both
> apply_late_template_attributes and tsubst_attributes don't appear to cope
> correctly with tsubst_attribute returning NULL_TREE. That, in turn, seems
> normal for an empty pack - as in the testcases - given the structure of the
> last part of the latter, handling PACK_EXPANSION_P (val). I'm finishing
> testing on x86_64-linux (in libstdc++-v3, so far so good).
>
> Thanks, Paolo.
>
> ///
>

Re: [PATCH] i386: Update -mfunction-return= for return with pop

[H.J. Lu]

On Mon, Feb 26, 2018 at 7:44 AM, Jan Hubicka  wrote:
>> On Mon, Feb 26, 2018 at 7:06 AM, Jan Hubicka  wrote:
>> >> On Mon, Feb 26, 2018 at 2:58 AM, Jan Hubicka  wrote:
>> >> >> On Mon, Feb 26, 2018 at 2:05 AM, Martin Liška  wrote:
>> >> >> > On 02/25/2018 02:37 AM, H.J. Lu wrote:
>> >> >> >>   PR target/r84530
>> >> >> >
>> >> >> > Just a nit I've noticed:
>> >> >> >
>> >> >> > s/r84530/84530
>> >> >>
>> >> >> Fixed.
>> >> >>
>> >> >> --
>> >> >> H.J.
>> >> >
>> >> >> From f08b8721ed038cefcee5a0bb1329b90a2d322269 Mon Sep 17 00:00:00 2001
>> >> >> From: "H.J. Lu" 
>> >> >> Date: Sat, 24 Feb 2018 05:05:49 -0800
>> >> >> Subject: [PATCH] i386: Update -mfunction-return= for return with pop
>> >> >>
>> >> >> When -mfunction-return= is used, simple_return_pop_internal should pop
>> >> >> return address into ECX register, adjust stack by bytes to pop from 
>> >> >> stack
>> >> >> and jump to the return thunk via ECX register.
>> >> >>
>> >> >> Tested on i686 and x86-64.
>> >> >>
>> >> >>   PR target/84530
>> >> >>   * config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove
>> >> >>   the bool argument.
>> >> >>   (ix86_output_indirect_function_return): New prototype.
>> >> >>   (ix86_split_simple_return_pop_internal): Likewise.
>> >> >>   * config/i386/i386.c (indirect_return_via_cx): New.
>> >> >>   (indirect_return_via_cx_bnd): Likewise.
>> >> >>   (indirect_thunk_name): Handle return va CX_REG.
>> >> >>   (output_indirect_thunk_function): Create alias for
>> >> >>   __x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd.
>> >> >>   (ix86_output_indirect_jmp): Remove the bool argument.
>> >> >>   (ix86_output_indirect_function_return): New function.
>> >> >>   (ix86_split_simple_return_pop_internal): Likewise.
>> >> >>   * config/i386/i386.md (*indirect_jump): Don't pass false
>> >> >>   to ix86_output_indirect_jmp.
>> >> >>   (*tablejump_1): Likewise.
>> >> >>   (simple_return_pop_internal): Change it to define_insn_and_split.
>> >> >>   Call ix86_split_simple_return_pop_internal to split it for
>> >> >>   -mfunction-return=.
>> >> >>   (simple_return_indirect_internal): Call
>> >> >>   ix86_output_indirect_function_return instead of
>> >> >>   ix86_output_indirect_jmp.
>> >> >
>> >> > It seems to make sense. Since LLVM has picked up our thunk names now,
>> >> > I wonder if they have same bug or someohow already assigned a name
>> >> > to this thunk. In the second case we probably ought to match it. Do
>> >> > you know what LLVM uses?
>> >> >
>> >>
>> >> I don't think LLVM has implemented -mfunction-return=.   I disclosed
>> >> my -mindirect-branch= approach to LLVM last year.  At the time, they
>> >> wanted freedom in their implementation and didn't want to be compatible
>> >> with mine.   Later they added GCC compatibility so that LLVM may be
>> >> used to compile Linux kernel.  I believe it will be the same case if this
>> >> option is used to compile Linux kernel.
>> >
>> > Patch is OK then, thanks!
>> >
>>
>> Checked into trunk.  OK for backport to GCC 7 branch after a few days?
> OK,

I checked in this patch to update comments.  I will backport it together to
GCC 7 branch.

Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 258004)
+++ config/i386/i386.c (working copy)
@@ -28999,8 +28999,7 @@ ix86_output_indirect_branch (rtx call_op
 ix86_output_indirect_branch_via_push (call_op, xasm, sibcall_p);
 }

-/* Output indirect jump.  CALL_OP is the jump target.  Jump is a
-   function return if RET_P is true.  */
+/* Output indirect jump.  CALL_OP is the jump target.  */

 const char *
 ix86_output_indirect_jmp (rtx call_op)


-- 
H.J.

[PATCH] expand description of poly_int conversions

[Martin Sebor]

Richard,

If you agree, I'd like to update the conversion section of
the poly_int manual to make the conversion to make it clearer
that the to_constant() function can be used even with class
types like offset_int besides scalars.

Also, when testing this I also tried converting poly64_int
into wide_int but that doesn't work.  Is there a way to do
that?

Thanks
Martin
gcc/ChangeLog:

	* doc/poly-int.texi (is_constant): Expand.

Index: gcc/doc/poly-int.texi
===
--- gcc/doc/poly-int.texi	(revision 258004)
+++ gcc/doc/poly-int.texi	(working copy)
@@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
 
 @item @var{value}.is_constant (&@var{c1})
 Return true if @code{poly_int} @var{value} is a compile-time constant,
-storing it in @var{c1} if so.  @var{c1} must be able to hold all
-constant values of @var{value} without loss of precision.
+storing it in @var{c1} if so.  @var{c1} may be a scalar or a wide int
+class type capable of holding all constant values of @var{value} without
+loss of precision.  The following example illustrates using the function
+to convert a @code{poly64_int} to @code{HOST_WIDE_INT} and to
+@code{offset_int}.
+@smallexample
+void f (poly64_int pi)
+@{
+  HOST_WIDE_INT hwi;
+  if (pi.is_constant (&hwi))
+; // Use hwi...
+  offset_int off;
+  if (pi.is_constant (&off))
+; // Use off...
+@}
+@end smallexample
 
+
 @item @var{value}.to_constant ()
 Assert that @var{value} is a compile-time constant and return its value.
 When using this function, please add a comment explaining why the

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Martin Sebor]

On 02/26/2018 10:39 AM, Jakub Jelinek wrote:

On Mon, Feb 26, 2018 at 10:32:27AM -0700, Martin Sebor wrote:

That attached revision updates the pass to directly convert
the poly64_int into offset_int using the API suggested by
Richard (thanks again).  As discussed below, I've made no
other changes.

Jakub, if you still have concerns that the false positive
suppression logic isn't sufficiently effective please post
a test case (or open a new bug).  I will look into it when
I get a chance.


Yes, I still have major concerns, I explained what I'd like to see
(differentiate clearly between what base is, either by adding a flag or
having separate base and base_addr, then in the users you can easily find
out what is what and can decide based on that).


I'm open to making these improvements but without a test case
or a way to validate them I'm not comfortable making intrusive
changes in this area at this late stage.  As I explained, the
code cannot be reached under the conditions you described.
In any event, the improvements you suggest are independent of
the fix for the ICE.


Until then, I'd like to get the ICE fix committed. Please
confirm that the attached patch is good to go in.


Due to the above concerns, I don't think the patch is good to go in.
If you find somebody else who thinks the patch is ok, I won't fight against
it though.


Jeff, when you have a chance, can you please review/approve
the patch?

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01441.html

Martin

C++ PATCH for c++/84551, ICE with concepts and DEBUG_BEGIN_STMT

[Jason Merrill]

DEBUG_BEGIN_STMT was confusing the concepts machinery, and it isn't
useful in concepts, which are never expanded.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8a2a7e8672b17af0231c82b6f3d4429efddec0d6
Author: Jason Merrill 
Date:   Mon Feb 26 13:48:34 2018 -0500

PR c++/84551 - ICE with concepts and -g.

* parser.c (add_debug_begin_stmt): Do nothing in a concept.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 4fa546a086c..f305c9c7eba 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -10699,6 +10699,9 @@ add_debug_begin_stmt (location_t loc)
 {
   if (!MAY_HAVE_DEBUG_MARKER_STMTS)
 return;
+  if (DECL_DECLARED_CONCEPT_P (current_function_decl))
+/* A concept is never expanded normally.  */
+return;
 
   tree stmt = build0 (DEBUG_BEGIN_STMT, void_type_node);
   SET_EXPR_LOCATION (stmt, loc);
diff --git a/gcc/testsuite/g++.dg/concepts/debug1.C 
b/gcc/testsuite/g++.dg/concepts/debug1.C
new file mode 100644
index 000..eeb63654243
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/debug1.C
@@ -0,0 +1,10 @@
+// PR c++/84551
+// { dg-options "-g -O -std=c++17 -fconcepts" }
+
+template concept bool C() { return true; }
+
+template requires C() class> struct A {};
+
+template requires true struct B {};
+
+A a;

Re: [PING] [PATCH] consider successor blocks when avoiding -Wstringop-truncation (PR 84468)

[Jeff Law]

On 02/24/2018 05:11 PM, Martin Sebor wrote:
> Attached is an updated patch with a fix for a bad assumption
> exposed by building the linux kernel.
> 
> On 02/19/2018 07:50 PM, Martin Sebor wrote:
>> PR 84468 points out a false positive in -Wstringop-truncation
>> in code like this:
>>
>>   struct A { char a[4]; };
>>
>>   void f (struct A *p, const struct A *q)
>>   {
>>     if (p->a)
>>   strncpy (p->a, q->a, sizeof p->a - 1);   // warning here
>>
>>     p->a[3] = '\0';
>>   }
>>
>> The warning is due to the code checking only the same basic block
>> as the one with the strncpy call for an assignment to the destination
>> to avoid it, but failing to check the successor basic block if there
>> is no subsequent statement in the current block.  (Eliminating
>> the conditional is being tracked in PR 21474.)
>>
>> The attached test case adds logic to avoid this false positive.
>> I don't know under what circumstances there could be more than
>> one successor block here so I don't handle that case.
So this is feeling more and more like we need to go back to the ideas
behind checking the virtual operand chains.

The patch as-written does not properly handle the case where BB has
multiple outgoing edges.  For gcc-8 you could probably get away with
checking that you have precisely one outgoing edge without EDGE_ABNORMAL
set in its flags in addition to the checks you're already doing.

But again, it's feeling more and more like the right fix is to go back
and walk the virtual operands.

Jeff

Re: [PATCH] Correct debug for -mcall-ms2sysv-xlogues stubs (PR target/83917, take 2)

[Jeff Law]

On 02/22/2018 07:56 AM, Jakub Jelinek wrote:
> Hi!
> 
> On Sat, Jan 20, 2018 at 06:01:16PM -0600, Daniel Santos wrote:
>> Thanks.  I like the idea of commonizing the macros for consistency.
> 
> Didn't see a progress on this P3 for a while, so I've written this
> version of the patch; no tests though, what I've been using in testing was:
> /* { dg-do compile { target lp64 } } */
> /* { dg-options "-mno-avx -msse2 -mcall-ms2sysv-xlogues -O2" } */
> 
> void __attribute__((sysv_abi, noipa))
> foo (void)
> {
> }
> 
> static void __attribute__((sysv_abi)) (*volatile foop) () = foo;
> 
> void __attribute__((ms_abi, noipa))
> bar (void)
> {
>   foop ();
> }
> 
> int
> main ()
> {
>   bar ();
>   return 0;
> }
> 
> with/without -fno-omit-frame-pointer, disas bar; b on the tail
> call in there, stepi; bt (which before the patch failed, now works),
> also up; p $rbp to see if %rbp has been properly declared to be saved.
> There is no need to cfi_startproc/cfi_endproc for every single entrypoint in
> there, it is enough if the whole range is covered.  On the other side
> we need the cfi_offset for the frame pointer case, otherwise up; p/x $rbp
> doesn't work properly.
> 
> Ok for trunk if it passes bootstrap/regtest on x86_64-linux and i686-linux?
> 
> 2018-02-22  Jakub Jelinek  
> 
>   PR debug/83917
>   * config/i386/i386-asm.h (PACKAGE_VERSION, PACKAGE_NAME,
>   PACKAGE_STRING, PACKAGE_TARNAME, PACKAGE_URL): Undefine between
>   inclusion of auto-target.h and auto-host.h.
>   (USE_GAS_CFI_DIRECTIVES): Define if not defined already based on
>   __GCC_HAVE_DWARF2_CFI_ASM.
>   (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
>   cfi_def_cfa_register, cfi_def_cfa, cfi_register, cfi_offset, cfi_push,
>   cfi_pop): Define.
>   * config/i386/cygwin.S: Don't include auto-host.h here, just
>   define USE_GAS_CFI_DIRECTIVES to 1 or 0 and include i386-asm.h.
>   (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
>   cfi_def_cfa_register, cfi_register, cfi_push, cfi_pop): Remove.
>   * config/i386/resms64fx.h: Add cfi_* directives.
>   * config/i386/resms64x.h: Likewise.
It's a bit ugly.  But OK.  We can refine further if needed.

jeff

Re: [PATCH] expand description of poly_int conversions

[Richard Sandiford]

Martin Sebor  writes:
> Richard,
>
> If you agree, I'd like to update the conversion section of
> the poly_int manual to make the conversion to make it clearer
> that the to_constant() function can be used even with class
> types like offset_int besides scalars.
>
> Also, when testing this I also tried converting poly64_int
> into wide_int but that doesn't work.  Is there a way to do
> that?

Not in one go, because you have to specify the intended precision
of the wide_int when constructing it from something like HOST_WIDE_INT.
(That's deliberate.)

>
> Thanks
> Martin
>
> gcc/ChangeLog:
>
>   * doc/poly-int.texi (is_constant): Expand.
>
> Index: gcc/doc/poly-int.texi
> ===
> --- gcc/doc/poly-int.texi (revision 258004)
> +++ gcc/doc/poly-int.texi (working copy)
> @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
>  
>  @item @var{value}.is_constant (&@var{c1})
>  Return true if @code{poly_int} @var{value} is a compile-time constant,
> -storing it in @var{c1} if so.  @var{c1} must be able to hold all
> -constant values of @var{value} without loss of precision.
> +storing it in @var{c1} if so.  @var{c1} may be a scalar or a wide int
> +class type capable of holding all constant values of @var{value} without

Not sure about "a scalar or a wide int", since that implies that wide ints
aren't scalar.  Even more pedantic, sorry, but c1 is an object rather than
a type.

At a higher level, I'm a bit nervous about singling this out as a special
case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
wide_int to be combined in the (hopefully) natural way.  E.g. you can
add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
and so on.

But if we do keep it like this, how about:

  @var{c1} must be some form of integer object that can hold all constant
  values of @var{value} without loss of precision; it can be either a normal
  C++ integer or a wide-int class like @code{offset_int}.

?

> +loss of precision.  The following example illustrates using the function
> +to convert a @code{poly64_int} to @code{HOST_WIDE_INT} and to
> +@code{offset_int}.
> +@smallexample
> +void f (poly64_int pi)

poly_int64

> +@{
> +  HOST_WIDE_INT hwi;
> +  if (pi.is_constant (&hwi))
> +; // Use hwi...
> +  offset_int off;
> +  if (pi.is_constant (&off))
> +; // Use off...
> +@}
> +@end smallexample
>  
> +
>  @item @var{value}.to_constant ()
>  Assert that @var{value} is a compile-time constant and return its value.
>  When using this function, please add a comment explaining why the

No need for the extra blank line.

Thanks,
Richard

Re: [PATCH][committed][PR tree-optimization/82123] 01/06 Do nothing in EVRP analyzer is not optimizing

[Jeff Law]

On 02/26/2018 05:27 AM, Richard Biener wrote:
> On Tue, Feb 20, 2018 at 7:49 PM, Jeff Law  wrote:
>> This is part #1 of the patches to fix 81592/82123.  The changes aren't
>> particularly large or invasive, but I already had them broken down
>> internally into distinct chunks, so I'm going to send them out that way.
>>
>> This patch allows the EVRP range analyzer to be safely called even when
>> not optimizing.  It does no analysis in that case.   This prevents
>> problems if we were to ask for sprintf warnings but not have the
>> optimizer enabled.
> 
> I don't really understand the issue -- when called from sprintf warnings
> the evrp analyzer shouldn't "optimize" anything, it only does analysis.
> How is that ever a problem when not optimizing?
When not optimizing we can have _DECL nodes showing in in places we
don't expect them.  We also don't consistently canonicalize conditions.
There may be other issues as well, I didn't dig deeply into all of them.

This causes all kinds of grief when we try to analyze statements.

Ideally we'll fix this stuff in gcc-9.  Until then it seems far better
to have the analyzer protect itself from this cruft than forcing every
consumer to guard calls into the analyzer.

Jeff

[committed] Fix C++ OpenMP parsing ICE (PR c++/84557)

[Jakub Jelinek]

Hi!

In C++, the OpenMP variable lists are lists of id-expressions, which
include template-ids; for those cp_parser_lookup_name_simple ICEs though,
so this patch just calls that for identifiers similarly to other
cp_parser_lookup_name_simple callers.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk so
far.

2018-02-26  Jakub Jelinek  

PR c++/84557
* parser.c (cp_parser_omp_var_list_no_open): Only call
cp_parser_lookup_name_simple on names satisfying identifier_p.
(cp_parser_oacc_routine): Likewise.

* g++.dg/gomp/pr84557.C: New test.

--- gcc/cp/parser.c.jj  2018-02-22 14:35:34.194215675 +0100
+++ gcc/cp/parser.c 2018-02-26 13:03:56.398478515 +0100
@@ -31339,7 +31339,10 @@ cp_parser_omp_var_list_no_open (cp_parse
  if (name == error_mark_node)
goto skip_comma;
 
- decl = cp_parser_lookup_name_simple (parser, name, token->location);
+ if (identifier_p (name))
+   decl = cp_parser_lookup_name_simple (parser, name, token->location);
+ else
+   decl = name;
  if (decl == error_mark_node)
cp_parser_name_lookup_error (parser, name, decl, NLE_NULL,
 token->location);
@@ -37843,7 +37846,9 @@ cp_parser_oacc_routine (cp_parser *parse
   /*template_p=*/NULL,
   /*declarator_p=*/false,
   /*optional_p=*/false);
-  tree decl = cp_parser_lookup_name_simple (parser, name, name_loc);
+  tree decl = (identifier_p (name)
+  ? cp_parser_lookup_name_simple (parser, name, name_loc)
+  : name);
   if (name != error_mark_node && decl == error_mark_node)
cp_parser_name_lookup_error (parser, name, decl, NLE_NULL, name_loc);
 
--- gcc/testsuite/g++.dg/gomp/pr84557.C.jj  2018-02-26 13:04:34.074472152 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr84557.C 2018-02-26 13:04:17.014475036 +0100
@@ -0,0 +1,14 @@
+// PR c++/84557
+// { dg-do compile }
+
+template struct A {};
+template struct B {};
+
+void
+foo ()
+{
+  #pragma omp parallel firstprivate (A)// { dg-error "is not a 
variable in clause" }
+  ;
+  #pragma omp parallel firstprivate (B<0>) // { dg-error "is not a 
variable in clause" }
+  ;
+}

Jakub

[PATCH] PR fortran/51434 -- ICE in gfc_simplify_transfer

[Steve Kargl]

All,

The attached patch fixes an ICE that occurs in gfc_simplify_tranfer.
The code that causes the problem is

  if (!gfc_is_constant_expr (source)
|| (gfc_init_expr_flag && !gfc_is_constant_expr (mold))
|| !gfc_is_constant_expr (size))
return NULL;

in particular gfc_is_constant_expr (mold) leads to segfault.  Removing
the 2nd line allows the testcase to compile, but leads to several
regressions.  I went down the rabbit with gdb-8.0.1 to see why this
was dying a horrible death, and came away with a large headache.
After conferring with F95 and F2018, I concluded (and I coudl be
wrong) that mold simply needs to available as a scalar or an
array and it's actual value was not needed.  So, I decided to 
use gfc_reduce_expr (mold) to see if this would fix up some 
rogue pointer, and well it worked.  So, OK to commit?

2018-02-26  Steven G. Kargl  

PF fortran/51434
* simplify.c (gfc_simplify_transfer): Reduce mold.

2018-02-26  Steven G. Kargl  

PF fortran/51434
* gfortran.dg/pr51434.f90: New test.

-- 
Steve
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 258006)
+++ gcc/fortran/simplify.c	(working copy)
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gfortran.h"
 #include "arith.h"
 #include "intrinsic.h"
+#include "match.h"
 #include "target-memory.h"
 #include "constructor.h"
 #include "version.h"	/* For version_string.  */
@@ -7370,10 +7371,12 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr *mol
   unsigned char *buffer;
   size_t result_length;
 
+  if (!gfc_is_constant_expr (source) || !gfc_is_constant_expr (size))
+return NULL;
 
-  if (!gfc_is_constant_expr (source)
-	|| (gfc_init_expr_flag && !gfc_is_constant_expr (mold))
-	|| !gfc_is_constant_expr (size))
+  if (!gfc_resolve_expr (mold))
+return NULL;
+  if (gfc_init_expr_flag && !gfc_is_constant_expr (mold))
 return NULL;
 
   if (!gfc_calculate_transfer_sizes (source, mold, size, &source_size,
Index: gcc/testsuite/gfortran.dg/pr51434.f90
===
--- gcc/testsuite/gfortran.dg/pr51434.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr51434.f90	(working copy)
@@ -0,0 +1,19 @@
+! { dg-do run }
+! PR fortran/51434
+module foo
+   implicit none
+   integer, parameter :: n = 5
+   character(len=1), parameter :: s(n) = 'a'
+   type :: a
+  integer :: m = n
+  character(len=1):: t(n) = transfer('abcde ', s)
+   end type a
+end module foo
+
+program bar
+   use foo
+   implicit none
+   type(a) c
+   if (c%m /= n) stop 1
+   if (any(c%t /= ['a', 'b', 'c', 'd', 'e'])) stop 2
+end program bar

Re: [PATCH] expand description of poly_int conversions

[Martin Sebor]

On 02/26/2018 12:45 PM, Richard Sandiford wrote:

Martin Sebor  writes:

Richard,

If you agree, I'd like to update the conversion section of
the poly_int manual to make the conversion to make it clearer
that the to_constant() function can be used even with class
types like offset_int besides scalars.

Also, when testing this I also tried converting poly64_int
into wide_int but that doesn't work.  Is there a way to do
that?


Not in one go, because you have to specify the intended precision
of the wide_int when constructing it from something like HOST_WIDE_INT.
(That's deliberate.)



Thanks
Martin

gcc/ChangeLog:

* doc/poly-int.texi (is_constant): Expand.

Index: gcc/doc/poly-int.texi
===
--- gcc/doc/poly-int.texi   (revision 258004)
+++ gcc/doc/poly-int.texi   (working copy)
@@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co

 @item @var{value}.is_constant (&@var{c1})
 Return true if @code{poly_int} @var{value} is a compile-time constant,
-storing it in @var{c1} if so.  @var{c1} must be able to hold all
-constant values of @var{value} without loss of precision.
+storing it in @var{c1} if so.  @var{c1} may be a scalar or a wide int
+class type capable of holding all constant values of @var{value} without


Not sure about "a scalar or a wide int", since that implies that wide ints
aren't scalar.  Even more pedantic, sorry, but c1 is an object rather than
a type.

At a higher level, I'm a bit nervous about singling this out as a special
case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
wide_int to be combined in the (hopefully) natural way.  E.g. you can
add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
and so on.

But if we do keep it like this, how about:

  @var{c1} must be some form of integer object that can hold all constant
  values of @var{value} without loss of precision; it can be either a normal
  C++ integer or a wide-int class like @code{offset_int}.

?


Sure.  Attached is an update with your change.

Martin

gcc/ChangeLog:

	* doc/poly-int.texi (is_constant): Expand.

Index: gcc/doc/poly-int.texi
===
--- gcc/doc/poly-int.texi	(revision 258004)
+++ gcc/doc/poly-int.texi	(working copy)
@@ -836,8 +836,23 @@ Return true if @code{poly_int} @var{value} is a co
 
 @item @var{value}.is_constant (&@var{c1})
 Return true if @code{poly_int} @var{value} is a compile-time constant,
-storing it in @var{c1} if so.  @var{c1} must be able to hold all
-constant values of @var{value} without loss of precision.
+storing it in @var{c1} if so.  @var{c1} must be some form of integer
+object that can hold all constant values of @var{value} without loss
+of precision; it can be either a normal C++ integer or a wide-int class
+like @code{offset_int}.  The following example illustrates using
+the function to convert a @code{poly_int64} to @code{HOST_WIDE_INT}
+and to @code{offset_int}.
+@smallexample
+void f (poly_int64 pi)
+@{
+  HOST_WIDE_INT hwi;
+  if (pi.is_constant (&hwi))
+; // Use hwi...
+  offset_int off;
+  if (pi.is_constant (&off))
+; // Use off...
+@}
+@end smallexample
 
 @item @var{value}.to_constant ()
 Assert that @var{value} is a compile-time constant and return its value.

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Jakub Jelinek]

On Mon, Feb 26, 2018 at 10:32:27AM -0700, Martin Sebor wrote:
> That attached revision updates the pass to directly convert
> the poly64_int into offset_int using the API suggested by
> Richard (thanks again).  As discussed below, I've made no
> other changes.
> 
> Jakub, if you still have concerns that the false positive
> suppression logic isn't sufficiently effective please post
> a test case (or open a new bug).  I will look into it when
> I get a chance.

Yes, I still have major concerns, I explained what I'd like to see
(differentiate clearly between what base is, either by adding a flag or
having separate base and base_addr, then in the users you can easily find
out what is what and can decide based on that).

> Until then, I'd like to get the ICE fix committed. Please
> confirm that the attached patch is good to go in.

Due to the above concerns, I don't think the patch is good to go in.
If you find somebody else who thinks the patch is ok, I won't fight against
it though.

Jakub

[PATCH] Fix ICE with -mforce-indirect-call (PR target/84564)

[Jakub Jelinek]

Hi!

While this isn't a regression, it is ICE in newly added feature and
so should be fixed too.  The problem is that with -mforce-indirect-call
even direct calls are emitted as indirect, and if we have in 32-bit
mode a direct call to a regparm(3) function or a direct call to a function
we've optimized using regparm(3) convention internally, we can't really
tail call it, as there aren't any registers left for the address of the
function in the indirect call, eax/ecx/edx are used to pass arguments, esp
has fixed role and the rest needs to be already restored.

The following patch refuses to tail call in that case, similarly how we
reject to tail call an indirect call to a regparm(3) function.

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

2018-02-26  Jakub Jelinek  

PR target/84564
* config/i386/i386.c (ix86_function_ok_for_sibcall): Check for
regparm >= 3 with no arg reg available also for calls with
flag_force_indirect_call.  Pass decl to ix86_function_regparm.

* gcc.target/i386/pr84564.c: New test.

--- gcc/config/i386/i386.c.jj   2018-02-22 22:25:57.109993153 +0100
+++ gcc/config/i386/i386.c  2018-02-26 15:14:11.786294313 +0100
@@ -6411,7 +6411,8 @@ ix86_function_ok_for_sibcall (tree decl,
 function via GOT slot are indirect.  */
   if (!decl
  || (bind_global && flag_pic && !flag_plt)
- || (TARGET_DLLIMPORT_DECL_ATTRIBUTES && DECL_DLLIMPORT_P (decl)))
+ || (TARGET_DLLIMPORT_DECL_ATTRIBUTES && DECL_DLLIMPORT_P (decl))
+ || flag_force_indirect_call)
{
  /* Check if regparm >= 3 since arg_reg_available is set to
 false if regparm == 0.  If regparm is 1 or 2, there is
@@ -6420,7 +6421,7 @@ ix86_function_ok_for_sibcall (tree decl,
 ??? The symbol indirect call doesn't need a call-clobbered
 register.  But we don't know if this is a symbol indirect
 call or not here.  */
- if (ix86_function_regparm (type, NULL) >= 3
+ if (ix86_function_regparm (type, decl) >= 3
  && !cfun->machine->arg_reg_available)
return false;
}
--- gcc/testsuite/gcc.target/i386/pr84564.c.jj  2018-02-26 15:10:02.981296789 
+0100
+++ gcc/testsuite/gcc.target/i386/pr84564.c 2018-02-26 14:57:38.287304183 
+0100
@@ -0,0 +1,21 @@
+/* PR target/84564 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mforce-indirect-call" } */
+
+int a, b, c, d;
+int foo (void);
+
+static int
+bar (int x, int y, int z)
+{
+  while (a)
+if (foo ())
+  bar (x, y, z);
+  return 0;
+}
+
+int
+baz (void)
+{
+  return bar (b, c, d);
+}

Jakub

[PATCH] i386: Don't generate alias for function return thunk

[H.J. Lu]

Function return thunks shouldn't be aliased to indirect branch thunks
since indirect branch thunks are placed in COMDAT section and a COMDAT
section with indirect branch may not have function return thunk.  This
patch generates function return thunks directly.

Tested on i686 and x86-64.  OK for trunk?

H.J.
---
gcc/

PR target/84574
* config/i386/i386.c (indirect_thunk_needed): Update comments.
(indirect_thunk_bnd_needed): Likewise.
(indirect_thunks_used): Likewise.
(indirect_thunks_bnd_used): Likewise.
(indirect_return_needed): New.
(indirect_return_bnd_needed): Likewise.
(output_indirect_thunk_function): Add a bool argument for
function return.
(output_indirect_thunk_function): Don't generate alias for
function return thunk.
(ix86_code_end): Call output_indirect_thunk_function to generate
function return thunks.
(ix86_output_function_return): Set indirect_return_bnd_needed
and indirect_return_needed instead of indirect_thunk_bnd_needed
and indirect_thunk_needed.

gcc/testsuite/

PR target/84574
* gcc.target/i386/ret-thunk-9.c: Expect __x86_return_thunk
label instead of __x86_indirect_thunk label.
---
 gcc/config/i386/i386.c  | 95 +++--
 gcc/testsuite/gcc.target/i386/ret-thunk-9.c |  2 +-
 2 files changed, 36 insertions(+), 61 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 49f872d103f..9041485bd61 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -10799,19 +10799,23 @@ ix86_setup_frame_addresses (void)
labels in call and return thunks.  */
 static int indirectlabelno;
 
-/* True if call and return thunk functions are needed.  */
+/* True if call thunk function is needed.  */
 static bool indirect_thunk_needed = false;
-/* True if call and return thunk functions with the BND prefix are
-   needed.  */
+/* True if call thunk function with the BND prefix is needed.  */
 static bool indirect_thunk_bnd_needed = false;
 
 /* Bit masks of integer registers, which contain branch target, used
-   by call and return thunks functions.  */
+   by call thunk functions.  */
 static int indirect_thunks_used;
 /* Bit masks of integer registers, which contain branch target, used
-   by call and return thunks functions with the BND prefix.  */
+   by call thunk functions with the BND prefix.  */
 static int indirect_thunks_bnd_used;
 
+/* True if return thunk function is needed.  */
+static bool indirect_return_needed = false;
+/* True if return thunk function with the BND prefix is needed.  */
+static bool indirect_return_bnd_needed = false;
+
 /* True if return thunk function via CX is needed.  */
 static bool indirect_return_via_cx;
 /* True if return thunk function via CX with the BND prefix is
@@ -11007,17 +11011,18 @@ output_indirect_thunk (enum indirect_thunk_prefix 
need_prefix,
 /* Output a funtion with a call and return thunk for indirect branch.
If BND_P is true, the BND prefix is needed.  If REGNO != UNVALID_REGNUM,
the function address is in REGNO.  Otherwise, the function address is
-   on the top of stack.  */
+   on the top of stack.  Thunk is used for function return if RET_P is
+   true.  */
 
 static void
 output_indirect_thunk_function (enum indirect_thunk_prefix need_prefix,
-   unsigned int regno)
+   unsigned int regno, bool ret_p)
 {
   char name[32];
   tree decl;
 
   /* Create __x86_indirect_thunk/__x86_indirect_thunk_bnd.  */
-  indirect_thunk_name (name, regno, need_prefix, false);
+  indirect_thunk_name (name, regno, need_prefix, ret_p);
   decl = build_decl (BUILTINS_LOCATION, FUNCTION_DECL,
 get_identifier (name),
 build_function_type_list (void_type_node, NULL_TREE));
@@ -11060,50 +11065,6 @@ output_indirect_thunk_function (enum 
indirect_thunk_prefix need_prefix,
ASM_OUTPUT_LABEL (asm_out_file, name);
   }
 
-  /* Create alias for __x86_return_thunk/__x86_return_thunk_bnd or
- __x86_return_thunk_ecx/__x86_return_thunk_ecx_bnd.  */
-  bool need_alias;
-  if (regno == INVALID_REGNUM)
-need_alias = true;
-  else if (regno == CX_REG)
-{
-  if (need_prefix == indirect_thunk_prefix_bnd)
-   need_alias = indirect_return_via_cx_bnd;
-  else
-   need_alias = indirect_return_via_cx;
-}
-  else
-need_alias = false;
-
-  if (need_alias)
-{
-  char alias[32];
-
-  indirect_thunk_name (alias, regno, need_prefix, true);
-#if TARGET_MACHO
-  if (TARGET_MACHO)
-   {
- fputs ("\t.weak_definition\t", asm_out_file);
- assemble_name (asm_out_file, alias);
- fputs ("\n\t.private_extern\t", asm_out_file);
- assemble_name (asm_out_file, alias);
- putc ('\n', asm_out_file);
- ASM_OUTPUT_LABEL (asm_out_file, alias);
-   }
-#else
-  ASM_OUTPUT_

Re: [v3 PATCH] Implement the missing bits of LWG 2769

[Jonathan Wakely]

On 25/02/18 23:22 +0200, Ville Voutilainen wrote:

Tested partially on Linux-x64, will test with the full suite on Linux-PPC64.
Ok for trunk and the gcc-7 branch? This is theoretically a breaking change
for the branch, but the committee has decided that they don't want
the support for copyable-but-not-movable types.

2018-02-25  Ville Voutilainen  

   Implement the missing bits of LWG 2769
   * include/std/any (any_cast(const any&)): Add static_assert.
   (any_cast(any&)): Likewise.
   (any_cast(any&&)): Likewise, and remove the handling
   for copyable-but-not-movable type.
   * testsuite/20_util/any/misc/any_cast.cc: Adjust.
   * testsuite/20_util/any/misc/any_cast_neg.cc: Likewise, and
   add new tests.



diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index 466b7ca..e0aba3c 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -455,6 +455,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  static_assert(any::__is_valid_cast<_ValueType>(),
  "Template argument must be a reference or CopyConstructible type");
+  static_assert(is_constructible_v<_ValueType,
+   const _AnyCast<_ValueType>&>,


This template argument should be aligned with "_ValueType" on the
previous line, not with "is_constructible".

Looking at that file, I'm also wondering if we want the alias _AnyCast
to be defined at namespace scope. It's only used in a few function
bodies, and its name is a bit misleading.

Could you just do:

 using _Up = remove_cv_t>;

in the four functions that use it?

Then I think the is_constructible specializations would fit on one line
anyway.

But those are just stylistic issues, the technical side of the patch
is fine. I had to look up why we had two overloads for any_cast(any&&)
and that seems to be a leftover from experimental::any, so thanks for
cleaning that up too.

Re: [PATCH] libstdc++-v3: Check for TLS support on mingw

[Jonathan Wakely]

Apologies if you get this mail multiple times, I'm having some trouble
sending mail to @gcc.gnu.org lists.



On 19/02/18 09:59 +0100, Hugo Beauzée-Luyssen wrote:
> libstdc++-v3: Check for TLS support on mingw
>
> 2018-02-16  Hugo Beauzée-Luyssen  
>
>* crossconfig.m4: Check for TLS support on mignw

Typo "minwg"

>* configure: regenerate
>
> Index: libstdc++-v3/crossconfig.m4
> ===
> --- libstdc++-v3/crossconfig.m4 (revision 257730)
> +++ libstdc++-v3/crossconfig.m4 (working copy)
> @@ -197,6 +197,7 @@ case "${host}" in
> GLIBCXX_CHECK_LINKER_FEATURES
> GLIBCXX_CHECK_MATH_SUPPORT
> GLIBCXX_CHECK_STDLIB_SUPPORT
> +GCC_CHECK_TLS
> ;;
>   *-netbsd*)
> SECTION_FLAGS='-ffunction-sections -fdata-sections'

Hi, thanks for the patch. I don't think we can apply it now, as the
GCC trunk is only open for regression fixes until GCC 8 is released.

How was this tested? Will it work for all versions of mingw that we
support? Is TLS enabled for native builds? (If so we definitely need
this, because otherwise mingw cross-compilers are not ABI compatibnle
with native ones).

Re: [PATCH] expand description of poly_int conversions

[Richard Sandiford]

Martin Sebor  writes:
> On 02/26/2018 12:45 PM, Richard Sandiford wrote:
>> Martin Sebor  writes:
>>> Richard,
>>>
>>> If you agree, I'd like to update the conversion section of
>>> the poly_int manual to make the conversion to make it clearer
>>> that the to_constant() function can be used even with class
>>> types like offset_int besides scalars.
>>>
>>> Also, when testing this I also tried converting poly64_int
>>> into wide_int but that doesn't work.  Is there a way to do
>>> that?
>>
>> Not in one go, because you have to specify the intended precision
>> of the wide_int when constructing it from something like HOST_WIDE_INT.
>> (That's deliberate.)
>>
>>>
>>> Thanks
>>> Martin
>>>
>>> gcc/ChangeLog:
>>>
>>> * doc/poly-int.texi (is_constant): Expand.
>>>
>>> Index: gcc/doc/poly-int.texi
>>> ===
>>> --- gcc/doc/poly-int.texi   (revision 258004)
>>> +++ gcc/doc/poly-int.texi   (working copy)
>>> @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
>>>
>>>  @item @var{value}.is_constant (&@var{c1})
>>>  Return true if @code{poly_int} @var{value} is a compile-time constant,
>>> -storing it in @var{c1} if so.  @var{c1} must be able to hold all
>>> -constant values of @var{value} without loss of precision.
>>> +storing it in @var{c1} if so.  @var{c1} may be a scalar or a wide int
>>> +class type capable of holding all constant values of @var{value} without
>>
>> Not sure about "a scalar or a wide int", since that implies that wide ints
>> aren't scalar.  Even more pedantic, sorry, but c1 is an object rather than
>> a type.
>>
>> At a higher level, I'm a bit nervous about singling this out as a special
>> case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
>> wide_int to be combined in the (hopefully) natural way.  E.g. you can
>> add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
>> and so on.
>>
>> But if we do keep it like this, how about:
>>
>>   @var{c1} must be some form of integer object that can hold all constant
>>   values of @var{value} without loss of precision; it can be either a normal
>>   C++ integer or a wide-int class like @code{offset_int}.
>>
>> ?
>
> Sure.  Attached is an update with your change.

LGTM (but I can't approve).

Thanks,
Richard

Re: [C++ PATCH] Fix ICE in cxx_eval_vec_init_1 (PR c++/84558)

[Jason Merrill]

OK.

On Mon, Feb 26, 2018 at 2:57 PM, Jakub Jelinek  wrote:
> Hi!
>
> The PR70001 optimization in cxx_eval_vec_init_1 uses
> initializer_constant_valid_p (eltinit, TREE_TYPE (eltinit))
> which doesn't work if eltinit is NULL.  This can happen if
> *non_constant_p is true, but ctx->quiet is true as well (for
> *non_constant_p && !ctx->quiet we break the cycle early).
> No initializer can be treated like a valid initializer and will
> have the advantage that we don't repeat the body for every array element
> and just do it once.  The caller will ignore the return value anyway
> when *non_constant_p.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-02-26  Jakub Jelinek  
>
> PR c++/84558
> * constexpr.c (cxx_eval_vec_init_1): For reuse, treat NULL eltinit 
> like
> a valid constant initializer.  Formatting fixes.
>
> * g++.dg/cpp1y/pr84558.C: New test.
>
> --- gcc/cp/constexpr.c.jj   2018-02-26 10:46:02.162316172 +0100
> +++ gcc/cp/constexpr.c  2018-02-26 14:07:38.705532369 +0100
> @@ -2959,9 +2959,8 @@ cxx_eval_vec_init_1 (const constexpr_ctx
>   if (!lvalue_p (init))
> eltinit = move (eltinit);
>   eltinit = force_rvalue (eltinit, tf_warning_or_error);
> - eltinit = (cxx_eval_constant_expression
> -(&new_ctx, eltinit, lval,
> - non_constant_p, overflow_p));
> + eltinit = cxx_eval_constant_expression (&new_ctx, eltinit, lval,
> + non_constant_p, overflow_p);
> }
>if (*non_constant_p && !ctx->quiet)
> break;
> @@ -2974,12 +2973,13 @@ cxx_eval_vec_init_1 (const constexpr_ctx
>else
> CONSTRUCTOR_APPEND_ELT (*p, idx, eltinit);
>/* Reuse the result of cxx_eval_constant_expression call
> - from the first iteration to all others if it is a constant
> - initializer that doesn't require relocations.  */
> +from the first iteration to all others if it is a constant
> +initializer that doesn't require relocations.  */
>if (reuse
>   && max > 1
> - && (initializer_constant_valid_p (eltinit, TREE_TYPE (eltinit))
> - == null_pointer_node))
> + && (eltinit == NULL_TREE
> + || (initializer_constant_valid_p (eltinit, TREE_TYPE (eltinit))
> + == null_pointer_node)))
> {
>   if (new_ctx.ctor != ctx->ctor)
> eltinit = new_ctx.ctor;
> --- gcc/testsuite/g++.dg/cpp1y/pr84558.C.jj 2018-02-26 14:33:56.575318295 
> +0100
> +++ gcc/testsuite/g++.dg/cpp1y/pr84558.C2018-02-26 14:33:33.142318527 
> +0100
> @@ -0,0 +1,6 @@
> +// PR c++/84558
> +// { dg-do compile { target c++14 } }
> +
> +struct A { static int i; constexpr A () { i = 0; } };
> +struct B { A a[2][3][4]; };
> +B b;
>
> Jakub

C++ PATCH for c++/84559, ICE with constexpr VLA

[Jason Merrill]

Clang rejects this testcase saying that the VLA is a non-literal type,
but I think we don't want that; we want to allow VLAs in a constexpr
function, where the length can be constant during constexpr
evaluation.

In this case, however, we are dealing with a constexpr variable rather
than a variable in a constexpr function, so we want to reject the VLA.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit d63c30c86d45831f20c4dc35f4ffaac2cfdd2588
Author: Jason Merrill 
Date:   Mon Feb 26 15:32:32 2018 -0500

PR c++/84559 - ICE with constexpr VLA.

* constexpr.c (ensure_literal_type_for_constexpr_object): Check
for constexpr variable with VLA type.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 26d0d099a05..92b13219215 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -112,6 +112,13 @@ ensure_literal_type_for_constexpr_object (tree decl)
  cp_function_chain->invalid_constexpr = true;
}
}
+  else if (DECL_DECLARED_CONSTEXPR_P (decl)
+  && variably_modified_type_p (type, NULL_TREE))
+   {
+ error ("% variable %qD has variably-modified type %qT",
+decl, type);
+ decl = error_mark_node;
+   }
 }
   return decl;
 }
diff --git a/gcc/testsuite/g++.dg/ext/constexpr-vla5.C 
b/gcc/testsuite/g++.dg/ext/constexpr-vla5.C
new file mode 100644
index 000..565d40ab077
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/constexpr-vla5.C
@@ -0,0 +1,7 @@
+// PR c++/84559
+// { dg-do compile { target c++11 } }
+
+void foo(int i)
+{
+  constexpr char x[i] = "";// { dg-error "" }
+}

Re: [PATCH][AArch64] PR84114: Avoid reassociating FMA

[James Greenhalgh]

On Thu, Feb 22, 2018 at 11:38:03AM +, Wilco Dijkstra wrote:
> As discussed in the PR, the reassociation phase runs before FMAs are formed
> and so can significantly reduce FMA opportunities.  Although reassociation
> could be switched off, it helps in many cases, so a better alternative is to
> only avoid reassociation of floating point additions.  This fixes the testcase
> and gives 1% speedup on SPECFP2017, fixing the performance regression.
> 
> OK for commit?

This is OK as a fairly safe fix for stage 4. We should fix reassociation
properly in GCC 9.

Thanks,
James

> 
> ChangeLog:
> 2018-02-23  Wilco Dijkstra  
> 
>   PR tree-optimization/84114
>   * config/aarch64/aarch64.c (aarch64_reassociation_width)
>   Avoid reassociation of FLOAT_MODE addition.
> --
> 
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 
> b3d5fde171920e5759046a4bd61cfcf9eb78d7dd..5f9541cf700aaf18c1f1ac73054614e2932781e4
>  100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -1109,15 +1109,16 @@ aarch64_min_divisions_for_recip_mul (machine_mode 
> mode)
>return aarch64_tune_params.min_div_recip_mul_df;
>  }
>  
> +/* Return the reassociation width of treeop OPC with mode MODE.  */
>  static int
> -aarch64_reassociation_width (unsigned opc ATTRIBUTE_UNUSED,
> -  machine_mode mode)
> +aarch64_reassociation_width (unsigned opc, machine_mode mode)
>  {
>if (VECTOR_MODE_P (mode))
>  return aarch64_tune_params.vec_reassoc_width;
>if (INTEGRAL_MODE_P (mode))
>  return aarch64_tune_params.int_reassoc_width;
> -  if (FLOAT_MODE_P (mode))
> +  /* Avoid reassociating floating point addition so we emit more FMAs.  */
> +  if (FLOAT_MODE_P (mode) && opc != PLUS_EXPR)
>  return aarch64_tune_params.fp_reassoc_width;
>return 1;
>  }

Re: [v3 PATCH] Implement the missing bits of LWG 2769

[Ville Voutilainen]

On 26 February 2018 at 22:52, Jonathan Wakely  wrote:
> But those are just stylistic issues, the technical side of the patch
> is fine. I had to look up why we had two overloads for any_cast(any&&)
> and that seems to be a leftover from experimental::any, so thanks for
> cleaning that up too.


It was added by me when we (well, I) decided to support
copyable-but-not-movable types.
See, the current specification doesn't allow getting those types out
of an rvalue any by value.
Such an operation will perform an ill-formed move, with the
two-overload solution it would've
fallen back on copying.
Weird as such types are, I thought it not-too-much-trouble to
SFINAE-hack it to work. The specification
has since been made stricter so that it doesn't leave any
implementation leeway to allow that,
so hence the removal of that lenience.

[PATCH/testsuite] avoid test failures with -fpic

[Martin Sebor]

Compiling a number of tests with -fpic results in failures
because the tests make use of non-inline, extern helper
functions defined within, and these helpers must be assumed
to have been superimposed elsewhere.

For example:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01762.html

I took a quick pass through the failures and declared
the helpers static to avoid them.  I only did this in failure
tests I recognized because I introduced them myself being unaware
that building the tests with -fpic was expected to work.

This should make the -fpic test results a lot cleaner than
they currently are, although I don't think it brings them
up to par with non-fpic results.

Unless there are objections in the next day or so I'll commit
the fixes as obvious.

Martin

gcc/testsuite/ChangeLog:

	* c-c++-common/Warray-bounds-2.c: Declare helper static to avoid
	-fpic test failures.
	* c-c++-common/Wrestrict-2.c: Same.
	* c-c++-common/Wstringop-truncation.c: Same.
	* gcc.dg/Warray-bounds-22.c: Same.
	* gcc.dg/Wstringop-overflow.c: Same.
	* gcc.dg/attr-alloc_size-3.c (unsigned_range): Same.
	(signed_range): Same.
	(unsigned_anti_range): Same.
	* gcc.dg/attr-alloc_size-4.c (unsigned_range): Same.
	(signed_range): Same.
	(unsigned_anti_range): Same.
	* gcc.dg/attr-alloc_size-7.c: Same.
	* gcc.dg/attr-alloc_size-8.c: Same.
	* gcc.dg/builtin-alloc-size.c: Same.
	* gcc.dg/builtin-stpncpy.c: Same.
	* gcc.dg/builtins-nonnull.c: Same.
	* gcc.dg/nonnull-4.c (g16_1_3_5_7_11_13): Same.
	* gcc.dg/pr79214.c: Same.
	* gcc.dg/tree-ssa/builtin-snprintf-warn-1.c: Same.
	* gcc.dg/tree-ssa/builtin-snprintf-warn-2.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-5.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-11.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-12.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-13.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-14.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-19.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: Same.


diff --git a/gcc/testsuite/c-c++-common/Warray-bounds-2.c b/gcc/testsuite/c-c++-common/Warray-bounds-2.c
index becb3d4..db05f04 100644
--- a/gcc/testsuite/c-c++-common/Warray-bounds-2.c
+++ b/gcc/testsuite/c-c++-common/Warray-bounds-2.c
@@ -24,7 +24,8 @@ struct __attribute__ ((packed)) Array
 
 /* Exercise memcpy out-of-bounds offsets with an array of known size.  */
 
-void wrap_memcpy_src_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
+static void
+wrap_memcpy_src_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
 {
   memcpy (d, s + i, n);   /* { dg-warning "offset 46 is out of the bounds \\\[0, 45] of object .ar. with type .(struct )?Array." "memcpy" } */
 }
@@ -39,7 +40,8 @@ void call_memcpy_src_xsize (char *d, size_t n)
 
 /* Exercise memcpy out-of-bounds offsets with an array of unknown size.  */
 
-void wrap_memcpy_src_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
+static void
+wrap_memcpy_src_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
 {
   memcpy (d, s + i, n);   /* { dg-warning "pointer overflow between offset \[0-9\]+ and size 3" "memcpy" } */
 }
@@ -49,7 +51,8 @@ void call_memcpy_src_diff_max (char *d, const char *s, size_t n)
   wrap_memcpy_src_diff_max (d, s, MAX, 3);
 }
 
-void wrap_memcpy_dst_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
+static void
+wrap_memcpy_dst_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
 {
   memcpy (d + i, s, n);   /* { dg-warning "offset 47 is out of the bounds \\\[0, 45] of object .ar1. with type .(struct )?Array." "memcpy" } */
 }
@@ -62,7 +65,8 @@ void call_memcpy_dst_xsize (const char *s, size_t n)
   sink (&ar1);
 }
 
-void wrap_memcpy_dst_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
+static void
+wrap_memcpy_dst_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
 {
   memcpy (d + i, s, n);   /* { dg-warning "offset -?\[0-9\]+ is out of the bounds \\\[0, 45] of object .ar2. with type .(struct )?Array." "memcpy" } */
 }
@@ -76,7 +80,7 @@ void call_memcpy_dst_diff_max (const char *s, size_t n)
 }
 
 
-void wrap_strcat_src_xsize (char *d, const char *s, ptrdiff_t i)
+static void wrap_strcat_src_xsize (char *d, const char *s, ptrdiff_t i)
 {
   strcat (d, s + i);   /* { dg-warning "offset 46 is out of the bounds \\\[0, 45] of object .ar3. with type .(struct )?Array." "strcat" } */
 }
@@ -89,7 +93,7 @@ void call_strcat_src_xsize (char *d)
   sink (&ar3);
 }
 
-void wrap_strcat_dst_xsize (char *d, const char *s, ptrdiff_t i)
+static void wrap_strcat_dst_xsize (char *d, const char *s, ptrdiff_t i)
 {
   strcat (d + i, s);   /* { dg-warning "offset 47 is out of the bounds \\\[0, 45] of object .ar4. with type .(struct )?Array." "strcat" } */
 }
@@ -103,7 +107,7 @@ void call_strcat_dst_xsize (const char *s)
 }
 
 
-void wrap_strcpy_src_xsize (char *d, const char *s, ptrdiff_t i)
+static void wrap_strcpy_src_xsize (char *d, const char *s, ptrdiff_t i)
 {
  

[PATCH] PR c/46921 Lost side effect when struct initializer expression uses comma operator

[dave . pagan]

This patch fixes improper handling of comma operator expression in a 
struct field initializer as described in:


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

Currently, function output_init_element () does not evaluate the left 
hand expression in a comma operator that's used for a struct initializer 
field if the right hand side is zero-sized. However, the left hand 
expression must be evaluated if it's found to have side effects (for 
example, a function call).


Patch was successfully bootstrapped and tested on x86_64-linux.

--Dave


/c
2018-02-26  David Pagan  

PR c/46921
* c-typeck.c (output_init_element): Ensure field initializer 
expression is always evaluated if there are side effects.

/testsuite
2018-02-26  David Pagan  

PR c/46921
* gcc.dg/pr46921.c: New test.
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(revision 257975)
+++ gcc/c/c-typeck.c(working copy)
@@ -9208,12 +9208,14 @@ output_init_element (location_t loc, tree value, t
  "enum conversion in initialization is invalid in C++");
 }
 
-  /* If this field is empty (and not at the end of structure),
- don't do anything other than checking the initializer.  */
+  /* If this field is empty and does not have side effects (and is not at 
+ the end of structure), don't do anything other than checking the 
+ initializer.  */
   if (field
   && (TREE_TYPE (field) == error_mark_node
  || (COMPLETE_TYPE_P (TREE_TYPE (field))
  && integer_zerop (TYPE_SIZE (TREE_TYPE (field)))
+ && !TREE_SIDE_EFFECTS (new_value)
  && (TREE_CODE (constructor_type) == ARRAY_TYPE
  || DECL_CHAIN (field)
 return;
Index: gcc/testsuite/gcc.dg/pr46921.c
===
--- gcc/testsuite/gcc.dg/pr46921.c  (revision 0)
+++ gcc/testsuite/gcc.dg/pr46921.c  (working copy)
@@ -0,0 +1,40 @@
+/* PR c/46921  lost side effect when struct initializer expr uses comma
+  operator  */
+
+/* { dg-do run } */
+/* { dg-options "" } */
+
+extern int printf(const char *, ...);
+extern void abort (void);
+
+typedef struct __uws_0 { } uw_unit;
+uw_unit uw_unit_v = {};
+
+struct __uws_1 
+{
+  struct __uws_0 __uwf_1;
+  struct __uws_1* __uwf_2;
+};
+
+static int left_hand_eval = 0;
+
+static void
+foo (const char *s)
+{
+  ++left_hand_eval;
+  printf("%s", s);
+}
+
+int
+main ()
+{
+  struct __uws_1 tmp = {(foo("Inner\n"), uw_unit_v)};
+  
+  printf("Outer\n");
+  /* left hand expression in comma operator initializer must always be
+ evaluated if there are side effects.  */
+  if (!left_hand_eval)
+abort ();
+  
+  return 0;
+}

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Michael Eager]

On 02/25/2018 11:44 PM, Andrew Guirguis wrote:

Dears,

Kindly find attached the patch bundle for Microblaze 
'-mpic-data-text-relative' feature.


Description of the feature in the following link:
https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md 



Bundle includes:
1) Change logs for GCC, binutils
2) GCC Test results and comparison with the original.
3) New Test case (picdtr.c)
4) The Patches (against current heads)


Hi Andrew --

Thanks for the submission.  I have the following recommendations:

Submit each patch to the appropriate project mailing list.  Only submit
the patch for the specific project, without patches for other projects.

Include a description of the changes with each patch as well as the
changelog.  Include the patch in your email or as an attachment.

It isn't clear why you sent your submission to the gdb-patches mailing
list, since there don't appear to be any GDB changes.  Conversely, it is
not clear why you did not include the binutils mailing list, since you
include a patch to that project.

Be sure to follow GNU coding conventions,  Check brace placement,
indent, maximum line length, if statements, etc.  I noticed a number
of places where these conventions are not followed in your patches.

GCC regression tests should include all tests (e.g., gcc.dg), not just 
the limited number of MicroBlaze-specific tests.


--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306

Re: [PING] [PATCH] consider successor blocks when avoiding -Wstringop-truncation (PR 84468)

[Martin Sebor]

On 02/26/2018 12:13 PM, Jeff Law wrote:

On 02/24/2018 05:11 PM, Martin Sebor wrote:

Attached is an updated patch with a fix for a bad assumption
exposed by building the linux kernel.

On 02/19/2018 07:50 PM, Martin Sebor wrote:

PR 84468 points out a false positive in -Wstringop-truncation
in code like this:

  struct A { char a[4]; };

  void f (struct A *p, const struct A *q)
  {
if (p->a)
  strncpy (p->a, q->a, sizeof p->a - 1);   // warning here

p->a[3] = '\0';
  }

The warning is due to the code checking only the same basic block
as the one with the strncpy call for an assignment to the destination
to avoid it, but failing to check the successor basic block if there
is no subsequent statement in the current block.  (Eliminating
the conditional is being tracked in PR 21474.)

The attached test case adds logic to avoid this false positive.
I don't know under what circumstances there could be more than
one successor block here so I don't handle that case.

So this is feeling more and more like we need to go back to the ideas
behind checking the virtual operand chains.

The patch as-written does not properly handle the case where BB has
multiple outgoing edges.  For gcc-8 you could probably get away with
checking that you have precisely one outgoing edge without EDGE_ABNORMAL
set in its flags in addition to the checks you're already doing.

But again, it's feeling more and more like the right fix is to go back
and walk the virtual operands.


I intentionally kept the patch as simple as possible to minimize
risk at this late stage.

Attached is a more robust version that handles multiple outgoing
edges and avoids those with the EDGE_ABNORMAL bit set.  Retested
on x86_64 and with the Linux kernel.

Enhancing this code to handle more complex cases is on my to-do
list for stage 1 (e.g., to handle bug 84561 where MEM_REF defeats
the detection of the nul assignment).

Martin
PR tree-optimization/84468 - bogus -Wstringop-truncation despite assignment after conditional strncpy

gcc/ChangeLog:

	PR tree-optimization/84468
	* tree-ssa-strlen.c (suppress_stringop_trunc): New function to also
	consider successor basic blocks.
	(maybe_diag_stxncpy_trunc): Call it.
gcc/testsuite/ChangeLog:

	PR tree-optimization/84468
	* gcc.dg/Wstringop-truncation.c: New test.
	* gcc.dg/Wstringop-truncation-2.c: New test.

Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c	(revision 258016)
+++ gcc/tree-ssa-strlen.c	(working copy)
@@ -1781,6 +1781,83 @@ is_strlen_related_p (tree src, tree len)
   return false;
 }
 
+/* Return true if -Wstringop-truncation for statement STMT should be
+   suppressed.  GSI is an interator initially pointing at STMT and
+   set to subsequent statements on recursive calls by the function.
+   REF refers to the object being referred to.  VISITED is a bitmap
+   of visited basic blocks to prevent infinite recursion.  */
+
+static bool
+suppress_stringop_trunc (gimple *stmt, gimple_stmt_iterator gsi, tree ref,
+			 bitmap visited)
+{
+  if (gsi_end_p (gsi))
+return false;
+
+  gimple *cur_stmt = gsi_stmt (gsi);
+  if (is_gimple_debug (cur_stmt) || stmt == cur_stmt)
+  gsi_next_nondebug (&gsi);
+
+  gimple *next_stmt = gsi_stmt (gsi);
+  if (!next_stmt)
+{
+  /* When there is no statement in the same basic block check
+	 the immediate successor block.  */
+  if (basic_block bb = gimple_bb (cur_stmt))
+	{
+	  /* Return if the basic block has already been visited.  */
+	  if (!bitmap_set_bit (visited, bb->index))
+	return false;
+
+	  edge e;
+	  edge_iterator ei;
+	  FOR_EACH_EDGE (e, ei, bb->succs)
+	{
+	  if (e->flags & EDGE_ABNORMAL)
+		continue;
+
+	  basic_block nextbb = e->dest;
+	  gimple_stmt_iterator it = gsi_start_bb (nextbb);
+	  if (suppress_stringop_trunc (stmt, it, ref, visited))
+		return true;
+	}
+	}
+
+  return false;
+}
+
+  if (!is_gimple_assign (next_stmt))
+return false;
+
+  tree lhs = gimple_assign_lhs (next_stmt);
+  tree_code code = TREE_CODE (lhs);
+  if (code == ARRAY_REF || code == MEM_REF)
+lhs = TREE_OPERAND (lhs, 0);
+
+  tree func = gimple_call_fndecl (stmt);
+  if (DECL_FUNCTION_CODE (func) == BUILT_IN_STPNCPY)
+{
+  tree ret = gimple_call_lhs (stmt);
+  if (ret && operand_equal_p (ret, lhs, 0))
+	return true;
+}
+
+  /* Determine the base address and offset of the reference,
+ ignoring the innermost array index.  */
+  if (TREE_CODE (ref) == ARRAY_REF)
+ref = TREE_OPERAND (ref, 0);
+
+  poly_int64 dstoff;
+  tree dstbase = get_addr_base_and_unit_offset (ref, &dstoff);
+
+  poly_int64 lhsoff;
+  tree lhsbase = get_addr_base_and_unit_offset (lhs, &lhsoff);
+  return (lhsbase
+	  && dstbase
+	  && known_eq (dstoff, lhsoff)
+	  && operand_equal_p (dstbase, lhsbase, 0));
+}
+
 /* Called by handle_builtin_stxncpy and by gimple_fold_builtin_strncpy
in gimple-fold.c.
Check to see if the specified bound 

Re: [PATCH] Correct debug for -mcall-ms2sysv-xlogues stubs (PR target/83917, take 2)

[Daniel Santos]

On 02/26/2018 02:20 AM, Jakub Jelinek wrote:
> On Sun, Feb 25, 2018 at 05:56:28PM -0600, Daniel Santos wrote:
>>> --- libgcc/config/i386/i386-asm.h.jj2018-01-03 10:42:56.317763517 
>>> +0100
>>> +++ libgcc/config/i386/i386-asm.h   2018-02-22 15:33:43.812922298 +0100
>>> @@ -27,8 +27,47 @@ see the files COPYING3 and COPYING.RUNTI
>>>  #define I386_ASM_H
>>>  
>>>  #include "auto-target.h"
>>> +#undef PACKAGE_VERSION
>>> +#undef PACKAGE_NAME
>>> +#undef PACKAGE_STRING
>>> +#undef PACKAGE_TARNAME
>>> +#undef PACKAGE_URL
>> This is a beautiful, temporary(?) fix to an ugly problem!
>>
>>>  #include "auto-host.h"
>>> --- libgcc/config/i386/cygwin.S.jj  2018-01-03 10:42:56.309763515 +0100
>>> +++ libgcc/config/i386/cygwin.S 2018-02-22 15:30:34.597925496 +0100
>>> @@ -23,31 +23,13 @@
>>>   * .
>>>   */
>>>  
>>> -#include "auto-host.h"
>> The following include should be here.
>>
>> +#include "i386-asm.h"
> I don't understand this.  i386-asm.h needs (both before my patch and after
> it) both auto-host.h and auto-target.h, as it tests
> HAVE_GAS_SECTIONS_DIRECTIVE (this one newly, comes from cygwin.S)

The problem is that HAVE_GAS_SECTIONS_DIRECTIVE gets defined (or not) in
../../gcc/auto-host.h, but you are testing it before including
auto-host.h, either directly or via i386-asm.h.  So if i386-asm.h
depends upon HAVE_GAS_SECTIONS_DIRECTIVE first being defined then it is
a circular dependency.

In its current form, cygwin.S would never define USE_GAS_CFI_DIRECTIVES
prior to including i386-asm.h and also never emit
    .cfi_sections    .debug_frame
and rather or not USE_GAS_CFI_DIRECTIVES ends up being defined to 1 or 0
depends upon the test of __GCC_HAVE_DWARF2_CFI_ASM in i386-asm.h.

So this area is new for me, but I don't understand why we're testing
HAVE_GAS_SECTIONS_DIRECTIVE in cygwin.S and __GCC_HAVE_DWARF2_CFI_ASM
when included from one of the stubs.  Is this an error, or a lack of my
understanding or both? :)

> HAVE_GAS_HIDDEN
> macros defined in auto-host.h
> and
> HAVE_AS_AVX
> macro defined in auto-target.h.
> Including auto-host.h when i386-asm.h will include it again just doesn't
> work, these headers don't have multiple inclusion guards.  And only including
> auto-target.h will work only if the
> .hidden
> and
> .cfi_sections .debug_frame
> tests are duplicated from gcc/configure.ac to libgcc/configure.ac, then we
> could include just auto-target.h in i386-asm.h.
> I've just followed what i386-asm.h has been doing.

And it's possible that I failed to test something correctly before
presuming it to be available, although I *think* the test for .hidden is
good.

>
>   Jakub
>

Thanks for your work on this.  If we need to test for CFI directives
differently when being included from cygwin.S, maybe we can just define
a simple cpp macro to indicate this and let i386-asm.h encapsulate the
implementation of it (e.g., testing HAVE_GAS_SECTIONS_DIRECTIVE or
__GCC_HAVE_DWARF2_CFI_ASM as appropriate).

Ultimately, the proper cleanup will be moving these tests out of
{gcc,libgcc}/configure.ac and into .m4 files in the root config
directory so that we don't uglify them with massive copy & pastes. 
These tests are also fairly complex as there are a lot of dependencies. 
m4 isn't my strong suite, but I can look at this after we're out of code
freeze.

Daniel

C++ PATCH for c++/84520, ICE with generic lambda in NSDMI

[Jason Merrill]

lambda_expr_this_capture assumes that we can find the fake 'this'
inserted while parsing an NSDMI, but it isn't there if we are
instantiating, rather than parsing, a generic lambda.

Tested x86_64-pc-linux-gnu, applying to trunk/7/6.
commit 9c64c953f0595e88cd911d488a415c8568934864
Author: Jason Merrill 
Date:   Mon Feb 26 18:01:05 2018 -0500

PR c++/84520 - ICE with generic lambda in NSDMI.

* lambda.c (lambda_expr_this_capture): Don't look for fake NSDMI
'this' in a generic lambda instantiation.

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 6a798266f12..3f77df037a2 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -758,11 +758,14 @@ lambda_expr_this_capture (tree lambda, bool add_capture_p)
 lambda_stack);
 
  if (LAMBDA_EXPR_EXTRA_SCOPE (tlambda)
+ && !COMPLETE_TYPE_P (LAMBDA_EXPR_CLOSURE (tlambda))
  && TREE_CODE (LAMBDA_EXPR_EXTRA_SCOPE (tlambda)) == FIELD_DECL)
{
  /* In an NSDMI, we don't have a function to look up the decl in,
 but the fake 'this' pointer that we're using for parsing is
-in scope_chain.  */
+in scope_chain.  But if the closure is already complete, we're
+in an instantiation of a generic lambda, and the fake 'this'
+is gone.  */
  init = scope_chain->x_current_class_ptr;
  gcc_checking_assert
(init && (TREE_TYPE (TREE_TYPE (init))
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nsdmi1.C 
b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nsdmi1.C
new file mode 100644
index 000..89ce519d812
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nsdmi1.C
@@ -0,0 +1,8 @@
+// PR c++/84520
+// { dg-do compile { target c++14 } }
+
+struct A
+{
+  static void foo(int);
+  void (*f)(int) = [](auto i) { foo(i); };
+};

C++ PATCH for c++/84441, ICE with base initialized from ?:

[Jason Merrill]

A while back I added unsafe_copy_elision_p to catch cases where we
don't want to initialize a base subobject directly from a call because
it might clobber data packed into the tail padding of the base.  Later
I extended that function to look into COMPOUND_EXPR.  This patch
further adjusts it to look into COND_EXPR.

Tested x86_64-pc-linux-gnu, applying to trunk/7/6.
commit 145aa5adf95adfa581f663e9a799f5fe0c6418cb
Author: Jason Merrill 
Date:   Mon Feb 26 18:23:30 2018 -0500

PR c++/84441 - ICE with base initialized from ?:

* call.c (unsafe_copy_elision_p): Handle COND_EXPR.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c47befdbf7f..11fe28292fb 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7580,6 +7580,15 @@ unsafe_copy_elision_p (tree target, tree exp)
   /* build_compound_expr pushes COMPOUND_EXPR inside TARGET_EXPR.  */
   while (TREE_CODE (init) == COMPOUND_EXPR)
 init = TREE_OPERAND (init, 1);
+  if (TREE_CODE (init) == COND_EXPR)
+{
+  /* We'll end up copying from each of the arms of the COND_EXPR directly
+into the target, so look at them. */
+  if (tree op = TREE_OPERAND (init, 1))
+   if (unsafe_copy_elision_p (target, op))
+ return true;
+  return unsafe_copy_elision_p (target, TREE_OPERAND (init, 2));
+}
   return (TREE_CODE (init) == AGGR_INIT_EXPR
  && !AGGR_INIT_VIA_CTOR_P (init));
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/elision3.C 
b/gcc/testsuite/g++.dg/cpp0x/elision3.C
new file mode 100644
index 000..7c5c8b9f0b9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/elision3.C
@@ -0,0 +1,21 @@
+// PR c++/84441
+// { dg-do compile { target c++11 } }
+
+struct B {
+  int *b;
+};
+struct A {
+  B b;
+  A (A &&);
+};
+struct C {
+  A c;
+  int d;
+};
+C bar ();
+struct D : C {
+  D ()
+: C (0 ? bar () : bar ())
+  {}
+};
+D d;

C++ PATCH for c++/84560, ICE capturing multi-dimensional VLA

[Jason Merrill]

The code was already there to give an error for this case, we just
weren't hitting it because array_of_runtime_bound_p was incorrectly
returning true.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1106dfa9e9df6e4dddb75c50db57cff953017fc7
Author: Jason Merrill 
Date:   Mon Feb 26 20:42:13 2018 -0500

PR c++/84560 - ICE capturing multi-dimensional VLA.

* tree.c (array_of_runtime_bound_p): False if the element is
variably-modified.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 41d9002d8f9..9b9e36a1173 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1043,6 +1043,8 @@ array_of_runtime_bound_p (tree t)
 {
   if (!t || TREE_CODE (t) != ARRAY_TYPE)
 return false;
+  if (variably_modified_type_p (TREE_TYPE (t), NULL_TREE))
+return false;
   tree dom = TYPE_DOMAIN (t);
   if (!dom)
 return false;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla2.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla2.C
new file mode 100644
index 000..d4de131fc23
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla2.C
@@ -0,0 +1,12 @@
+// PR c++/84560
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+void f() {
+  int n = 1;
+  int m = 1;
+  int d[n][m];
+  [&]() {
+return d[1];   // { dg-error "variabl" }
+  }();
+}

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

[Ian Lance Taylor via gcc-patches]

On Sat, Feb 24, 2018 at 1:54 AM, Roland McGrath via gcc-patches
 wrote:
> Anybody want to look at this?
>
> It rebases identically on today's trunk.  I'd like to commit it to
> trunk and gcc-7-branch and gcc-6-branch ideally.

You are recreating the conditions used in
default_elf_asm_named_section, so I think you ought to have comments
referring back and forth between them.

This is OK with the two additional comments.

Ian



> On Thu, Sep 22, 2016 at 1:15 PM, Roland McGrath  wrote:
>> ping?
>>
>> On Thu, Sep 15, 2016 at 4:09 PM, Roland McGrath  wrote:
>>> This fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 (which I've
>>> just filed).
>>>
>>> OK for trunk?
>>>
>>> I'm not sure if this kind of fix is appropriate for gcc-6-branch or not,
>>> but I'd like to backport it there too if it is acceptable.
>>>
>>>
>>> Thanks,
>>> Roland
>>>
>>>
>>> gcc/
>>> 2016-09-15  Roland McGrath  <
>>>
>>> PR other/77609
>>> * varasm.c (default_section_type_flags): Set SECTION_NOTYPE for
>>> any section for which we don't know a specific type it should have,
>>> regardless of name.  Previously this was done only for the exact
>>> names ".init_array", ".fini_array", and ".preinit_array".
>>>
>>> diff --git a/gcc/varasm.c b/gcc/varasm.c
>>> index 00a9b30..0d7ea38 100644
>>> --- a/gcc/varasm.c
>>> +++ b/gcc/varasm.c
>>> @@ -6210,15 +6210,20 @@ default_section_type_flags (tree decl, const
>>> char *name, int reloc)
>>>|| strncmp (name, ".gnu.linkonce.tb.", 17) == 0)
>>>  flags |= SECTION_TLS | SECTION_BSS;
>>>
>>> -  /* These three sections have special ELF types.  They are neither
>>> - SHT_PROGBITS nor SHT_NOBITS, so when changing sections we don't
>>> - want to print a section type (@progbits or @nobits).  If someone
>>> - is silly enough to emit code or TLS variables to one of these
>>> - sections, then don't handle them specially.  */
>>> -  if (!(flags & (SECTION_CODE | SECTION_BSS | SECTION_TLS))
>>> -  && (strcmp (name, ".init_array") == 0
>>> - || strcmp (name, ".fini_array") == 0
>>> - || strcmp (name, ".preinit_array") == 0))
>>> +  /* Various sections have special ELF types that the assembler will
>>> + assign by default based on the name.  They are neither SHT_PROGBITS
>>> + nor SHT_NOBITS, so when changing sections we don't want to print a
>>> + section type (@progbits or @nobits).  Rather than duplicating the
>>> + assembler's knowledge of what those special name patterns are, just
>>> + let the assembler choose the type if we don't know a specific
>>> + reason to set it to something other than the default.  SHT_PROGBITS
>>> + is the default for sections whose name is not specially known to
>>> + the assembler, so it does no harm to leave the choice to the
>>> + assembler when @progbits is the best thing we know to use.  If
>>> + someone is silly enough to emit code or TLS variables to one of
>>> + these sections, then don't handle them specially.  */
>>> +  if (!(flags & (SECTION_CODE | SECTION_BSS | SECTION_TLS | 
>>> SECTION_ENTSIZE))
>>> +  && !(HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE)))
>>>  flags |= SECTION_NOTYPE;
>>>
>>>return flags;

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Martin Sebor]

While reviewing other related bugs I noticed 83502.  This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline).  Somehow those are still copied from
the primary to the specialization and can cause conflicts.


Hmm, that's odd.  Why is that?


Because duplicate_decl calls diagnose_mismatched_attributes()
on the NEWDECL and OLDDECL.  (Attribute optimize would do the
same thing.)  I was trying to keep the fix small but it makes
sense to take care of this as well so I have in this revision.


It does fix the second test case but with the noreturn change
it would issue a bogus -Wmissing-attributes warning for the
explicit specialization below.  Adding the warn_unused_result
attribute to it would then make GCC complain about a conflict
between the added attribute and noreturn, while removing it
would lead to worse code.

   template 
   int __attribute__ ((warn_unused_result)) f (T) { return 0; }

   template <>
   int __attribute__ ((noreturn)) f (int) { throw 0; }

   void fi () { f (0); }


I continue to disagree with this use of attribute noreturn.

+  /* Merge the function-has-side-effects bit.  */
+  if (TREE_THIS_VOLATILE (newdecl))
+TREE_THIS_VOLATILE (olddecl) = 1;
+
+  if (merge_attr)


TREE_THIS_VOLATILE means attribute noreturn, not whether the function
has side-effects; it should be handled in the blocks controlled by
merge_attr.


Whoops.  That was a silly goof.  I must have misread the comment
above the macro definition.  I also didn't have a test for it (or
some of the other changes I've made) so I didn't see the problem.

Attached is an enhanced version of the patch that handles (and
tests) more of the commonly used attributes.  I'm not sure why
in the merge_attr block I have to merge TREE_THIS_VOLATILE and
TREE_NOTHROW back and forth but not also READONLY, PURE, or
MALLOC, but without it tests fail.

Martin

PS Would it be possible to add a new macro with "noreturn" in
the name to make it more intuitive?  (And ditto perhaps also
for TREE_READONLY for "const" functions, though for whatever
reason that seems easier to decipher.  I know you're all used
to it but it's far from intuitive.)

PPS Duplicate_decls is over 1,400 lines long.  If there is more
work to do here in stage 1 (I suspect there might be), would you
mind if I broke it up into two or more, say one for functions,
another for types, or whatever grouping makes most sense to make
it easier to follow?
PR c++/83871 - wrong code for attribute const and pure on distinct template specializations
PR c++/83503 - [8 Regression] bogus -Wattributes for const and pure on function template specialization

gcc/ChangeLog:

	PR c++/83871
	* gcc/doc/invoke.texi (-Wmissing-attributes): New option.

gcc/c-family/ChangeLog:

	PR c++/83871
	* c.opt (-Wmissing-attributes): New option.

gcc/cp/ChangeLog:

	PR c++/83871
	PR c++/83503
	* cp-tree.h (warn_spec_missing_attributes): New function.
	((check_explicit_specialization): Add an argument.  Call the above
	function.
	* decl.c (duplicate_decls): Avoid applying primary function template's
	attributes to its explicit specializations.
	cp/pt.c (warn_spec_missing_attributes): Define.

gcc/testsuite/ChangeLog:

	PR c++/83871
	PR c++/83503
	* g++.dg/Wmissing-attributes.C: New test.
	* g++.dg/ext/attr-const-pure.C: New test.
	* g++.dg/ext/attr-const.C: New test.
	* g++.dg/ext/attr-deprecated-2.C: New test.
	* g++.dg/ext/attr-malloc-2.C: New test.
	* g++.dg/ext/attr-malloc.C: New test.
	* g++.dg/ext/attr-noinline-2.C: New test.
	* g++.dg/ext/attr-noinline.C: New test.
	* g++.dg/ext/attr-nonnull.C: New test.
	* g++.dg/ext/attr-noreturn-2.C: New test.
	* g++.dg/ext/attr-noreturn.C: New test.
	* g++.dg/ext/attr-nothrow-2.C: New test.
	* g++.dg/ext/attr-nothrow.C: New test.
	* g++.dg/ext/attr-optimize.C: New test.
	* g++.dg/ext/attr-pure.C: New test.
	* g++.dg/ext/attr-returns-nonnull.C: New test.
	* g++.dg/ext/attr-warning.C: New test.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 421b146..a4c8c8f 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -781,6 +781,11 @@ Wtemplates
 C++ ObjC++ Var(warn_templates) Warning
 Warn on primary template declaration.
 
+Wmissing-attributes
+C ObjC C++ ObjC++ Var(warn_missing_attributes) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall)
+Warn about declarations of entities that may be missing attributes
+that related entities have been declared with it.
+
 Wmissing-format-attribute
 C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format)
 ;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index aef022f..abcd1a6 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6463,7 +6463,8 @@ extern void end_specialization			(void);
 extern void begin_explicit_instantiation	(void);
 extern void end_explicit_instantiation		(void);
 extern void check_unqualified_spec_or_inst	(tree, location_t);
-extern tree check_explicit_specialization	(tree, tree, int, int);
+extern tree check_explicit_specialization	(tree, tree, i