[FYI] pass --enable-obsolete to build configure

2019-11-02 Thread Alexandre Oliva
Configuring GCC for obsolete targets works as long as build = host.
When it isn't, --enable-obsolete is not passed down to the additional
build configure started by gcc/configure, used to generate
auto-build.h.  The build configure fails and we end up without a
auto-build.h, but the host configure proceeds, so we only get a fatal
failure much later, when make realizes auto-build.h is not there and
there's no rule to create it.

This patch gets the host configure to fail when the build configure
does, leaving the temporary build configure dir behind for
investigation.  It also arranges for --enable-obsolete to be passed
down to the build configure.

Alas, the latter triggered a warning in the build configure because
--enable-obsolete is not a recognized configure option.  That's not
reported in the host configure because of the
--disable-option-checking passed by the top-level configure, so I
arranged for that to be passed down to the build configure as well.

Finally, since my initial suspicion when investigating this failure
was that auto-build.h had been removed after configuration and there
was no rule to rebuild it, I'm adding rules to gcc/Makefile to get it
created or updated as needed.  Since it is configure that creates it,
as run by e.g. config.status --recheck, and config.status is created
after auto-build.h, I've made config.status depend on auto-build.h,
and added a dummy rule to create auto-build.h.  This would normally
not be enough to create a header when needed, but since Makefile
depends on config.status, and make first updates Makefile, it ends up
working, as long as nothing else that Makefile depends on requires
auto-build.h but not config.status.  The config.status dependency and
the auto-build.h rule are only enabled in the cases in which
auto-build.h is actually used, namely when build != host.

Tested on x86_64-linux-gnu, with build != host and an obsolete target,
to check the --enable-obsolete passing down, and a native configuration
to check that the new Makefile rules are not enabled.

I'll check this in if there aren't objections in the next few days.


for  gcc/ChangeLog

* configure.ac: Pass --enable-obsolete=* and
--enable-option-checking=* down to build configure, and fail
if it fails.  AC_SUBST HAVE_AUTO_BUILD.
* configure: Rebuild.
* Makefile.in [HAVE_AUTO_BUILD] (auto-build.h): New rule.
[HAVE_AUTO_BUILD] (config.status): Depend on auto-build.h.
---
 gcc/Makefile.in  |8 
 gcc/configure|   37 -
 gcc/configure.ac |8 +++-
 3 files changed, 43 insertions(+), 10 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 035b58f..95f054c 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1899,6 +1899,14 @@ cstamp-h: config.in config.status
CONFIG_FILES= \
LANGUAGES="$(CONFIG_LANGUAGES)" $(SHELL) config.status
 
+# On configurations that require auto-build.h, it is created while
+# running configure, so make config.status depend on it, so that
+# config.status --recheck runs and updates or creates it.
+@HAVE_AUTO_BUILD@auto-build.h: $(srcdir)/configure $(srcdir)/config.gcc
+@HAVE_AUTO_BUILD@  @if test -f $@; then echo rerunning config.status to 
update $@; \
+@HAVE_AUTO_BUILD@  else echo rerunning config.status to update $@; fi
+@HAVE_AUTO_BUILD@config.status: auto-build.h
+
 # Really, really stupid make features, such as SUN's KEEP_STATE, may force
 # a target to build even if it is up-to-date.  So we must verify that
 # config.status does not exist before failing.
diff --git a/gcc/configure b/gcc/configure
index 5794582..1ebe373 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -774,6 +774,7 @@ LIBINTL_DEP
 LIBINTL
 USE_NLS
 get_gcc_base_ver
+HAVE_AUTO_BUILD
 extra_opt_files
 extra_modes_file
 NATIVE_SYSTEM_HEADER_DIR
@@ -903,6 +904,7 @@ infodir
 docdir
 oldincludedir
 includedir
+runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -1067,6 +1069,7 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
+runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE}'
@@ -1319,6 +1322,15 @@ do
   | -silent | --silent | --silen | --sile | --sil)
 silent=yes ;;
 
+  -runstatedir | --runstatedir | --runstatedi | --runstated \
+  | --runstate | --runstat | --runsta | --runst | --runs \
+  | --run | --ru | --r)
+ac_prev=runstatedir ;;
+  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
+  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
+  | --run=* | --ru=* | --r=*)
+runstatedir=$ac_optarg ;;
+
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
 ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1456,7 +1468,7 @@ fi
 for ac_var in  exec_prefix prefix bindir sbindir libexecdir datarootdir \
  

[wwwdocs] readings.html -- switch www.adapteva.com to https

2019-11-02 Thread Gerald Pfeifer
Committed.

Gerald

- Log -
commit 0f32e95bf23411b8247c122588bfd14079b93ed0
Author: Gerald Pfeifer 
Date:   Sat Nov 2 21:24:24 2019 +

Switch www.adapteva.com to https.

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 5c30391..03010f0 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -127,7 +127,7 @@ names.
  
  Epiphany
   Manufacturer: Adapteva
-  http://www.adapteva.com/;>Manufacturer's website with
+  https://www.adapteva.com;>Manufacturer's website with
   additional information about the Epiphany architecture.
  
  

---


Re: introduce -fcallgraph-info option

2019-11-02 Thread Alexandre Oliva
On Oct 30, 2019, Richard Biener  wrote:

> One way of operation would be to
> generate the graph during the compilation step

Stack usage is only computed during prologue/epilogue generation in RTL.

> Additional arguments to -fcallgraph-info might be used to direct the
> output to a specific directory as well.

I've adjusted open_auxiliary_file for LTO recompilation auxiliary files
to be placed in the same location as the specified executable output
name, and noted that in the documentation.

I've also added a bitmap to output nodes for externals, accidentally
dropped in the transition to incremental generation of the .ci file.

Regstrapped on x86_64-linux-gnu.  Ok to install?


introduce -fcallgraph-info option

This was first submitted many years ago
https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html

The command line option -fcallgraph-info is added and makes the
compiler generate another output file (xxx.ci) for each compilation
unit (or LTO partitoin), which is a valid VCG file (you can launch
your favorite VCG viewer on it unmodified) and contains the "final"
callgraph of the unit.  "final" is a bit of a misnomer as this is
actually the callgraph at RTL expansion time, but since most
high-level optimizations are done at the Tree level and RTL doesn't
usually fiddle with calls, it's final in almost all cases.  Moreover,
the nodes can be decorated with additional info: -fcallgraph-info=su
adds stack usage info and -fcallgraph-info=da dynamic allocation info.


for  gcc/ChangeLog
>From  Eric Botcazou  , Alexandre Oliva  
>

* common.opt (-fcallgraph-info[=]): New option.
* doc/invoke.texi (Developer options): Document it.
* opts.c (common_handle_option): Handle it.
* builtins.c (expand_builtin_alloca): Record allocation if
-fcallgraph-info=da.
* calls.c (expand_call): If -fcallgraph-info, record the call.
(emit_library_call_value_1): Likewise.
* flag-types.h (enum callgraph_info_type): New type.
* explow.c: Include stringpool.h.
(set_stack_check_libfunc): Set SET_SYMBOL_REF_DECL on the symbol.
* function.c (allocate_stack_usage_info): New.
(allocate_struct_function): Call it for -fcallgraph-info.
(prepare_function_start): Call it otherwise.
(record_final_call, record_dynamic_alloc): New.
* function.h (struct callinfo_callee): New.
(CALLEE_FROM_CGRAPH_P): New.
(struct callinfo_dalloc): New.
(struct stack_usage): Add callees and dallocs.
(record_final_call, record_dynamic_alloc): Declare.
* gimplify.c (gimplify_decl_expr): Record dynamically-allocated
object if -fcallgraph-info=da.
* optabs-libfuncs.c (build_libfunc_function): Keep SYMBOL_REF_DECL.
* print-tree.h (print_decl_identifier): Declare.
(PRINT_DECL_ORIGIN, PRINT_DECL_NAME, PRINT_DECL_UNIQUE_NAME): New.
* print-tree.c: Include print-tree.h.
(print_decl_identifier): New function.
* toplev.c: Include print-tree.h.
(callgraph_info_file): New global variable.
(callgraph_info_external_printed): Likewise.
(open_auxiliary_file): Use dump_base_name for LTO partitions.
(output_stack_usage): Rename to...
(output_stack_usage_1): ... this.  Make it static, add cf
parameter.  If -fcallgraph-info=su, print stack usage to cf.
If -fstack-usage, use print_decl_identifier for
pretty-printing.
(INDIRECT_CALL_NAME): New.
(dump_final_node_vcg_start): New.
(dump_final_callee_vcg, dump_final_node_vcg): New.
(output_stack_usage): New.
(lang_dependent_init): Open and start file if
-fcallgraph-info.  Allocated callgraph_info_external_printed.
(finalize): If callgraph_info_file is not null, finish it,
close it, and release callgraph_info_external_printed.

for  gcc/ada/ChangeLog

* gcc-interface/misc.c (callgraph_info_file): Delete.
---
 gcc/ada/gcc-interface/misc.c |3 -
 gcc/builtins.c   |4 +
 gcc/calls.c  |6 +
 gcc/common.opt   |8 ++
 gcc/doc/invoke.texi  |   22 +
 gcc/explow.c |5 +
 gcc/flag-types.h |   16 
 gcc/function.c   |   59 -
 gcc/function.h   |   30 +++
 gcc/gimplify.c   |4 +
 gcc/optabs-libfuncs.c|4 -
 gcc/opts.c   |   26 ++
 gcc/output.h |2 
 gcc/print-tree.c |   76 +
 gcc/print-tree.h |4 +
 gcc/toplev.c |  186 ++
 16 files changed, 402 insertions(+), 53 deletions(-)

diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
index 4abd4d5..d68b373 100644
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -54,9 +54,6 @@
 #include "ada-tree.h"
 #include "gigi.h"
 

Re: [PATCH] Improve unrolling heuristics, PR91975

2019-11-02 Thread Andreas Schwab
This breaks bootstrap on powerpc:

/daten/gcc/gcc-20191101/Build/./prev-gcc/xg++ 
-B/daten/gcc/gcc-20191101/Build/./prev-gcc/ -B/usr/powerpc64-suse-linux/bin/ 
-nostdinc++ 
-B/daten/gcc/gcc-20191101/Build/prev-powerpc64-suse-linux/libstdc++-v3/src/.libs
 
-B/daten/gcc/gcc-20191101/Build/prev-powerpc64-suse-linux/libstdc++-v3/libsupc++/.libs
  
-I/daten/gcc/gcc-20191101/Build/prev-powerpc64-suse-linux/libstdc++-v3/include/powerpc64-suse-linux
  
-I/daten/gcc/gcc-20191101/Build/prev-powerpc64-suse-linux/libstdc++-v3/include  
-I/daten/gcc/gcc-20191101/libstdc++-v3/libsupc++ 
-L/daten/gcc/gcc-20191101/Build/prev-powerpc64-suse-linux/libstdc++-v3/src/.libs
 
-L/daten/gcc/gcc-20191101/Build/prev-powerpc64-suse-linux/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle 
-DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall 
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag 
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -I. -I. 
-I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include  
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc/../libbacktrace   -o rs6000-c.o -MT rs6000-c.o -MMD -MP -MF 
./.deps/rs6000-c.TPo ../../gcc/config/rs6000/rs6000-c.c
In file included from ../../gcc/c-family/c-common.h:27,
 from ../../gcc/config/rs6000/rs6000-c.c:29:
../../gcc/fold-const.h: In function 'tree_node* 
altivec_build_resolved_builtin(tree_node**, int, const altivec_builtin_types*)':
../../gcc/fold-const.h:74:21: error: 'arg_type[1]' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]
   74 |fold_convert_loc (UNKNOWN_LOCATION, T1, T2)
  | ^
../../gcc/config/rs6000/rs6000-c.c:6062:8: note: 'arg_type[1]' was declared here
 6062 |   tree arg_type[3];
  |^~~~
In file included from ../../gcc/c-family/c-common.h:27,
 from ../../gcc/config/rs6000/rs6000-c.c:29:
../../gcc/fold-const.h:74:21: error: 'arg_type[2]' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]
   74 |fold_convert_loc (UNKNOWN_LOCATION, T1, T2)
  | ^
../../gcc/config/rs6000/rs6000-c.c:6062:8: note: 'arg_type[2]' was declared here
 6062 |   tree arg_type[3];
  |^~~~
cc1plus: all warnings being treated as errors

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


[PATCH] Support multiple registers for the frame pointer

2019-11-02 Thread Kwok Cheung Yeung
The AMD GCN architecture uses 64-bit pointers, but the scalar registers 
are 32-bit wide, so pointers must reside in a pair of registers.


The two hard registers holding the frame pointer are currently fixed, 
but if they are changed to unfixed (so that the FP can be eliminated), 
GCC would sometimes allocate the second register to a pseudo while the 
frame pointer was in use, clobbering the value of the FP and crashing 
the program.


GCC currently does not handle multi-register hard frame pointers 
properly - no_unit_alloc_regs, regs_ever_live, eliminable_regset and 
ira_no_alloc_regs (which gets copied to lra_no_alloc_regs) are only set 
for HARD_FRAME_POINTER_REGNUM and not for any subsequent registers that 
may be used, which means that the register allocators consider 
HARD_FRAME_POINTER_REGNUM+1 free. This patch determines the number of 
registers needed to store the frame pointer using hard_regno_nregs, and 
sets the required variables for HARD_FRAME_POINTER_REGNUM and however 
many adjacent registers are needed (which on most architectures should 
be zero).


Bootstrapped on x86_64 and tested with no regressions, which is not 
surprising as nothing different happens when the FP fits into a single 
register. I believe this is true for the 64-bit variants of the more 
popular architectures as well (ARM, RS6000, MIPS, Sparc). Are there any 
other architectures similar to GCN (i.e. 64-bit pointers with 32-bit GPRs)?


I have not included any specific testcases for this issue as it can 
affect pretty much everything not using -fomit-frame-pointer on AMD GCN.


Okay for trunk?

Kwok Yeung


Add support for using multiple registers to hold the frame pointer

2019-11-02  Kwok Cheung Yeung  

gcc/
* ira.c (setup_alloc_regs): Setup no_unit_alloc_regs for
frame pointer in multiple registers.
(ira_setup_eliminable_regset): Setup eliminable_regset,
ira_no_alloc_regs and regs_ever_live for frame pointer in
multiple registers.

diff --git a/gcc/ira.c b/gcc/ira.c
index 9f8da67..25e9359 100644
--- a/gcc/ira.c
+++ b/gcc/ira.c
@@ -515,7 +515,13 @@ setup_alloc_regs (bool use_hard_frame_p)
 #endif
   no_unit_alloc_regs = fixed_nonglobal_reg_set;
   if (! use_hard_frame_p)
-SET_HARD_REG_BIT (no_unit_alloc_regs, HARD_FRAME_POINTER_REGNUM);
+{
+  int fp_reg_count = hard_regno_nregs (HARD_FRAME_POINTER_REGNUM, 
Pmode);

+  for (int reg = HARD_FRAME_POINTER_REGNUM;
+  reg < HARD_FRAME_POINTER_REGNUM + fp_reg_count;
+  reg++)
+   SET_HARD_REG_BIT (no_unit_alloc_regs, reg);
+}
   setup_class_hard_regs ();
 }

@@ -2248,6 +2254,7 @@ ira_setup_eliminable_regset (void)
 {
   int i;
   static const struct {const int from, to; } eliminables[] = 
ELIMINABLE_REGS;

+  int fp_reg_count = hard_regno_nregs (HARD_FRAME_POINTER_REGNUM, Pmode);

   /* Setup is_leaf as frame_pointer_required may use it.  This function
  is called by sched_init before ira if scheduling is enabled.  */
@@ -2276,7 +2283,8 @@ ira_setup_eliminable_regset (void)
frame pointer in LRA.  */

   if (frame_pointer_needed)
-df_set_regs_ever_live (HARD_FRAME_POINTER_REGNUM, true);
+for (i = 0; i < fp_reg_count; i++)
+  df_set_regs_ever_live (HARD_FRAME_POINTER_REGNUM + i, true);

   ira_no_alloc_regs = no_unit_alloc_regs;
   CLEAR_HARD_REG_SET (eliminable_regset);
@@ -2306,17 +2314,21 @@ ira_setup_eliminable_regset (void)
 }
   if (!HARD_FRAME_POINTER_IS_FRAME_POINTER)
 {
-  if (!TEST_HARD_REG_BIT (crtl->asm_clobbers, 
HARD_FRAME_POINTER_REGNUM))

-   {
- SET_HARD_REG_BIT (eliminable_regset, HARD_FRAME_POINTER_REGNUM);
- if (frame_pointer_needed)
-   SET_HARD_REG_BIT (ira_no_alloc_regs, HARD_FRAME_POINTER_REGNUM);
-   }
-  else if (frame_pointer_needed)
-   error ("%s cannot be used in % here",
-  reg_names[HARD_FRAME_POINTER_REGNUM]);
-  else
-   df_set_regs_ever_live (HARD_FRAME_POINTER_REGNUM, true);
+  for (i = 0; i < fp_reg_count; i++)
+   if (!TEST_HARD_REG_BIT (crtl->asm_clobbers,
+   HARD_FRAME_POINTER_REGNUM + i))
+ {
+   SET_HARD_REG_BIT (eliminable_regset,
+ HARD_FRAME_POINTER_REGNUM + i);
+   if (frame_pointer_needed)
+ SET_HARD_REG_BIT (ira_no_alloc_regs,
+   HARD_FRAME_POINTER_REGNUM + i);
+ }
+   else if (frame_pointer_needed)
+ error ("%s cannot be used in % here",
+reg_names[HARD_FRAME_POINTER_REGNUM + i]);
+   else
+ df_set_regs_ever_live (HARD_FRAME_POINTER_REGNUM + i, true);
 }
 }



Re: [PATCH target/92295] Fix inefficient vector constructor

2019-11-02 Thread Hongtao Liu
Hi Jakub:
  Could you help reviewing this patch.

PS: Since this patch is related to vectors(avx512f), and Uros
mentioned before that he has no intension to maintain avx512f.

On Fri, Nov 1, 2019 at 9:12 AM Hongtao Liu  wrote:
>
> Hi uros:
>   This patch is about to fix inefficient vector constructor.
>   Currently in ix86_expand_vector_init_concat, vector are initialized
> per 2 elements which can miss some optimization opportunity like
> pr92295.
>
>   Bootstrap and i386 regression test is ok.
>   Ok for trunk?
>
> Changelog
> gcc/
> PR target/92295
> * config/i386/i386-expand.c (ix86_expand_vector_init_concat)
> Enhance ix86_expand_vector_init_concat.
>
> gcc/testsuite
> * gcc.target/i386/pr92295.c: New test.
>
> --
> BR,
> Hongtao



-- 
BR,
Hongtao


[patch, fortran] Fix PR 92113

2019-11-02 Thread Thomas Koenig

Hello world,

the attached patch fixes an 8/9/10 regression where, to fix PR 84487
by not putting the initializers and vtabs into the read-only section
(for reasons of size, which could grow enormously) led to a regression
on POWER9 and other non-x86 architectures, where the initializer was
sometimes optimized away, depending on optimization levels.

This was a strange beast to hunt down. This only showed up on
the testresults for gcc 8, so I tried to find out what commit
had fixed this on trunk, in order to backport.

However, bisecting this I found that the test case actually
segfaults all the way up to current trunk when run by hand.
By running the testsuite, I didn't see it.  This is strange,
and raises some issues about the testsuite and the possibility
of a latent issue, but I lack the knowledge to hunt this down.

In the meantime, here is this patch, which puts the vtabs and
the initializers where the user actually specified something
into the read-only section again.

Test case: Well, theoretically it is already there, so it makes
little sense to add a new one.

Regression-tested on powerpc64le-unknown-linux-gnu, also
verified by hand that pr51434.f90 now passes with -O2 there.

OK for trunk/9/8?

Regards

Thomas

2019-11-02  Thomas Koenig   




PR fortran/92133 

* trans-decl.c (gfc_get_symbol_decl): If __def_init actually 


contains a value, put it into  the read-only section.
Index: trans-decl.c
===
--- trans-decl.c	(Revision 277486)
+++ trans-decl.c	(Arbeitskopie)
@@ -1911,14 +1911,19 @@ gfc_get_symbol_decl (gfc_symbol * sym)
   if (sym->attr.associate_var)
 GFC_DECL_ASSOCIATE_VAR_P (decl) = 1;
 
-  /* We no longer mark __def_init as read-only so it does not take up
- space in the read-only section and dan go into the BSS instead,
- see PR 84487.  Marking this as artificial means that OpenMP will
- treat this as predetermined shared.  */
-  if (sym->attr.vtab
-  || (sym->name[0] == '_' && gfc_str_startswith (sym->name, "__def_init")))
-DECL_ARTIFICIAL (decl) = 1;
+  /* We only mark __def_init as read-only if it actually has an
+ initializer so it does not needlessly take up space in the
+ read-only section and can go into the BSS instead, see PR 84487.
+ Marking this as artificial means that OpenMP will treat this as
+ predetermined shared.  */
 
+  if (sym->attr.vtab || gfc_str_startswith (sym->name, "__def_init"))
+{
+  DECL_ARTIFICIAL (decl) = 1;
+  if (sym->attr.vtab || sym->value)
+	TREE_READONLY (decl) = 1;
+}
+
   return decl;
 }
 


[committed] declare variant scoring

2019-11-02 Thread Jakub Jelinek
Hi!

The following patch implements the scoring, except it doesn't handle the
case when a call is nested in 188+ OpenMP constructs yet.

At least in the current standard wording, the score can be a sum of
up to 8 2^X numbers where X is quite arbitrary constant (because the
construct nesting depth can be arbitrary too) plus some user provided
integral constants with supported integral types, so if it can't be represented
in the widest_int, I think I need to find some bit above what the sum of
the user constants (and 1) needs where some bit is unset and thus addition
can't overflow into further bits and simply represent the number as
widest_int + up to 8 2^X numbers represented by those Xs, and then just
write a comparison function for that.

Regtested on x86_64-linux and i686-linux, committed to trunk.

2019-11-02  Jakub Jelinek  

* gimplify.h (omp_construct_selector_matches): Change return
type to int, add a new SCORES argument.
* gimplify.c (omp_construct_selector_matches): Likewise.  If
SCORES is non-NULL, compute scores of each construct.
* omp-general.h (omp_get_context_selector): Declare.
* omp-general.c (omp_maybe_offloaded, omp_context_selector_matches):
Adjust omp_construct_selector_matches callers.
(omp_get_context_selector): New function, moved from c-family/c-omp.c.
(omp_context_compute_score): New function.
(omp_resolve_declare_variant): Compute scores and decide based on
that.
c-family/
* c-common.h (c_omp_get_context_selector): Remove.
* c-omp.c (c_omp_get_context_selector): Moved to omp-general.c
and renamed to omp_get_context_selector.
c/
* c-parser.c (c_finish_omp_declare_variant): Use
omp_get_context_selector instead of c_omp_get_context_selector.
cp/
* decl.c (omp_declare_variant_finalize_one): Use
omp_get_context_selector instead of c_omp_get_context_selector.
testsuite/
* c-c++-common/gomp/declare-variant-12.c: New test.

--- gcc/gimplify.h.jj   2019-11-01 22:19:46.253883112 +0100
+++ gcc/gimplify.h  2019-11-02 08:07:55.118710131 +0100
@@ -75,7 +75,7 @@ extern void omp_firstprivatize_variable
 extern enum gimplify_status gimplify_expr (tree *, gimple_seq *, gimple_seq *,
   bool (*) (tree), fallback_t);
 
-HOST_WIDE_INT omp_construct_selector_matches (enum tree_code *, int);
+int omp_construct_selector_matches (enum tree_code *, int, int *);
 
 extern void gimplify_type_sizes (tree, gimple_seq *);
 extern void gimplify_one_sizepos (tree *, gimple_seq *);
--- gcc/gimplify.c.jj   2019-11-01 22:19:46.222883585 +0100
+++ gcc/gimplify.c  2019-11-02 08:07:55.123710053 +0100
@@ -10381,14 +10381,24 @@ gimplify_adjust_omp_clauses (gimple_seq
 
 /* Return 0 if CONSTRUCTS selectors don't match the OpenMP context,
-1 if unknown yet (simd is involved, won't be known until vectorization)
-   and positive number if they do, the number is then the number of constructs
-   in the OpenMP context.  */
+   and 1 if they do.  If SCORES is non-NULL, it should point to an array
+   of at least 2*NCONSTRUCTS+2 ints, and will be filled with the positions
+   of the CONSTRUCTS (position -1 if it will never match) followed by
+   number of constructs in the OpenMP context construct trait.  If the
+   score depends on whether it will be in a declare simd clone or not,
+   the function returns 2 and there will be two sets of the scores, the first
+   one for the case that it is not in a declare simd clone, the other
+   that it is in a declare simd clone.  */
 
-HOST_WIDE_INT
-omp_construct_selector_matches (enum tree_code *constructs, int nconstructs)
+int
+omp_construct_selector_matches (enum tree_code *constructs, int nconstructs,
+   int *scores)
 {
   int matched = 0, cnt = 0;
   bool simd_seen = false;
+  bool target_seen = false;
+  int declare_simd_cnt = -1;
+  auto_vec codes;
   for (struct gimplify_omp_ctx *ctx = gimplify_omp_ctxp; ctx;)
 {
   if (((ctx->region_type & ORT_PARALLEL) && ctx->code == OMP_PARALLEL)
@@ -10401,7 +10411,9 @@ omp_construct_selector_matches (enum tre
  && !omp_find_clause (ctx->clauses, OMP_CLAUSE_BIND)))
{
  ++cnt;
- if (matched < nconstructs && ctx->code == constructs[matched])
+ if (scores)
+   codes.safe_push (ctx->code);
+ else if (matched < nconstructs && ctx->code == constructs[matched])
{
  if (ctx->code == OMP_SIMD)
{
@@ -10412,7 +10424,12 @@ omp_construct_selector_matches (enum tre
  ++matched;
}
  if (ctx->code == OMP_TARGET)
-   return matched < nconstructs ? 0 : simd_seen ? -1 : cnt;
+   {
+ if (scores == NULL)
+   return matched < nconstructs ? 0 : simd_seen ? -1 : 1;
+ target_seen = true;
+ break;
+   }
}
   else if 

[PING**2] [PATCH] Fix dwarf-lineinfo inconsistency of inlined subroutines

2019-11-02 Thread Bernd Edlinger
Ping...

On 10/27/19 9:14 AM, Bernd Edlinger wrote:
> Ping...
> 
> I'd like to ping for this patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
> 
> 
> Thanks
> Bernd.
> 
> On 10/20/19 9:58 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes an issue with the gdb step-over aka. "n" command.
>>
>> It can be seen when you debug an optimized stage-3 cc1
>> it does not affect -O0 code, though.
>>
>> This example debug session will explain the effect.
>>
>> (gdb) b get_alias_set
>> Breakpoint 5 at 0xa099f0: file ../../gcc-trunk/gcc/alias.c, line 837.
>> (gdb) r
>> Breakpoint 5, get_alias_set (t=t@entry=0x77ff7ab0) at 
>> ../../gcc-trunk/gcc/alias.c:837
>> 837if (t == error_mark_node
>> (gdb) n
>> 839&& (TREE_TYPE (t) == 0 || TREE_TYPE (t) == error_mark_node)))
>> (gdb) n
>> 3382   return __t;  <-- now we have a problem: wrong line info here
>> (gdb) bt
>> #0  get_alias_set (t=t@entry=0x77ff7ab0) at 
>> ../../gcc-trunk/gcc/tree.h:3382
>> #1  0x00b25dfe in set_mem_attributes_minus_bitpos 
>> (ref=0x7746f990, t=0x77ff7ab0, objectp=1, bitpos=...)
>> at ../../gcc-trunk/gcc/emit-rtl.c:1957
>> #2  0x01137a55 in make_decl_rtl (decl=0x77ff7ab0) at 
>> ../../gcc-trunk/gcc/varasm.c:1518
>> #3  0x0113b6e8 in assemble_variable (decl=0x77ff7ab0, 
>> top_level=, at_end=, 
>> dont_output_data=0) at ../../gcc-trunk/gcc/varasm.c:2246
>> #4  0x0113f0ea in varpool_node::assemble_decl (this=0x7745b000) 
>> at ../../gcc-trunk/gcc/varpool.c:584
>> #5  0x0113fa17 in varpool_node::assemble_decl (this=0x7745b000) 
>> at ../../gcc-trunk/gcc/varpool.c:750
>>
>>
>> There are at least two problems here:
>>
>> First you did not want to step into the TREE_TYPE, but it happens all
>> the time, even if you use "n" to step over it.
>>
>> And secondly, from the call stack, you don't know where you are in 
>> get_alias_set.
>> But the code that is executing at this point is actually the x == 0 || x == 
>> error_mark_node
>> from alias.c, line 839, which contains the inlined body of the TREE_TYPE, but
>> the rest of the if.  So there is an inconsistency in the  
>>
>> Contents of the .debug_info section:
>>
>>  <2><4f686>: Abbrev Number: 12 (DW_TAG_inlined_subroutine)
>> <4f687>   DW_AT_abstract_origin: <0x53d4e>
>> <4f68b>   DW_AT_entry_pc: 0x7280
>> <4f693>   DW_AT_GNU_entry_view: 1
>> <4f695>   DW_AT_ranges  : 0xb480
>> <4f699>   DW_AT_call_file   : 8  <- alias.c
>> <4f69a>   DW_AT_call_line   : 839
>> <4f69c>   DW_AT_call_column : 8
>> <4f69d>   DW_AT_sibling : <0x4f717>
>>
>>  The File Name Table (offset 0x253):
>>   8 2   0   0   alias.c
>>   102   0   0   tree.h
>>
>> Contents of the .debug_ranges section:
>>
>> b480 7280 7291 
>> b480 2764 277e 
>> b480 
>>
>> The problem is at pc=0x7291 in the Line Number Section:
>>
>>  Line Number Statements:
>>
>>   [0x8826]  Special opcode 61: advance Address by 4 to 0x7284 and Line 
>> by 0 to 3380
>>   [0x8827]  Set is_stmt to 1
>>   [0x8828]  Special opcode 189: advance Address by 13 to 0x7291 and Line 
>> by 2 to 3382 (*)
>>   [0x8829]  Set is_stmt to 0 (**)
>>   [0x882a]  Copy (view 1)
>>   [0x882b]  Set File Name to entry 8 in the File Name Table <- back to 
>> alias.c
>>   [0x882d]  Set column to 8
>>   [0x882f]  Advance Line by -2543 to 839
>>   [0x8832]  Copy (view 2)
>>   [0x8833]  Set column to 27
>>   [0x8835]  Special opcode 61: advance Address by 4 to 0x7295 and Line 
>> by 0 to 839
>>   [0x8836]  Set column to 3
>>   [0x8838]  Set is_stmt to 1 <-- next line info counts: alias.c:847
>>   [0x8839]  Special opcode 153: advance Address by 10 to 0x729f and Line 
>> by 8 to 847
>>   [0x883a]  Set column to 7
>>
>> (*) this line is tree.h:3382, but the program counter is *not* within the 
>> subroutine,
>> but exactly at the first instruction *after* the subroutine according to the 
>> debug_ranges.
>>
>> What makes it worse, is that (**) makes gdb ignore the new location info 
>> alias.c:839,
>> which means, normally the n command would have continued to pc=0x729f, which 
>> is at alias.c:847.
>>
>>
>> The problem happens due to a block with only var
>> This patch fixes this problem by moving (**) to the first statement with a 
>> different line number.
>>
>> In alias.c.316r.final this looks like that:
>>
>> (note 2884 2883 1995 31 0x7f903a931ba0 NOTE_INSN_BLOCK_BEG)
>> (note 1995 2884 2885 31 ../../gcc-trunk/gcc/tree.h:3377 
>> NOTE_INSN_INLINE_ENTRY)
>> (note 2885 1995 1996 31 0x7f903a931c00 NOTE_INSN_BLOCK_BEG)
>> [...]
>> (note 50 39 59 32 [bb 32] NOTE_INSN_BASIC_BLOCK)
>> (note 59 50 60 32 NOTE_INSN_DELETED)
>> (note 60 59 1997 32 NOTE_INSN_DELETED)
>> (note 1997 60 2239 32 ../../gcc-trunk/gcc/tree.h:3382 NOTE_INSN_BEGIN_STMT)
>> (note 2239 1997 2240 32 (var_location