Re: [patch, fortran] New take on PR 82373

[Thomas Koenig]

Hi Steve,


I like this patch much better than the last.  It's
ok with me, but you might want give 24 hours to let
the world rotate before committing (ie., allow others
to comment)


Committed as r253768.  Thanks for the review!

I don't think it is worth backporting, so I'll close
the bug. If somebody thinks that we should indeed backport,
please let me know.

Regards

Thomas

[PATCH] Use Pcrt1.o%s/gPcrt1.o%s for -static-pie

[H.J. Lu]

crt1.o is used to create dynamic and non-PIE static executables.  Static
PIE needs to link with Pcrt1.o, instead of crt1.o, to relocate static PIE
at run-time.  When -pg is used with -static-pie, gPcrt1.o should be used.

Tested on x86-64.  OK for master?

Thanks.

H.J.
---
* config/gnu-user.h (GNU_USER_TARGET_STARTFILE_SPEC): Use
Pcrt1.o%s/gPcrt1.o%s for -static-pie.
---
 gcc/config/gnu-user.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
index a967b69a350..c1cfdc3da90 100644
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -51,9 +51,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #if defined HAVE_LD_PIE
 #define GNU_USER_TARGET_STARTFILE_SPEC \
   "%{shared:; \
- pg|p|profile:gcrt1.o%s; \
+ pg|p|profile:%{static-pie:gPcrt1.o%s;:gcrt1.o%s}; \
  static:crt1.o%s; \
- static-pie|" PIE_SPEC ":Scrt1.o%s; \
+ static-pie:Pcrt1.o%s; \
+ " PIE_SPEC ":Scrt1.o%s; \
  :crt1.o%s} \
crti.o%s \
%{static:crtbeginT.o%s; \
-- 
2.13.5

[patch, fortran] Fix PR 79795

[Thomas Koenig]

Hello world,

the attached patch fixes a regression by turning an ICE-on-invalid into
an error message (and making sure that it fits).

Regression-tested on trunk.

OK for all affected branches (8/7/6)?

Regards

Thomas

2017-10-15  Thomas Koenig  

PR fortran/79795
* resolve.c (resovle_symbol): Change gcc_assert to
sensible error message.

2017-10-15  Thomas Koenig  

PR fortran/79795
* gfortran.dg/assumed_size_2.f90: New test.
Index: resolve.c
===
--- resolve.c	(Revision 253768)
+++ resolve.c	(Arbeitskopie)
@@ -14403,7 +14403,23 @@ resolve_symbol (gfc_symbol *sym)
 
   if (as)
 {
-  gcc_assert (as->type != AS_IMPLIED_SHAPE);
+  /* If AS_IMPLIED_SHAPE makes it to here, it must be a bad
+	 specification expression.  */
+  if (as->type == AS_IMPLIED_SHAPE)
+	{
+	  int i;
+	  for (i=0; irank; i++)
+	{
+	  if (as->lower[i] != NULL && as->upper[i] == NULL)
+		{
+		  gfc_error ("Bad specification for assumed size array at %L",
+			 &as->lower[i]->where);
+		  return;
+		}
+	}
+	  gcc_unreachable();
+	}
+
   if (((as->type == AS_ASSUMED_SIZE && !as->cp_was_assumed)
 	   || as->type == AS_ASSUMED_SHAPE)
 	  && !sym->attr.dummy && !sym->attr.select_type_temporary)
! { dg-do compile }
subroutine foo(a)
  dimension  a(*,*) ! { dg-error "Bad specification for assumed size array" }
end

Re: Go patch committed to GCC 7 branch: Update MIPS architecture names

[Ian Lance Taylor]

On Mon, Oct 9, 2017 at 9:59 AM, Ian Lance Taylor  wrote:
> I've committed a set of patches by James Cowgill to the GCC 7 branch,
> backported from trunk.  These patches update the MIPS architecture
> names to the names expected by Go programmers.  The backported patches
> are:
> https://golang.org/cl/46150
> https://golang.org/cl/46151
> https://golang.org/cl/46152
> https://golang.org/cl/46153
> https://golang.org/cl/46154
> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01777.html

These required some further patches on the GCC 7 branch:
https://golang.org/cl/46712 by Urox Bizjak
https://golang.org/cl/46839 by Andreas Krebbel

This fixes GCC PR 82559.

Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.  Committed to
GCC 7 branch.

Ian
Index: libgo/go/syscall/syscall_linux_alpha.go
===
--- libgo/go/syscall/syscall_linux_alpha.go (revision 253769)
+++ libgo/go/syscall/syscall_linux_alpha.go (working copy)
@@ -8,38 +8,6 @@
 
 import "unsafe"
 
-type PtraceRegs struct {
-   R0  uint64
-   R1  uint64
-   R2  uint64
-   R3  uint64
-   R4  uint64
-   R5  uint64
-   R6  uint64
-   R7  uint64
-   R8  uint64
-   R19 uint64
-   R20 uint64
-   R21 uint64
-   R22 uint64
-   R23 uint64
-   R24 uint64
-   R25 uint64
-   R26 uint64
-   R27 uint64
-   R28 uint64
-   Hae uint64
-   Trap_a0 uint64
-   Trap_a1 uint64
-   Trap_a2 uint64
-   Ps  uint64
-   Pc  uint64
-   Gp  uint64
-   R16 uint64
-   R17 uint64
-   R18 uint64
-}
-
 func (r *PtraceRegs) PC() uint64 {
return r.Pc
 }
Index: libgo/go/syscall/syscall_linux_s390.go
===
--- libgo/go/syscall/syscall_linux_s390.go  (revision 253769)
+++ libgo/go/syscall/syscall_linux_s390.go  (working copy)
@@ -8,9 +8,9 @@
 
 import "unsafe"
 
-func (r *PtraceRegs) PC() uint64 { return uint64(r.Psw.Addr) }
+func (r *PtraceRegs) PC() uint64 { return uint64(r.Psw.addr) }
 
-func (r *PtraceRegs) SetPC(pc uint64) { r.Psw.Addr = uint32(pc) }
+func (r *PtraceRegs) SetPC(pc uint64) { r.Psw.addr = uint32(pc) }
 
 const syscall_PTRACE_PEEKUSR_AREA = 0x5000
 const syscall_PTRACE_POKEUSR_AREA = 0x5001
Index: libgo/go/syscall/syscall_linux_s390x.go
===
--- libgo/go/syscall/syscall_linux_s390x.go (revision 253769)
+++ libgo/go/syscall/syscall_linux_s390x.go (working copy)
@@ -8,9 +8,9 @@
 
 import "unsafe"
 
-func (r *PtraceRegs) PC() uint64 { return r.Psw.Addr }
+func (r *PtraceRegs) PC() uint64 { return r.Psw.addr }
 
-func (r *PtraceRegs) SetPC(pc uint64) { r.Psw.Addr = pc }
+func (r *PtraceRegs) SetPC(pc uint64) { r.Psw.addr = pc }
 
 const syscall_PTRACE_PEEKUSR_AREA = 0x5000
 const syscall_PTRACE_POKEUSR_AREA = 0x5001
Index: libgo/mksysinfo.sh
===
--- libgo/mksysinfo.sh  (revision 253769)
+++ libgo/mksysinfo.sh  (working copy)
@@ -295,17 +295,8 @@
 # _user_regs_struct.
 regs=`grep '^type _user_regs_struct struct' gen-sysinfo.go || true`
 if test "$regs" = ""; then
-  # s390
-  regs=`grep '^type __user_regs_struct struct' gen-sysinfo.go || true`
-  if test "$regs" != ""; then
-# Substructures of __user_regs_struct on s390
-upcase_fields "__user_psw_struct" "PtracePsw" >> ${OUT} || true
-upcase_fields "__user_fpregs_struct" "PtraceFpregs" >> ${OUT} || true
-upcase_fields "__user_per_struct" "PtracePer" >> ${OUT} || true
-  else
-# mips*
-regs=`grep '^type _pt_regs struct' gen-sysinfo.go || true`
-  fi
+  # mips*
+  regs=`grep '^type _pt_regs struct' gen-sysinfo.go || true`
 fi
 if test "$regs" != ""; then
   regs=`echo $regs | sed -e 's/type _pt_regs struct//'`

[PATCH, RFC] Add a pass counter for "are we there yet" purposes

[Sandra Loosemore]

This patch is a first cut at solving the problem discussed in this thread

https://gcc.gnu.org/ml/gcc/2017-10/msg00016.html

where I have some nios2 backend patches in my queue that need a way of 
knowing whether the split1 pass has run yet.  There seemed to be 
agreement that a general way to query the pass manager for this 
information would be useful.


The approach I took here is to add a new counter field, so that I can do 
the test I want with


  opt_pass *split1_pass = g->get_passes ()->get_pass_split_all_insns ();
  if (current_pass->pass_number > split1_pass->pass_number)
...

Well, mostly.  :-P  There are some gotchas.

* TARGET_ASM_OUTPUT_MI_THUNK is called outside the pass manager (so 
current_pass is NULL) and on many targets this hook is implemented by 
setting reload_completed to 1, generating some RTL, and invoking some 
passes directly to emit code.


* modulo-sched.c also plays tricks with setting reload_completed to 
pretend to be something it's not.


* Possibly other places?  E.g. I'm not familiar with how plugins work.

For my purposes it's good enough to check reload_completed before the 
test in the code snippet above, but trying to determine whether a 
particular post-reload pass has run won't work.  So this isn't as 
general as it ought to be, at least not until we get rid of the 
reload_completed hackery.


Since this patch isn't useful without something that uses the pass 
counters, I tested it on nios2-linux-gnu with my not-yet-posted patch 
set, by wiring it up in parallel with my previously-implemented solution 
of adding a target-specific pass to set a flag, with various assertions 
to check for consistency.  I also had some temporary debugging code in 
there at one point to print the pass numbers.


WDYT?  Is this the right direction?  I'm somewhat worried that we're 
getting late in stage 1 and I'd really like to finish up my nios2 
patches; so if getting this right looks like a tar pit, I think I should 
probably stick with my previous implementation for now.


-Sandra

2017-10-15  Sandra Loosemore  

	gcc/
	* pass_manager.h (pass_manager::enumerate_passes): Declare.
	* tree-pass.h (opt_pass::pass_number): Declare.
	* passes.c (enumerate_pass_list): New.
	(pass_manager::enumerate_passes): New.
	(pass_manager::register_pass): Call enumerate_passes.
	(pass_manager::pass_manager): Likewise.
Index: gcc/pass_manager.h
===
--- gcc/pass_manager.h	(revision 253327)
+++ gcc/pass_manager.h	(working copy)
@@ -103,6 +103,7 @@ private:
   void set_pass_for_id (int id, opt_pass *pass);
   void register_dump_files (opt_pass *pass);
   void create_pass_tab () const;
+  void enumerate_passes () const;
 
 private:
   context *m_ctxt;
Index: gcc/tree-pass.h
===
--- gcc/tree-pass.h	(revision 253327)
+++ gcc/tree-pass.h	(working copy)
@@ -108,6 +108,11 @@ public:
   /* Static pass number, used as a fragment of the dump file name.  */
   int static_pass_number;
 
+  /* Pass number used for enumerating the pass list.  This differs from
+ static_pass_number in that the numbering is sequential and all passes
+ have a meaningful number assigned.  */
+  int pass_number;
+
 protected:
   gcc::context *m_ctxt;
 };
Index: gcc/passes.c
===
--- gcc/passes.c	(revision 253327)
+++ gcc/passes.c	(working copy)
@@ -899,6 +899,35 @@ pass_manager::create_pass_tab (void) con
 
 static bool override_gate_status (opt_pass *, tree, bool);
 
+/* Enumerate pass list PASS starting with counter COUNTER.  */
+
+static int
+enumerate_pass_list (opt_pass *pass, int counter)
+{
+  do
+{
+  pass->pass_number = ++counter;
+  if (pass->sub)
+	counter = enumerate_pass_list (pass->sub, counter);
+  pass = pass->next;
+}
+  while (pass);
+  return counter;
+}
+
+/* Enumerate all optimization passes.  */
+
+void
+pass_manager::enumerate_passes () const
+{
+  int counter = 0;
+  counter = enumerate_pass_list (all_lowering_passes, counter);
+  counter = enumerate_pass_list (all_small_ipa_passes, counter);
+  counter = enumerate_pass_list (all_regular_ipa_passes, counter);
+  counter = enumerate_pass_list (all_late_ipa_passes, counter);
+  counter = enumerate_pass_list (all_passes, counter);
+}
+
 /* Dump the instantiated name for PASS. IS_ON indicates if PASS
is turned on or not.  */
 
@@ -1508,6 +1537,9 @@ pass_manager::register_pass (struct regi
   XDELETE (added_pass_nodes);
   added_pass_nodes = next_node;
 }
+
+  /* Update the pass enumeration.  */
+  enumerate_passes ();
 }
 
 /* Construct the pass tree.  The sequencing of passes is driven by
@@ -1614,6 +1646,9 @@ pass_manager::pass_manager (context *ctx
   register_dump_files (all_regular_ipa_passes);
   register_dump_files (all_late_ipa_passes);
   register_dump_files (all_passes);
+
+  /* Enumerate passes.  */
+  enumerate_passes ();

Re: [Bug libstdc++/82558] [8 Regression] V8 JavaScript engine segfaults since r249235

[François Dumont]

Hi

    Attached patch applied as trivial.

2017-10-16  François Dumont  

    PR libstdc++/82558
    * include/bits/stl_bvector.h (fill): Add iterator offset check.
    * testsuite/23_containers/vector/bool/82558.cc: New.

Thanks for the report.

François

On 16/10/2017 07:25, fdumont at gcc dot gnu.org wrote:

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

François Dumont  changed:

What|Removed |Added

  Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
gnu.org



Index: include/bits/stl_bvector.h
===
--- include/bits/stl_bvector.h	(revision 253775)
+++ include/bits/stl_bvector.h	(working copy)
@@ -417,7 +417,7 @@
 	if (__last._M_offset != 0)
 	  __fill_bvector(__last._M_p, 0, __last._M_offset, __x);
   }
-else
+else if (__first._M_offset != __last._M_offset)
   __fill_bvector(__first._M_p, __first._M_offset, __last._M_offset, __x);
   }
 
Index: testsuite/23_containers/vector/bool/82558.cc
===
--- testsuite/23_containers/vector/bool/82558.cc	(nonexistent)
+++ testsuite/23_containers/vector/bool/82558.cc	(working copy)
@@ -0,0 +1,32 @@
+// Copyright (C) 2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// 23.3.8  class vector
+
+#include 
+
+// libstdc++/82558
+void test01()
+{
+  std::vector v;
+  std::fill(v.begin(), v.begin(), false);
+}
+
+int main()
+{
+  test01();
+}

[PATCH] Update -ffunction/data-sections documentation

[Sebastian Huber]

gcc/
* invoke.texi (ffunction-sections and fdata-sections): Update.
---
 gcc/doc/invoke.texi | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4e7dfb33c31..7bc051a1fc5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9712,18 +9712,26 @@ file if the target supports arbitrary sections.  The 
name of the
 function or the name of the data item determines the section's name
 in the output file.
 
-Use these options on systems where the linker can perform optimizations
-to improve locality of reference in the instruction space.  Most systems
-using the ELF object format and SPARC processors running Solaris 2 have
-linkers with such optimizations.  AIX may have these optimizations in
-the future.
-
-Only use these options when there are significant benefits from doing
-so.  When you specify these options, the assembler and linker
-create larger object and executable files and are also slower.
-You cannot use @command{gprof} on all systems if you
-specify this option, and you may have problems with debugging if
-you specify both this option and @option{-g}.
+Use these options on systems where the linker can perform optimizations to
+improve locality of reference in the instruction space.  Most systems using the
+ELF object format have linkers with such optimizations.  On AIX, the linker
+rearranges sections (CSECTs) based on the call graph.  The performance impact
+varies.
+
+Together with a linker garbage collection (linker @option{--gc-sections}
+option) these options may lead to smaller statically linked executables (after
+stripping).
+
+On ELF/DWARF systems these options do not degenerate the quality of the debug
+information.  There could be issues with other object files/debug info formats.
+
+Only use these options when there are significant benefits from doing so.  When
+you specify these options, the assembler and linker create larger object and
+executable files and are also slower.  These options affect code generation.
+They prevent optimzations by the compiler and assembler using relative
+locations inside a translation unit since the locations are unknown until
+link-time.  An examples for such an optimization is a call to short call
+relaxation.
 
 @item -fbranch-target-load-optimize
 @opindex fbranch-target-load-optimize
-- 
2.12.3

Re: [PATCH PR/82546] tree node size

[Richard Biener]

On October 13, 2017 8:29:40 PM GMT+02:00, Nathan Sidwell  wrote:
>[Although I filed this as a middle-end bug, it's really a core infra 
>bug, not sure who the best reviewer is]
>
>In working on tree streaming in the modules branch, I discovered poor 
>tree node size and hierarchy bits.
>
>Here's a fix for the first part of that.  tree.c (tree_code_size) 
>returns sizeof (tree_type_non_common) for any tcc_type node. That's 
>wasteful, given we have tree_type_common-> 
>tree_type_with_lang_specific-> tree_type_non_common available as 
>choices.  It's also obscuring defects in (at least) the c++ FE where we
>
>use tree_type_non_common fields, but claim the node doesn't contain
>that 
>structure.   Ew.
>
>This patch makes tree_code_size ask the lang hook for the size of 
>non-core type nodes.  It also fixes the c++ and objc FEs to return a 
>size for the nodes it cares about.
>
>I don't (yet) know whether all the core types are tree_type_non_common,
>
>nor whether the FE's can return smaller sizes than the do with this 
>patch.  But at least the control flow is now correct.  during
>developing 
>this patch I added an assert that the lang hook was returning a size at
>
>least as big as tree_type_non_common, so they couldn't be more broken 
>than before the patch.
>
>I intend to continue cleaning this up of course.  It's not clear to me 
>whether we should cache these node sizes in an array, and the way it 
>goes about checking nodes with nested switches is understandable, but 
>possible not the fastest solution. However let's at least get the
>sizing 
>right first.

We were conservative exactly to avoid the langhook here. I think there's 
similar 'bug' on the decl side. 

Richard. 

>ok?
>
>nathan

Re: [PATCH, RFC] Add a pass counter for "are we there yet" purposes

[Richard Biener]

On October 16, 2017 7:38:50 AM GMT+02:00, Sandra Loosemore 
 wrote:
>This patch is a first cut at solving the problem discussed in this
>thread
>
>https://gcc.gnu.org/ml/gcc/2017-10/msg00016.html
>
>where I have some nios2 backend patches in my queue that need a way of 
>knowing whether the split1 pass has run yet.  There seemed to be 
>agreement that a general way to query the pass manager for this 
>information would be useful.
>
>The approach I took here is to add a new counter field, so that I can
>do 
>the test I want with
>
> opt_pass *split1_pass = g->get_passes ()->get_pass_split_all_insns ();
>   if (current_pass->pass_number > split1_pass->pass_number)
> ...
>
>Well, mostly.  :-P  There are some gotchas.
>
>* TARGET_ASM_OUTPUT_MI_THUNK is called outside the pass manager (so 
>current_pass is NULL) and on many targets this hook is implemented by 
>setting reload_completed to 1, generating some RTL, and invoking some 
>passes directly to emit code.
>
>* modulo-sched.c also plays tricks with setting reload_completed to 
>pretend to be something it's not.
>
>* Possibly other places?  E.g. I'm not familiar with how plugins work.
>
>For my purposes it's good enough to check reload_completed before the 
>test in the code snippet above, but trying to determine whether a 
>particular post-reload pass has run won't work.  So this isn't as 
>general as it ought to be, at least not until we get rid of the 
>reload_completed hackery.
>
>Since this patch isn't useful without something that uses the pass 
>counters, I tested it on nios2-linux-gnu with my not-yet-posted patch 
>set, by wiring it up in parallel with my previously-implemented
>solution 
>of adding a target-specific pass to set a flag, with various assertions
>
>to check for consistency.  I also had some temporary debugging code in 
>there at one point to print the pass numbers.
>
>WDYT?  Is this the right direction?  I'm somewhat worried that we're 
>getting late in stage 1 and I'd really like to finish up my nios2 
>patches; so if getting this right looks like a tar pit, I think I
>should 
>probably stick with my previous implementation for now.

I missed the post of why you need to know this. But as you noticed we're using 
reload_completed for similar purpose. There's also the possibility of 
setting/adding a pass property that split could provide and which you could 
query. We're using this to signal the various different lowering stages in 
GIMPLE for example. 

Richard. 

>
>-Sandra