Re: copy/copy_backward/fill/fill_n/equal rework

[François Dumont]

Ping ?

On 9/9/19 8:34 PM, François Dumont wrote:

Hi

    This patch improves stl_algobase.h 
copy/copy_backward/fill/fill_n/equal implementations. The improvements 
are:


- activation of algo specialization for __gnu_debug::_Safe_iterator 
(w/o _GLIBCXX_DEBUG mode)


- activation of algo specialization for _Deque_iterator even if mixed 
with another kind of iterator.


- activation of algo specializations __copy_move_a2 for something else 
than pointers. For example this code:


std::vector v { 'a', 'b',  };

ostreambuf_iterator out(std::cout);

std::copy(v.begin(), v.end(), out);

is not calling the specialization __copy_move_a2(const char*, const 
char*, ostreambuf_iterator<>);


It also fix a _GLIBCXX_DEBUG issue where the __niter_base 
specialization was wrongly removing the _Safe_iterator<> layer. The 
testsuite/25_algorithms/copy/debug/1_neg.cc test case was failing on a 
debug assertion because _after_ the copy we were trying to increment 
the vector iterator after past-the-end. Of course the problem is the 
_after_, Debug mode should detect this _before_ it takes place which 
it does now.


Note that std::fill_n is now making use of std::fill for some 
optimizations dealing with random access iterators.


Performances are very good:

Before:

copy_backward_deque_iterators.cc    deque 2 deque 1084r 1084u 
0s 0mem    0pf
copy_backward_deque_iterators.cc    deque 2 vector 3373r 3372u 
0s 0mem    0pf
copy_backward_deque_iterators.cc    vector 2 deque 3316r 3316u 
0s 0mem    0pf
copy_backward_deque_iterators.cc    int deque 2 char vector 3610r 
3609u    0s 0mem    0pf
copy_backward_deque_iterators.cc    char vector 2 int deque 3552r 
3552u    0s 0mem    0pf
copy_backward_deque_iterators.cc    deque 2 list 10528r 10528u 
0s 0mem    0pf
copy_backward_deque_iterators.cc    list 2 deque 2161r 2162u 
0s 0mem    0pf
copy_deque_iterators.cc      deque 2 deque         752r 
751u    0s 0mem    0pf
copy_deque_iterators.cc      deque 2 vector       3300r 
3299u    0s 0mem    0pf
copy_deque_iterators.cc      vector 2 deque       3144r 
3140u    0s 0mem    0pf
copy_deque_iterators.cc      int deque 2 char vector      3340r 
3338u    1s 0mem    0pf
copy_deque_iterators.cc      char vector 2 int deque      3132r 
3132u    0s 0mem    0pf
copy_deque_iterators.cc      deque 2 list     10013r 
10012u    0s 0mem    0pf
copy_deque_iterators.cc      list 2 deque     2274r 
2275u    0s 0mem    0pf
equal_deque_iterators.cc     deque vs deque       8676r 
8675u    0s 0mem    0pf
equal_deque_iterators.cc     deque vs vector      5870r 
5870u    0s 0mem    0pf
equal_deque_iterators.cc     vector vs deque      3163r 
3163u    0s 0mem    0pf
equal_deque_iterators.cc     int deque vs char vector     5845r 
5845u    0s 0mem    0pf
equal_deque_iterators.cc     char vector vs int deque     3307r 
3307u    0s 0mem    0pf


After:

copy_backward_deque_iterators.cc    deque 2 deque  697r  697u 
0s 0mem    0pf
copy_backward_deque_iterators.cc    deque 2 vector  219r  218u 
0s 0mem    0pf
copy_backward_deque_iterators.cc    vector 2 deque  453r  453u 
0s 0mem    0pf
copy_backward_deque_iterators.cc    int deque 2 char vector 1914r 
1915u    0s 0mem    0pf
copy_backward_deque_iterators.cc    char vector 2 int deque 2112r 
2111u    0s 0mem    0pf
copy_backward_deque_iterators.cc    deque 2 list 7770r 7771u 
0s 0mem    0pf
copy_backward_deque_iterators.cc    list 2 deque 2194r 2193u 
0s 0mem    0pf
copy_deque_iterators.cc      deque 2 deque         505r 
504u    0s 0mem    0pf
copy_deque_iterators.cc      deque 2 vector        221r 
221u    0s 0mem    0pf
copy_deque_iterators.cc      vector 2 deque        398r 
397u    0s 0mem    0pf
copy_deque_iterators.cc      int deque 2 char vector      1770r 
1767u    0s 0mem    0pf
copy_deque_iterators.cc      char vector 2 int deque      1995r 
1993u    0s 0mem    0pf
copy_deque_iterators.cc      deque 2 list     7650r 
7641u    2s 0mem    0pf
copy_deque_iterators.cc      list 2 deque     2270r 
2270u    0s 0mem    0pf
equal_deque_iterators.cc     deque vs deque        769r 
768u    0s 0mem    0pf
equal_deque_iterators.cc     deque vs vector       231r 
230u    0s 0mem    0pf
equal_deque_iterators.cc     vector vs deque       397r 
397u    0s 0mem    0pf
equal_deque_iterators.cc     int deque vs char vector     1541r 
1541u    0s 0mem    0pf
equal_deque_iterators.cc     char vector vs int deque     1623r 
1623u    0s 0mem    0pf


In Debug Mode it is of course even better. I haven't had the patience 
to run the benches before the patch, it just takes 

Re: C++ PATCH for c++/91877 - ICE with converting member of packed struct.

[Jason Merrill]

On 9/24/19 11:17 AM, Marek Polacek wrote:

This started to ICE with my CWG 2352 fix.  In reference_binding, we now bind
directly when the types are similar, not just when they are the same.  But even
direct binding can involve a temporary, e.g. for a bit-field, or, as in this
test, for a packed field.


Well, if there's a temporary, it isn't direct binding.


convert_like will actually create the temporary, but we were triggering the
assert checking that the types are the same.  Now they don't have to be, so
adjust the assert accordingly.


Previously we could have gotten a derived class, but we would have a 
ck_base to make the assert succeed.  Do we want a ck_qual under the 
ck_ref_bind?  It isn't necessary for adjustment, but might be helpful 
for conversion sequence ranking (which seems to be missing some standard 
wording).  On the other hand, it might be too much trouble making things 
understand ck_ref_bind around ck_qual, and compare_ics can probably do 
just fine without.


The patch is OK, but please add some testcases for overload resolution 
with more and less-qualified similar types.



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

2019-09-24  Marek Polacek  

PR c++/91877 - ICE with converting member of packed struct.
* call.c (convert_like_real): Use similar_type_p in an assert.

* g++.dg/conversion/packed1.C: New test.

diff --git gcc/cp/call.c gcc/cp/call.c
index 77f10a9f5f1..45b984ecb11 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -7382,8 +7382,7 @@ convert_like_real (conversion *convs, tree expr, tree fn, 
int argnum,
tree type = TREE_TYPE (ref_type);
cp_lvalue_kind lvalue = lvalue_kind (expr);
  
-	gcc_assert (same_type_ignoring_top_level_qualifiers_p

-   (type, next_conversion (convs)->type));
+   gcc_assert (similar_type_p (type, next_conversion (convs)->type));
if (!CP_TYPE_CONST_NON_VOLATILE_P (type)
&& !TYPE_REF_IS_RVALUE (ref_type))
  {
diff --git gcc/testsuite/g++.dg/conversion/packed1.C 
gcc/testsuite/g++.dg/conversion/packed1.C
new file mode 100644
index 000..c4be930bc19
--- /dev/null
+++ gcc/testsuite/g++.dg/conversion/packed1.C
@@ -0,0 +1,12 @@
+// PR c++/91877 - ICE with converting member of packed struct.
+// { dg-do compile { target c++11 } }
+// { dg-options "-fpack-struct" }
+
+template  class b {
+public:
+  b(const a &);
+};
+struct {
+  int *c;
+} d;
+void e() { b(d.c); }

[Bug middle-end/23409] [meta-bug] data dependence analyzer (BAD vs. BOP)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> None of the bugs that this one depends upon are still open. Is it ok to
> close this?

Assuming that's the case; closing.

[PATCH v4] Missed function specialization + partial devirtualization

[luoxhu]

Hi,

Sorry for replying so late due to cauldron conference and other LTO issues
I was working on.

v4 Changes:
 1. Rebase to trunk.
 2. Remove num_of_ics and use vector's length to avoid redundancy.
 3. Update the code in ipa-profile.c to improve review feasibility.
 4. Add function has_indirect_call_p and has_multiple_indirect_call_p.
 5. For parameter control, I will leave it to next patch as it is a
relative independent function.  Currently, maximum number of
promotions is GCOV_TOPN_VALUES as only 4 profiling value limited
from profile-generate, therefore minimum probability is adjusted to
25% in value-prof.c, it was 75% also by hard code for single
indirect target.  No control to minimal number of edge
executions yet.  What's more, this patch is a bit large now.

This patch aims to fix PR69678 caused by PGO indirect call profiling
performance issues.
The bug that profiling data is never working was fixed by Martin's pull
back of topN patches, performance got GEOMEAN ~1% improvement(+24% for
511.povray_r specifically).
Still, currently the default profile only generates SINGLE indirect target
that called more than 75%.  This patch leverages MULTIPLE indirect
targets use in LTO-WPA and LTO-LTRANS stage, as a result, function
specialization, profiling, partial devirtualization, inlining and
cloning could be done successfully based on it.
Performance can get improved from 0.70 sec to 0.38 sec on simple tests.
Details are:
  1.  PGO with topn is enabled by default now, but only one indirect
  target edge will be generated in ipa-profile pass, so add variables to enable
  multiple speculative edges through passes, speculative_id will record the
  direct edge index bind to the indirect edge, indirect_call_targets length
  records how many direct edges owned by the indirect edge, postpone gimple_ic
  to ipa-profile like default as inline pass will decide whether it is benefit
  to transform indirect call.
  2.  Use speculative_id to track and search the reference node matched
  with the direct edge's callee for multiple targets.  Actually, it is the
  caller's responsibility to handle the direct edges mapped to same indirect
  edge.  speculative_call_info will return one of the direct edge specified,
  this will leverage current IPA edge process framework mostly.
  3.  Enable LTO WPA/LTRANS stage multiple indirect call targets analysis for
  profile full support in ipa passes and cgraph_edge functions.  speculative_id
  can be set by make_speculative id when multiple targets are binded to
  one indirect edge, and cloned if new edge is cloned.  speculative_id
  is streamed out and stream int by lto like lto_stmt_uid.
  4.  Add 1 in module testcase and 2 cross module testcases.
  5.  Bootstrap and regression test passed on Power8-LE.  No function
  and performance regression for SPEC2017.

gcc/ChangeLog

2019-09-25  Xiong Hu Luo  

PR ipa/69678
* cgraph.c (symbol_table::create_edge): Init speculative_id.
(cgraph_edge::make_speculative): Add param for setting speculative_id.
(cgraph_edge::speculative_call_info): Find reference by
speculative_id for multiple indirect targets.
(cgraph_edge::resolve_speculation): Decrease the speculations
for indirect edge, drop it's speculative if not direct target
left.
(cgraph_edge::redirect_call_stmt_to_callee): Likewise.
(cgraph_node::verify_node): Don't report error if speculative
edge not include statement.
(cgraph_edge::has_multiple_indirect_call_p): New function.
(cgraph_edge::has_indirect_call_p): New function.
* cgraph.h (struct indirect_target_info): New struct.
(indirect_call_targets): New vector variable.
(make_speculative): Add param for setting speculative_id.
(cgraph_edge::has_multiple_indirect_call_p): New declare.
(cgraph_edge::has_indirect_call_p): New declare.
(speculative_id): New variable.
* cgraphclones.c (cgraph_node::create_clone): Clone speculative_id.
* ipa-inline.c (inline_small_functions): Fix iterator update.
* ipa-profile.c (ipa_profile_generate_summary): Add indirect
multiple targets logic.
(ipa_profile): Likewise.
* ipa-ref.h (speculative_id): New variable.
* ipa.c (process_references): Fix typo.
* lto-cgraph.c (lto_output_edge): Add indirect multiple targets
logic.  Stream out speculative_id.
(input_edge): Likewise.
* predict.c (dump_prediction): Remove edges count assert to be
precise.
* symtab.c (symtab_node::create_reference): Init speculative_id.
(symtab_node::clone_references): Clone speculative_id.
(symtab_node::clone_referring): Clone speculative_id.
(symtab_node::clone_reference): Clone speculative_id.
(symtab_node::clear_stmts_in_references): Clear speculative_id.
* tree-inline.c (copy_bb): Duplicate all the 

[Bug c++/91876] Segmentation fault when comparing std::system_error::code() and std::errc::invalid_argument

[lachiepoop at naver dot com]

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

--- Comment #2 from Young  ---
(In reply to Jonathan Wakely from comment #1)
> The gdb backtrace shows your program is linked to the wrong libstdc++.so
> that comes from the gcc-4.4.7 system compiler, not the one from gcc-7.2.1
> that you compiled with.
> 
> See
> https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
> and
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.
> html#manual.intro.using.linkage.dynamic

Thanks for your comment. 
Following is an update of me trying to match libstdc++ and gcc version, which
ended up in smoke.

My executable(a.out) seems to linked against /usr/lib64/libstdc++.so.6. Take a
look at gdb log:

  #0  0x003603269ca2 in std::error_category::equivalent(std::error_code
const&, int) const () from /usr/lib64/libstdc++.so.6

And I have double checked as well:

  $ ldd a.out
linux-vdso.so.1 =>  (0x7ffe32ff3000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00360320)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0035fee0)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003600e0)
libc.so.6 => /lib64/libc.so.6 (0x0035fea0)
/lib64/ld-linux-x86-64.so.2 (0x0035fe20)
libm.so.6 => /lib64/libm.so.6 (0x0035ffa0)

My libstdc++ (surprisingly) appears to be of gcc 4:

  $ ls -l /usr/lib64/libstdc++.so.6
  lrwxrwxrwx. 1 root root 19 Feb 21  2017 /usr/lib64/libstdc++.so.6 ->
libstdc++.so.6.0.13

According to this
page(https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html#abi.versioning.history),
libstdc++.so.6.0.13 is of gcc 4.4.2, as Jonathan pointed out.

I am on CentOS 6 and devtoolset-7. The devtoolset-7 actually provides
libstdc++.so:

  $ ls -l
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/libstdc++.so
  -rw-r--r-- 1 root root 210 Oct 25  2017
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/libstdc++.so
  $ cat
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/libstdc++.so
  /* GNU ld script
 Use the shared library, but some functions are only in
 the static library, so try that secondarily.  */
  OUTPUT_FORMAT(elf64-x86-64)
  INPUT ( /usr/lib64/libstdc++.so.6 -lstdc++_nonshared )

And it is pointing back to /usr/lib64/libstdc++.so.6.0.13.

For the moment, I can not lay my hands on libstdc++.so.6.0.24, which, according
to the above page, is paired with gcc7.

Thank you.

Re: git conversion of GCC wwwdocs repository

[Jason Merrill]

On Tue, Sep 24, 2019 at 6:16 PM Joseph Myers  wrote:
> On Tue, 24 Sep 2019, Jonathan Wakely wrote:
> > On Tue, 24 Sep 2019 at 21:46, Joseph Myers wrote:
> > >
> > > Would anyone like to make any comments on this conversion from CVS to git?
> >
> > It looks pretty good. I note that the author map just uses the
> > committer's current email address, meaning I have commits using my
> > @redhat.com address nearly a decade before I started working at Red
> > Hat. But that's a small price to pay for moving from CVS to Git in my
> > opinion. And t's arguably correct to have all my commits under one
> > identity rather than several different ones anyway.
>
> If people prefer to use @gcc.gnu.org addresses, that's a small matter of
> adjusting the postprocessing of the author map from the gcc-conversion
> repository to replace the addresses there with usern...@gcc.gnu.org while
> keeping the names from that author map.  (The postprocessing is needed
> anyway for this conversion because cvs-fast-export uses a more restricted
> author map syntax than reposurgeon does.  Because there is no ChangeLog in
> wwwdocs, more sophisticated systems for identifying the relevant email
> address for each commit from the ChangeLog aren't practical the same way
> they are for the main GCC repository.)

That would be my preference.

Jason

[Bug other/91879] --with-build-sysroot doesn't work as expected

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
Those -isystem paths are the *non-sysroot* kind of paths for headers for a 
cross compiler.

There is no support for building a *non-sysroot* cross toolchain when its 
libc is installed in a location other than the configured location, as 
there is no non-sysroot-headers equivalent of --with-build-sysroot.  
Rather, you can only build a sysroot toolchain that way, meaning 
configuring with the --with-sysroot and --with-build-sysroot options.

If you want to configure a non-sysroot cross toolchain with such directory 
arrangements, you need to configure it as a sysroot one (with 
--with-sysroot=$prefix/$target and a corresponding --with-build-sysroot= 
option).  Then, you need to have a $target/usr -> . symlink present during 
the build process (under $DESTDIR/$prefix) to emulate a sysroot 
arrangement well enough for the installed headers to be found during the 
build (usr -> . works for newlib, other libraries may need other symlinks, 
e.g. mingw -> . for MinGW-w64 targets).  I don't know if that works for 
DJGPP, but it definitely works for newlib and MinGW-w64, as I've 
implemented build systems doing just that.

[Bug tree-optimization/91890] [10 Regression] -Warray-bounds warning testing glibc not suppressed by pragma

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-25
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=55881
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The diagnostic pragmas don't work very well for the middle-end
warnings (e.g., with inlining, as discussed in bug 55881).  In this test case,
moving the #pragma GCC diagnostic ignored above the strcpy calls does the
trick.  I haven't looked into why.  Something similar was reported in bug
66099.  Manu had some ideas for how to make it work more reliably but I haven't
had the time to work on it and don't expect to for GCC 10.

[PATCH] xtensa: fix PR target/91880

[Max Filippov]

Xtensa hwloop_optimize segfaults when zero overhead loop is about to be
inserted as the first instruction of the function.
Insert zero overhead loop instruction into new basic block before the
loop when basic block that precedes the loop is empty.

2019-09-24  Max Filippov  
gcc/
* config/xtensa/xtensa.c (hwloop_optimize): Insert zero overhead
loop instruction into new basic block before the loop when basic
block that precedes the loop is empty.

gcc/testsuite/
* gcc.target/xtensa/pr91880.c: New test case.
* gcc.target/xtensa/xtensa.exp: New test suite.
---
 gcc/config/xtensa/xtensa.c |  5 ++--
 gcc/testsuite/gcc.target/xtensa/pr91880.c  | 10 
 gcc/testsuite/gcc.target/xtensa/xtensa.exp | 41 ++
 3 files changed, 54 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/xtensa/pr91880.c
 create mode 100644 gcc/testsuite/gcc.target/xtensa/xtensa.exp

diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c
index ee5612441e25..2527468d57db 100644
--- a/gcc/config/xtensa/xtensa.c
+++ b/gcc/config/xtensa/xtensa.c
@@ -4235,7 +4235,9 @@ hwloop_optimize (hwloop_info loop)
 
   seq = get_insns ();
 
-  if (!single_succ_p (entry_bb) || vec_safe_length (loop->incoming) > 1)
+  entry_after = BB_END (entry_bb);
+  if (!single_succ_p (entry_bb) || vec_safe_length (loop->incoming) > 1
+  || !entry_after)
 {
   basic_block new_bb;
   edge e;
@@ -4256,7 +4258,6 @@ hwloop_optimize (hwloop_info loop)
 }
   else
 {
-  entry_after = BB_END (entry_bb);
   while (DEBUG_INSN_P (entry_after)
  || (NOTE_P (entry_after)
 && NOTE_KIND (entry_after) != NOTE_INSN_BASIC_BLOCK))
diff --git a/gcc/testsuite/gcc.target/xtensa/pr91880.c 
b/gcc/testsuite/gcc.target/xtensa/pr91880.c
new file mode 100644
index ..f4895a1bb8ec
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/pr91880.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fomit-frame-pointer -fno-tree-vectorize" } */
+
+void foo (unsigned int n, char *a, char *b)
+{
+  int i;
+
+  for (i = 0; i <= n - 1; ++i)
+a[i] = b[i];
+}
diff --git a/gcc/testsuite/gcc.target/xtensa/xtensa.exp 
b/gcc/testsuite/gcc.target/xtensa/xtensa.exp
new file mode 100644
index ..8720327f526e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/xtensa.exp
@@ -0,0 +1,41 @@
+# Copyright (C) 2019 Free Software Foundation, Inc.
+
+# This program 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 of the License, or
+# (at your option) any later version.
+#
+# This program 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 GCC; see the file COPYING3.  If not see
+# .
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Exit immediately if this isn't an Xtensa target.
+if ![istarget xtensa*-*-*] then {
+  return
+}
+
+# Load support procs.
+load_lib gcc-dg.exp
+
+# If a testcase doesn't have special options, use these.
+global DEFAULT_CFLAGS
+if ![info exists DEFAULT_CFLAGS] then {
+set DEFAULT_CFLAGS " -ansi -pedantic-errors"
+}
+
+# Initialize `dg'.
+dg-init
+
+# Main loop.
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\]]] \
+   "" $DEFAULT_CFLAGS
+
+# All done.
+dg-finish
-- 
2.11.0

Re: [Darwin, PPC, Mode Iterators 1/n, committed] Use mode iterators in picbase patterns.

[Segher Boessenkool]

Hi Iain,

On Tue, Sep 24, 2019 at 08:31:16PM +0100, Iain Sandoe wrote:
> This switches the picbase load and reload patterns to use the 'P' mode
> iterator instead of writing an SI and DI pattern for each (and deletes the
> old patterns).  No functional change intended.

>  (define_expand "load_macho_picbase"
> -  [(set (reg:SI LR_REGNO)
> +  [(set (reg LR_REGNO)

This changes it to VOIDmode instead?  It should have been reg:P LR_REGNO?

>  (define_expand "reload_macho_picbase"
> -  [(set (reg:SI LR_REGNO)
> +  [(set (reg LR_REGNO)

Same here.


Segher

[Bug other/91879] --with-build-sysroot doesn't work as expected

[stsp at users dot sourceforge.net]

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

--- Comment #10 from Stas Sergeev  ---
(In reply to Jonathan Wakely from comment #9)
> It's possible the paths passed to -isystem should be prefixed with = when a
> sysroot is in use,

Great idea! Maybe it can even be unconditional,
as w/o --sysroot it won't change anything?
I hacked that solution in. Also I've found that
I was setting --with-build-sysroot wrongly in the
previous example: I included prefix into it, but
it shouldn't be there.

Now with your = idea I've got further only for a
tiny bit. It fails on the same conftest as before.
It now finds the headers! But fails to find libs...
---
configure:4135:
/home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/x
gcc -B/home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/
-B/usr/loc
al/cross/i586-pc-msdosdjgpp/bin/ -B/usr/local/cross/i586-pc-msdosdjgpp/lib/
-isy
stem=/usr/local/cross/i586-pc-msdosdjgpp/include
-isystem=/usr/local/cross/i586-
pc-msdosdjgpp/sys-include --sysroot=/home/stas/src/build-gcc/ttt   -o conftest
-
g -O2   conftest.c  >&5
/home/stas/src/build-gcc/ttt/usr/local/cross/bin/i586-pc-msdosdjgpp-ld: cannot
f
ind crt0.o: No such file or directory
/home/stas/src/build-gcc/ttt/usr/local/cross/bin/i586-pc-msdosdjgpp-ld: cannot
f
ind -lc
collect2: error: ld returned 1 exit status
---

If I correct -B options above, then it links!
Any firther ideas? :) We are really getting close
to the solution.


> but prefixing them with $DESTDIR is definitely wrong.

I renamed the ticket. Sorry for misleading conclusions.

[Bug tree-optimization/91890] New: [10 Regression] -Warray-bounds warning testing glibc not suppressed by pragma

[jsm28 at gcc dot gnu.org]

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

Bug ID: 91890
   Summary: [10 Regression] -Warray-bounds warning testing glibc
not suppressed by pragma
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

r275981 ("PR middle-end/91631 - buffer overflow into an array member of a
declared object not detected") introduced an error when the following code is
built with -O2 -Wall -Werror (the problem isn't that there is a -Warray-bounds
diagnostic for the code, the problem is that the pragma is no longer
suppressing it for some reason). This is reduced from a glibc testcase (which
has had the pragma to suppress the warning for some time, but the pragma is no
longer working).

char one[50];
char two[50];

void
test_strncat (void)
{
  (void) __builtin_strcpy (one, "gh");
  (void) __builtin_strcpy (two, "ef");

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-overflow="
#pragma GCC diagnostic ignored "-Warray-bounds"
  (void) __builtin_strncat (one, two, 99); 
#pragma GCC diagnostic pop
}


aarch64-glibc-linux-gnu-gcc -S -O2 -Wall -Werror tester.c
tester.c: In function 'test_strncat':
tester.c:13:10: error: '__builtin_strncat' forming offset [50, 98] is out of
the bounds [0, 50] of object 'one' with type 'char[50]' [-Werror=array-bounds]
   13 |   (void) __builtin_strncat (one, two, 99);
  |  ^~~~
tester.c:1:6: note: 'one' declared here
1 | char one[50];
  |  ^~~
cc1: all warnings being treated as errors

[Bug c++/91889] Boost does not build with top-of-tree GCC

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Can I get a preprocessed source file?

[Bug c++/91889] New: Boost does not build with top-of-tree GCC

[sje at gcc dot gnu.org]

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

Bug ID: 91889
   Summary: Boost does not build with top-of-tree GCC
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

A recent g++ change broke the boost build.  It is dying with many (many)
errors like this:

./boost/intrusive/list.hpp:1448:7:   required from here
./boost/intrusive/detail/list_iterator.hpp:93:41: error: call of overloaded
'get
_next(boost::intrusive::list_node*&)' is ambiguous
   93 |   node_ptr p = node_traits::get_next(members_.nodeptr_);
  |~^~~
In file included from ./boost/intrusive/list_hook.hpp:20,
 from ./boost/intrusive/list.hpp:20,
 from ./boost/fiber/context.hpp:29,
 from libs/fiber/src/algo/algorithm.cpp:9:

Marek thinks it is due to his recent patch:

commit 5ac76b02008255b7f427e6309c2dc3e42bd64561
Author: mpolacek 
Date:   Mon Sep 23 17:37:54 2019 +

PR c++/91844 - Implement CWG 2352, Similar types and reference
binding.
* call.c (reference_related_p): Use similar_type_p instead of
same_type_p.
(reference_compatible_p): Update implementation to match CWG 2352.
* cp-tree.h (similar_type_p): Declare.
* typeck.c (similar_type_p): New.

* g++.dg/cpp0x/pr33930.C: Add dg-error.
* g++.dg/cpp0x/ref-bind1.C: New test.
* g++.dg/cpp0x/ref-bind2.C: New test.
* g++.dg/cpp0x/ref-bind3.C: New test.
* g++.old-deja/g++.pt/spec35.C: Remove dg-error.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@276058
138bc75d-0d04-0410-961f-82ee72b054a4

[PATCH] PR fortran/91802 -- rank+corank must be less than 16

[Steve Kargl]

The attached patch has been tested on x86_64-*-freebsd.  OK to commit?

2019-09-24  Steven G. Kargl  

PR fortran/91802
* decl.c (attr_decl1): Check if rank+corank > 15.

2019-09-24  Steven G. Kargl  

PR fortran/91802
* gfortran.dg/pr91802.f90: New test.
-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 275969)
+++ gcc/fortran/decl.c	(working copy)
@@ -8468,6 +8468,15 @@ attr_decl1 (void)
   goto cleanup;
 }
 
+  /* Check F2018:C822.  */
+  if (sym->attr.dimension && sym->attr.codimension
+  && sym->as && sym->as->rank + sym->as->corank > 15)
+{
+  gfc_error ("rank + corank of %qs exceeds 15 at %C", sym->name);
+  m = MATCH_ERROR;
+  goto cleanup;
+}
+
   if (sym->attr.cray_pointee && sym->as != NULL)
 {
   /* Fix the array spec.  */
Index: gcc/testsuite/gfortran.dg/pr91802.f90
===
--- gcc/testsuite/gfortran.dg/pr91802.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91802.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=single" }
+! Code contributed by Gerhard Steinmetz
+! PR fortran/91802
+module m
+   real :: x
+   dimension ::   x(1,2,1,2,1,2,1,2)
+   codimension :: x[1,2,1,2,1,2,1,*] ! { dg-error "exceeds 15" }
+end

Re: Boost build broken due to recent C++ change?

[Marek Polacek]

On Tue, Sep 24, 2019 at 10:16:27PM +, Steve Ellcey wrote:
> A recent g++ change (I haven't tracked down exactly which one, but in
> the last day or two) seems to have broken my boost build.  It is dying
> with lots of errors like:
> 
> ./boost/intrusive/list.hpp:1448:7:   required from here
> ./boost/intrusive/detail/list_iterator.hpp:93:41: error: call of
> overloaded 'get
> _next(boost::intrusive::list_node*&)' is ambiguous
>93 |   node_ptr p = node_traits::get_next(members_.nodeptr_);
>   |~^~~
> In file included from ./boost/intrusive/list_hook.hpp:20,
>  from ./boost/intrusive/list.hpp:20,
>  from ./boost/fiber/context.hpp:29,
>  from libs/fiber/src/algo/algorithm.cpp:9:
> 
> Has anyone else run into this?  I will try to create a cutdown test
> case.

I'm afraid this will be my

commit 5ac76b02008255b7f427e6309c2dc3e42bd64561
Author: mpolacek 
Date:   Mon Sep 23 17:37:54 2019 +

PR c++/91844 - Implement CWG 2352, Similar types and reference 
binding.
* call.c (reference_related_p): Use similar_type_p instead of
same_type_p.
(reference_compatible_p): Update implementation to match CWG 2352.
* cp-tree.h (similar_type_p): Declare.
* typeck.c (similar_type_p): New.

* g++.dg/cpp0x/pr33930.C: Add dg-error.
* g++.dg/cpp0x/ref-bind1.C: New test.
* g++.dg/cpp0x/ref-bind2.C: New test.
* g++.dg/cpp0x/ref-bind3.C: New test.
* g++.old-deja/g++.pt/spec35.C: Remove dg-error.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@276058 
138bc75d-0d04-0410-961f-82ee72b054a4

Please open a bug.

Marek

[PATCH] The inline keyword is supported in all new C standards

[Palmer Dabbelt]

The documentation used to indicate that the inline keyword was only
supported by c99 and c11, whereas in fact it is supported by c99 and all
newer standards.

gcc/ChangeLog

2019-09-24  Palmer Dabbelt  

* doc/extended.texi (Alternate Keywords): Change "-std=c11" to "a
later standard."
---
 gcc/doc/extend.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 64fccfe9b87..ef2fde3d989 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10739,7 +10739,7 @@ a general-purpose header file that should be usable by 
all programs,
 including ISO C programs.  The keywords @code{asm}, @code{typeof} and
 @code{inline} are not available in programs compiled with
 @option{-ansi} or @option{-std} (although @code{inline} can be used in a
-program compiled with @option{-std=c99} or @option{-std=c11}).  The
+program compiled with @option{-std=c99} or a later standard).  The
 ISO C99 keyword
 @code{restrict} is only available when @option{-std=gnu99} (which will
 eventually be the default) or @option{-std=c99} (or the equivalent
-- 
2.21.0

[Bug debug/91887] [7/8/9/10 Regression] -fdebug-types-section ICE building chromium

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #3 from Marek Polacek  ---
class A {
public:
  A();
  template  A(U);
};
template  struct B { typedef A type; };
template 
int Bind(R(Args...), typename B::type...) { return 0; }
void KeepBufferRefs(A, A) { A a, b(Bind(KeepBufferRefs, a, b)); }

Re: git conversion of GCC wwwdocs repository

[Jonathan Wakely]

On Tue, 24 Sep 2019 at 23:15, Joseph Myers wrote:
>
> On Tue, 24 Sep 2019, Jonathan Wakely wrote:
>
> > On Tue, 24 Sep 2019 at 21:46, Joseph Myers wrote:
> > >
> > > Would anyone like to make any comments on this conversion from CVS to git?
> >
> > It looks pretty good. I note that the author map just uses the
> > committer's current email address, meaning I have commits using my
> > @redhat.com address nearly a decade before I started working at Red
> > Hat. But that's a small price to pay for moving from CVS to Git in my
> > opinion. And t's arguably correct to have all my commits under one
> > identity rather than several different ones anyway.
>
> If people prefer to use @gcc.gnu.org addresses, that's a small matter of
> adjusting the postprocessing of the author map from the gcc-conversion
> repository to replace the addresses there with usern...@gcc.gnu.org while
> keeping the names from that author map.

I don't feel strongly about it.

Boost build broken due to recent C++ change?

[Steve Ellcey]

A recent g++ change (I haven't tracked down exactly which one, but in
the last day or two) seems to have broken my boost build.  It is dying
with lots of errors like:

./boost/intrusive/list.hpp:1448:7:   required from here
./boost/intrusive/detail/list_iterator.hpp:93:41: error: call of
overloaded 'get
_next(boost::intrusive::list_node*&)' is ambiguous
   93 |   node_ptr p = node_traits::get_next(members_.nodeptr_);
  |~^~~
In file included from ./boost/intrusive/list_hook.hpp:20,
 from ./boost/intrusive/list.hpp:20,
 from ./boost/fiber/context.hpp:29,
 from libs/fiber/src/algo/algorithm.cpp:9:

Has anyone else run into this?  I will try to create a cutdown test
case.

Steve Ellcey
sell...@marvell.com

Re: git conversion of GCC wwwdocs repository

[Joseph Myers]

On Tue, 24 Sep 2019, Jonathan Wakely wrote:

> On Tue, 24 Sep 2019 at 21:46, Joseph Myers wrote:
> >
> > Would anyone like to make any comments on this conversion from CVS to git?
> 
> It looks pretty good. I note that the author map just uses the
> committer's current email address, meaning I have commits using my
> @redhat.com address nearly a decade before I started working at Red
> Hat. But that's a small price to pay for moving from CVS to Git in my
> opinion. And t's arguably correct to have all my commits under one
> identity rather than several different ones anyway.

If people prefer to use @gcc.gnu.org addresses, that's a small matter of 
adjusting the postprocessing of the author map from the gcc-conversion 
repository to replace the addresses there with usern...@gcc.gnu.org while 
keeping the names from that author map.  (The postprocessing is needed 
anyway for this conversion because cvs-fast-export uses a more restricted 
author map syntax than reposurgeon does.  Because there is no ChangeLog in 
wwwdocs, more sophisticated systems for identifying the relevant email 
address for each commit from the ChangeLog aren't practical the same way 
they are for the main GCC repository.)

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

Re: git conversion of GCC wwwdocs repository

[Jonathan Wakely]

On Tue, 24 Sep 2019 at 21:46, Joseph Myers wrote:
>
> Would anyone like to make any comments on this conversion from CVS to git?

It looks pretty good. I note that the author map just uses the
committer's current email address, meaning I have commits using my
@redhat.com address nearly a decade before I started working at Red
Hat. But that's a small price to pay for moving from CVS to Git in my
opinion. And t's arguably correct to have all my commits under one
identity rather than several different ones anyway.

[PATCH] PR fortran/91864 -- inquiry parameter is a constant

[Steve Kargl]

The attached patch has been tested on x86_64-*-freebsd.  OK to commit?

2019-09-24  Steven G. Kargl  

PR fortran/91864
* gcc/fortran/io.c (match_io_element): An inquiry parameter cannot be
read into.
* gcc/fortran/match.c (gfc_match_allocate): An inquiry parameter 
can be neither an allocate-object nor stat variable.
(gfc_match_deallocate): An inquiry parameter cannot be deallocated.

2019-09-24  Steven G. Kargl  

PR fortran/91864
* gcc/testsuite/gfortran.dg/pr91864.f90

-- 
Steve
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c	(revision 276104)
+++ gcc/fortran/io.c	(working copy)
@@ -3657,8 +3657,18 @@ match_io_element (io_kind k, gfc_code **cpp)
 {
   m = gfc_match_variable (, 0);
   if (m == MATCH_NO)
-	gfc_error ("Expected variable in READ statement at %C");
+	{
+	  gfc_error ("Expecting variable in READ statement at %C");
+	  m = MATCH_ERROR;
+	}
 
+  if (m == MATCH_YES && expr->expr_type == EXPR_CONSTANT)
+	{
+	  gfc_error ("Expecting variable or io-implied-do in READ statement "
+		   "at %L", >where);
+	  m = MATCH_ERROR;
+	}
+
   if (m == MATCH_YES
 	  && expr->expr_type == EXPR_VARIABLE
 	  && expr->symtree->n.sym->attr.external)
@@ -3667,7 +3677,6 @@ match_io_element (io_kind k, gfc_code **cpp)
 		 >where);
 	  m = MATCH_ERROR;
 	}
-
 }
   else
 {
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 276104)
+++ gcc/fortran/match.c	(working copy)
@@ -4242,6 +4242,12 @@ gfc_match_allocate (void)
   if (m == MATCH_ERROR)
 	goto cleanup;
 
+  if (tail->expr->expr_type == EXPR_CONSTANT)
+	{
+	  gfc_error ("Unexpected constant at %C");
+	  goto cleanup;
+	}
+
   if (gfc_check_do_variable (tail->expr->symtree))
 	goto cleanup;
 
@@ -4374,6 +4380,12 @@ alloc_opt_list:
 	  tmp = NULL;
 	  saw_stat = true;
 
+	  if (stat->expr_type == EXPR_CONSTANT)
+	{
+	  gfc_error ("STAT tag at %L cannot be a constant", >where);
+	  goto cleanup;
+	}
+
 	  if (gfc_check_do_variable (stat->symtree))
 	goto cleanup;
 
@@ -4649,6 +4661,12 @@ gfc_match_deallocate (void)
 	goto cleanup;
   if (m == MATCH_NO)
 	goto syntax;
+
+  if (tail->expr->expr_type == EXPR_CONSTANT)
+	{
+	  gfc_error ("Unexpected constant at %C");
+	  goto cleanup;
+	}
 
   if (gfc_check_do_variable (tail->expr->symtree))
 	goto cleanup;
Index: gcc/testsuite/gfortran.dg/pr91864.f90
===
--- gcc/testsuite/gfortran.dg/pr91864.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91864.f90	(working copy)
@@ -0,0 +1,22 @@
+program p
+   integer :: i
+   read (*,*) i%kind   ! { dg-error "Expecting variable or io-implied-do" }
+end
+
+subroutine t
+   integer, allocatable :: x(:)
+   integer :: stat
+   allocate (x(3), stat=stat%kind)   ! { dg-error "cannot be a constant" }
+end
+
+subroutine u
+   integer, allocatable :: x(:)
+   integer :: stat
+   allocate (x(3), stat%kind=stat)   ! { dg-error "Unexpected constant" }
+end
+
+subroutine v
+   integer, allocatable :: x(:)
+   integer :: stat
+   deallocate (x, stat%kind=stat)   ! { dg-error "Unexpected constant" }
+end

[Bug other/91879] DESTDIR support seems incomplete

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
It's possible the paths passed to -isystem should be prefixed with = when a
sysroot is in use, but prefixing them with $DESTDIR is definitely wrong.

[Bug target/91880] ICE: segfault in hwloop_optimize

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
Minimal reproducer:

void f(unsigned int n, char *a, char *b)
{
int i;
for (i = 0; i <= n - 1; ++i)
a[i] = b[i];
}

The issue is that entry_bb is empty in the hwloop_optimize, and entry_after is
NULL.

[Bug other/91879] DESTDIR support seems incomplete

[stsp at users dot sourceforge.net]

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

--- Comment #8 from Stas Sergeev  ---
(In reply to Andrew Pinski from comment #7)
> Have you looked into --with-build-sysroot ?

Thanks! Very helpful.
But now it has the same problem when configuring libstdc++:
---
configure:4574:
/home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/x
gcc -B/home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/
-B/usr/loc
al/cross/i586-pc-msdosdjgpp/bin/ -B/usr/local/cross/i586-pc-msdosdjgpp/lib/
-isy
stem /usr/local/cross/i586-pc-msdosdjgpp/include -isystem
/usr/local/cross/i586-
pc-msdosdjgpp/sys-include
--sysroot=/home/stas/src/build-gcc/ttt/usr/local/cross
-c -g -O2  conftest.c >&5
conftest.c:10:10: fatal error: stdio.h: No such file or directory
   10 | #include 
  |  ^
---

As you can see, it added the correct --sysroot.
But unfortunately -isystem is still unaffected.
If I change -isystem in the command line above, then
conftest.c can be compiled.


Here's the full top-level configure invocation:
---
../gnu/gcc-9.2.0/configure --disable-plugin --enable-lto --disable-libssp --
disable-nls --enable-libquadmath-support --enable-version-specific-runtime-libs
--enable-fat --enable-libstdcxx-filesystem-ts
--with-build-sysroot=/home/stas/sr
c/build-gcc/ttt/usr/local/cross --target=i586-pc-msdosdjgpp
--prefix=/usr/local/
cross --enable-languages=c,c++
---

As you can see, I added --with-build-sysroot.

Re: [PATCH] Remove vectorizer reduction operand swapping

[Christophe Lyon]

On Wed, 18 Sep 2019 at 20:11, Richard Biener  wrote:
>
>
> It shouldn't be neccessary.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> (SLP part testing separately)
>
> Richard.
>
> 2019-09-18  Richard Biener  
>
> * tree-vect-loop.c (vect_is_simple_reduction): Remove operand
> swapping.
> (vectorize_fold_left_reduction): Remove assert.
> (vectorizable_reduction): Also expect COND_EXPR non-reduction
> operand in position 2.  Remove assert.
>

Hi,

Since this was committed (r275898), I've noticed a regression on armeb:
FAIL: gcc.dg/vect/vect-cond-4.c execution test

I'm seeing this with qemu, but I do not have the execution traces yet.

Christophe

> Index: gcc/tree-vect-loop.c
> ===
> --- gcc/tree-vect-loop.c(revision 275872)
> +++ gcc/tree-vect-loop.c(working copy)
> @@ -3278,56 +3278,8 @@ vect_is_simple_reduction (loop_vec_info
>   || !flow_bb_inside_loop_p (loop, gimple_bb (def2_info->stmt))
>   || vect_valid_reduction_input_p (def2_info)))
>  {
> -  if (! nested_in_vect_loop && orig_code != MINUS_EXPR)
> -   {
> - /* Check if we can swap operands (just for simplicity - so that
> -the rest of the code can assume that the reduction variable
> -is always the last (second) argument).  */
> - if (code == COND_EXPR)
> -   {
> - /* Swap cond_expr by inverting the condition.  */
> - tree cond_expr = gimple_assign_rhs1 (def_stmt);
> - enum tree_code invert_code = ERROR_MARK;
> - enum tree_code cond_code = TREE_CODE (cond_expr);
> -
> - if (TREE_CODE_CLASS (cond_code) == tcc_comparison)
> -   {
> - bool honor_nans = HONOR_NANS (TREE_OPERAND (cond_expr, 0));
> - invert_code = invert_tree_comparison (cond_code, 
> honor_nans);
> -   }
> - if (invert_code != ERROR_MARK)
> -   {
> - TREE_SET_CODE (cond_expr, invert_code);
> - swap_ssa_operands (def_stmt,
> -gimple_assign_rhs2_ptr (def_stmt),
> -gimple_assign_rhs3_ptr (def_stmt));
> -   }
> - else
> -   {
> - if (dump_enabled_p ())
> -   report_vect_op (MSG_NOTE, def_stmt,
> -   "detected reduction: cannot swap operands 
> "
> -   "for cond_expr");
> - return NULL;
> -   }
> -   }
> - else
> -   swap_ssa_operands (def_stmt, gimple_assign_rhs1_ptr (def_stmt),
> -  gimple_assign_rhs2_ptr (def_stmt));
> -
> - if (dump_enabled_p ())
> -   report_vect_op (MSG_NOTE, def_stmt,
> -   "detected reduction: need to swap operands: ");
> -
> - if (CONSTANT_CLASS_P (gimple_assign_rhs1 (def_stmt)))
> -   LOOP_VINFO_OPERANDS_SWAPPED (loop_info) = true;
> -}
> -  else
> -{
> -  if (dump_enabled_p ())
> -report_vect_op (MSG_NOTE, def_stmt, "detected reduction: ");
> -}
> -
> +  if (dump_enabled_p ())
> +   report_vect_op (MSG_NOTE, def_stmt, "detected reduction: ");
>return def_stmt_info;
>  }
>
> @@ -5969,7 +5921,6 @@ vectorize_fold_left_reduction (stmt_vec_
>gcc_assert (!nested_in_vect_loop_p (loop, stmt_info));
>gcc_assert (ncopies == 1);
>gcc_assert (TREE_CODE_LENGTH (code) == binary_op);
> -  gcc_assert (reduc_index == (code == MINUS_EXPR ? 0 : 1));
>gcc_assert (STMT_VINFO_VEC_REDUCTION_TYPE (stmt_info)
>   == FOLD_LEFT_REDUCTION);
>
> @@ -6542,9 +6493,9 @@ vectorizable_reduction (stmt_vec_info st
>   reduc_index = i;
> }
>
> -  if (i == 1 && code == COND_EXPR)
> +  if (code == COND_EXPR)
> {
> - /* Record how value of COND_EXPR is defined.  */
> + /* Record how the non-reduction-def value of COND_EXPR is defined.  
> */
>   if (dt == vect_constant_def)
> {
>   cond_reduc_dt = dt;
> @@ -6622,10 +6573,6 @@ vectorizable_reduction (stmt_vec_info st
>   return false;
> }
>
> -  /* vect_is_simple_reduction ensured that operand 2 is the
> -loop-carried operand.  */
> -  gcc_assert (reduc_index == 2);
> -
>/* Loop peeling modifies initial value of reduction PHI, which
>  makes the reduction stmt to be transformed different to the
>  original stmt analyzed.  We need to record reduction code for

Re: git conversion of GCC wwwdocs repository

[Joseph Myers]

Would anyone like to make any comments on this conversion from CVS to git?

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

[Bug debug/91888] New: GCC will write absolute paths into DW_AT_GNU_dwo_name even with -fdebug-prefix-map

[cbiesinger at google dot com]

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

Bug ID: 91888
   Summary: GCC will write absolute paths into DW_AT_GNU_dwo_name
even with -fdebug-prefix-map
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbiesinger at google dot com
  Target Milestone: ---

Created attachment 46939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46939=edit
testcase script

$ readelf --debug-dump /tmp/outputs/foo
[...]
<20>   DW_AT_GNU_dwo_name: (indirect string, offset: 0x0):
/tmp/outputs/foo.dwo
<24>   DW_AT_comp_dir: .

That's despite compiling with -fdebug-prefix-map=/tmp=.

See the attached script that creates and compiles a simple c file.

(this is with gcc from git trunk, revision
e8f8842d90abe5eafa8c32f08fbc3a747a45747c from sep 24)

[Bug debug/91888] GCC will write absolute paths into DW_AT_GNU_dwo_name even with -fdebug-prefix-map

[cbiesinger at google dot com]

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

--- Comment #1 from Christian Biesinger  ---
(sorry, copied the wrong revision. it's actually
ed342df533bf18eee2d5f84f1251a13f43d78505 from sep 21)

Re: [libcpp] Issue a pedantic warning for UCNs outside UCS codespace

[Eric Botcazou]

> I think this has to depend on the C standards version.  I think each C
> standard needs to be read against the edition of ISO 10646 current at
> the time of standards approval (the references are sadly not
> versioned, so the version is implied).  Early versions of ISO 10646
> definitely do not have the codespace restriction you mention.

Note the already existing hardcoded check in ucn_valid_in_identifier though.

-- 
Eric Botcazou

[Bug c++/90309] Spurious warning shift-negative-value

[adl at gnu dot org]

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

Alexandre Duret-Lutz  changed:

   What|Removed |Added

 CC||adl at gnu dot org

--- Comment #6 from Alexandre Duret-Lutz  ---
Came here to report a similar issue, except without the virtual.

With gcc (Raspbian 8.3.0-6+rpi1) 8.3.0 from Raspbian buster on ARM:

$ cat foo2.cc
struct a
{
  int nonempty;
};

struct b
{
  typedef unsigned (b::*unsigned_fun)() const;
  unsigned_fun fun;
};

struct c: public a, public b
{
  c()
  {
fun = static_cast(::get_val);
  }
  unsigned get_val() const;
};

$ g++ -c -Wall -W foo2.cc
foo2.cc: In constructor ‘c::c()’:
foo2.cc:16:51: warning: left shift of negative value [-Wshift-negative-value]
 fun = static_cast(::get_val);
   ^
https://gcc.godbolt.org/z/J08QVd

Luckily in the project where this occurs I can simply swap the inheritance
order (public b, public a) to get rid of this warning.

Re: [C++ Patch] Use DECL_SOURCE_LOCATION more in name-lookup.c

[Marek Polacek]

On Tue, Sep 24, 2019 at 09:07:03PM +0200, Paolo Carlini wrote:
> Hi,
> 
> Marek's recent fix prompted an audit of name-lookup.c and I found a few
> additional straightforward places where we should use a more accurate
> location. Tested x86_64-linux.
> 
> Thanks, Paolo.
> 
> ///
> 

> /cp
> 2019-09-24  Paolo Carlini  
> 
>   * name-lookup.c (check_extern_c_conflict): Use DECL_SOURCE_LOCATION.
>   (check_local_shadow): Use it in three additional places.
> 
> /testsuite
> 2019-09-24  Paolo Carlini  
> 
>   * g++.dg/diagnostic/redeclaration-1.C: New.
>   * g++.dg/lookup/extern-c-hidden.C: Test location(s) too.
>   * g++.dg/lookup/extern-c-redecl.C: Likewise.
>   * g++.dg/lookup/extern-c-redecl6.C: Likewise.
>   * g++.old-deja/g++.other/using9.C: Likewise.

LGTM.

Marek

[Darwin, PPC, Mode Iterators 1/n, committed] Use mode iterators in picbase patterns.

[Iain Sandoe]

This switches the picbase load and reload patterns to use the 'P' mode
iterator instead of writing an SI and DI pattern for each (and deletes the
old patterns).  No functional change intended.

Tested on powerpc-darwin9, powerpc64-linux-gnu,
applied to mainline
thanks
Iain

gcc/ChangeLog:

2019-09-24  Iain Sandoe  

* config/rs6000/rs6000.md (load_macho_picbase_): New, using
the 'P' mode iterator, replacing the (removed) SI and DI variants.
(reload_macho_picbase_): Likewise.

diff --git a/gcc/config/rs6000/darwin.md b/gcc/config/rs6000/darwin.md
index 471058dd41..4a284211af 100644
--- a/gcc/config/rs6000/darwin.md
+++ b/gcc/config/rs6000/darwin.md
@@ -217,7 +217,7 @@ You should have received a copy of the GNU General Public 
License
   "")
 
 (define_expand "load_macho_picbase"
-  [(set (reg:SI LR_REGNO)
+  [(set (reg LR_REGNO)
 (unspec [(match_operand 0 "")]
UNSPEC_LD_MPIC))]
   "(DEFAULT_ABI == ABI_DARWIN) && flag_pic"
@@ -230,9 +230,9 @@ You should have received a copy of the GNU General Public 
License
   DONE;
 })
 
-(define_insn "load_macho_picbase_si"
-  [(set (reg:SI LR_REGNO)
-   (unspec:SI [(match_operand:SI 0 "immediate_operand" "s")
+(define_insn "load_macho_picbase_"
+  [(set (reg:P LR_REGNO)
+   (unspec:P [(match_operand:P 0 "immediate_operand" "s")
(pc)] UNSPEC_LD_MPIC))]
   "(DEFAULT_ABI == ABI_DARWIN) && flag_pic"
 {
@@ -246,22 +246,6 @@ You should have received a copy of the GNU General Public 
License
   [(set_attr "type" "branch")
(set_attr "cannot_copy" "yes")])
 
-(define_insn "load_macho_picbase_di"
-  [(set (reg:DI LR_REGNO)
-   (unspec:DI [(match_operand:DI 0 "immediate_operand" "s")
-   (pc)] UNSPEC_LD_MPIC))]
-  "(DEFAULT_ABI == ABI_DARWIN) && flag_pic && TARGET_64BIT"
-{
-#if TARGET_MACHO
-  machopic_should_output_picbase_label (); /* Update for new func.  */
-#else
-  gcc_unreachable ();
-#endif
-  return "bcl 20,31,%0\n%0:";
-}
-  [(set_attr "type" "branch")
-   (set_attr "cannot_copy" "yes")])
-
 (define_expand "macho_correct_pic"
   [(set (match_operand 0 "")
(plus (match_operand 1 "")
@@ -301,7 +285,7 @@ You should have received a copy of the GNU General Public 
License
   [(set_attr "length" "8")])
 
 (define_expand "reload_macho_picbase"
-  [(set (reg:SI LR_REGNO)
+  [(set (reg LR_REGNO)
 (unspec [(match_operand 0 "")]
UNSPEC_RELD_MPIC))]
   "(DEFAULT_ABI == ABI_DARWIN) && flag_pic"
@@ -314,9 +298,9 @@ You should have received a copy of the GNU General Public 
License
   DONE;
 })
 
-(define_insn "reload_macho_picbase_si"
-  [(set (reg:SI LR_REGNO)
-(unspec:SI [(match_operand:SI 0 "immediate_operand" "s")
+(define_insn "reload_macho_picbase_"
+  [(set (reg:P LR_REGNO)
+(unspec:P [(match_operand:P 0 "immediate_operand" "s")
(pc)] UNSPEC_RELD_MPIC))]
   "(DEFAULT_ABI == ABI_DARWIN) && flag_pic"
 {
@@ -337,29 +321,6 @@ You should have received a copy of the GNU General Public 
License
   [(set_attr "type" "branch")
(set_attr "cannot_copy" "yes")])
 
-(define_insn "reload_macho_picbase_di"
-  [(set (reg:DI LR_REGNO)
-   (unspec:DI [(match_operand:DI 0 "immediate_operand" "s")
-   (pc)] UNSPEC_RELD_MPIC))]
-  "(DEFAULT_ABI == ABI_DARWIN) && flag_pic && TARGET_64BIT"
-{
-#if TARGET_MACHO
-  if (machopic_should_output_picbase_label ())
-{
-  static char tmp[64];
-  const char *cnam = machopic_get_function_picbase ();
-  snprintf (tmp, 64, "bcl 20,31,%s\n%s:\n%%0:", cnam, cnam);
-  return tmp;
-}
-  else
-#else
-  gcc_unreachable ();
-#endif
-return "bcl 20,31,%0\n%0:";
-}
-  [(set_attr "type" "branch")
-   (set_attr "cannot_copy" "yes")])
-
 ;; We need to restore the PIC register, at the site of nonlocal label.
 
 (define_insn_and_split "nonlocal_goto_receiver"

[Bug other/91879] DESTDIR support seems incomplete

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Stas Sergeev from comment #4)
> (In reply to Harald van Dijk from comment #1)
> > The ways to handle libc being installed in non-standard locations depend on
> > your specific use case. GCC provides the --with-sysroot and
> > --with-native-system-header-dir configure options,
> 
> These ones specify the locations permanently.
> My problem is that I need a different sysroot/system-header-dir
> only for the time of building the gcc libs.

Have you looked into --with-build-sysroot ?
--with-build-sysroot
--with-build-sysroot=dir
Tells GCC to consider dir as the system root (see --with-sysroot) while
building target libraries, instead of the directory specified with
--with-sysroot. This option is only useful when you are already using
--with-sysroot. You can use --with-build-sysroot when you are configuring with
--prefix set to a directory that is different from the one in which you are
installing GCC and your target libraries.

This option affects the system root for the compiler used to build target
libraries (which runs on the build system); it does not affect the compiler
which is used to build GCC itself.

If you specify the --with-native-system-header-dir=dirname option then the
compiler will search that directory within dirname for native system headers
rather than the default /usr/include.

[Darwin, PPC, Mode Iterators 0/n, committed] Make iterators visible to darwin.md.

[Iain Sandoe]

As a clean-up, we want to be able to use mode iterators in darwin.md.
This patch moves the include point for the Darwin md file until after
the definition of the mode iterators and attrs.  No functional change
intended.

Discussed with, and approved by, Segher off-line,
Tested on powerpc-darwin9, powerpc64-linux-gnu, applied to mainline,
thanks
Iain

gcc/ChangeLog:

2019-09-24  Iain Sandoe  

* config/rs6000/rs6000.md: Move darwin.md include until
after the definition of the mode iterators.

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index f0b0bb4526..4dbf85bbc9 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -361,8 +361,6 @@
 (include "predicates.md")
 (include "constraints.md")
 
-(include "darwin.md")
-
 ^L
 ;; Mode iterators
 
@@ -731,6 +729,7 @@
 (SF "TARGET_P8_VECTOR")
 (DI "TARGET_POWERPC64")])
 
+(include "darwin.md")
 ^L
 ;; Start with fixed-point load and store insns.  Here we put only the more
 ;; complex forms.  Basic data transfer is done later.

[Bug debug/91887] [7/8/9/10 Regression] -fdebug-types-section ICE building chromium

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
   Target Milestone|--- |7.5
Summary|-fdebug-types-section ICE   |[7/8/9/10 Regression]
   |building chromium   |-fdebug-types-section ICE
   ||building chromium

--- Comment #2 from Marek Polacek  ---
GCC 6 is fine, GCC 7 ICEs so it's a regression.

Started with r240578.

[Bug tree-optimization/91570] [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
Fixed in r276105.

[C++ Patch] Use DECL_SOURCE_LOCATION more in name-lookup.c

[Paolo Carlini]

Hi,

Marek's recent fix prompted an audit of name-lookup.c and I found a few 
additional straightforward places where we should use a more accurate 
location. Tested x86_64-linux.


Thanks, Paolo.

///

/cp
2019-09-24  Paolo Carlini  

* name-lookup.c (check_extern_c_conflict): Use DECL_SOURCE_LOCATION.
(check_local_shadow): Use it in three additional places.

/testsuite
2019-09-24  Paolo Carlini  

* g++.dg/diagnostic/redeclaration-1.C: New.
* g++.dg/lookup/extern-c-hidden.C: Test location(s) too.
* g++.dg/lookup/extern-c-redecl.C: Likewise.
* g++.dg/lookup/extern-c-redecl6.C: Likewise.
* g++.old-deja/g++.other/using9.C: Likewise.
Index: cp/name-lookup.c
===
--- cp/name-lookup.c(revision 276104)
+++ cp/name-lookup.c(working copy)
@@ -2549,12 +2549,12 @@ check_extern_c_conflict (tree decl)
   if (mismatch)
{
  auto_diagnostic_group d;
- pedwarn (input_location, 0,
+ pedwarn (DECL_SOURCE_LOCATION (decl), 0,
   "conflicting C language linkage declaration %q#D", decl);
  inform (DECL_SOURCE_LOCATION (old),
  "previous declaration %q#D", old);
  if (mismatch < 0)
-   inform (input_location,
+   inform (DECL_SOURCE_LOCATION (decl),
"due to different exception specifications");
}
   else
@@ -2674,7 +2674,8 @@ check_local_shadow (tree decl)
  /* ARM $8.3 */
  if (b->kind == sk_function_parms)
{
- error ("declaration of %q#D shadows a parameter", decl);
+ error_at (DECL_SOURCE_LOCATION (decl),
+   "declaration of %q#D shadows a parameter", decl);
  return;
}
}
@@ -2700,7 +2701,8 @@ check_local_shadow (tree decl)
   && (old_scope->kind == sk_cond || old_scope->kind == sk_for))
{
  auto_diagnostic_group d;
- error ("redeclaration of %q#D", decl);
+ error_at (DECL_SOURCE_LOCATION (decl),
+   "redeclaration of %q#D", decl);
  inform (DECL_SOURCE_LOCATION (old),
  "%q#D previously declared here", old);
  return;
@@ -2723,7 +2725,8 @@ check_local_shadow (tree decl)
   && in_function_try_handler))
{
  auto_diagnostic_group d;
- if (permerror (input_location, "redeclaration of %q#D", decl))
+ if (permerror (DECL_SOURCE_LOCATION (decl),
+"redeclaration of %q#D", decl))
inform (DECL_SOURCE_LOCATION (old),
"%q#D previously declared here", old);
  return;
Index: testsuite/g++.dg/diagnostic/redeclaration-1.C
===
--- testsuite/g++.dg/diagnostic/redeclaration-1.C   (nonexistent)
+++ testsuite/g++.dg/diagnostic/redeclaration-1.C   (working copy)
@@ -0,0 +1,20 @@
+void
+foo (int i)
+{
+  int i  // { dg-error "7:declaration of .int i. shadows a parameter" }
+(0);
+  
+  for (int j ;;)
+int j  // { dg-error "9:redeclaration of .int j." }
+  (0);
+}
+
+void
+bar (int i)
+  try
+{ }
+  catch (...)
+{
+  int i  // { dg-error "11:redeclaration of .int i." }
+   (0);
+}
Index: testsuite/g++.dg/lookup/extern-c-hidden.C
===
--- testsuite/g++.dg/lookup/extern-c-hidden.C   (revision 276104)
+++ testsuite/g++.dg/lookup/extern-c-hidden.C   (working copy)
@@ -4,8 +4,8 @@ extern "C" float fabsf (float);  // { dg-message "
 
 namespace Bob 
 {
-  extern "C" float fabsf (float, float); // { dg-error "C language" }
+  extern "C" float fabsf (float, float); // { dg-error "20:conflicting C 
language" }
   extern "C" double fabs (double, double); // { dg-message "previous 
declaration" }
 }
 
-extern "C" double fabs (double); // { dg-error "C language" }
+extern "C" double fabs (double); // { dg-error "19:conflicting C language" }
Index: testsuite/g++.dg/lookup/extern-c-redecl.C
===
--- testsuite/g++.dg/lookup/extern-c-redecl.C   (revision 276104)
+++ testsuite/g++.dg/lookup/extern-c-redecl.C   (working copy)
@@ -8,4 +8,4 @@ namespace A {
 // next line should trigger an error because
 // it conflicts with previous declaration of foo_func (), due to
 // different exception specifications.
-extern "C" void foo_func (); // { dg-error "C language linkage|exception 
specifications" }
+extern "C" void foo_func (); // { dg-error "17:conflicting C language 
linkage|exception specifications" }
Index: testsuite/g++.dg/lookup/extern-c-redecl6.C
===
--- testsuite/g++.dg/lookup/extern-c-redecl6.C  (revision 276104)
+++ testsuite/g++.dg/lookup/extern-c-redecl6.C  (working copy)
@@ -16,10 +16,10 

[committed] handle null and non-constant values in get_range_strlen_dynamic (PR 91570)

[Martin Sebor]

I committed r276105 fixing these two issues plus one more that
Jeff noticed yesterday.

Martin

On 9/21/19 6:03 PM, Martin Sebor wrote:

The new get_range_strlen_dynamic function has a couple of bugs
where it assumes that the length range bounds it gets back from
get_range_strlen are non-null integer constants.  The attached
"quick and dirty" fix removes those assumptions.  Since it's
apparently causing package failures in Jeff's GCC buildbot
I will commit the patch on Monday to get those builds to pass.
But I'm not too happy with how fragile this seems to be so I
will try to do some further cleanup here in the near future
to make it more robust.

Martin

[Bug tree-optimization/91570] [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue Sep 24 19:04:54 2019
New Revision: 276105

URL: https://gcc.gnu.org/viewcvs?rev=276105=gcc=rev
Log:
PR tree-optimization/91570 - ICE in get_range_strlen_dynamic on a conditional
of two strings

gcc/Changelog:
* tree-ssa-strlen.c (get_range_strlen_dynamic): Handle null and
non-constant minlen, maxlen and maxbound.

gcc/testsuite/Changelog:
* gcc.dg/pr91570.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr91570.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug debug/91887] -fdebug-types-section ICE building chromium

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-bisection,
   ||needs-reduction
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
ICE reproduced.

[Bug debug/91887] New: -fdebug-types-section ICE building chromium

[jason at gcc dot gnu.org]

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

Bug ID: 91887
   Summary: -fdebug-types-section ICE building chromium
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46938=edit
unincluded testcase

Compiling this file with -g -fdebug-types-section hits an ICE under
lookup_external_ref, because we're trying to look up a DW_TAG_typedef that has
no symbol.  We shouldn't be trying to form an external reference to a typedef
in the first place; brief attempts to come up with a small testcase have not
reproduced the problem.

Re: [PATCH] driver: Also prune joined switches with negation

[Matt Turner]

On Tue, Sep 24, 2019 at 1:24 AM Kyrill Tkachov
 wrote:
>
> Hi Matt,
>
> On 9/24/19 5:04 AM, Matt Turner wrote:
> > When -march=native is passed to host_detect_local_cpu to the backend,
> > it overrides all command lines after it.  That means
> >
> > $ gcc -march=native -march=armv8-a
> >
> > is treated as
> >
> > $ gcc -march=armv8-a -march=native
> >
> > Prune joined switches with Negative and RejectNegative to allow
> > -march=armv8-a to override previous -march=native on command-line.
> >
> > This is the same fix as was applied for i386 in SVN revision 269164
> > but for
> > aarch64 and arm.
> >
> The fix is ok for arm and LGTM for aarch64 FWIW.

Thanks!

> How has this been tested?

The problem was noticed in this bug report:

   https://bugs.gentoo.org/693522

I remembered seeing the i386 fix and I separately encountered the
problem on ARM when building the pixman library which has iwMMXt code
which requires march=iwmmxt (Could I bribe someone into fixing that by
giving gcc an -miwmmxt flag?)

I verified the fix works by patching gcc and seeing that nss (the
package from the Gentoo bug report) successfully builds with
CFLAGS="-march=native -O2 -pipe"

SVN revision 269164 also added some tests to the gcc test suite, but I
am not sufficiently familiar with building gcc and running the test
suite to verify that any test I speculatively add actually works.

> However...
>
>
> > gcc/
> >
> > PR driver/69471
> > * config/aarch64/aarch64.opt (march=): Add Negative(march=).
> > (mtune=): Add Negative(mtune=).
> > * config/arm/arm.opt: Likewise.
> > ---
> >  gcc/config/aarch64/aarch64.opt | 5 +++--
> >  gcc/config/arm/arm.opt | 4 ++--
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/gcc/config/aarch64/aarch64.opt
> > b/gcc/config/aarch64/aarch64.opt
> > index 865b6a6d8ca..908dca23b3c 100644
> > --- a/gcc/config/aarch64/aarch64.opt
> > +++ b/gcc/config/aarch64/aarch64.opt
> > @@ -119,7 +119,8 @@ EnumValue
> >  Enum(aarch64_tls_size) String(48) Value(48)
> >
> >  march=
> > -Target RejectNegative ToLower Joined Var(aarch64_arch_string)
> > +Target RejectNegative Negative(march=) ToLower Joined
> > Var(aarch64_arch_string)
> > +
> >  Use features of architecture ARCH.
> >
> >  mcpu=
>
>
> ... Looks like we'll need something similar for -mcpu. On arm and
> aarch64 the -mcpu is the most commonly used option and that can also
> take a "native" value that would suffer from the same issue I presume.

Thank you. I've sent a second version with this addressed in reply to
my initial patch.

If the patch is okay, I think we'd appreciate it if it were backported
to the gcc-8 branch as well.

[Bug c++/78752] [concepts] ICE with constrained variadic member function

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
Created attachment 46937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46937=edit
Patch against concepts-cxx2a (git format-patch format)

Adds a test for PR78752, which had been semi-fixed. The attached patch rebuilds
constraints involving abbreviated functions with function argument packs and
updates the corresponding template parameter list. We weren't doing that
before, so we were checking constraints with the wrong arguments.

[PATCH] driver: Also prune joined switches with negation

[Matt Turner]

When -march=native is passed to host_detect_local_cpu to the backend,
it overrides all command lines after it.  That means

$ gcc -march=native -march=armv8-a

is treated as

$ gcc -march=armv8-a -march=native

Prune joined switches with Negative and RejectNegative to allow
-march=armv8-a to override previous -march=native on command-line.

This is the same fix as was applied for i386 in SVN revision 269164 but for
aarch64 and arm.

gcc/

PR driver/69471
* config/aarch64/aarch64.opt (march=): Add Negative(march=).
(mtune=): Add Negative(mtune=). (mcpu=): Add Negative(mcpu=).
* config/arm/arm.opt: Likewise.
---
 gcc/config/aarch64/aarch64.opt | 6 +++---
 gcc/config/arm/arm.opt | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt
index 865b6a6d8ca..fc43428b32a 100644
--- a/gcc/config/aarch64/aarch64.opt
+++ b/gcc/config/aarch64/aarch64.opt
@@ -119,15 +119,15 @@ EnumValue
 Enum(aarch64_tls_size) String(48) Value(48)
 
 march=
-Target RejectNegative ToLower Joined Var(aarch64_arch_string)
+Target RejectNegative Negative(march=) ToLower Joined Var(aarch64_arch_string)
 Use features of architecture ARCH.
 
 mcpu=
-Target RejectNegative ToLower Joined Var(aarch64_cpu_string)
+Target RejectNegative Negative(mcpu=) ToLower Joined Var(aarch64_cpu_string)
 Use features of and optimize for CPU.
 
 mtune=
-Target RejectNegative ToLower Joined Var(aarch64_tune_string)
+Target RejectNegative Negative(mtune=) ToLower Joined Var(aarch64_tune_string)
 Optimize for CPU.
 
 mabi=
diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt
index 452f0cf6d67..76c10ab62a2 100644
--- a/gcc/config/arm/arm.opt
+++ b/gcc/config/arm/arm.opt
@@ -82,7 +82,7 @@ mapcs-stack-check
 Target Report Mask(APCS_STACK) Undocumented
 
 march=
-Target RejectNegative ToLower Joined Var(arm_arch_string)
+Target RejectNegative Negative(march=) ToLower Joined Var(arm_arch_string)
 Specify the name of the target architecture.
 
 ; Other arm_arch values are loaded from arm-tables.opt
@@ -107,7 +107,7 @@ Target Report Mask(CALLER_INTERWORKING)
 Thumb: Assume function pointers may go to non-Thumb aware code.
 
 mcpu=
-Target RejectNegative ToLower Joined Var(arm_cpu_string)
+Target RejectNegative Negative(mcpu=) ToLower Joined Var(arm_cpu_string)
 Specify the name of the target CPU.
 
 mfloat-abi=
@@ -232,7 +232,7 @@ Target Report Mask(TPCS_LEAF_FRAME)
 Thumb: Generate (leaf) stack frames even if not needed.
 
 mtune=
-Target RejectNegative ToLower Joined Var(arm_tune_string)
+Target RejectNegative Negative(mtune=) ToLower Joined Var(arm_tune_string)
 Tune code for the given processor.
 
 mprint-tune-info
-- 
2.21.0

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Perhaps we should just remove the assert:

--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1085,7 +1085,6 @@ constexpr_call_hasher::equal (constexpr_call *lhs,
constexpr_call *rhs)
 {
   tree lhs_arg = TREE_VALUE (lhs_bindings);
   tree rhs_arg = TREE_VALUE (rhs_bindings);
-  gcc_assert (same_type_p (TREE_TYPE (lhs_arg), TREE_TYPE (rhs_arg)));
   if (!cp_tree_equal (lhs_arg, rhs_arg))
 return false;
   lhs_bindings = TREE_CHAIN (lhs_bindings);

Re: [libcpp] Issue a pedantic warning for UCNs outside UCS codespace

[Florian Weimer]

* Eric Botcazou:

> the Universal Character Names accepted by the C family of compilers
> are mapped to those of ISO/IEC 10646, which defines the Universal
> Character Set codespace as the range 0-0x10 inclusive.  The
> upper bound is already enforced for identifiers but not for
> literals, so the following code is accepted in C99:
>
> #include 
>
> wchar_t a = L'\U0011';
>
> whereas it is rejected with an error by other compilers (Clang, MSVC).
>
> I'm not sure whether the compiler is really equired to issue a diagnostic in 
> this case.  Moreover a few tests in the testsuite manipulate UCNs outside the 
> UCS codespace.  That's why I suggest issuing a pedantic warning.
>
> Tested on x86_64-suse-linux, OK for the mainline?

Since this is a pedantic warning …

I think this has to depend on the C standards version.  I think each C
standard needs to be read against the edition of ISO 10646 current at
the time of standards approval (the references are sadly not
versioned, so the version is implied).  Early versions of ISO 10646
definitely do not have the codespace restriction you mention.

Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for review

[Bernhard Reutner-Fischer]

On Tue, 24 Sep 2019 15:11:43 +0100
Mark Eggleston  wrote:

> I didn't realise that's how it worked. That's cleaner. Once fixed OK for 
> commit?

> +@item -Wno-overwrite-recursive
> +@opindex @code{Woverwrite-recursive}
> +@cindex  warnings, overwrite recursive
> +Do not warn when @option{-fno-automatic} is used with @option{-frecursive}. 
> Recursion
> +will be broken if the relevant local variables do not have the attribute
> +@code{AUTOMATIC} explicitly declared. This option can be used to suppress 
> the warning
> +when it is known that recursion is not broken. Useful for build environment 
> that use
> +@option{-Werror}.

I'm not a native speaker, but i would expect environment in plural.
With that nit fixed i have no further comments, i.e. looks fine but i
cannot approve it.

thanks,

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
r266816 is already present gcc-9-branch but it didn't fix the ICE.  I'm afraid
it's r272125, but alas that doesn't seem to be backportable.

[Bug other/91879] DESTDIR support seems incomplete

[stsp at users dot sourceforge.net]

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

--- Comment #6 from Stas Sergeev  ---
(In reply to Jonathan Wakely from comment #5)
> Which makes sense, since the system headers are not part of GCC itself, so
> why would it expect them in the temporary staging area for GCC's own files?

OK, I understand.
But then its a bit unclear to me how to build
the cross-compiler. I build both gcc and its libs
on the host, so somehow I need to provide it with
the location of the headers _on host_, which is
different with what will it be later on the target.

> You didn't show how. What exact commands did you run?
If only that would be so easy to tell with the script I have. :)

> I'm not interested in the libtool command that GCC runs, I want to know what
> your script does. Not what it runs basically, but precisely. The configure
> command, and the make commands.
OK, still "basically", but hopefully more informative than before:
---
export DESTDIR=/path/to/somedir
cd builddir

../gnu/gcc-9.2.0/configure --disable-plugin --enable-lto --disable-libssp --
disable-nls --enable-libquadmath-support --enable-version-specific-runtime-libs
--enable-fat --enable-libstdcxx-filesystem-ts --target=i586-pc-msdosdjgpp
--pref
ix=/usr/local/cross --enable-languages=c,c++

make all-gcc
make install-gcc
make [ fails here ]
make install-strip
---

Some things are still stripped, as the script also
sets pathes after make install-gcc and does some other
things. If this is still not enough, I'll work on a
minimal reproducer.

> So if you need it defined before that step, you're doing something wrong. We
> can't tell what you're doing wrong, because you haven't said what you're
> doing.

I am trying to get this build script to work:
https://github.com/stsp/build-gcc/tree/master
to build djgpp tool-chain w/o root privs.
The current strategy of that script is to install
built gcc on host (needs root), then build gcc libs
from there. I want to confine it to the DESTDIR,
including the headers installation, so the way I
run that script (I don't expect you are going to try
it yourself of course):
---
QUIET=1 DESTDIR=`pwd`/ttt ./build-djgpp.sh gcc-9.2.0
---

Re: Question on direction of GCC support for HWASAN.

[Evgenii Stepanov via gcc-patches]

On Tue, Sep 24, 2019 at 9:36 AM Szabolcs Nagy  wrote:
>
> On 23/09/2019 08:52, Martin Liška wrote:
> > On 9/20/19 7:11 PM, Matthew Malcomson wrote:
> >> The implementation is unlikely to be production-quality since
> >> development on libhwasan is only on its `platform` ABI.  This libhwasan
> >> ABI requires changes to the system libc so that it calls into libhwasan
> >> on interesting events.
> >> I haven't looked into adding these changes to glibc, but expect that
> >> most people running a Linux distribution would not want to install a
> >> special glibc to use this sanitizer.
> >
> > Can you please provide a link about what special one needs in glibc
> > to support HWASAN?
>
> i don't know if there is such a link other than taking
> a hint from the internal api in the source
> https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/hwasan/hwasan_interface_internal.h
>
> memory has to be (un)tagged on (de)allocation, which
> requires libc help to know the limits and when the
> (de)allocation happens in case of tls/stack memory
> (e.g. dealloced at unwind, longjmp, setcontext, thread
> exit, thread cancel, child exit after vfork) and in
> case of global data in dynamically loaded shared libs.

This is a slightly better link, but it misses
__hwasan_library_(load|unload) hooks:
https://github.com/llvm/llvm-project/blob/master/compiler-rt/include/sanitizer/hwasan_interface.h

You can also search bionic source for __hwasan and __sanitizer:
https://android.googlesource.com/platform/bionic/+/refs/heads/master

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

--- Comment #9 from Marek Polacek  ---
Confirming that latest GCC 9 still ICEs.

[Bug other/91879] DESTDIR support seems incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
(In reply to Stas Sergeev from comment #3)
> And yet what I see is that when gcc is building its libs,
> it looks for the system headers under prefix, not under destdir.

Which makes sense, since the system headers are not part of GCC itself, so why
would it expect them in the temporary staging area for GCC's own files?


> (In reply to Jonathan Wakely from comment #2)
> > (In reply to Stas Sergeev from comment #0)
> > > Hello.
> > > 
> > > I tried to build gcc with non-empty DESTDIR.
> > 
> > What exact commands did you run?
> 
> I have the script that runs basically "make all-gcc" and
> "make" after setting some env vars. And what fails is the
> plain "make" step. I can show you how exactly:

You didn't show how. What exact commands did you run?

I'm not interested in the libtool command that GCC runs, I want to know what
your script does. Not what it runs basically, but precisely. The configure
command, and the make commands.

> Please note the
> -isystem /usr/local/cross/i586-pc-msdosdjgpp/include -isystem
> /usr/local/cross/i586-pc-msdosdjgpp/sys-include
> 
> above. Clearly it misses the DESTDIR, and feeding the
> DESTDIR there makes the problem to go away.

The GNU coding standards specifically say "DESTDIR should be supported only in
the install* and uninstall* targets, as those are the only targets where it is
useful." -- https://www.gnu.org/prep/standards/html_node/DESTDIR.html

So if you need it defined before that step, you're doing something wrong. We
can't tell what you're doing wrong, because you haven't said what you're doing.

Re: [PATCH 3/4] New IPA-SRA implementation

[Martin Jambor]

Hi,

sorry for replying so late, I still haven't recovered from two weeks of
traveling and conferences.

On Sat, Sep 21 2019, Richard Sandiford wrote:
> Hi,
>
> Thanks for doing this.
>
> Martin Jambor  writes:
>> +/* Analyze function body scan results stored in param_accesses and
>> +   param_accesses, detect possible transformations and store information of
>> +   those in function summary.  NODE, FUN and IFS are all various structures
>> +   describing the currently analyzed function.  */
>> +
>> +static void
>> +process_scan_results (cgraph_node *node, struct function *fun,
>> +  isra_func_summary *ifs,
>> +  vec *param_descriptions)
>> +{
>> +  bool check_pass_throughs = false;
>> +  bool dereferences_propagated = false;
>> +  tree parm = DECL_ARGUMENTS (node->decl);
>> +  unsigned param_count = param_descriptions->length();
>> +
>> +  for (unsigned desc_index = 0;
>> +   desc_index < param_count;
>> +   desc_index++, parm = DECL_CHAIN (parm))
>> +{
>> +  gensum_param_desc *desc = &(*param_descriptions)[desc_index];
>> +  if (!desc->locally_unused && !desc->split_candidate)
>> +continue;
>
> I'm jumping in the middle without working through the whole pass,
> so this is probably a daft question sorry, but: what is this loop
> required to do when:
>
>   !desc->split_candidate && desc->locally_unused

You have figured out correctly that this is a thinko.  I meant not to
continue for non-register-types which might not be used locally but
their locally_unused flag is only set a few lines below...

>
> ?  AFAICT...
>
>> +
>> +  if (flag_checking)
>> +isra_verify_access_tree (desc->accesses);
>> +
>> +  if (!dereferences_propagated
>> +  && desc->by_ref
>> +  && desc->accesses)
>> +{
>> +  propagate_dereference_distances (fun);
>> +  dereferences_propagated = true;
>> +}
>> +
>> +  HOST_WIDE_INT nonarg_acc_size = 0;
>> +  bool only_calls = true;
>> +  bool check_failed = false;
>> +
>> +  int entry_bb_index = ENTRY_BLOCK_PTR_FOR_FN (fun)->index;
>> +  for (gensum_param_access *acc = desc->accesses;
>> +   acc;
>> +   acc = acc->next_sibling)
>> +if (check_gensum_access (parm, desc, acc, _acc_size, _calls,
>> + entry_bb_index))
>> +  {
>> +check_failed = true;
>> +break;
>> +  }
>> +  if (check_failed)
>> +continue;
>> +
>> +  if (only_calls)
>> +desc->locally_unused = true;

...specifically here.

>> +
>> +  HOST_WIDE_INT cur_param_size
>> += tree_to_uhwi (TYPE_SIZE (TREE_TYPE (parm)));
>> +  HOST_WIDE_INT param_size_limit;
>> +  if (!desc->by_ref || optimize_function_for_size_p (fun))
>> +param_size_limit = cur_param_size;
>> +  else
>> +param_size_limit = (PARAM_VALUE (PARAM_IPA_SRA_PTR_GROWTH_FACTOR)
>> +   * cur_param_size);
>> +  if (nonarg_acc_size > param_size_limit
>> +  || (!desc->by_ref && nonarg_acc_size == param_size_limit))
>> +{
>> +  disqualify_split_candidate (desc, "Would result into a too big set of"
>> +  "replacements.");
>> +}
>> +  else
>> +{
>> +  /* create_parameter_descriptors makes sure unit sizes of all
>> + candidate parameters fit unsigned integers restricted to
>> + ISRA_ARG_SIZE_LIMIT.  */
>> +  desc->param_size_limit = param_size_limit / BITS_PER_UNIT;
>> +  desc->nonarg_acc_size = nonarg_acc_size / BITS_PER_UNIT;
>> +  if (desc->split_candidate && desc->ptr_pt_count)
>> +{
>> +  gcc_assert (desc->by_ref);
>> +  check_pass_throughs = true;
>> +}
>> +}
>> +}
>
> ...disqualify_split_candidate should be a no-op in that case,
> because we've already disqualified the parameter for a different reason.
> So it looks like the main effect is instead to set up param_size_limit
> and nonarg_acc_size, the latter of which I assume is 0 when
> desc->locally_unused.

This is the only bit where you are wrong, param_size_limit is the type
size for aggregates and twice pointer size for pointers (well, actually
PARAM_IPA_SRA_PTR_GROWTH_FACTOR times the size of a pointer).  Even for
locally unused parameters because we might "pull" some of them from
callees, when there are some.  But it is not really relevant for the
problem you are facing.

>
> The reason for asking is that the final "else" says that we've already
> checked that param_size_limit is in range, but that's only true if
> desc->split_candidate.  In particular:
>
>   if (is_gimple_reg (parm)
> && !isra_track_scalar_param_local_uses (fun, node, parm, num,
> _call_uses))
>   {
> if (dump_file && (dump_flags & TDF_DETAILS))
>   fprintf (dump_file, " is a scalar with only %i call uses\n",
>scalar_call_uses);
>
> desc->locally_unused = true;
> desc->call_uses 

[Bug rtl-optimization/91865] Combine misses opportunity to remove (sign_extend (zero_extend)) before searching for insn patterns

[jozefl.gcc at gmail dot com]

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

--- Comment #3 from Jozef Lawrynowicz  ---
Created attachment 46936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46936=edit
msp430-extendhipsi2.diff

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[h2+bugs at fsfe dot org]

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

--- Comment #8 from Hannes Hauswedell  ---
Anything I can do to help resolve this? We have library code that breaks
because of the issue and since 9.2 is deployed everywhere that 9.1 was used,
this is very disruptive...

Thank you!

[Bug rtl-optimization/91865] Combine misses opportunity to remove (sign_extend (zero_extend)) before searching for insn patterns

[jozefl.gcc at gmail dot com]

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

--- Comment #2 from Jozef Lawrynowicz  ---
A related issue can be observed if "char i" is made global instead of an
argument to func.

const int table[2] = {1, 2};

int foo;
char i;

void func(void)
{
  foo = table[i];
}

Combine combines the zero_extend and sign_extend insns into a single
(sign_extend(subreg)) insn:

Trying 6 -> 7:
6: r27:HI=zero_extend([`i'])
7: r28:PSI=sign_extend(r27:HI)#0
  REG_DEAD r27:HI
Failed to match this instruction:
(set (reg:PSI 28 [ i ])
(sign_extend:PSI (subreg:HI (mem/c:QI (symbol_ref:PSI ("i")

As far as I'm aware, this is a "discouraged" use of subreg, but also means we
miss out on the best match.

Note that the subreg in the combined instruction is unrelated to the subreg
that is the rvalue of insn 7. The subreg in insn 7 is from the RTL pattern for
extendhipsi2.
To avoid any confusion I've attached a one line patch
(msp430-extendhispsi2.diff) which removes the the subreg from this RTL insn
pattern, yet the the subreg in the insn combine searches for remains. Here is
the output from combine with the patch (note the the lack of subreg in insn 7):

Trying 6 -> 7:  
6: r27:HI=zero_extend([`i'])
7: r28:PSI=sign_extend(r27:HI)  
  REG_DEAD r27:HI   
Successfully matched this instruction:  
(set (reg:PSI 28 [ i ]) 
(sign_extend:PSI (subreg:HI (mem/c:QI (symbol_ref:PSI ("i")
allowing combination of insns 6 and 7   
original costs 16 + 8 = 24  
replacement cost 20 
deferring deletion of insn with uid = 6.
modifying insn i3 7: r28:PSI=sign_extend([`i']#0)   
deferring rescan insn with uid = 7.

Even though we matched, it is undesirable since we matched the costly
"extendhipsi2".
We want to match movqipsi2, which would happen if:
(sign_extend:PSI (zero_extend:HI (mem:QI))) -> (zero_extend:PSI (mem:QI))

P.S. I believe the subreg in some of the msp430 RTL patterns is because of
historical issues with reload and/or optimization tweaks. The attached patch is
just to clarify the behaviour I mentioned and not necessarily beneficial
overall.

[libcpp] Issue a pedantic warning for UCNs outside UCS codespace

[Eric Botcazou]

Hi,

the Universal Character Names accepted by the C family of compilers are mapped 
to those of ISO/IEC 10646, which defines the Universal Character Set codespace 
as the range 0-0x10 inclusive.  The upper bound is already enforced for 
identifiers but not for literals, so the following code is accepted in C99:

#include 

wchar_t a = L'\U0011';

whereas it is rejected with an error by other compilers (Clang, MSVC).

I'm not sure whether the compiler is really equired to issue a diagnostic in 
this case.  Moreover a few tests in the testsuite manipulate UCNs outside the 
UCS codespace.  That's why I suggest issuing a pedantic warning.

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


2019-09-24  Eric Botcazou  

libcpp/
* charset.c (UCS_LIMIT): New macro.
(ucn_valid_in_identifier): Use it instead of a hardcoded constant.
(_cpp_valid_ucn): Issue a pedantic warning for UCNs larger than
UCS_LIMIT outside of identifiers.


2019-09-24  Eric Botcazou  

gcc/testsuite/
* gcc.dg/cpp/ucs.c: Add test for new warning and adjust.
* gcc.dg/cpp/utf8-5byte-1.c: Add -w to the options.
* gcc.dg/attr-alias-5.c: Likewise.

-- 
Eric BotcazouIndex: libcpp/charset.c
===
--- libcpp/charset.c	(revision 275988)
+++ libcpp/charset.c	(working copy)
@@ -901,6 +901,9 @@ struct ucnrange {
 };
 #include "ucnid.h"
 
+/* ISO 10646 defines the UCS codespace as the range 0-0x10 inclusive.  */
+#define UCS_LIMIT 0x10
+
 /* Returns 1 if C is valid in an identifier, 2 if C is valid except at
the start of an identifier, and 0 if C is not valid in an
identifier.  We assume C has already gone through the checks of
@@ -915,7 +918,7 @@ ucn_valid_in_identifier (cpp_reader *pfi
   int mn, mx, md;
   unsigned short valid_flags, invalid_start_flags;
 
-  if (c > 0x10)
+  if (c > UCS_LIMIT)
 return 0;
 
   mn = 0;
@@ -1016,6 +1019,9 @@ ucn_valid_in_identifier (cpp_reader *pfi
whose short identifier is less than 00A0 other than 0024 ($), 0040 (@),
or 0060 (`), nor one in the range D800 through DFFF inclusive.
 
+   If the hexadecimal value is larger than the upper bound of the UCS
+   codespace specified in ISO/IEC 10646, a pedantic warning is issued.
+
*PSTR must be preceded by "\u" or "\U"; it is assumed that the
buffer end is delimited by a non-hex digit.  Returns false if the
UCN has not been consumed, true otherwise.
@@ -1135,6 +1141,10 @@ _cpp_valid_ucn (cpp_reader *pfile, const
"universal character %.*s is not valid at the start of an identifier",
 		   (int) (str - base), base);
 }
+  else if (result > UCS_LIMIT)
+cpp_error (pfile, CPP_DL_PEDWARN,
+	   "%.*s is outside the UCS codespace",
+	   (int) (str - base), base);
 
   *cp = result;
   return true;
Index: gcc/testsuite/gcc.dg/attr-alias-5.c
===
--- gcc/testsuite/gcc.dg/attr-alias-5.c	(revision 275988)
+++ gcc/testsuite/gcc.dg/attr-alias-5.c	(working copy)
@@ -1,7 +1,7 @@
 /* Verify diagnostics for aliases to strings containing extended
identifiers or bad characters.  */
 /* { dg-do compile } */
-/* { dg-options "-std=gnu99" } */
+/* { dg-options "-std=gnu99 -w" } */
 /* { dg-require-alias "" } */
 /* { dg-require-ascii-locale "" } */
 /* { dg-skip-if "" { powerpc*-*-aix* } } */
Index: gcc/testsuite/gcc.dg/cpp/ucs.c
===
--- gcc/testsuite/gcc.dg/cpp/ucs.c	(revision 275988)
+++ gcc/testsuite/gcc.dg/cpp/ucs.c	(working copy)
@@ -39,7 +39,7 @@
 #endif
 
 #if WCHAR_MAX >= 0x7ff
-# if L'\U1234abcd' != 0x1234abcd
+# if L'\U1234abcd' != 0x1234abcd /* { dg-warning "outside" "" } */
 #  error bad long ucs	/* { dg-bogus "bad" "bad U1234abcd evaluation" } */
 # endif
 #endif
@@ -49,7 +49,7 @@ void foo ()
   int c;
 
   c = L'\ubad';		/* { dg-error "incomplete" "incomplete UCN 1" } */
-  c = L"\U1234"[0];	/* { dg-error "incomplete" "incompete UCN 2" } */
+  c = L"\U1234"[0];	/* { dg-error "incomplete" "incomplete UCN 2" } */
 
   c = L'\u000x';	/* { dg-error "incomplete" "non-hex digit in UCN" } */
   /* If sizeof(HOST_WIDE_INT) > sizeof(wchar_t), we can get a multi-character
@@ -64,4 +64,6 @@ void foo ()
   c = '\u0025';		/* { dg-error "not a valid" "0025 invalid UCN" } */
   c = L"\uD800"[0];	/* { dg-error "not a valid" "D800 invalid UCN" } */
   c = L'\UDFFF';	/* { dg-error "not a valid" "DFFF invalid UCN" } */
+
+  c = L'\U0011';	/* { dg-warning "outside" "11 outside UCS" } */
 }
Index: gcc/testsuite/gcc.dg/cpp/utf8-5byte-1.c
===
--- gcc/testsuite/gcc.dg/cpp/utf8-5byte-1.c	(revision 275988)
+++ gcc/testsuite/gcc.dg/cpp/utf8-5byte-1.c	(working copy)
@@ -1,7 +1,7 @@
 /* Test for bug in conversions from 5-byte UTF-8 sequences in
cpplib.  */
 /* { dg-do run { target { 4byte_wchar_t } } } */
-/* { 

[Bug target/91886] New: [10 regression] powerpc64 impossible register constraint in asm

[nsz at gcc dot gnu.org]

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

Bug ID: 91886
   Summary: [10 regression] powerpc64 impossible register
constraint in asm
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

this used to work for me:

double fmax(double x, double y)
{
__asm__ ("xsmaxdp %x0, %x1, %x2" : "=ws"(x) : "ws"(x), "ws"(y));
return x;
}

compiled to

fmax:
xsmaxdp 1, 1, 2
    blr

now (gcc version 10.0.0 20190924) i get

fmax.c: In function 'fmax':
fmax.c:3:2: error: impossible constraint in 'asm'
3 |  __asm__ ("xsmaxdp %x0, %x1, %x2" : "=ws"(x) : "ws"(x), "ws"(y));
  |  ^~~

[Bug c++/87441] [concepts] Found compiler internal error: in tsubst at cp/pt.c:13657

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #4 from Jeff Chapman  ---
Created attachment 46935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46935=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug c++/86269] [concepts] ICE with intermediate concepts notation

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #2 from Jeff Chapman  ---
Created attachment 46934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46934=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug c++/86000] ICE with requires statement in a non constexpr if

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #3 from Jeff Chapman  ---
Created attachment 46933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46933=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

Re: [PATCH] Remove unused #include "vec.h" from hash-table.h

[Segher Boessenkool]

On Tue, Sep 24, 2019 at 07:44:10AM +0200, Bernhard Reutner-Fischer wrote:
> On Mon, 23 Sep 2019 14:52:19 -0500
> "Christian Biesinger via gcc-patches"  wrote:
> > From: Christian Biesinger 
> > Removes an unused include as a cleanup. Requires updating
> > lots of files who previously relied on this transitive include.
> 
> Note that we have a tool to help prune unused includes, somewhere.

contrib/header-tools/reduce-headers?  And see gcc-order-headers.


Segher

[Bug c++/85808] [concepts] unqualified name lookup breaks after qualified lookup in nested requirement

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #1 from Jeff Chapman  ---
Created attachment 46932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46932=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

Re: Question on direction of GCC support for HWASAN.

[Szabolcs Nagy]

On 23/09/2019 08:52, Martin Liška wrote:
> On 9/20/19 7:11 PM, Matthew Malcomson wrote:
>> The implementation is unlikely to be production-quality since
>> development on libhwasan is only on its `platform` ABI.  This libhwasan
>> ABI requires changes to the system libc so that it calls into libhwasan
>> on interesting events.
>> I haven't looked into adding these changes to glibc, but expect that
>> most people running a Linux distribution would not want to install a
>> special glibc to use this sanitizer.
> 
> Can you please provide a link about what special one needs in glibc
> to support HWASAN?

i don't know if there is such a link other than taking
a hint from the internal api in the source
https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/hwasan/hwasan_interface_internal.h

memory has to be (un)tagged on (de)allocation, which
requires libc help to know the limits and when the
(de)allocation happens in case of tls/stack memory
(e.g. dealloced at unwind, longjmp, setcontext, thread
exit, thread cancel, child exit after vfork) and in
case of global data in dynamically loaded shared libs.

[Bug c++/85241] Requires-expressions, fold expressions, and member function templates with dependent parameters don't play nicely

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #4 from Jeff Chapman  ---
Created attachment 46931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46931=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This and the related PR appear to be fixed on concepts-cxx2a. Patch adds a test
for this PR.

Re: [AArch64][SVE] Utilize ASRD instruction for division and remainder

[Richard Sandiford]

Yuliang Wang  writes:
> Hi,
>
> The C snippets below  (signed division/modulo by a power-of-2 immediate 
> value):
>
> #define P ...
>
> void foo_div (int *a, int *b, int N)
> {
> for (int i = 0; i < N; i++)
> a[i] = b[i] / (1 << P);
> }
> void foo_mod (int *a, int *b, int N)
> {
> for (int i = 0; i < N; i++)
> a[i] = b[i] % (1 << P);
> }
>
> Vectorize to the following on AArch64 + SVE:
>
> foo_div:
> movx0, 0
> movw2, N
> ptruep1.b, all
> whilelop0.s, wzr, w2
> .p2align3,,7
> .L2:
> ld1wz1.s, p0/z, [x3, x0, lsl 2]
> cmpltp2.s, p1/z, z1.s, #0//
> movz0.s, p2/z, #7//
> addz0.s, z0.s, z1.s//
> asrz0.s, z0.s, #3//
> st1wz0.s, p0, [x1, x0, lsl 2]
> incwx0
> whilelop0.s, w0, w2
> b.any.L2
> ret
>
> foo_mod:
> ...
> .L2:
> ld1wz0.s, p0/z, [x3, x0, lsl 2]
> cmpltp2.s, p1/z, z0.s, #0//
> movz1.s, p2/z, #-1//
> lsrz1.s, z1.s, #29//
> addz0.s, z0.s, z1.s//
> andz0.s, z0.s, #{2^P-1}//
> subz0.s, z0.s, z1.s//
> st1wz0.s, p0, [x1, x0, lsl 2]
> incwx0
> whilelop0.s, w0, w2
> b.any.L2
> ret
>
> This patch utilizes the special-purpose ASRD (arithmetic shift-right for 
> divide by immediate) instruction:
>
> foo_div:
> ...
> .L2:
> ld1wz0.s, p0/z, [x3, x0, lsl 2]
> asrdz0.s, p1/m, z0.s, #{P}//
> st1wz0.s, p0, [x1, x0, lsl 2]
> incwx0
> whilelop0.s, w0, w2
> b.any.L2
> ret
>
> foo_mod:
> ...
> .L2:
> ld1wz0.s, p0/z, [x3, x0, lsl 2]
> movprfxz1, z0//
> asrdz1.s, p1/m, z1.s, #{P}//
> lslz1.s, z1.s, #{P}//
> subz0.s, z0.s, z1.s//
> st1wz0.s, p0, [x1, x0, lsl 2]
> incwx0
> whilelop0.s, w0, w2
> b.any.L2
> ret
>
> Added new tests. Built and regression tested on aarch64-none-elf.
>
> Best Regards,
> Yuliang Wang
>
>
> gcc/ChangeLog:
>
> 2019-09-23  Yuliang Wang  
>
> * config/aarch64/aarch64-sve.md (asrd3): New pattern for ASRD.
> * config/aarch64/iterators.md (UNSPEC_ASRD): New unspec.
> (ASRDIV): New int iterator.
> * internal-fn.def (IFN_ASHR_DIV): New internal function.
> * optabs.def (ashr_div_optab): New optab.
> * tree-vect-patterns.c (vect_recog_divmod_pattern):
> Modify pattern to support new operation.
> * doc/md.texi (asrd$var{m3}): Documentation for the above.
> * doc/sourcebuild.texi (vect_asrdiv_si): Document new target selector.

This looks good to me.  My only real question is about naming:
maybe IFN_DIV_POW2 would be a better name for the internal function
and sdiv_pow2_optab/"div_pow2$a3" for the optab?  But I'm useless at
naming things, so maybe others would prefer your names.

Thanks,
Richard

>
> gcc/testsuite/ChangeLog:
>
> 2019-09-23  Yuliang Wang  
>
> * gcc.dg/vect/vect-asrdiv-1.c: New test.
> * gcc.target/aarch64/sve/asrdiv_1.c: As above.
> * lib/target-support.exp (check_effective_target_vect_asrdiv_si):
> Return true for AArch64 with SVE.
>
> diff --git a/gcc/config/aarch64/aarch64-sve.md 
> b/gcc/config/aarch64/aarch64-sve.md
> index 
> f58353e9c6dc0df97ce4074db6bb22181f426e5b..607440b7ba16d5616695f29a9cf7c4c277a4a502
>  100644
> --- a/gcc/config/aarch64/aarch64-sve.md
> +++ b/gcc/config/aarch64/aarch64-sve.md
> @@ -71,6 +71,7 @@
>  ;;  [INT] Binary logical operations
>  ;;  [INT] Binary logical operations (inverted second input)
>  ;;  [INT] Shifts
> +;;  [INT] Shifts (rounding towards 0)
>  ;;  [FP] General binary arithmetic corresponding to rtx codes
>  ;;  [FP] General binary arithmetic corresponding to unspecs
>  ;;  [FP] Addition
> @@ -2563,6 +2564,46 @@
>[(set_attr "movprfx" "yes")]
>  )
>  
> +;; -
> +;;  [INT] Shifts (rounding towards 0)
> +;; -
> +;; Includes:
> +;; - ASRD
> +;; -
> +
> +;; Unpredicated arithmetic right shift for division by power-of-2.
> +(define_expand "asrd3"
> +  [(set (match_operand:SVE_I 0 "register_operand" "")
> + (unspec:SVE_I
> +   [(match_dup 3)
> +(unspec:SVE_I
> +  [(match_operand:SVE_I 1 "register_operand" "")
> +   (match_operand 2 "aarch64_simd_rshift_imm")]
> + UNSPEC_ASRD)]
> +  UNSPEC_PRED_X))]
> +  "TARGET_SVE"
> +  {
> +operands[3] = aarch64_ptrue_reg (mode);
> +  }
> +)
> +
> +;; Predicated ASRD with PTRUE.
> +(define_insn "*asrd3"
> +  [(set (match_operand:SVE_I 0 "register_operand" "=w, ?")
> + (unspec:SVE_I
> +   [(match_operand: 1 "register_operand" "Upl, Upl")
> +(unspec:SVE_I
> +  [(match_operand:SVE_I 2 "register_operand" "0, w")
> +   (match_operand 3 "aarch64_simd_rshift_imm")]
> + UNSPEC_ASRD)]
> +  UNSPEC_PRED_X))]
> +  "TARGET_SVE"
> +  "@
> +  asrd\t%0., %1/m, %0., #%3
> +  movprfx\t%0, %2\;asrd\t%0., %1/m, %0., #%3"
> +  [(set_attr "movprfx" "*,yes")]
> +)
> +
>  ;; 

[Bug other/91879] DESTDIR support seems incomplete

[stsp at users dot sourceforge.net]

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

--- Comment #4 from Stas Sergeev  ---
(In reply to Harald van Dijk from comment #1)
> The ways to handle libc being installed in non-standard locations depend on
> your specific use case. GCC provides the --with-sysroot and
> --with-native-system-header-dir configure options,

These ones specify the locations permanently.
My problem is that I need a different sysroot/system-header-dir
only for the time of building the gcc libs.
This is when DESTDIR is set. When the package
is installed on the target, then DESTDIR is
unset and the prefix locations should be used.
So I think the options you pointed, do not help
in my case. Somehow I need the build system to
pick up DESTDIR while building its libs.

If I could pass the variable name to --with-native-system-header-dir,
like -with-native-system-header-dir=\$DESTDIR/somedir
(dollar is "escaped" in that example to not expand immediately)
then that would work, but I don't suppose passing
the variable name is possible?

[Bug c++/84140] Inline friends are not constrained by concepts

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #3 from Jeff Chapman  ---
Created attachment 46930
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46930=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

Re: [PATCH] Fix ICE when __builtin_calloc has no LHS (PR tree-optimization/91014).

[Jeff Law]

On 9/24/19 4:34 AM, Martin Liška wrote:
> On 9/24/19 11:14 AM, Thomas Schwinge wrote:
>> Hi!
>>
>> Curious: even if you found the issue on a s390x target, shouldn't this
>> (presumably generic?) test case live in a generic place instead of
>> 'gcc.target/s390/'?
> 
> Sure, that's logical and I've just tested that locally on x86_64-linux-gnu.
> 
> Ready to be installed?
Sure, and IMHO moving tests like this should be something that can be
done without explicit ACKs.

jeff

[Bug c++/82794] ICE: Cannot allocate memory for concept with default argument

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #3 from Jeff Chapman  ---
Created attachment 46929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46929=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug c++/82740] [concepts] requires clause evaluated early

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #1 from Jeff Chapman  ---
Created attachment 46928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46928=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug tree-optimization/91885] New: ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate

[sje at gcc dot gnu.org]

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

Bug ID: 91885
   Summary: ICE when compiling SPEC 2017 blender benchmark with
-O3 -fprofile-generate
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

When compiling the SPEC 2017 526.blender_r benchmark for peak, the compilation
that tries to generate profile information aborts with an ICE.  This happens to
me on an Aarch64 machine (ThunderX2) with -O3 -fprofile-generate.  Below is a
small testcase cutdown from blender that shows the ICE.


% /extra/sellcey/gcc-tot/install/bin/gcc -O3 -fprofile-generate x.i
during GIMPLE pass: vect
x.i: In function 'IMB_indexer_open':
x.i:18:20: internal compiler error: in execute_todo, at passes.c:2032
   18 | struct anim_index *IMB_indexer_open(const char *name) {
  |^~~~
0xb87933 execute_todo
../../gcc/gcc/passes.c:2032
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

% cat x.i
typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;
typedef __int64_t int64_t;
typedef __uint64_t uint64_t;
inline void BLI_endian_switch_int64(int64_t *val) {
  uint64_t tval = *val;
  *val = ((tval >> 56)) | ((tval << 40) & 0x00ffll) | ((tval << 24)
& 0xff00ll) | ((tval << 8) & 0x00ffll) | ((tval >> 8) &
0xff00ll) | ((tval >> 24) & 0x00ffll) | ((tval >> 40) &
0xff00ll) | ((tval << 56));
}
typedef struct anim_index_entry {
  unsigned long long seek_pos_dts;
  unsigned long long pts;
} anim_index_entry;
extern struct anim_index_entry *MEM_callocN(int);
struct anim_index {
  int num_entries;
  struct anim_index_entry *entries;
};
struct anim_index *IMB_indexer_open(const char *name) {
  char header[13];
  struct anim_index *idx;
  int i;
  idx->entries = MEM_callocN(8);
  if (((1 == 0) != (header[8] == 'V'))) {
   for (i = 0; i < idx->num_entries; i++) {
BLI_endian_switch_int64((int64_t *)>entries[i].seek_pos_dts);
BLI_endian_switch_int64((int64_t *)>entries[i].pts);
   }
  }
}

[Bug libstdc++/91871] iterator_to_const_iterator() in testsuite_hooks.h causes valid -Wreturn-stack-address warnings with LLVM

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=49974

--- Comment #6 from Martin Sebor  ---
Or maybe it's bug 49974, depending on what type the template is instantiated
on.

[Bug c++/49974] missing -Wreturn-local-addr for indirectly returning reference to local/temporary

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90905

--- Comment #15 from Martin Sebor  ---
GCC 10 issues two warnings for the first test case in comment #0:

pr49974.C: In function ‘const X& g()’:
pr49974.C:8:15: warning: function returns address of local variable
[-Wreturn-local-addr]
8 | return f(x);  // !!!
  |   ^
pr49974.C:7:7: note: declared here
7 | X x;
  |   ^
In function ‘const X& h()’:
cc1plus: warning: function returns address of local variable
[-Wreturn-local-addr]
pr49974.C:7:7: note: declared here


The second test case is not diagnosed (due to a similar problem as pr90905). 
The test cases in comment #8  are also not diagnosed.

Re: [PATCH] PR tree-optimization/90836 Missing popcount pattern matching

[Dmitrij Pochepko]

Hi,

can anybody take a look at v2?

Thanks,
Dmitrij

On Mon, Sep 09, 2019 at 10:03:40PM +0300, Dmitrij Pochepko wrote:
> Hi all.
> 
> Please take a look at v2 (attached).
> I changed patch according to review comments. The same testing was performed 
> again.
> 
> Thanks,
> Dmitrij
> 
> On Thu, Sep 05, 2019 at 06:34:49PM +0300, Dmitrij Pochepko wrote:
> > This patch adds matching for Hamming weight (popcount) implementation. The 
> > following sources:
> > 
> > int
> > foo64 (unsigned long long a)
> > {
> > unsigned long long b = a;
> > b -= ((b>>1) & 0xULL);
> > b = ((b>>2) & 0xULL) + (b & 0xULL);
> > b = ((b>>4) + b) & 0x0F0F0F0F0F0F0F0FULL;
> > b *= 0x0101010101010101ULL;
> > return (int)(b >> 56);
> > }
> > 
> > and
> > 
> > int
> > foo32 (unsigned int a)
> > {
> > unsigned long b = a;
> > b -= ((b>>1) & 0xUL);
> > b = ((b>>2) & 0xUL) + (b & 0xUL);
> > b = ((b>>4) + b) & 0x0F0F0F0FUL;
> > b *= 0x01010101UL;
> > return (int)(b >> 24);
> > }
> > 
> > and equivalents are now recognized as popcount for platforms with hw 
> > popcount support. Bootstrapped and tested on x86_64-pc-linux-gnu and 
> > aarch64-linux-gnu systems with no regressions. 
> > 
> > (I have no write access to repo)
> > 
> > Thanks,
> > Dmitrij
> > 
> > 
> > gcc/ChangeLog:
> > 
> > PR tree-optimization/90836
> > 
> > * gcc/match.pd (popcount): New pattern.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR tree-optimization/90836
> > 
> > * lib/target-supports.exp (check_effective_target_popcount)
> > (check_effective_target_popcountll): New effective targets.
> > * gcc.dg/tree-ssa/popcount4.c: New test.
> > * gcc.dg/tree-ssa/popcount4l.c: New test.
> > * gcc.dg/tree-ssa/popcount4ll.c: New test.
> 
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index 0317bc7..b1867bf 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -5358,6 +5358,70 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >(cmp (popcount @0) integer_zerop)
> >(rep @0 { build_zero_cst (TREE_TYPE (@0)); }
> >  
> > +/* 64- and 32-bits branchless implementations of popcount are detected:
> > +
> > +   int popcount64c (uint64_t x)
> > +   {
> > + x -= (x >> 1) & 0xULL;
> > + x = (x & 0xULL) + ((x >> 2) & 0xULL);
> > + x = (x + (x >> 4)) & 0x0f0f0f0f0f0f0f0fULL;
> > + return (x * 0x0101010101010101ULL) >> 56;
> > +   }
> > +
> > +   int popcount32c (uint32_t x)
> > +   {
> > + x -= (x >> 1) & 0x;
> > + x = (x & 0x) + ((x >> 2) & 0x);
> > + x = (x + (x >> 4)) & 0x0f0f0f0f;
> > + return (x * 0x01010101) >> 24;
> > +   }  */
> > +(simplify
> > +  (convert
> > +(rshift
> > +  (mult
> > +   (bit_and:c
> > + (plus:c
> > +   (rshift @8 INTEGER_CST@5)
> > +   (plus:c@8
> > + (bit_and @6 INTEGER_CST@7)
> > + (bit_and
> > +   (rshift
> > + (minus@6
> > +   @0
> > +   (bit_and
> > + (rshift @0 INTEGER_CST@4)
> > + INTEGER_CST@11))
> > + INTEGER_CST@10)
> > +   INTEGER_CST@9)))
> > + INTEGER_CST@3)
> > +   INTEGER_CST@2)
> > +  INTEGER_CST@1))
> > +  /* Check constants and optab.  */
> > +  (with
> > + {
> > +   tree argtype = TREE_TYPE (@0);
> > +   unsigned prec = TYPE_PRECISION (argtype);
> > +   int shift = TYPE_PRECISION (long_long_unsigned_type_node) - prec;
> > +   const unsigned long long c1 = 0x0101010101010101ULL >> shift,
> > +   c2 = 0x0F0F0F0F0F0F0F0FULL >> shift,
> > +   c3 = 0xULL >> shift,
> > +   c4 = 0xULL >> shift;
> > + }
> > +(if (types_match (type, integer_type_node) && tree_to_uhwi (@4) == 1
> > + && tree_to_uhwi (@10) == 2 && tree_to_uhwi (@5) == 4
> > + && tree_to_uhwi (@1) == prec - 8 && tree_to_uhwi (@2) == c1
> > + && tree_to_uhwi (@3) == c2 && tree_to_uhwi (@9) == c3
> > + && tree_to_uhwi (@7) == c3 && tree_to_uhwi (@11) == c4
> > + && optab_handler (popcount_optab, TYPE_MODE (argtype))
> > +   != CODE_FOR_nothing)
> > +   (switch
> > +   (if (types_match (argtype, long_long_unsigned_type_node))
> > + (BUILT_IN_POPCOUNTLL @0))
> > +   (if (types_match (argtype, long_unsigned_type_node))
> > + (BUILT_IN_POPCOUNTL @0))
> > +   (if (types_match (argtype, unsigned_type_node))
> > + (BUILT_IN_POPCOUNT @0))
> > +
> >  /* Simplify:
> >  
> >   a = a1 op a2
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/popcount4.c 
> > b/gcc/testsuite/gcc.dg/tree-ssa/popcount4.c
> > new file mode 100644
> > index 000..9f759f8
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/popcount4.c
> > @@ -0,0 +1,22 @@
> > +/* { dg-do compile } */
> > +/* { 

[Bug libstdc++/91871] iterator_to_const_iterator() in testsuite_hooks.h causes valid -Wreturn-stack-address warnings with LLVM

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90905

--- Comment #5 from Martin Sebor  ---
If the template is instantiated it should be diagnosed by -Wreturn-local-addr,
but it isn't.  Bug 90905 tracks that limitation.

[Bug c++/82507] [concepts] premature substitution into constraint of non-template member function

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #3 from Jeff Chapman  ---
Created attachment 46927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46927=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

C++ PATCH for c++/91877 - ICE with converting member of packed struct.

[Marek Polacek]

This started to ICE with my CWG 2352 fix.  In reference_binding, we now bind
directly when the types are similar, not just when they are the same.  But even
direct binding can involve a temporary, e.g. for a bit-field, or, as in this
test, for a packed field.

convert_like will actually create the temporary, but we were triggering the
assert checking that the types are the same.  Now they don't have to be, so
adjust the assert accordingly.

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

2019-09-24  Marek Polacek  

PR c++/91877 - ICE with converting member of packed struct.
* call.c (convert_like_real): Use similar_type_p in an assert.

* g++.dg/conversion/packed1.C: New test.

diff --git gcc/cp/call.c gcc/cp/call.c
index 77f10a9f5f1..45b984ecb11 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -7382,8 +7382,7 @@ convert_like_real (conversion *convs, tree expr, tree fn, 
int argnum,
tree type = TREE_TYPE (ref_type);
cp_lvalue_kind lvalue = lvalue_kind (expr);
 
-   gcc_assert (same_type_ignoring_top_level_qualifiers_p
-   (type, next_conversion (convs)->type));
+   gcc_assert (similar_type_p (type, next_conversion (convs)->type));
if (!CP_TYPE_CONST_NON_VOLATILE_P (type)
&& !TYPE_REF_IS_RVALUE (ref_type))
  {
diff --git gcc/testsuite/g++.dg/conversion/packed1.C 
gcc/testsuite/g++.dg/conversion/packed1.C
new file mode 100644
index 000..c4be930bc19
--- /dev/null
+++ gcc/testsuite/g++.dg/conversion/packed1.C
@@ -0,0 +1,12 @@
+// PR c++/91877 - ICE with converting member of packed struct.
+// { dg-do compile { target c++11 } }
+// { dg-options "-fpack-struct" }
+
+template  class b {
+public:
+  b(const a &);
+};
+struct {
+  int *c;
+} d;
+void e() { b(d.c); }

[Bug testsuite/91884] libgomp testsuite: (not) using a specific driver for C++, Fortran

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
One stopgap patch is
,
to un-break libgomp Fortran testing in a context where '-lquadmath' is not
automatically deduced from '-lgfortran' in a cross-compilation setting.

[Bug testsuite/91884] New: libgomp testsuite: (not) using a specific driver for C++, Fortran

[tschwinge at gcc dot gnu.org]

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

Bug ID: 91884
   Summary: libgomp testsuite: (not) using a specific driver for
C++, Fortran
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

This is to keep track of the discussion started in
, where I propose to
change libgomp testsuite to use a specific driver for C++, Fortran testing,
instead of re-inventing what these drivers are doing, using 'gcc' with flags
such as '-lgfortran'.

In the first follow-up message, I had posted a set of patches.  These are still
valid, hopefully, and can be used to complete this task, if we agree that's the
way to go.

(I don't think I ever figured out the reason for the current setup, where
libgomp testing is not using a specific driver for C++, Fortran?)

[Bug c++/80773] [Concepts] Internal Compiler error on template parameter pack expansion

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #2 from Jeff Chapman  ---
Created attachment 46926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46926=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

Re: [PATCH][RFC] Come up with VEC_COND_OP_EXPRs.

[Richard Sandiford]

Richard Biener  writes:
> On Tue, Sep 24, 2019 at 1:57 PM Richard Sandiford
>  wrote:
>>
>> Richard Biener  writes:
>> > On Tue, Sep 24, 2019 at 1:11 PM Richard Sandiford
>> >  wrote:
>> >>
>> >> Martin Liška  writes:
>> >> > Hi.
>> >> >
>> >> > The patch introduces couple of new TREE_CODEs that will help us to have
>> >> > a proper GIMPLE representation of current VECT_COND_EXPR. Right now,
>> >> > the first argument is typically a GENERIC tcc_expression tree with 2 
>> >> > operands
>> >> > that are visited at various places in GIMPLE code. That said, based on 
>> >> > the discussion
>> >> > with Richi, I'm suggesting to come up with e.g.
>> >> > VECT_COND_LT_EXPR. Such a 
>> >> > change logically
>> >> > introduces new GIMPLE_QUATERNARY_RHS gassignments. For now, the 
>> >> > VEC_COND_EXPR remains
>> >> > and is only valid in GENERIC and gimplifier will take care of the 
>> >> > corresponding transition.
>> >> >
>> >> > The patch is a prototype and missing bits are:
>> >> > - folding support addition for GIMPLE_QUATERNARY_RHS is missing
>> >> > - fancy tcc_comparison expressions like LTGT_EXPR, UNORDERED_EXPR, 
>> >> > ORDERED_EXPR,
>> >> >   UNLT_EXPR and others are not supported right now
>> >> > - comments are missing for various functions added
>> >> >
>> >> > Apart from that I was able to bootstrap and run tests with a quite 
>> >> > small fallout.
>> >> > Thoughts?
>> >> > Martin
>> >>
>> >> I think this is going in the wrong direction.  There are some targets
>> >> that can only handle VEC_COND_EXPRs well if we know the associated
>> >> condition, and others where a compare-and-VEC_COND_EXPR will always be
>> >> two operations.  In that situation, it seems like the native gimple
>> >> representation should be the simpler representation rather than the
>> >> more complex one.  That way the comparisons can be optimised
>> >> independently of any VEC_COND_EXPRs on targets that benefit from that.
>> >>
>> >> So IMO it would be better to use three-operand VEC_COND_EXPRs with
>> >> no embedded conditions as the preferred gimple representation and
>> >> have internal functions for the fused operations that some targets
>> >> prefer.  This means that using fused operations is "just" an instruction
>> >> selection decision rather than hard-coded throughout gimple.  (And that
>> >> fits in well with the idea of doing more instruction selection in gimple.)
>> >
>> > So I've been doing that before, but more generally also for COND_EXPR.
>> > We cannot rely on TER and the existing RTL expansion "magic" for the
>> > instruction selection issue you mention because TER isn't reliable.  With
>> > IFNs for optabs we could do actual [vector] condition instruction selection
>> > before RTL expansion, ignoring "single-use" issues - is that what you are
>> > hinting at?
>>
>> Yeah.  It'd be similar to how most FMA selection happens after
>> vectorisation but before expand.
>>
>> > How should the vectorizer deal with this?  Should it directly
>> > use the optab IFNs then when facing "split" COND_EXPRs?  IIRC the
>> > most fallout of a simple patch (adjusting is_gimple_condexpr) is in the
>> > vectorizer.
>>
>> I guess that would be down to how well the vector costings work if we
>> just stick to VEC_COND_EXPR and cost the comparison separately.  Using
>> optabs directly in the vectoriser definitely sounds OK if that ends up
>> being necessary for good code.  But if (like you say) the COND_EXPR is
>> also split apart, we'd be costing the scalar comparison and selection
>> separately as well.
>>
>> > Note I'm specifically looking for a solution that applies to both COND_EXPR
>> > and VEC_COND_EXPR since both suffer from the same issues.
>>
>> Yeah, think the same approach would work for COND_EXPR if it's needed.
>> (And I think the same trade-off applies there too.  Some targets will
>> always need a separate comparison to implement a four-operand COND_EXPR.)
>>
>> > There was also recent work in putting back possibly trapping comparisons
>> > into [VEC_]COND_EXPR because it doesn't interfere with EH and allows
>> > better code.
>>
>> OK, that's a good counter-reason :-)  But it seems quite special-purpose.
>> I assume this works even for targets that do split the VEC_COND_EXPR
>> because the result is undefined on entry to the EH receiver if the
>> operation didn't complete.  But that should be true of any non-trapping
>> work done after the comparison, with the same proviso.
>>
>> So this still seems like an instruction-selection issue.  We're just
>> saying that it's OK to combine a trapping comparison and a VEC_COND_EXPR
>> from the non-trapping path.  The same would be true for any other
>> instruction selection that combines trapping and non-trapping
>> operations, provided that the speculated parts can never trap.
>
> Sure, but that case would necessarily be combining the compare and the
> select to the compare place which is "backwards" (and would speculate
> the select).  Certainly something we don't do 

[Bug c++/91845] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 10.

[Bug c++/91868] wrong location info with -Wshadow on C++ constructors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/80746] [concepts] ICE evaluating constraints for concepts with dependent template parameters

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #4 from Jeff Chapman  ---
Created attachment 46925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46925=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This and the related PRs appear to be fixed on concepts-cxx2a. Patch adds a
test for this PR.

NLNet funding proposal for donations to gcc vector processor

[Luke Kenneth Casson Leighton]

https://libre-riscv.org/nlnet_2019_gcc/

Long story short, caveats first:

* this is not recruitment
* it is not a job offer either (so cannot go on the FSF page)
* i asked on irc and contacted the steering committee but did not receive a
response
* the deadline is Oct 1st so there is time pressure

I am looking for people who would like to be the recipient of charitable
donations, direct from the NLNet Foundation [1] for the purposes of a gcc
vector processor port to the newly developed Libre RISC-V SoC.

This processor is a hybrid CPU / VPU / GPU with an entirely unique type of
"tagged" vectorisation that effectively turns scalar operations into
parallel ones.

It is quite similar to the Cray Vector Engine, which forms the basis of the
RISCV RVV Extension.  With the addition of RVV support to LLVM one of my
big concerns is that gcc will be left behind, here.

If anyone over the next few days and weeks sees this message and would like
to work on a gcc port, based on the *existing* RISC-V gcc port, please do
get in touch promptly and/or ask questions, here.

With thanks and gratitude,

L.

[1] https://nlnet.nl/PET/ EU Grant  No 825310 https://nlnet.nl/foundation/
charitable tax status agreements established, links available


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

[Bug c++/91868] wrong location info with -Wshadow on C++ constructors

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue Sep 24 14:40:24 2019
New Revision: 276103

URL: https://gcc.gnu.org/viewcvs?rev=276103=gcc=rev
Log:
PR c++/91868 - improve -Wshadow location.
* name-lookup.c (check_local_shadow): Use DECL_SOURCE_LOCATION
instead of input_location.

* g++.dg/warn/Wshadow-16.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wshadow-16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/91845] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Tue Sep 24 14:38:53 2019
New Revision: 276102

URL: https://gcc.gnu.org/viewcvs?rev=276102=gcc=rev
Log:
PR c++/91845 - ICE with invalid pointer-to-member.
* expr.c (mark_use): Use error_operand_p.
* typeck2.c (build_m_component_ref): Check error_operand_p after
calling mark_[lr]value_use.

* g++.dg/cpp1y/pr91845.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr91845.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/expr.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91882] boolean XOR tautology missed optimisation

[SztfG at yandex dot ru]

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

--- Comment #1 from SztfG at yandex dot ru ---
Similar problem with other tautology:

unsigned int impl_bit(unsigned int a, unsigned int b) // bitwise implication
{
  return (~a | b);
}

unsigned int eq_bit(unsigned int a, unsigned int b) // bitwise equivalence
{
  return (~a ^ b);
}

// good optimisation - "return 1;"
unsigned int always_true(unsigned int a, unsigned int b)
{
  return eq_bit(impl_bit(a,b), impl_bit(b,a)) == eq_bit(a, b); // ( (a -> b) =
(b -> a) ) = (a = b) tautology
}



bool impl_bool(bool a, bool b
{
return (!a || b);
}

// bad optimisation
bool always_true(bool a, bool b)
{
return (impl(a,b) == impl(b,a)) == (a == b); // ( (a -> b) = (b -> a) ) =
(a = b) tautology
}

Re: C++ PATCH for c++/91845 - ICE with invalid pointer-to-member.

[Jason Merrill]

OK.

On Mon, Sep 23, 2019 at 10:06 PM Marek Polacek  wrote:
>
> build_m_component_ref checks if either datum/component it got are erroneous 
> but
> they can be turned into the error_mark_node by mark_use as in this case: datum
> is "a" before the call to mark_lvalue_use, but that emits an error and returns
> the error_mark_node, which then crashes.
>
> We can just move the checks after calling mark_[lr]value_use; those just
> return when they get the error_mark_node.  But I tweaked mark_use to also
> handle the case when the type is erroneous.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-09-23  Marek Polacek  
>
> PR c++/91845 - ICE with invalid pointer-to-member.
> * expr.c (mark_use): Use error_operand_p.
> * typeck2.c (build_m_component_ref): Check error_operand_p after
> calling mark_[lr]value_use.
>
> * g++.dg/cpp1y/pr91845.C: New test.
>
> diff --git gcc/cp/expr.c gcc/cp/expr.c
> index 212a7f93c5a..d488912d5db 100644
> --- gcc/cp/expr.c
> +++ gcc/cp/expr.c
> @@ -96,7 +96,7 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
>  {
>  #define RECUR(t) mark_use ((t), rvalue_p, read_p, loc, reject_builtin)
>
> -  if (expr == NULL_TREE || expr == error_mark_node)
> +  if (expr == NULL_TREE || error_operand_p (expr))
>  return expr;
>
>if (reject_builtin && reject_gcc_builtin (expr, loc))
> diff --git gcc/cp/typeck2.c gcc/cp/typeck2.c
> index d5098fa24bb..58fa54f40af 100644
> --- gcc/cp/typeck2.c
> +++ gcc/cp/typeck2.c
> @@ -2068,12 +2068,12 @@ build_m_component_ref (tree datum, tree component, 
> tsubst_flags_t complain)
>tree binfo;
>tree ctype;
>
> -  if (error_operand_p (datum) || error_operand_p (component))
> -return error_mark_node;
> -
>datum = mark_lvalue_use (datum);
>component = mark_rvalue_use (component);
>
> +  if (error_operand_p (datum) || error_operand_p (component))
> +return error_mark_node;
> +
>ptrmem_type = TREE_TYPE (component);
>if (!TYPE_PTRMEM_P (ptrmem_type))
>  {
> diff --git gcc/testsuite/g++.dg/cpp1y/pr91845.C 
> gcc/testsuite/g++.dg/cpp1y/pr91845.C
> new file mode 100644
> index 000..cb80dd7a8a7
> --- /dev/null
> +++ gcc/testsuite/g++.dg/cpp1y/pr91845.C
> @@ -0,0 +1,14 @@
> +// PR c++/91845 - ICE with invalid pointer-to-member.
> +// { dg-do compile { target c++14 } }
> +
> +void non_const_mem_ptr() {
> +  struct A {
> +  };
> +  constexpr A a = {1, 2}; // { dg-error "too many initializers" }
> +  struct B {
> +int A::*p;
> +constexpr int g() const {
> +  return a.*p; // { dg-error "use of local variable" }
> +};
> +  };
> +}

Re: C++ PATCH for c++/91868 - improve -Wshadow location.

[Jason Merrill]

OK.

On Mon, Sep 23, 2019 at 10:04 PM Marek Polacek  wrote:
>
> We can improve various -Wshadow warnings by using DECL_SOURCE_LOCATION
> rather than whatever is in input_location.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-09-23  Marek Polacek  
>
> PR c++/91868 - improve -Wshadow location.
> * name-lookup.c (check_local_shadow): Use DECL_SOURCE_LOCATION
> instead of input_location.
>
> * g++.dg/warn/Wshadow-16.C: New test.
>
> diff --git gcc/cp/name-lookup.c gcc/cp/name-lookup.c
> index 8bbb92ddc9f..74f1072fa8c 100644
> --- gcc/cp/name-lookup.c
> +++ gcc/cp/name-lookup.c
> @@ -2771,7 +2771,7 @@ check_local_shadow (tree decl)
> msg = "declaration of %qD shadows a previous local";
>
>auto_diagnostic_group d;
> -  if (warning_at (input_location, warning_code, msg, decl))
> +  if (warning_at (DECL_SOURCE_LOCATION (decl), warning_code, msg, decl))
> inform_shadowed (old);
>return;
>  }
> @@ -2798,7 +2798,7 @@ check_local_shadow (tree decl)
> || TYPE_PTRMEMFUNC_P (TREE_TYPE (decl)))
>   {
> auto_diagnostic_group d;
> -   if (warning_at (input_location, OPT_Wshadow,
> +   if (warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wshadow,
> "declaration of %qD shadows a member of %qT",
> decl, current_nonlambda_class_type ())
> && DECL_P (member))
> @@ -2818,7 +2818,7 @@ check_local_shadow (tree decl)
>  /* XXX shadow warnings in outer-more namespaces */
>  {
>auto_diagnostic_group d;
> -  if (warning_at (input_location, OPT_Wshadow,
> +  if (warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wshadow,
>   "declaration of %qD shadows a global declaration",
>   decl))
> inform_shadowed (old);
> diff --git gcc/testsuite/g++.dg/warn/Wshadow-16.C 
> gcc/testsuite/g++.dg/warn/Wshadow-16.C
> new file mode 100644
> index 000..1ba54ec107d
> --- /dev/null
> +++ gcc/testsuite/g++.dg/warn/Wshadow-16.C
> @@ -0,0 +1,24 @@
> +// PR c++/91868 - improve -Wshadow location.
> +// { dg-options "-Wshadow" }
> +
> +int global; // { dg-message "shadowed declaration" }
> +
> +struct S
> +{
> +  static int bar; // { dg-message "shadowed declaration" }
> +  S (int i) { int bar // { dg-warning "19:declaration of .bar. shadows a 
> member" }
> +  (1);
> +int global // { dg-warning "9:declaration of .global. shadows a global 
> declaration" }
> +  (42);
> +  }
> +};
> +
> +void
> +foo ()
> +{
> +  int xx; // { dg-message "shadowed declaration" }
> +  {
> +S xx // { dg-warning "7:declaration of .xx. shadows a previous local" }
> +(42);
> +  }
> +}

[Bug middle-end/91883] New: Division by a constant could be optimized for known variables value range

[antoshkka at gmail dot com]

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

Bug ID: 91883
   Summary: Division by a constant could be optimized for known
variables value range
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

unsigned long long kBorder = (1ull<<62);

unsigned long long sample(unsigned long long m) {
if (m >= kBorder) __builtin_unreachable();
return m / 10;
}

It produces the following assembly:

sample(unsigned long long):
  movabs rdx, -3689348814741910323
  mov rax, rdi
  mul rdx
  mov rax, rdx
  shr rax, 3
  ret

However, knowing that the higher bits are always 0, the constant could be
adjusted to avoid the `shr rax, 3`:

sample(unsigned long long):
  movabs rax, 1844674407370955162
  mul rdi
  mov rax, rdx
  ret

Godbolt playground: https://godbolt.org/z/YU2yAC

This issue is probably related to PR 91881

P.S.: that optimization is important for std::to_chars(..., double) like
functions, where a significant of a double is extracted into an unsigned long
long variable, so its upper bits are always zero.

[Bug tree-optimization/91882] New: boolean XOR tautology missed optimisation

[SztfG at yandex dot ru]

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

Bug ID: 91882
   Summary: boolean XOR tautology missed optimisation
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

This functions is always return true regardless of the value of the arguments:

bool bool_xor_test(bool a, bool b)
{
  return (a != b) == ((a || b) && !(a && b));
}

bool bool_xor_test2(bool a, bool b)
{
  return (a ^ b) == ((a || b) && !(a && b));
}

but compiler does not simplify to "return true;". Expression ((a || b) && !(a
&& b)) poorly optimized


BUT! In this case:
bool xor_test_unsigned_int(unsigned int a, unsigned int b)
{
  return (a ^ b) == ((a | b) & ~(a & b));
}

It actually simlified to "return true;" :

movl$1, %eax
ret

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
I would like to see this also fixed. But I know Honza has some comments about
the patch. Honza?

[Bug middle-end/91881] New: Value range knowledge of higher bits not used in optimizations

[antoshkka at gmail dot com]

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

Bug ID: 91881
   Summary: Value range knowledge of higher bits not used in
optimizations
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

unsigned long long sample2(unsigned long long m) {
if (m >= 100) __builtin_unreachable();
m *= 16;
return m >> 3;
}

After the `if` statement we do know that the higher bits are set to 0. So
instead of generating the following assembly:

sample2(unsigned long long):
  mov rax, rdi
  sal rax, 4
  shr rax, 3
  ret

A more optimal assembly could be generated:

sample2(unsigned long long):
  lea rax, [rdi + rdi]
  ret


Godbolt playground: https://godbolt.org/z/1iSpTh

P.S.: that optimization is important for std::to_chars(..., double) like
functions, where a significant of a double is extracted into an unsigned long
long variable, so its upper bits are always zero.

Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for review

[Mark Eggleston]

On 24/09/2019 14:53, Bernhard Reutner-Fischer wrote:

On Tue, 24 Sep 2019 12:12:04 +0100
Mark Eggleston  wrote:


@@ -411,7 +411,7 @@ gfc_post_options (const char **pfilename)
 && flag_max_stack_var_size != 0)
   gfc_warning_now (0, "Flag %<-fno-automatic%> overwrites 
%<-fmax-stack-var-size=%d%>",
 flag_max_stack_var_size);
-  else if (!flag_automatic && flag_recursive)
+  else if (!flag_automatic && flag_recursive && warn_overwrite_recursive)
   gfc_warning_now (0, "Flag %<-fno-automatic%> overwrites 
%<-frecursive%>");
 else if (!flag_automatic && flag_openmp)
   gfc_warning_now (0, "Flag %<-fno-automatic%> overwrites %<-frecursive%> 
implied by "


Doesn't look right to me. Do you want
gfc_warning_now (OPT_Woverwrite_recursive, "Flag ...
instead?

Done.

by "instead" i mean you to leave the if unchanged.
I didn't realise that's how it worked. That's cleaner. Once fixed OK for 
commit?


thanks,


--
https://www.codethink.co.uk/privacy.html

[Bug target/91816] Arm generates out of range conditional branches in Thumb2

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for review

[Bernhard Reutner-Fischer]

On Tue, 24 Sep 2019 12:12:04 +0100
Mark Eggleston  wrote:

> >> @@ -411,7 +411,7 @@ gfc_post_options (const char **pfilename)
> >> && flag_max_stack_var_size != 0)
> >>   gfc_warning_now (0, "Flag %<-fno-automatic%> overwrites 
> >> %<-fmax-stack-var-size=%d%>",
> >> flag_max_stack_var_size);
> >> -  else if (!flag_automatic && flag_recursive)
> >> +  else if (!flag_automatic && flag_recursive && warn_overwrite_recursive)
> >>   gfc_warning_now (0, "Flag %<-fno-automatic%> overwrites 
> >> %<-frecursive%>");
> >> else if (!flag_automatic && flag_openmp)
> >>   gfc_warning_now (0, "Flag %<-fno-automatic%> overwrites 
> >> %<-frecursive%> implied by "
> >>
> > Doesn't look right to me. Do you want
> > gfc_warning_now (OPT_Woverwrite_recursive, "Flag ...
> > instead?
> Done.

by "instead" i mean you to leave the if unchanged.

thanks,