[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
Bug seems to start sometime between revision 276550 and 276650.

[Bug c++/92040] Type requirements don't appear to work when a type doesn't exist.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-10
 Ever confirmed|0   |1

[Bug middle-end/92037] [10 Regression] LTO bootstrap broken in selftests

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-10
 CC||dmalcolm at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Jambor  ---
Started with Honza's r276469 (git mirror 047f91509cb) but that likely only
exposed some latent issue.  Given where the segfault takes place, perhaps the
symbol_table needs re-initialization in between different self-tests... David?

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

[krebbel at gcc dot gnu.org]

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

--- Comment #7 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Oct 10 07:56:25 2019
New Revision: 276790

URL: https://gcc.gnu.org/viewcvs?rev=276790&root=gcc&view=rev
Log:
S/390: PR91035 Fix call to __morestack

For the call to __morestack we use a special ABI in the S/390 back-end
which requires us to emit a parameter block to the .rodata section.
It contains the label whereto __morestack needs to return.  The
parameter block needs to be explicit in RTL since we also need to take
the address of it loaded into r1 in order to pass its address to
__morestack.  In order to express correctly what __morestack does its
RTX also contained the return label. Hence we had the return label to
occur twice in the insn stream.  This is problematic when it comes to
redirecting edges.  The correlation between these two occurrences of
the label cannot be expressed so when doing a redirect only the label
in the jump RTX gets modified while the parameter block label stays as
is.

The patch avoids having two instancs of the label by merging the
parameter block generation and the __morestack call RTX into one. By
doing this I could also get rid of the unspec which was required for
the parameter block generation so far.

gcc/ChangeLog:

2019-10-10  Andreas Krebbel  

PR target/91035
* config/s390/s390-protos.h (s390_output_split_stack_data): Add
prototype.
* config/s390/s390.md (UNSPECV_SPLIT_STACK_DATA): Remove.
("split_stack_data", "split_stack_call")
("split_stack_call_", "split_stack_cond_call")
("split_stack_cond_call_"): Remove.
("@split_stack_call", "@split_stack_cond_call"): New
insn definition.
* config/s390/s390.c (s390_output_split_stack_data): New function.
(s390_expand_split_stack_prologue): Use the merged expander.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390-protos.h
trunk/gcc/config/s390/s390.c
trunk/gcc/config/s390/s390.md

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

[krebbel at gcc dot gnu.org]

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

--- Comment #8 from Andreas Krebbel  ---
With that patch GCCGO bootstraps fine until r275473 where libgo got updated to
version 1.13beta1. Then there are a few problems with hardware crypto support
on Z. I'll try to address these with separate patches and BZs.

I plan to commit the patch also to GCC 9 and 8 after giving it some time on
master.

[Bug libstdc++/91057] Data race in locale(const locale&, Facet*) constructor

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #3 from Kewen Lin  ---
The commit in comment #2 seems caused bootstrap to fail on powerpc64le.

/home/linkw/gcc/gcc-svn/libstdc++-v3/src/c++98/locale.cc: In member function
‘std::size_t std::locale::id::_M_id() const’:
/home/linkw/gcc/gcc-svn/libstdc++-v3/src/c++98/locale.cc:508:47: error: invalid
conversion from ‘const std::locale::id*’ to ‘std::locale::id*’ [-fpermissive]
  508 |  if (locale::id* f = find_ldbl_sync_facet(this))
  |   ^
  |   |
  |   const std::locale::id*
/home/linkw/gcc/gcc-svn/libstdc++-v3/src/c++98/locale.cc:481:36: note:  
initializing argument 1 of ‘std::locale::id*
std::{anonymous}::find_ldbl_sync_facet(std::locale::id*)’
  481 |   find_ldbl_sync_facet(locale::id* __idp)
  |^

One workaround could be:

Index: libstdc++-v3/src/c++98/locale.cc
===
--- libstdc++-v3/src/c++98/locale.cc(revision 276787)
+++ libstdc++-v3/src/c++98/locale.cc(working copy)
@@ -478,7 +478,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #ifdef _GLIBCXX_LONG_DOUBLE_COMPAT
 namespace {
   inline locale::id*
-  find_ldbl_sync_facet(locale::id* __idp)
+  find_ldbl_sync_facet(const locale::id* __idp)
   {
 # define _GLIBCXX_SYNC_ID(facet, mangled) \
 if (__idp == &::mangled) \

[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Alan Coopersmith  ---
> This seems to go back to:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a6905708d86d6c2d8560168ac5accb816a2038c8
> and was probably to deal with the bit of the Solaris system headers in
> various releases that throws an error if you try to define _XOPEN_SOURCE
> to 600 or 700 and didn't have a __STDC_VERSION__ matching C99 defined.

Right: the corresponding patch submission with background info is at
https://gcc.gnu.org/ml/gcc-patches/2010-05/msg01308.html.

As it happens, a colleague just yesterday ran into the `no C99 without
XPG6' issue on some 2016 SRU of Solaris 11.3.  Given that those checks
were remove only later, I fear the current code in g++ has to stay for
those not on the latest bits (like non-support users).

[Bug middle-end/92037] [10 Regression] LTO bootstrap broken in selftests

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  ---
> Started with Honza's r276469 (git mirror 047f91509cb) but that likely only
> exposed some latent issue.  Given where the segfault takes place, perhaps the
> symbol_table needs re-initialization in between different self-tests... David?
One posibility would be lifetime DSE bug in the C++ conversion of the
code. We had some issues with that in the past.

Honza
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug target/91796] Sub-optimal YMM register allocation.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The #c0 issue is a RA decision, what registers it decides to use for each
pseudo register.
As for #c1, the optimizers see that what you've typed there is a constant and
optimizes it into a constant (which is desirable).  Whether that particular
constant is better loaded into a register using a memory load or two
instructions depends on various factors, we obviously have special cases for
constants that can be built using a single non-memory instruction (e.g. zero
vector or all ones vector), whether to do that for other constant is something
that needs to be thought out, benchmarked etc.

[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Store-merging sees:
  MEM[(struct  &)&D.16119] ={v} {CLOBBER};
  MEM[(struct _Uninitialized *)&D.16119] ={v} {CLOBBER};
  MEM[(struct _Uninitialized *)&D.16119]._M_storage = 0;
  MEM[(struct _Variant_storage *)&D.16119]._M_index = 0;
so perhaps we could just add handling of clobbers to store-merging, similarly
like we already handle = {} initializers; of course never remove the clobbers,
but just assume that zeros (or anything else) can be stored in the bytes that
actually weren't stored.

[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase:
struct S { int a; char b; char c[3]; S () : a (0), b (0) {} };
void foo (struct S);
void bar (void) { struct S s; foo (s); }

[Bug tree-optimization/88760] GCC unrolling is suboptimal

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #27 from Wilco  ---
(In reply to Segher Boessenkool from comment #26)
> Yeah, and it probably should be a param (that different targets can default
> differently, per CPU probably).  On most Power CPUs all loops take a minimum
> number of cycles per iteration (say, three), but that translates to a lot of
> instructions (say, >10).
> 
> Small loops should probably be unrolled at -O2 already as well.  Maybe fixed
> length loops only?

Agreed, there is no reason not to unroll (or vectorize) with -O2 given several
other compilers do (and beat GCC as a result). It's best to limit unrolling to
small loops and only 2x unless it's 1-2 instructions.

[Bug target/91833] [10 Regression] [AArch64] LSE atomics depends on glibc specific sys/auxv.h

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||wilco at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Wilco  ---
Fixed

[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #4)
> Store-merging sees:
>   MEM[(struct  &)&D.16119] ={v} {CLOBBER};
>   MEM[(struct _Uninitialized *)&D.16119] ={v} {CLOBBER};
>   MEM[(struct _Uninitialized *)&D.16119]._M_storage = 0;
>   MEM[(struct _Variant_storage *)&D.16119]._M_index = 0;
> so perhaps we could just add handling of clobbers to store-merging,
> similarly like we already handle = {} initializers; of course never remove
> the clobbers, but just assume that zeros (or anything else) can be stored in
> the bytes that actually weren't stored.

Ah, yeah - that sounds like a nice trick.  There may be cases where another
value besides zero is cheaper (-1 comes to my mind here), not sure if we
need to try optimize that.

[Bug target/91834] [10 Regression ] [AArch64] LSE atomics, warnings due to unpredictable behavior with strx and the same register for s and t

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||wilco at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Wilco  ---
Fixed

[Bug ipa/92043] fuzzer.c:177:1: internal compiler error: in edge_badness, at ipa-inline.c:900

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Richard Biener  ---
GCC 4.8 is no longer maintained, please file this bug with RedHat instead.

[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Just a proof of concept:
--- gcc/gimple-ssa-store-merging.c.jj   2019-10-02 16:35:21.016450769 +0200
+++ gcc/gimple-ssa-store-merging.c  2019-10-10 11:51:20.912101959 +0200
@@ -4361,7 +4361,6 @@ rhs_valid_for_store_merging_p (tree rhs)
 {
   unsigned HOST_WIDE_INT size;
   if (TREE_CODE (rhs) == CONSTRUCTOR
-  && !TREE_CLOBBER_P (rhs)
   && CONSTRUCTOR_NELTS (rhs) == 0
   && TYPE_SIZE_UNIT (TREE_TYPE (rhs))
   && tree_fits_uhwi_p (TYPE_SIZE_UNIT (TREE_TYPE (rhs
@@ -4794,7 +4793,7 @@ store_valid_for_store_merging_p (gimple
   return gimple_assign_single_p (stmt)
 && gimple_vdef (stmt)
 && lhs_valid_for_store_merging_p (gimple_assign_lhs (stmt))
-&& !gimple_has_volatile_ops (stmt);
+&& (!gimple_has_volatile_ops (stmt) || gimple_clobber_p (stmt));
 }

 enum basic_block_status { BB_INVALID, BB_VALID, BB_EXTENDED_VALID };
@@ -4875,7 +4874,7 @@ pass_store_merging::execute (function *f
  if (is_gimple_debug (stmt))
continue;

- if (gimple_has_volatile_ops (stmt))
+ if (gimple_has_volatile_ops (stmt) && !gimple_clobber_p (stmt))
{
  /* Terminate all chains.  */
  if (dump_file && (dump_flags & TDF_DETAILS))
fixes the #c5 testcase, but breaks the #c0 one, so this shows we need to handle
clobbers
more carefully.  The reason #c0 breaks is that the rest of store-merging
considers the = {}
stores as zeroing and so thinks if it leaves it in the stream, it will zero it.
 That is not the case with the clobbers.
I guess we also need to be careful when clobbers happen in the middle of store
sequence rather than just at the start
(the question is if it wouldn't be better if some earlier pass (DSE) removed in
  MEM[(struct  &)&D.16119] ={v} {CLOBBER};
  MEM[(struct _Uninitialized *)&D.16119] ={v} {CLOBBER};
The first one is a 5 byte clobber, the second one 4 byte clobber and when the
second one must alias the first one and is a subset of the previous one, I
don't see an advantage in keeping both).
If say DSE removes that, we could just punt on a clobber in the middle and
handle carefully clobber at the start (make sure to keep the clobber unless we
perhaps overwrite it fully, and don't count the clobber as another stmt unless
we manage to overwrite it fully).

[Bug debug/91507] wrong debug for completed array with previous incomplete declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
  Known to fail|10.0|

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/80155] [7/8/9/10 regression] Performance regression with code hoisting enabled

[jye2 at gcc dot gnu.org]

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

--- Comment #46 from jye2 at gcc dot gnu.org ---
Author: jye2
Date: Thu Oct 10 10:29:47 2019
New Revision: 276797

URL: https://gcc.gnu.org/viewcvs?rev=276797&root=gcc&view=rev
Log:
Pickup patch rejected in trunk.
2019-09-11  Wilco Dijkstra  


PR tree-optimization/80155
* common/config/arm/arm-common.c (arm_option_optimization_table):
Enable -fcode-hoisting with -Os.

Added:
branches/ARM/arm-9-branch/gcc/ChangeLog.arm
Modified:
branches/ARM/arm-9-branch/gcc/common/config/arm/arm-common.c

[Bug c++/72682] Redundant concept diagnostics when the same concept is checked multiple times

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Jonathan Wakely  ---
Seems to be fixed on trunk:

72682.cc: In function 'int main()':
72682.cc:14:16: error: cannot call function 'void f(T) [with T = S]'
   14 | int main(){ f(s); }
  |^
72682.cc:11:44: note: constraints not satisfied
   11 | template requires B void f(T){}
  |^
72682.cc: In function 'void f(T) [with T = S]':
72682.cc:3:14:   required for the satisfaction of 'A'
72682.cc:5:14:   required for the satisfaction of 'B'
72682.cc:3:18:   in requirements with 'S a'
72682.cc:3:35: note: the required expression '(a == a)' is invalid
3 | concept bool A = requires(T a) { a==a; };
  |  ~^~~

[Bug c++/92044] New: Poor diagnostics for concept that should be a qualified-id

[redi at gcc dot gnu.org]

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

Bug ID: 92044
   Summary: Poor diagnostics for concept that should be a
qualified-id
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

namespace N {
  template
concept foo = true;
}

template requires N::foo
void ok(T) { }

template requires foo
void bad1(T) { }

template requires (foo)
void bad2(T) { }


dym.cc:9:34: error: expression after 'requires' must be enclosed in parentheses
9 | template requires foo
  |  ^
dym.cc:9:34: error: expression after 'requires' must be enclosed in parentheses
dym.cc:9:34: error: expected unqualified-id before '<' token
dym.cc:12:32: error: 'foo' was not declared in this scope; did you mean
'concept foo'?
   12 | template requires (foo)
  |^~~
  |concept foo
dym.cc:3:13: note: 'concept foo' declared here
3 | concept foo = true;
  | ^~~
dym.cc:12:32: error: 'foo' was not declared in this scope; did you mean
'concept foo'?
   12 | template requires (foo)
  |^~~
  |concept foo
dym.cc:3:13: note: 'concept foo' declared here
3 | concept foo = true;
  | ^~~
dym.cc:12:22: error: expression after 'requires' must be enclosed in
parentheses
   12 | template requires (foo)
  |  ^~~~
dym.cc:12:35: error: expected ')' before '<' token
   12 | template requires (foo)
  |   ~   ^
  |   )


The first error is misleading, the expression doesn't need to be enclosed in
parentheses, it needs to be qualified (but the compiler doesn't know that so
thinks it's a less-than expression).

The second error is a duplicate of the first. The third is reasonable, given
the first error, but it would be nice if it could be suppressed.

Ideally the compiler would look for 'foo' and suggest qualifying it instead of
adding the parentheses (which wouldn't actually fix anything).

The fourth error should say "did you mean 'N::foo'?" not 'concept foo'.

The fifth error is just nonsense, it *is* enclosed in parentheses. Could that
and the sixth error be suppressed after the earlier "did you mean"?

[Bug libstdc++/91057] Data race in locale(const locale&, Facet*) constructor

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Sorry for not testing on a target that defines _GLIBCXX_LONG_DOUBLE_COMPAT.
Your patch is approved for trunk, please go ahead and commit it.

[Bug target/92022] [8/9/10 Regression] ICE in alpha_handle_trap_shadows, at config/alpha/alpha.c:8847

[doko at debian dot org]

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

--- Comment #2 from Matthias Klose  ---
yes, that fixes it, at least with a cross compiler.  I don't have a native
build yet.

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #24 from Jakub Jelinek  ---
Shouldn't dse_optimize_redundant_stores be at least a little bit more
aggressive?
I mean on:
struct S { int a; char b; char c; char d; };
void foo (struct S);
void bar (void) { struct S s = {}; s.a = 0; s.b = 0; s.c = 0; s.d = 0; foo (s);
}
dse1 removes s.a = 0; but keeps the rest, dse2 removes s.b = 0; but keeps the
rest, dse3 removes s.c = 0; but still keeps s.d = 0; and only store-merging in
this case optimizes it, while e.g. in GCC 6 or 8 fre1 optimized this (GCC 9
fre1 no longer does).
So, rather than just walking immediate uses of the vdef, can't it under some
small limit keep walking the vdef-vuse chains, skip loads/stores that cannot
alias it, and when removing a redundant store keep looking after it (or, even
when not removing, such as s.a = 3; above, keep looking for stores to bytes
that don't overlap already non-zero ones)?
Or is it better to readd it in FRE after fixing whatever bugs it had that lead
to the removal?

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
The FRE redundant store removal went away in r273135 aka PR91091 fix.

[Bug c++/92045] New: [7 8 9 10 regression][C++11] valid alignas ignored with spurious warning

[wilco at gcc dot gnu.org]

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

Bug ID: 92045
   Summary: [7 8 9 10 regression][C++11] valid alignas ignored
with spurious warning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

Since GCC7 alignas no longer works correctly if the requested alignment is
larger than MAX_STACK_ALIGNMENT (which is 8 or 16 on most targets). This is
incorrect since the equivalent attribute aligned does the right thing.

#include 

int f1(int x)
{
  __attribute((aligned (64))) int arr[10];
  return arr[x];
}

int f2(int x)
{
  alignas(64) int arr[10];
  return arr[x];
}

align.c: In function 'int f2(int)':
align.c:11:25: warning: requested alignment 64 is larger than 16 [-Wattributes]
   alignas(64) int arr[10];

[Bug target/92022] [8/9/10 Regression] ICE in alpha_handle_trap_shadows, at config/alpha/alpha.c:8847

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Matthias Klose from comment #2)
> yes, that fixes it, at least with a cross compiler.  I don't have a native
> build yet.

I don't have access to alpha anymore, I can't bootstrap and regtest the patch
properly. There is a remote chance that the patch breaks bootstrap.

[Bug target/92022] [8/9/10 Regression] ICE in alpha_handle_trap_shadows, at config/alpha/alpha.c:8847

[doko at debian dot org]

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

--- Comment #4 from Matthias Klose  ---
see https://buildd.debian.org/status/logs.php?pkg=gcc-9&arch=alpha
the bootstrap succeeds, but the testsuite times out. That might be an unrelated
issue, but I can't tell.

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #25)
> The FRE redundant store removal went away in r273135 aka PR91091 fix.

I'll see whether I can do something about FRE.  Redundant store removal
there isn't a good fit and thus not easy to get semantically correct.

[Bug target/92022] [8/9/10 Regression] ICE in alpha_handle_trap_shadows, at config/alpha/alpha.c:8847

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Matthias Klose from comment #4)
> see https://buildd.debian.org/status/logs.php?pkg=gcc-9&arch=alpha
> the bootstrap succeeds, but the testsuite times out. That might be an
> unrelated issue, but I can't tell.

It looks good to me, I'll commit the patch (and the testcase) later today.

[Bug middle-end/92046] New: Command line options (that are per-functions) are affecting --params which are global.

[hubicka at gcc dot gnu.org]

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

Bug ID: 92046
   Summary: Command line options (that are per-functions) are
affecting --params which are global.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

There is code that sets various --param values defaults depending on
optimizations. (look for uses of maybe_set_param_value).
This is done only at startup and is not adjusted when command line options
change. For example

gcc -Ofast -flto t.c -c
gcc t.o -Og

will get -Og --param values while compiling functions from t.o which are
intended to be optimized with -Ofast

[Bug middle-end/92046] Command line options (that are per-functions) are affecting --params which are global.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-10
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I'll pick some.

[Bug middle-end/92046] Command line options (that are per-functions) are affecting --params which are global.

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 47014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47014&action=edit
prototype

Something like this.  Note the behavior changes if the user manually specifies
any of the parameters.  We'd need to add a maybe_get_and_adjust_param_value
that gets the unaltered value if the user specified it.  But for that we'd
have to hard pass-in global_options and global_options_set (or hardcode it
in params.c).  But then the behavior between -O2 and -O2 --param
max-stores-to-sink=2 would be different (even though that's the documented
default of the
--param) - which is btw the current behavior.  We could check against the
default value but that means the behavior is different if targets change the
param and the behavior differs between --param X=default and X=default-1
(drastically in the case of dropping to zero).

I think for the vectorizer the only problematic case is
PARAM_VECT_MAX_VERSION_FOR_ALIAS_CHECKS, the others are documented to be
turned off.  Likewise max-stores-to-sink.  So I made
vect-maxversion-for-alias-checks adjusted relatively with
-fvect-cost-model=cheap so a global changed
--param still has an effect.

[Bug middle-end/92016] [10 Regression] excess errors in Wstringop-overflow-17.c

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
I confirm this appeared with r276645

[Bug target/92047] New: [10 regression] aarch64 regressions after r276645

[clyon at gcc dot gnu.org]

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

Bug ID: 92047
   Summary: [10 regression] aarch64 regressions after r276645
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

After r276645, I've noticed regressions on aarch64:
FAIL: gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times ld1b\\tz[0-9]+.b, p[0-9]+/z, \\[x[0-9]+, x[0-9]+\\] 16
FAIL: gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times st1b\\tz[0-9]+.b, p[0-9]+, \\[x[0-9]+, x[0-9]+\\] 16
FAIL: gcc.target/aarch64/sve/reduc_strict_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tfadda\\ts[0-9]+, p[0-7], s[0-9]+, z[0-9]+\\.s 4
FAIL: gcc.target/aarch64/vect-ld1r-compile-fp.c scan-assembler
ld1r\\t{v[0-9]+.2d
FAIL: gcc.target/aarch64/vect-ld1r-compile.c scan-assembler ld1r\\t{v[0-9]+.2d
FAIL: gcc.target/aarch64/vect-ld1r-compile.c scan-assembler ld1r\\t{v[0-9]+.4h

[Bug target/92048] New: [10 regression] armeb regression after r276645

[clyon at gcc dot gnu.org]

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

Bug ID: 92048
   Summary: [10 regression] armeb regression after r276645
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed that r276645 introduced a regression on armeb:
FAIL: gcc.dg/vect/fast-math-vect-pr29925.c scan-tree-dump-times vect
"vectorized 1 loops" 1

maybe it's just a matter of skipping the test for this target?

[Bug middle-end/92037] [10 Regression] LTO bootstrap broken in selftests

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  ---
It is lifetime dse issue in symbol table construction. I am testing

* cgraph.c (symbol_table_test::symbol_table_test): Use ggc_alloc
rather than ggc_alloc_cleared to alloc symbol table.
* toplev.c (general_init): Likewise.
* cgraph.h (symbol_table): Explicitly construct every field.
Index: cgraph.c
===
--- cgraph.c(revision 276707)
+++ cgraph.c(working copy)
@@ -3835,7 +3832,7 @@ symbol_table_test::symbol_table_test ()
 {
   gcc_assert (saved_symtab == NULL);
   saved_symtab = symtab;
-  symtab = new (ggc_cleared_alloc  ()) symbol_table ();
+  symtab = new (ggc_alloc  ()) symbol_table ();
 }

 /* Destructor.  Restore the old value of symtab.  */
Index: toplev.c
===
--- toplev.c(revision 276707)
+++ toplev.c(working copy)
@@ -1170,7 +1170,7 @@ general_init (const char *argv0, bool in
   /* Create the passes.  */
   g->set_passes (new gcc::pass_manager (g));

-  symtab = new (ggc_cleared_alloc  ()) symbol_table ();
+  symtab = new (ggc_alloc  ()) symbol_table ();

   statistics_early_init ();
   debuginfo_early_init ();
Index: cgraph.h
===
--- cgraph.h(revision 276707)
+++ cgraph.h(working copy)
@@ -2095,9 +2095,19 @@ public:
   friend struct cgraph_node;
   friend struct cgraph_edge;

-  symbol_table (): cgraph_max_uid (1), cgraph_max_summary_id (0),
-  edges_max_uid (1), edges_max_summary_id (0),
-  cgraph_released_summary_ids (), edge_released_summary_ids ()
+  symbol_table (): 
+  cgraph_count (0), cgraph_max_uid (1), cgraph_max_summary_id (0),
+  edges_count (0), edges_max_uid (1), edges_max_summary_id (0),
+  cgraph_released_summary_ids (), edge_released_summary_ids (),
+  nodes (NULL), asmnodes (NULL), asm_last_node (NULL),
+  order (0), global_info_ready (false), state (PARSING),
+  function_flags_ready (false), cpp_implicit_aliases_done (false),
+  section_hash (NULL), assembler_name_hash (NULL), init_priority_hash (NULL),
+  dump_file (NULL), ipa_clones_dump_file (NULL), cloned_nodes (),
+  m_first_edge_removal_hook (NULL), m_first_cgraph_removal_hook (NULL),
+  m_first_edge_duplicated_hook (NULL), m_first_cgraph_duplicated_hook (NULL),
+  m_first_cgraph_insertion_hook (NULL), m_first_varpool_insertion_hook (NULL),
+  m_first_varpool_removal_hook (NULL)
   {
   }

@@ -2343,6 +2353,9 @@ public:
   /* Vector of released summary IDS for cgraph nodes.  */
   vec GTY ((skip)) edge_released_summary_ids;

+  /* Return symbol used to separate symbol name from suffix.  */
+  static char symbol_suffix_separator ();
+
   symtab_node* GTY(()) nodes;
   asm_node* GTY(()) asmnodes;
   asm_node* GTY(()) asm_last_node;
@@ -2372,9 +2385,6 @@ public:

   FILE* GTY ((skip)) dump_file;

-  /* Return symbol used to separate symbol name from suffix.  */
-  static char symbol_suffix_separator ();
-
   FILE* GTY ((skip)) ipa_clones_dump_file;

   hash_set  GTY ((skip)) cloned_nodes;

[Bug middle-end/92037] [10 Regression] LTO bootstrap broken in selftests

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Author: hubicka
Date: Thu Oct 10 13:04:44 2019
New Revision: 276804

URL: https://gcc.gnu.org/viewcvs?rev=276804&root=gcc&view=rev
Log:
PR middle-end/92037
* cgraph.c (symbol_table_test::symbol_table_test): Use ggc_alloc
rather than ggc_alloc_cleared to alloc symbol table.
* toplev.c (general_init): Likewise.
* cgraph.h (symbol_table): Explicitly construct every field.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/toplev.c

[Bug c++/92049] New: bogus errors with -fchecking=2

[mpolacek at gcc dot gnu.org]

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

Bug ID: 92049
   Summary: bogus errors with -fchecking=2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Several tests fail with bogus errors, at least

g++.dg/cpp0x/constexpr-ctor12.C g++.dg/cpp0x/constexpr-ctor13.C 
g++.dg/cpp0x/pr70538.C g++.dg/template/builtin1.C 
g++.dg/template/non-dependent14.C g++.dg/template/typeid1.C 
g++.dg/wrappers/pr83814.C

E.g.,

template struct cond;

template struct S {
  void f(int i) {
cond<__builtin_constant_p(i)>();
  }
};

S<1> s;

$ ./cc1plus -quiet builtin1.C -fchecking=2
builtin1.C: In member function ‘void S< >::f(int)’:
builtin1.C:7:5: error: invalid use of incomplete type ‘struct cond’
7 | cond<__builtin_constant_p(i)>();
  | ^~~
builtin1.C:3:23: note: declaration of ‘struct cond’
3 | template struct cond;
  |   ^~~~

[Bug c++/92049] bogus errors with -fchecking=2

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Started with the concepts merger r276764.

[Bug c++/92049] bogus errors with -fchecking=2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
-fchecking=2 enables the call to fold_non_dependent_expr in
build_non_dependent_expr:

  /* When checking, try to get a constant value for all non-dependent
 expressions in order to expose bugs in *_dependent_expression_p
 and constexpr.  This can affect code generation, see PR70704, so
 only do this for -fchecking=2.  */
  if (flag_checking > 1
  && cxx_dialect >= cxx11 
  /* Don't do this during nsdmi parsing as it can lead to
 unexpected recursive instantiations.  */
  && !parsing_nsdmi ()
  /* Don't do this during concept processing either and for
 the same reason.  */
  && !processing_constraint_expression_p ())
fold_non_dependent_expr (expr);

[Bug fortran/92050] New: internal compiler error: in gfc_conv_procedure_call

[rp83 at gmx dot com]

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

Bug ID: 92050
   Summary: internal compiler error: in gfc_conv_procedure_call
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rp83 at gmx dot com
  Target Milestone: ---

The module in the minimal working example below triggers an internal compiler
error when compiled with gfortran -fcheck=all.

- System: Ubuntu 18.04.3 LTS, 4.15.0-65-generic x86_64
- Command line that triggers the bug: gfortran -fcheck=all -c buggy.f95
- Regression: the bug is triggered when the code is compiled with gfortran
versions 9, 8, 7, but not with versions 5 and 6.

A few observations:
- Calling the function fun_par() directly rather than the binding "fun" does
not trigger the bug: 
  write(*,*) fun_par(this%m(1)%p, x)
- Defining "p" in "comp" using "type(par)" instead of "class(par)" does not
trigger the bug.
- Same bug when "p" is specified to be a pointer instead of an allocatable
vector.
- When the dimension of the result y in fun_par() is a scalar (y instead of
y(size(x))), the bug is not triggered.


MINIMAL WORKING EXAMPLE: buggy.f95

module buggy
  implicit none

  type :: par
  contains
procedure, public :: fun => fun_par
  end type par

  type comp
class(par), allocatable :: p
  end type comp

  type foo
type(comp), allocatable :: m(:)
  end type foo

contains

  function fun_par(this)
class(par) :: this
integer:: fun_par(1)
fun_par = 0
  end function fun_par

  subroutine update_foo(this)
class(foo) :: this
write(*,*) this%m(1)%p%fun()
  end subroutine update_foo

end module buggy


COMPILER OUTPUTS

The code was tested using gfortran versions 9, 8, 7, 6, and 5:

GNU Fortran (Ubuntu 9.2.1-8ubuntu1~18.04.york0) 9.2.1 20190909
GNU Fortran (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0
GNU Fortran (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
GNU Fortran (Ubuntu 6.5.0-2ubuntu1~18.04) 6.5.0 20181026
GNU Fortran (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010

using gfortran 5 and 6: no errors.

using gfortran 9, 8, and 7:

$ gfortran-9 -fcheck=all -c buggy.f95 
buggy.f95:27:0:

   27 | write(*,*) this%m(1)%p%fun()
  | 
internal compiler error: in gfc_conv_procedure_call, at
fortran/trans-expr.c:6785
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gfortran-8 -fcheck=all -c buggy.f95 
buggy.f95:27:0:

 write(*,*) this%m(1)%p%fun()

internal compiler error: in gfc_conv_procedure_call, at
fortran/trans-expr.c:6410
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gfortran-7 -fcheck=all -c buggy.f95 
buggy.f95:27:0:

 write(*,*) this%m(1)%p%fun()

internal compiler error: in gfc_conv_procedure_call, at
fortran/trans-expr.c:6290
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/92046] Command line options (that are per-functions) are affecting --params which are global.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |10.0

--- Comment #3 from Richard Biener  ---
Some tackled, will try to tackle those depending on -On as well.

[Bug middle-end/92046] Command line options (that are per-functions) are affecting --params which are global.

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 10 14:02:25 2019
New Revision: 276807

URL: https://gcc.gnu.org/viewcvs?rev=276807&root=gcc&view=rev
Log:
2019-10-10  Richard Biener  

PR middle-end/92046
* opts.c (finish_options): Do not influence global --params
from options that are adjustable per function.
* tree-vect-data-refs.c (vect_enhance_data_refs_alignment):
Apply --param adjustment based on active cost-model.
* tree-ssa-phiopt.c (cond_if_else_store_replacement): Disable
further store-sinking when vectorization or if-conversion
are not enabled.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c
trunk/gcc/tree-ssa-phiopt.c
trunk/gcc/tree-vect-data-refs.c

[Bug target/91796] Sub-optimal YMM register allocation.

[maxim.yegorushkin at gmail dot com]

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

--- Comment #3 from Maxim Egorushkin  ---
It seems to me that register allocation has been a weak spot in gcc for years. 

gcc often allocates registers in such a way that extra register moves are
necessary, compared to competition, like in this particular case. The extra
register moves could be 0 cost to execute due to hardware register renaming,
but they still waste CPU instruction decoder and cache resources. 

Whereas I haven't seen such cases with clang at all, but I don't use it as much
as gcc. I wonder why gcc register allocation cannot be at least as good as
clang's.

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[iii at linux dot ibm.com]

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

Ilya Leoshkevich  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Ilya Leoshkevich  ---
I'm happy with x86 and spec improvements; the latter has also helped me to make
progress with S/390 implementation of signaling comparisons. Thanks!

[Bug c++/92049] bogus errors with -fchecking=2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-10
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
The complete set of tests I saw fail in my build yesterday is:

!  FAIL: g++.dg/cpp0x/constexpr-ctor12.C (1: +1)
!  FAIL: g++.dg/cpp0x/constexpr-ctor13.C (1: +1)
!  FAIL: g++.dg/cpp0x/pr70538.C (3: +3)
!  FAIL: g++.dg/template/builtin1.C (3: +3)
!  FAIL: g++.dg/template/non-dependent14.C (3: +3)
!  FAIL: g++.dg/template/typeid1.C (3: +3)
!  FAIL: g++.dg/torture/Wsizeof-pointer-memaccess2.C (2: +2)
!  FAIL: g++.dg/wrappers/pr83814.C (3: +3)

[Bug target/92051] New: Many aarch64 SVE tests fail with ICE (expected integer_cst, have poly_int_cst in to_wide)

[sje at gcc dot gnu.org]

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

Bug ID: 92051
   Summary: Many aarch64 SVE tests fail  with ICE  (expected
integer_cst, have poly_int_cst in to_wide)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

I am seeing several hundred aarch64 sve tests fail with an ICE since Oct 8,
2019. One such failure is gcc.target/aarch64/sve/while_1.c, the ICE is:

0x6150f7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9924
0x679e13 tree_int_cst_elt_check(tree_node const*, int, char const*, int, char
const*)
../../gcc/gcc/tree.h:3455
0x679e13 wi::to_wide(tree_node const*)
../../gcc/gcc/tree.h:5795
0xe89417 value_range_base::lower_bound(unsigned int) const
../../gcc/gcc/tree-vrp.c:6136
0xe8954f value_range_base::lower_bound(unsigned int) const
../../gcc/gcc/tree-vrp.c:6123
0x1412203 range_operator::fold_range(tree_node*, value_range_base const&,
value_range_base const&) const
../../gcc/gcc/range-op.cc:156
0xe92287 range_fold_binary_expr(value_range_base*, tree_code, tree_node*,
value_range_base const*, value_range_base const*)
../../gcc/gcc/tree-vrp.c:1915
0xf0ba47 vr_values::extract_range_from_binary_expr(value_range*, tree_code,
tree_node*, tree_node*, tree_node*)
../../gcc/gcc/vr-values.c:808
0xf126cf vr_values::extract_range_from_assignment(value_range*, gassign*)
../../gcc/gcc/vr-values.c:1466
0x1357e73 evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool)
../../gcc/gcc/gimple-ssa-evrp-analyze.c:307
0xd213e7 dom_opt_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-dom.c:1503
0x1331f3f dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:309
0xd2099f execute^M
../../gcc/gcc/tree-ssa-dom.c:724
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions

[Bug target/88630] Incorrect float negating together with convertion to int on ST-40

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo  ---
Author: olegendo
Date: Thu Oct 10 15:21:27 2019
New Revision: 276809

URL: https://gcc.gnu.org/viewcvs?rev=276809&root=gcc&view=rev
Log:
gcc/
PR target/88630
* config/sh/sh.h (TARGET_FPU_SH4_300): New macro.
* config/sh/sh.c (sh_option_override): Enable fsca and fsrra insns
also for TARGET_FPU_SH4_300.
(sh_emit_mode_set): Check for TARGET_FPU_SH4_300 instead of
TARGET_SH4_300.
* config/sh/sh.md (toggle_pr): Add TARGET_FPU_SH4_300 condition.
(negsf2): Expand to either negsf2_fpscr or negsf2_no_fpscr.
(*negsf2_i): Split into ...
(negsf2_fpscr, negsf2_no_fpscr): ... these new patterns.
(abssf2): Expand to either abssf2_fpsc or abssf2_no_fpsc.
(**abssf2_i): Split into ...
(abssf2_fpscr, abssf2_no_fpscr): ... these new patterns.
(negdf2): Expand to either negdf2_fpscr or negdf2_no_fpscr.
(*negdf2_i): Split into ...
(negdf2_fpscr, negdf2_no_fpscr): ... these new patterns.
(absdf2): Expand to either absdf2_fpscr or absdf2_no_fpsc.
(**abssf2_i): Split into ...
(absdf2_fpscr, absdf2_no_fpscr): ... these new patterns.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.h
trunk/gcc/config/sh/sh.md

[Bug c++/92052] New: No message for adding the noreturn attribute only after the first declaration

[hstong at ca dot ibm.com]

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

Bug ID: 92052
   Summary: No message for adding the noreturn attribute only
after the first declaration
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

Given the following:
void f(void), f [[noreturn]](void);

GCC does not produce any message (even with -std=c++11 -pedantic -Wall -Wextra)
with respect to C++11 subclause 7.6.3 [dcl.attr.noreturn] paragraph 1:

The first declaration of a function shall specify the `noreturn` attribute if
any declaration of that function specifies the `noreturn` attribute.

### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -std=c++11 -pedantic -Wall -Wextra -xc++ -


### ACTUAL OUTPUT:
(No messages; rc=0).


### EXPECTED OUTPUT:
(Warning or error).


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-9.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-9.2.0/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9.2.0/configure --prefix=/opt/wandbox/gcc-9.2.0
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-9.2.0/lib,-rpath,/opt/wandbox/gcc-9.2.0/lib64,-rpath,/opt/wandbox/gcc-9.2.0/lib32
--enable-lto
Thread model: posix
gcc version 9.2.0 (GCC)

[Bug target/88630] Incorrect float negating together with convertion to int on ST-40

[olegendo at gcc dot gnu.org]

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

--- Comment #15 from Oleg Endo  ---
Author: olegendo
Date: Thu Oct 10 15:24:05 2019
New Revision: 276825

URL: https://gcc.gnu.org/viewcvs?rev=276825&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2019-10-10  Oleg Endo  

PR target/88630
* config/sh/sh.h (TARGET_FPU_SH4_300): New macro.
* config/sh/sh.c (sh_option_override): Enable fsca and fsrra insns
also for TARGET_FPU_SH4_300.
(sh_emit_mode_set): Check for TARGET_FPU_SH4_300 instead of
TARGET_SH4_300.
* config/sh/sh.md (toggle_pr): Add TARGET_FPU_SH4_300 condition.
(negsf2): Expand to either negsf2_fpscr or negsf2_no_fpscr.
(*negsf2_i): Split into ...
(negsf2_fpscr, negsf2_no_fpscr): ... these new patterns.
(abssf2): Expand to either abssf2_fpsc or abssf2_no_fpsc.
(**abssf2_i): Split into ...
(abssf2_fpscr, abssf2_no_fpscr): ... these new patterns.
(negdf2): Expand to either negdf2_fpscr or negdf2_no_fpscr.
(*negdf2_i): Split into ...
(negdf2_fpscr, negdf2_no_fpscr): ... these new patterns.
(absdf2): Expand to either absdf2_fpscr or absdf2_no_fpsc.
(**abssf2_i): Split into ...
(absdf2_fpscr, absdf2_no_fpscr): ... these new patterns.


Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/sh/sh.c
branches/gcc-9-branch/gcc/config/sh/sh.h
branches/gcc-9-branch/gcc/config/sh/sh.md

[Bug c++/92052] No message for adding the noreturn attribute only after the first declaration

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Marek Polacek  ---
I've fixed this in GCC 10:

$ xg++ -c 92052.C
92052.C:1:15: error: function ‘void f()’ declared ‘[[noreturn]]’ but its first
declaration was not
1 | void f(void), f [[noreturn]](void);
  |   ^
92052.C:1:6: note: previous declaration of ‘void f()’
1 | void f(void), f [[noreturn]](void);
  |  ^

[Bug target/88630] Incorrect float negating together with convertion to int on ST-40

[olegendo at gcc dot gnu.org]

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

--- Comment #16 from Oleg Endo  ---
Author: olegendo
Date: Thu Oct 10 15:28:31 2019
New Revision: 276837

URL: https://gcc.gnu.org/viewcvs?rev=276837&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2019-10-10  Oleg Endo  

PR target/88630
* config/sh/sh.h (TARGET_FPU_SH4_300): New macro.
* config/sh/sh.c (sh_option_override): Enable fsca and fsrra insns
also for TARGET_FPU_SH4_300.
(sh_emit_mode_set): Check for TARGET_FPU_SH4_300 instead of
TARGET_SH4_300.
* config/sh/sh.md (toggle_pr): Add TARGET_FPU_SH4_300 condition.
(negsf2): Expand to either negsf2_fpscr or negsf2_no_fpscr.
(*negsf2_i): Split into ...
(negsf2_fpscr, negsf2_no_fpscr): ... these new patterns.
(abssf2): Expand to either abssf2_fpsc or abssf2_no_fpsc.
(**abssf2_i): Split into ...
(abssf2_fpscr, abssf2_no_fpscr): ... these new patterns.
(negdf2): Expand to either negdf2_fpscr or negdf2_no_fpscr.
(*negdf2_i): Split into ...
(negdf2_fpscr, negdf2_no_fpscr): ... these new patterns.
(absdf2): Expand to either absdf2_fpscr or absdf2_no_fpsc.
(**abssf2_i): Split into ...
(absdf2_fpscr, absdf2_no_fpscr): ... these new patterns.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/sh/sh.c
branches/gcc-8-branch/gcc/config/sh/sh.h
branches/gcc-8-branch/gcc/config/sh/sh.md

[Bug target/88630] Incorrect float negating together with convertion to int on ST-40

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Oleg Endo  ---
Fixed on trunk (GCC 10), GCC 9, GCC 8.

Thanks for reporting and testing!

[Bug libstdc++/91057] Data race in locale(const locale&, Facet*) constructor

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
There's another problem. I'm testing the fix now.

[Bug c++/92053] New: Compilation fails or succeeds depending on the optimization flags

[antoshkka at gmail dot com]

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

Bug ID: 92053
   Summary: Compilation fails or succeeds depending on the
optimization flags
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the following code:

#include 
#include 
#include 

struct widget;
using variant_t = std::variant;

struct my_func {
my_func(variant_t&& arg) {
std::make_unique(std::move(arg));
}
};

struct widget {};
my_func f({});


With `-std=c++2a -O0` it compiles. With `-std=c++2a -O2` it fails on a static
assert in instantiation of 'struct std::is_default_constructible'. 

Godbolt playground: https://godbolt.org/z/-d26aG

[Bug target/92022] [8/9/10 Regression] ICE in alpha_handle_trap_shadows, at config/alpha/alpha.c:8847

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Oct 10 16:11:10 2019
New Revision: 276839

URL: https://gcc.gnu.org/viewcvs?rev=276839&root=gcc&view=rev
Log:
PR target/92022
* config/alpha/alpha.c (alpha_handle_trap_shadows): Skip DEBUG_INSN.

testsuite/ChangeLog:

PR target/92022
* g++.dg/pr92022.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/pr92022.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/alpha/alpha.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/91057] Data race in locale(const locale&, Facet*) constructor

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
That should be fixed at r276840

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 10 16:16:17 2019
New Revision: 276840

URL: https://gcc.gnu.org/viewcvs?rev=276840&root=gcc&view=rev
Log:
PR libstdc++/91057 fix bootstrap failure on powerpc

PR libstdc++/91057
* src/c++98/locale.cc [_GLIBCXX_LONG_DOUBLE_COMPAT]
(find_ldbl_sync_facet): Fix parameter type and missing return.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++98/locale.cc

[Bug libstdc++/91057] Data race in locale(const locale&, Facet*) constructor

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
That should be fixed at r276840

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 10 16:16:17 2019
New Revision: 276840

URL: https://gcc.gnu.org/viewcvs?rev=276840&root=gcc&view=rev
Log:
PR libstdc++/91057 fix bootstrap failure on powerpc

PR libstdc++/91057
* src/c++98/locale.cc [_GLIBCXX_LONG_DOUBLE_COMPAT]
(find_ldbl_sync_facet): Fix parameter type and missing return.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++98/locale.cc

[Bug target/91796] Sub-optimal YMM register allocation.

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Since fwprop.c has

static rtx
propagate_rtx (rtx x, machine_mode mode, rtx old_rtx, rtx new_rtx,
   bool speed)
{
  rtx tem;
  bool collapsed;
  int flags;

  if (REG_P (new_rtx) && REGNO (new_rtx) < FIRST_PSEUDO_REGISTER)
return NULL_RTX;

it doesn't propagate V4DF 20 xmm0 from

(insn 2 5 3 2 (set (reg/v:V4DF 85 [ from ])
(reg:V4DF 20 xmm0 [ from ])) "/tmp/bad.c":3:52 1261 {movv4df_internal}
 (expr_list:REG_DEAD (reg:V4DF 20 xmm0 [ from ])
(nil)))

to

(insn 11 8 13 2 (set (reg:V4DF 89)
(and:V4DF (reg:V4DF 88)
(reg/v:V4DF 85 [ from ]))) "./include/avxintrin.h":168:10 1877
{*andv4df3}
 (expr_list:REG_DEAD (reg:V4DF 88)
(expr_list:REG_DEAD (reg/v:V4DF 85 [ from ])
(nil

Can we propagate hard register here?

[Bug target/91796] Sub-optimal YMM register allocation.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Wasn't the whole point of Segher's combiner changes not to propagate hard
registers into instructions to leave the RA more in control?
Propagating something in some other pass would undo that change.

[Bug c++/92054] New: `final` does not cause devirtualization of nested calls

[antoshkka at gmail dot com]

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

Bug ID: 92054
   Summary: `final` does not cause devirtualization of nested
calls
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:


struct A {
virtual int f() { return 0; }
virtual int g() { return f() + 40; } 
};

struct B2 final : A {
int f() override { return 42; }
};

int test(B2& b) {
return b.g();
}


GCC-10 generates the assembly that does a fair vptr call. However, `B2` is
final, so any call to the virtual functions of `A` end up with a call to the
same function in `B2`. So `B2::g()` should inline the `A::g()` and get
optimized to:

int test(B2& b) { return B2::f() + 40; }


Which is just 82, because `B2::f()` always returns 42.

Godbolt playground: https://godbolt.org/z/PJ4nL-

[Bug c++/92045] [7/8/9/10 regression][C++11] valid alignas ignored with spurious warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 89357.

*** This bug has been marked as a duplicate of bug 89357 ***

[Bug c++/89357] alignas for automatic variables with alignment greater than 16 fails

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
*** Bug 92045 has been marked as a duplicate of this bug. ***

[Bug c++/58601] [meta-bug] alignas

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58601
Bug 58601 depends on bug 92045, which changed state.

Bug 92045 Summary: [7/8/9/10 regression][C++11] valid alignas ignored with 
spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92045

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug target/92055] New: [avr] Support 64-bit double

[gjl at gcc dot gnu.org]

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

Bug ID: 92055
   Summary: [avr] Support 64-bit double
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Enhancement to support IEEE compatible double.

[Bug target/92055] [avr] Support 64-bit double

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 47015
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47015&action=edit
Proposed extension.

[Bug c++/89357] [7/8/9/10 regression][C++11] alignas for automatic variables with alignment greater than 16 fails

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

Summary|alignas for automatic   |[7/8/9/10
   |variables with alignment|regression][C++11] alignas
   |greater than 16 fails   |for automatic variables
   ||with alignment greater than
   ||16 fails

--- Comment #5 from Wilco  ---
(In reply to Andrew Pinski from comment #4)
> *** Bug 92045 has been marked as a duplicate of this bug. ***

[Bug target/91796] Sub-optimal YMM register allocation.

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
And as for the constant, seems ICC also emits just constant load from memory
instead of trying two instructions instead and clang, while it uses broadcast
to save .rodata, doesn't use two instructions either:
https://godbolt.org/z/MekI1X

[Bug c/87488] hyperlink filenames in diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
Author: dmalcolm
Date: Thu Oct 10 16:57:30 2019
New Revision: 276841

URL: https://gcc.gnu.org/viewcvs?rev=276841&root=gcc&view=rev
Log:
pretty-print: support URL escape sequences (PR 87488)

https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
describes an emerging standard for embedding URLs in escape sequences
for marking up text output.  This is supported e.g. by recent releases
of GNOME Terminal.

This patch adds support to our pretty-printing framework for emitting
URLs.

A followup patch uses this to add URLs to the pertinent documentation
for the output of -fdiagnostics-show-option.

gcc/ChangeLog:
PR 87488
* common.opt (fdiagnostics-urls=): New option.
(diagnostic-url.h): Add SourceInclude.
(diagnostic_url_rule): New enum.
* diagnostic-color.c: Include "diagnostic-url.h".
(diagnostic_urls_enabled_p): New function.
* diagnostic-url.h: New file.
* diagnostic.c: Include "diagnostic-url.h".
(diagnostic_urls_init): New function.
* diagnostic.h (diagnostic_urls_init): New decl.
* doc/invoke.texi (Diagnostic Message Formatting Options): Add
-fdiagnostics-urls to the list.
(-fdiagnostics-urls): New option.
* gcc.c (driver_handle_option): Handle OPT_fdiagnostics_urls_.
(driver::global_initializations): Call diagnostic_urls_init.
* opts-global.c (init_options_once): Likewise.
* opts.c (common_handle_option): Handle OPT_fdiagnostics_urls_.
* pretty-print.c (pretty_printer::pretty_printer): Initialize
show_urls.
(pp_begin_url): New function.
(pp_end_url): New function.
(selftest::test_urls): New selftest.
(selftest::pretty_print_c_tests): Call it.
* pretty-print.h (pretty_printer::show_urls): New field.
(pp_begin_url): New decl.
(pp_end_url): New decl.

gcc/testsuite/ChangeLog:
PR 87488
* lib/prune.exp (TEST_ALWAYS_FLAGS): Add -fdiagnostics-urls=never.


Added:
trunk/gcc/diagnostic-url.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/diagnostic-color.c
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/doc/invoke.texi
trunk/gcc/gcc.c
trunk/gcc/opts-global.c
trunk/gcc/opts.c
trunk/gcc/pretty-print.c
trunk/gcc/pretty-print.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/prune.exp

[Bug fortran/92050] internal compiler error: in gfc_conv_procedure_call

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #1 from kargl at gcc dot gnu.org ---
The ICE is caused by an assert() in the code.  Lines 7020-7035 in
trans-expr.c are the following:

  if (args && args->expr && args->expr->ts.type == BT_CLASS
  && sym->ts.type == BT_CLASS && result != NULL_TREE && DECL_P (result)
  && !GFC_CLASS_TYPE_P (TREE_TYPE (result)))
{
  gfc_se parmse;
  gfc_expr *class_expr = gfc_find_and_cut_at_last_class_ref (args->expr);

  gfc_init_se (&parmse, NULL);
  gfc_conv_expr (&parmse, class_expr);
  if (!DECL_LANG_SPECIFIC (result))
gfc_allocate_lang_decl (result);
  GFC_DECL_SAVED_DESCRIPTOR (result) = parmse.expr;
  gfc_free_expr (class_expr);
//  gcc_assert (parmse.pre.head == NULL_TREE
//&& parmse.post.head == NULL_TREE);
}

Commenting out the assert allows the code to compile with
-fcheck=bounds.  The code was added in revision 241439 by
Andre Vehreschild on 2016-10-22.  Andre, the assert be 
removed or hidden behind flag_bounds_check?

[Bug target/77918] S390: Floating point comparisons don't raise invalid for unordered operands.

[iii at gcc dot gnu.org]

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

--- Comment #8 from iii at gcc dot gnu.org ---
Author: iii
Date: Thu Oct 10 17:00:29 2019
New Revision: 276842

URL: https://gcc.gnu.org/viewcvs?rev=276842&root=gcc&view=rev
Log:
[PATCH 1/3] S/390: Do not use signaling vector comparisons on z13

z13 supports only non-signaling vector comparisons.  This means we
cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.  Notify
middle-end about this by using more restrictive operator predicate in
vcond.

gcc/ChangeLog:

2019-10-10  Ilya Leoshkevich  

PR target/77918
* config/s390/vector.md (vcond_comparison_operator): New
predicate.
(vcond): Use vcond_comparison_operator.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/vector.md

[Bug c/87488] hyperlink filenames in diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #10 from David Malcolm  ---
Author: dmalcolm
Date: Thu Oct 10 17:03:46 2019
New Revision: 276843

URL: https://gcc.gnu.org/viewcvs?rev=276843&root=gcc&view=rev
Log:
Documentation hyperlinks for [-Wname-of-option] (PR 87488)

This patch uses the support for pretty-printing escaped URLs added in
the previous patch (PR 87488) so that in a sufficiently capable terminal
the [-Wname-of-option] emitted at the end of each diagnostic becomes a
hyperlink to the documentation for that option on the GCC website.

I've tested it with Fedora 30's GNOME Terminal (3.32.2 with VTE 0.56.3);
the option text is printed with a dotted underline, hovering shows the
URL, and on right-clicking it offers menu items to visit/copy the URL.

gcc/ChangeLog:
PR 87488
* Makefile.in (CFLAGS-opts.o): Pass in DOCUMENTATION_ROOT_URL via
-D.
* configure.ac (--with-documentation-root-url): New option.
* configure: Regenerate.
* diagnostic-format-json.cc (json_end_diagnostic): If there is an
option URL, add it as a new string field of the diagnostic option.
* diagnostic.c (diagnostic_initialize): Initialize get_option_url.
(print_option_information): If get_option_url is non-NULL, call
it, and if the result is non-NULL, potentially emit an escape
sequence to markup the option text with the resulting URL.
* diagnostic.h (diagnostic_context::get_option_url): New callback.
* doc/invoke.texi (-fdiagnostics-format=): Add "option_url" to
example of JSON output.
* opts-diagnostic.h (get_option_url): New decl.
* opts.c (get_option_url): New function.
* toplev.c (general_init): Initialize the get_option_url callback.

gcc/testsuite/ChangeLog:
PR 87488
* c-c++-common/diagnostic-format-json-2.c: Expect an "option_url"
field.
* c-c++-common/diagnostic-format-json-3.c: Likewise.
* gfortran.dg/diagnostic-format-json-2.F90: Likewise.
* gfortran.dg/diagnostic-format-json-3.F90: Likewise.
* jit.dg/test-error-array-bounds.c (create_code): Ensure that
error messages don't contain escaped URLs.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/diagnostic-format-json.cc
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/doc/invoke.texi
trunk/gcc/opts-diagnostic.h
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/diagnostic-format-json-2.c
trunk/gcc/testsuite/c-c++-common/diagnostic-format-json-3.c
trunk/gcc/testsuite/c-c++-common/diagnostic-format-json-4.c
trunk/gcc/testsuite/gfortran.dg/diagnostic-format-json-2.F90
trunk/gcc/testsuite/gfortran.dg/diagnostic-format-json-3.F90
trunk/gcc/testsuite/jit.dg/test-error-array-bounds.c
trunk/gcc/toplev.c

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||wilco at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #17 from Wilco  ---
Not a GCC bug, just a gmp configuration oddity.

[Bug c/87488] hyperlink filenames in diagnostics

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #11 from David Malcolm  ---
r276841 implements URL support within pretty_printer.

r276843 uses this to implement hyperlinks to our documentation for the
[-Wname-of-option] text in our diagnostics.

I'm still not convinced that we should do this for filenames (based on the
objections in comment #3), so I'm going to mark this bug as resolved.

[Bug fortran/92050] internal compiler error: in gfc_conv_procedure_call

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
This patch allows the code to compile, but I have no idea
if it is correct.

Index: trans-expr.c
===
--- trans-expr.c(revision 276837)
+++ trans-expr.c(working copy)
@@ -7031,8 +7031,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym
gfc_allocate_lang_decl (result);
   GFC_DECL_SAVED_DESCRIPTOR (result) = parmse.expr;
   gfc_free_expr (class_expr);
-  gcc_assert (parmse.pre.head == NULL_TREE
- && parmse.post.head == NULL_TREE);
+  if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+ && parmse.pre.head == NULL_TREE)
+   gcc_unreachable ();
+  gcc_assert (parmse.post.head == NULL_TREE);
 }

   /* Follow the function call with the argument post block.  */

[Bug fortran/92050] internal compiler error: in gfc_conv_procedure_call

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Thu, Oct 10, 2019 at 05:25:10PM +, sgk at troutmask dot
apl.washington.edu wrote:
> --- Comment #2 from Steve Kargl  ---
> This patch allows the code to compile, but I have no idea
> if it is correct.
> 
> Index: trans-expr.c
> ===
> --- trans-expr.c(revision 276837)
> +++ trans-expr.c(working copy)
> @@ -7031,8 +7031,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym
> gfc_allocate_lang_decl (result);
>GFC_DECL_SAVED_DESCRIPTOR (result) = parmse.expr;
>gfc_free_expr (class_expr);
> -  gcc_assert (parmse.pre.head == NULL_TREE
> - && parmse.post.head == NULL_TREE);
> +  if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
> + && parmse.pre.head == NULL_TREE)
> +   gcc_unreachable ();
> +  gcc_assert (parmse.post.head == NULL_TREE);
>  }

Bummer patch causes regression.  The only fix seems to
be to remove the assert that parmse.pre.head == NULL_TREE.

[Bug target/92022] [8/9/10 Regression] ICE in alpha_handle_trap_shadows, at config/alpha/alpha.c:8847

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Oct 10 17:45:40 2019
New Revision: 276844

URL: https://gcc.gnu.org/viewcvs?rev=276844&root=gcc&view=rev
Log:
PR target/92022
* config/alpha/alpha.c (alpha_handle_trap_shadows): Skip DEBUG_INSN.

testsuite/ChangeLog:

PR target/92022
* g++.dg/pr92022.C: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/pr92022.C
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/alpha/alpha.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug target/92022] [8/9/10 Regression] ICE in alpha_handle_trap_shadows, at config/alpha/alpha.c:8847

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Oct 10 17:58:24 2019
New Revision: 276845

URL: https://gcc.gnu.org/viewcvs?rev=276845&root=gcc&view=rev
Log:
PR target/92022
* config/alpha/alpha.c (alpha_handle_trap_shadows): Skip DEBUG_INSN.

testsuite/ChangeLog:

PR target/92022
* g++.dg/pr92022.C: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/pr92022.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/alpha/alpha.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c/92056] New: ice in expr_object_size, at tree-object-si ze.c:675 with -O3

[dcb314 at hotmail dot com]

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

Bug ID: 92056
   Summary: ice in expr_object_size, at tree-object-si ze.c:675
with -O3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 47016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47016&action=edit
C source code

The attached C code, when compiled by -O3, does this:

cgenl.c: In function ‘ncglex’:
ncgenl.c:1752:5: internal compiler error: in expr_object_size, at
tree-object-si
ze.c:675
0x6bc6ff expr_object_size
../../trunk/gcc/tree-object-size.c:675
0xe500c1 cond_expr_object_size
../../trunk/gcc/tree-object-size.c:909
0xe500c1 collect_object_sizes_for
../../trunk/gcc/tree-object-size.c:987
0xe4dfe8 compute_builtin_object_size(tree_node*, int, unsigned long*,
tree_node*
*)
../../trunk/gcc/tree-object-size.c:578

The problem seems to start between 276750 and 276800. I'll
have my usual go at reducing the code.

[Bug target/92041] m68k optimizations (-O2, -O3 or -Ofast) generates wrong code

[djipi.mari at gmail dot com]

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

Jean-Paul Mari  changed:

   What|Removed |Added

  Known to work||8.3.0
  Known to fail||9.1.0

--- Comment #2 from Jean-Paul Mari  ---
Following the bug 78074 fix workaround (-fno-builtin) generates a correct
assembly now. Thank you for the hint.

[Bug target/92022] [8/9/10 Regression] ICE in alpha_handle_trap_shadows, at config/alpha/alpha.c:8847

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #9 from Uroš Bizjak  ---
Fixed everywhere.

[Bug middle-end/91691] Cross compiling glibc produces a false maybe-uninitialized error

[alistair at alistair23 dot me]

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

--- Comment #4 from Alistair  ---
Thanks for looking into this Jim. We have worked around it in glibc master, so
that's fine that it can't be back ported. I'm glad it has been fixed in the
latest version.

[Bug libstdc++/92057] New: variant converting constructor fails for primitives

[pj at patrickjohnston dot org]

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

Bug ID: 92057
   Summary: variant converting constructor fails for primitives
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pj at patrickjohnston dot org
  Target Milestone: ---

Minimal testcase: https://wandbox.org/permlink/hzzjBrpCVZ4Cvwf8 (includes
output of gcc -v).

The problem did not exist in v9.2.0

[Bug middle-end/26241] [7/8/9/10 Regression] None of the IPA passes are documented in passes.texi

[sandra at gcc dot gnu.org]

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

--- Comment #20 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Oct 10 19:44:26 2019
New Revision: 276851

URL: https://gcc.gnu.org/viewcvs?rev=276851&root=gcc&view=rev
Log:
2019-10-10  Xiong Hu Luo  
Sandra Loosemore  

gcc/

PR middle-end/26241
* doc/lto.texi (IPA): Reference to the IPA passes.
* doc/passes.texi (Pass manager): Add node IPA passes and
  description for each IPA pass.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/lto.texi
trunk/gcc/doc/passes.texi

[Bug tree-optimization/92056] [10 Regression] ice in expr_object_size, at tree-object-si ze.c:675 with -O3

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-10
 CC||msebor at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|ice in expr_object_size, at |[10 Regression] ice in
   |tree-object-si ze.c:675 |expr_object_size, at
   |with -O3|tree-object-si ze.c:675
   ||with -O3
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Most likely caused by r276773.

during GIMPLE pass: strlen
In file included from ncgen.y:921:
ncgenl.c:1752:5: internal compiler error: in expr_object_size, at
tree-object-size.c:676
0x13635b1 expr_object_size
/src/gcc/svn/gcc/tree-object-size.c:675
0x136435e cond_expr_object_size
/src/gcc/svn/gcc/tree-object-size.c:909
0x13646b9 collect_object_sizes_for
/src/gcc/svn/gcc/tree-object-size.c:987
0x1362f3f compute_builtin_object_size(tree_node*, int, unsigned long*,
tree_node**)
/src/gcc/svn/gcc/tree-object-size.c:578
0x15430ae determine_min_objsize
/src/gcc/svn/gcc/tree-ssa-strlen.c:3387
0x15435e8 get_len_or_size
/src/gcc/svn/gcc/tree-ssa-strlen.c:3513
0x154367a strxcmp_eqz_result
/src/gcc/svn/gcc/tree-ssa-strlen.c:3540
0x1543d8c handle_builtin_string_cmp
/src/gcc/svn/gcc/tree-ssa-strlen.c:3727
0x15463b1 strlen_check_and_optimize_call
/src/gcc/svn/gcc/tree-ssa-strlen.c:4654
0x1546d42 check_and_optimize_stmt
/src/gcc/svn/gcc/tree-ssa-strlen.c:4794
0x1547878 strlen_dom_walker::before_dom_children(basic_block_def*)
/src/gcc/svn/gcc/tree-ssa-strlen.c:5021
0x2063f44 dom_walker::walk(basic_block_def*)
/src/gcc/svn/gcc/domwalk.c:309
0x1547b4c printf_strlen_execute
/src/gcc/svn/gcc/tree-ssa-strlen.c:5087
0x1547de2 execute
/src/gcc/svn/gcc/tree-ssa-strlen.c:5189

[Bug c++/92058] constinit disregards non-constexpr constructor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-10
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Mine.

[Bug c++/92058] New: constinit disregards non-constexpr constructor

[mpolacek at gcc dot gnu.org]

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

Bug ID: 92058
   Summary: constinit disregards non-constexpr constructor
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

struct B {
B() {}
};

struct A {
constexpr static inline B b2{};
constinit static inline B b1{};
};

int main() {
A a;
}

Here b2 fails but b1 succeeds.

[Bug c++/92059] New: Crash on tr2::dynamic_bitset::operator=() with optimization

[jharris at simplexinvestments dot com]

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

Bug ID: 92059
   Summary: Crash on tr2::dynamic_bitset::operator=() with
optimization
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jharris at simplexinvestments dot com
  Target Milestone: ---

Created attachment 47017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47017&action=edit
Self-contained preprocesor output file

On CentOS7 x86_64, gcc 8.3.1, this simple program (.ii attached) causes a crash
on execution when built with any level of optimization greater than -O0.  It
seems to be in the vector assignment, but that works fine
outside of tr2::dynamic_bitset.

It also works fine if you specify a template parameter of uint8_t.  Both
valgrind and asan complain loudly on execution, and it throws a bad_alloc() as
the code is shown.

I used the latest source (for tr2::dynamic_bitset) from github, but it's the
same result as that found with the compiler distribution (devtoolset-8).

#define _GLIBCXX_NODISCARD [[nodiscard]]
#include "./dynamic_bitset"

int main()
{
  std::tr2::dynamic_bitset<> b1(1), b2(1);
  b2 = b1; // crash
  return 0;
}

Compiled with 
gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)
g++ -O3 --std=c++17 main.ii -o main

$ ./main
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

g++ -O1 --std=c++17 main.ii -o main
$ ./main
Segmentation fault (core dumped)

[Bug tree-optimization/92056] [10 Regression] ice in expr_object_size, at tree-object-si ze.c:675 with -O3

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Reduced code is:

a, b, c;
*d;
e() {
  switch (c) {
  case 33:
for (;; d++)
  if (strcmp(b ?: "", d))
return;
  case 4:
sprintf("", a);
  }
}

[Bug c/87488] hyperlink filenames in diagnostics

[egmont at gmail dot com]

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

Egmont Koblinger  changed:

   What|Removed |Added

 CC||egmont at gmail dot com

--- Comment #12 from Egmont Koblinger  ---
(In reply to Jonathan Wakely from comment #3) 

> [the spec] says there should be a hostname part, so not just
> file:///path but file://hostname/path

Yes. The exact reason for this design is that it can be detected when the
filename belongs to a remote host and not mistakenly open its local
counterpart.

E.g. gnome-terminal just tells you it doesn't know how to open that file.
iTerm2, as far as I know, offers you to fetch it via scp (which only works if
the host is accessible under its name in a single hop).

> If I compile on a remote machine I don't want URLs that include the remote
> hostname (which might not even be reachable from my local machine via that
> name) or even necessarily the path relative to the remote machine.

Do you have any particular concern other than "I don't want..."?

You access a remote host from your local one (possibly via multiple hops) and
you're free to issue commands like "hostname" remotely. It's most likely
printed in your prompt. I don't see how the remote host automatically telling
it when you run gcc would be any sort of data leakage or privacy concern -- if
that's what you are worried of.

> I might
> want to be able to click on a filename in the output of the remote
> compilation but have it open the corresponding file locally.

Fair expectation from the user's point of view. iTerm2's scp feature does this
in simple setups.

> So it might be
> useful to have one or more -fdiagnostic-xxx options that allow me to set the
> hostname explicitly,

Or gcc could simply prefer $HOSTNAME if defined.

> and/or to map from one path to another. So when I click
> on myfile.c on the remote host I can get a URL to a local copy of that file
> (which I would edit and push to the remote machine before recompiling).

It's unclear to me how that local copy would be created -- or do you only
consider setups where the entire source tree has a local copy available? And
what about files that are outside of your project, e.g. system headers? If gcc
wants to point to /usr/include/stdio.h of the remote host, how would it map to
a local one?

That being said, I'm not against this approach at all. Maybe you could define
how your remote files map to local ones, and ones that don't have a 1:1 local
counterpart (with guaranteed same content) would remain unlinkified by gcc. Or
maybe you could rewrite all filenames so that they use sshfs that lets you
access the entire remote filesystem. Seems perhaps a bit cumbersome to
implement, and also potentially cumbersome for users to set up, and your use
case might IMHO be a quite special one, so I'm not sure if it's all worth it,
but it might be.

I assume however that the majority of developers compile locally. (Do you gcc
devs have any stats on this?) For them linkifying the files would just work,
and might be a great convenience feature. IMO a convenience feature not working
for all of gcc's users, only for the majority of them, should not be a reason
per se for rejecting it.

And let me emphasize again: Those who compile remotely wouldn't get a sneaky
faulty behavior where a different local counterpart is opened and they waste
precious time pondering why the hell that's relevant at all (assuming that the
remote hostname differs from the local one, a pretty reasonable assumption I
hope). The worst they would get is a hyperlink that fails to open. GCC could
even employ other simple low hanging fruit tricks, e.g. to enable/disable
linkifying filenames by default based on the absence/presence of some $SSH_*
env var or so, or the build system could do such magic.


(In reply to David Malcolm from comment #4)

> Is there a way to encode the line number in the URL?

Unfortunately no, not yet. See the comments under the gist (especially the ones
from Aug 2019) for the reasons and where we are stuck at the moment.

[Bug middle-end/92059] Crash on tr2::dynamic_bitset::operator=() with optimization

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Be aware that everything in the tr2 directory is unmaintained and untouched for
years.

[Bug libstdc++/92057] variant converting constructor fails for primitives

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Please provide the information requested by https://gcc.gnu.org/bugs/ not just
a URL.

Please also check whether you are simply seeing the expected result due to GCC
10 implementing the changes in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0608r3.html

[Bug fortran/91801] ICE in gfc_simplify_reshape, at fortran/simplify.c:6733

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 10 21:56:08 2019
New Revision: 276853

URL: https://gcc.gnu.org/viewcvs?rev=276853&root=gcc&view=rev
Log:
2019-10-10  Steven G. Kargl  

PR fortran/91801
* simplify.c (gfc_simplify_reshape): Convert a gcc_assert into a
gfc_error as a user can easily hit the condition.

2019-10-10  Steven G. Kargl  

PR fortran/91801
* gfortran.dg/pr91801.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91801.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/simplify.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91801] ICE in gfc_simplify_reshape, at fortran/simplify.c:6733

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |9.3

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on trunk and 9-brnach.  Closing.  Thanks for bug report.

[Bug c++/92053] Compilation fails or succeeds depending on the optimization flags

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||needs-reduction
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-10
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  ICC accepts the code.

[Bug c++/92060] New: Alias template as template template argument confused by GCC as other template

[hstong at ca dot ibm.com]

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

Bug ID: 92060
   Summary: Alias template as template template argument confused
by GCC as other template
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

In the following, the alias template `Q` merely acts as a deducible template
([dcl.type.simple]) that behaves similarly to the class template `A`, it is not
the same template as `A`. GCC treats `Q` as `A` for the purposes of declaration
matching when used as a template template argument.

### SOURCE ():
template  class TT> struct AA;

template  struct A;
template  using Q = A;

void f(AA *) { }
void f(AA *) { }  // GCC claims this is a redefinition of f(AA *).


### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++2a -pedantic -Wall -Wextra -xc++ -


### EXPECTED OUTPUT:
(Clean compile).


### ACTUAL OUTPUT:
:7:6: error: redefinition of 'void f(AA*)'
:6:6: note: 'void f(AA*)' previously defined here


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-9.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-9.2.0/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9.2.0/configure --prefix=/opt/wandbox/gcc-9.2.0
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-9.2.0/lib,-rpath,/opt/wandbox/gcc-9.2.0/lib64,-rpath,/opt/wandbox/gcc-9.2.0/lib32
--enable-lto
Thread model: posix
gcc version 9.2.0 (GCC)

[Bug c++/92060] Alias template as template template argument confused by GCC as other template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-10
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug fortran/91649] ICE in gfc_resolve_findloc, at fortran/iresolve.c:1827

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #1)

> $ cat z6.f90
> program p
>logical :: back = .true.
>integer :: x(1) = findloc([1, 2, 1], 2.0, back=back)
>print *, x
> end
> 
> 
> $ gfortran-10-20190901 -c z4.f90
> $ gfortran-10-20190901 -c z5.f90
> $ gfortran-10-20190901 -c z6.f90
> z6.f90:3:50:
> 
> 3 |integer :: x(1) = findloc([1, 2, 1], 2.0, back=back)
>   |  1
> Error: Parameter 'back' at (1) has not been declared or is a variable, which
> does not reduce to a constant expression

I think the error message here is correct.  BACK is
a variable.  It is not a named constant.  Of course,
I could be missing something.

[Bug c++/92049] bogus errors with -fchecking=2

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Caused by

@@ -26326,9 +26559,9 @@ build_non_dependent_expr (tree expr)
 unexpected recursive instantiations.  */
   && !parsing_nsdmi ()
   /* Don't do this during concept expansion either and for
- the same reason.  */
-  && !expanding_concept ())
-fold_non_dependent_expr (expr, tf_none);
+the same reason.  */
+  && !parsing_constraint_expression_p ())
+fold_non_dependent_expr (expr);

   STRIP_ANY_LOCATION_WRAPPER (expr);

found in

commit 5aadd5d943b0522963cb7afdb3484c45d867defb
Author: Jason Merrill 
Date:   Mon Jan 7 19:58:31 2019 -0500

December checkpoint of C++2a Concepts overhaul.

Squashed commit of the following:

but I don't see that change in the ChangeLog.  I guess we need that tf_none
back.  Testing a patch.