[Bug tree-optimization/95854] ICE in find_bswap_or_nop_1 of pass store-merging

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||aarch64
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-24
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed by code inspection.

[Bug gcov-profile/95847] [9/10/11 Regression] Internal error when processing pFUnit generated files with --coverage

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
Summary|Internal error when |[9/10/11 Regression]
   |processing pFUnit generated |Internal error when
   |files with --coverage   |processing pFUnit generated
   ||files with --coverage
   Keywords||ice-on-valid-code

[Bug tree-optimization/95845] Failure to optimize vector load made in separate operations to single load

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2020-06-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So this is

  VIEW_CONVERT_EXPR(r)[0] = *ptr;
  VIEW_CONVERT_EXPR(r)[1] = *(ptr + 4);

from the FEs and

  _1 = *ptr_4(D);
  r_6 = BIT_INSERT_EXPR ;
  _2 = MEM[(const float *)ptr_4(D) + 4B];
  r_7 = BIT_INSERT_EXPR ;

after SSA rewrite.  There's no further combining of inserts happening,
I guess forwprop might want to see whether an insert chain forms a full
CTOR.  BB vectorization might also a candidate to look at but it would
be quite late.

The issue with forwprop is to somehow avoid quadraticness in searching
the chain which will be difficult given it's structure.  One possibility
would be to perform a forward search from BIT_INSERT_EXPRs with a
default def arg and mark the last BIT_INSERT_EXPR in a single-use chain
as to be processed.  Or declare it not a problem.

[Bug tree-optimization/95761] [11 regression] ICE during GIMPLE pass: slp verify_ssa failed

[dimhen at gmail dot com]

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

--- Comment #8 from Dmitry G. Dyachenko  ---
(In reply to Martin Liška from comment #7)
> I see the test-cases fixed.
> Can you still reproduce that?

r11-1553 PASS x_1.i for me and FAIL unreduced one.
r11-1582 PASS x_1.i, x_2.i for me and PASS unreduced.

Thanks

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Alexandre Oliva  ---
akrl, any clue as to where this .out is coming from in your runs?  I get .exe
in my arm test runs; I don't see anything that selects .out, only .exe; and the
driver disregards the .exe suffix in executable output, regardless of platform,
when recognizing that the single source has the same basename as the linker
output.

[Bug target/95843] Duplicated ISA info in driver-i386.c and i386-builtins.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug tree-optimization/95855] New: A missing ifcvt optimization to generate fcsel

[yangyang305 at huawei dot com]

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

Bug ID: 95855
   Summary: A missing ifcvt optimization to generate fcsel
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyang305 at huawei dot com
  Target Milestone: ---

For the following case,

double test(double* d1, double* d2, double* d3, int num, double* ip) {
  double dmax[3];
  for (int i = 0; i < num; i++) {
dmax[0] = d1[i] < dmax[0] ? dmax[0] : d1[i];
dmax[1] = d2[i] < dmax[1] ? dmax[1] : d2[i];
dmax[2] = d3[i] < dmax[2] ? dmax[2] : d3[i];
ip[i] = dmax[2];
  }
  return dmax[0] + dmax[1] + dmax[2];
}

gcc -O3 generates:

movid0, #0
mov x5, 0
cmp w3, 0
ble .L3
.p2align 3,,7
.L2:
ldr d4, [x0, x5, lsl 3]
ldr d3, [x1, x5, lsl 3]
ldr d0, [x2, x5, lsl 3]
fcmpe   d1, d4
fcsel   d1, d1, d4, gt
fcmpe   d2, d3
fcsel   d2, d2, d3, gt
fcmpe   d5, d0
bgt .L8
str d0, [x4, x5, lsl 3]
add x5, x5, 1
cmp w3, w5
ble .L3
fmovd5, d0
b   .L2
.p2align 2,,3
.L8:
str d5, [x4, x5, lsl 3]
add x5, x5, 1
cmp w3, w5
bgt .L2
fmovd0, d5
.L3:
faddd1, d1, d2
faddd0, d1, d0
ret

Gcc generates fcsel instruction for "dmax[0] = d1[i] < dmax[0] ? dmax[0] :
d1[i];dmax[1] = d2[i] < dmax[1] ? dmax[1] : d2[i];" and doesn't do so for
"dmax[2] = d3[i] < dmax[2] ? dmax[2] : d3[i];". 

Pass_split_paths splits the corresponding bb so that pass_rtl_ifcvt failed to
generate the fcsel instruction. Moreover, I have found that pass_split_paths
has already added some checks to aovid spoiling if-conversion if, while the
above case is not covered. I plan to add some checks in pass_split_paths to fix
this problem and have prepared the following patch：

diff -uprN a/gcc/gimple-ssa-split-paths.c b/gcc/gimple-ssa-split-paths.c
--- a/gcc/gimple-ssa-split-paths.c
+++ b/gcc/gimple-ssa-split-paths.c
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-ssa.h"
 #include "tree-phinodes.h"
 #include "ssa-iterators.h"
+#include "cfghooks.h"

 /* Given LATCH, the latch block in a loop, see if the shape of the
path reaching LATCH is suitable for being split by duplication.
@@ -254,6 +255,44 @@ is_feasible_trace (basic_block bb)
}
 }

+  /* Canonicalize the form.  */
+  if (single_pred_p (pred1) && single_pred (pred1) == pred2
+  && empty_block_p (pred1))
+std::swap (pred1, pred2);
+
+  /* This is meant to catch another kind of cases that are likely
opportunities
+ for if-conversion. After canonicalizing, PRED2 must be an empty block and
+ PRED1 must be the only predecessor of PRED2. Moreover, PRED1 is supposed
+ to end with a cond_stmt which has the same args with the PHI in BB. */
+  if (single_pred_p (pred2) && single_pred (pred2) == pred1
+  && empty_block_p (pred2))
+{
+  gimple *cond_stmt = last_stmt (pred1);
+  if (cond_stmt && gimple_code (cond_stmt) == GIMPLE_COND)
+   {
+ tree lhs = gimple_cond_lhs (cond_stmt);
+ tree rhs = gimple_cond_rhs (cond_stmt);
+
+ gimple_stmt_iterator gsi;
+ for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+   {
+ gimple *phi = gsi_stmt (gsi);
+ if ((gimple_phi_arg_def (phi, 0) == lhs
+  && gimple_phi_arg_def (phi, 1) == rhs)
+ || (gimple_phi_arg_def (phi, 0) == rhs
+ && gimple_phi_arg_def (phi, 1) == lhs))
+   {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+   fprintf (dump_file,
+"Block %d appears to be optimized to a join "
+"point for if-convertable half-diamond.\n",
+bb->index);
+ return false;
+   }
+   }
+   }
+}
+
   /* If the joiner has no PHIs with useful uses there is zero chance
  of CSE/DCE/jump-threading possibilities exposed by duplicating it.  */
   bool found_useful_phi = false;

With this patch, gcc -O3 generates:

cmp w3, 0
ble .L2
mov x5, 0
.p2align 3,,7
.L9:
ldr d5, [x0, x5, lsl 3]
ldr d4, [x1, x5, lsl 3]
ldr d3, [x2, x5, lsl 3]
fcmpe   d0, d5
fcsel   d0, d0, d5, gt
fcmpe   d2, d4
fcsel   d2, d2, d4, gt
fcmpe   d1, d3
fcsel   d1, d1, d3, gt
str d1, [x4, x5, lsl 3]
add x5, x5, 1
cmp w3, w5
bgt .L9
.L2:
faddd0, d0, d2
faddd0, d0, d1
  

[Bug middle-end/64242] Longjmp expansion incorrect

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #40 from Paul Hua  ---
(In reply to Andrew Pinski from comment #39)
> Created attachment 47830 [details]
> MIPS patch
> 
> This is the MIPS patch, I will post it by the end of next week.

any update ?

[Bug tree-optimization/95854] New: ICE in find_bswap_or_nop_1 of pass store-merging

[zhoukaipeng3 at huawei dot com]

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

Bug ID: 95854
   Summary: ICE in find_bswap_or_nop_1 of pass store-merging
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhoukaipeng3 at huawei dot com
  Target Milestone: ---

ICE log:

during GIMPLE pass: store-merging
pr87132.c: In function ‘main’:
pr87132.c:5:5: internal compiler error: in tree_to_uhwi, at tree.c:7332
5 | int main()
  | ^~~~
0xfc2fcf tree_to_uhwi(tree_node const*)
../.././gcc/tree.c:7332
0xfc2fcf tree_to_uhwi(tree_node const*)
../.././gcc/tree.c:7330
0x169420b find_bswap_or_nop_1
../.././gcc/gimple-ssa-store-merging.c:602
0x1696c1b find_bswap_or_nop_1
../.././gcc/gimple-ssa-store-merging.c:589
0x1696c1b process_store
../.././gcc/gimple-ssa-store-merging.c:4773
0x1696c1b execute
../.././gcc/gimple-ssa-store-merging.c:4996


Command: gcc -S -march=armv8.5-a+sve2 -fno-vect-cost-model -fno-tree-scev-cprop
 -O3 -ftracer pr87132.c

GCC version: gcc version 11.0.0 20200618 (experimental) (GCC)

The problem occurs in find_bswap_or_nop_1.
The stmt is "_27 = BIT_FIELD_REF ". 
So "tree_to_uhwi (TREE_OPERAND (rhs1, 2))" failed.

I plan to add a judgement before to make sure both TREE_OPERAND (rhs1, 1) and
TREE_OPERAND (rhs1, 2) are INTEGER_CST.

[Bug c++/88323] implement C++20 language features.

[jason at gcc dot gnu.org]

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

Bug 93976 Summary: Implement P2082R1, Fixing CTAD for aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93976

   What|Removed |Added

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

[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/93976] Implement P2082R1, Fixing CTAD for aggregates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
Version|10.0|11.0

--- Comment #2 from Jason Merrill  ---
Implemented for GCC 11.

[Bug ipa/95775] Command line argument for target_clones?

[yyc1992 at gmail dot com]

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

--- Comment #4 from Yichao Yu  ---
> Hey. My opinion is similar to Richi's. If you really want a highly optimized 
> library, you should rather use a dlopen mechanism with pre-built set of 
> options.

Well, a few things,

1. That sounds like an argument against `target_clone` and `target`. If
dlopen'ing different libraries is your recommended solution then none of these
would be needed.
2. The solution you propose put all the pression on the user of the library.
That has a few problems.

   2.1. There are strictly more users than libraries. (Assuming the library is
used at all) so this is forcing more (repeated) work to be done.
   2.2. The author of the library and to a lesser degree the builder of the
library has the best knowledge of the set of features that can benefit the
library/the most useful for the deployment environment. The author of the user
code of the library, who has to implement the dispatch/loading logic in general
has much less complete knowledge of what the target to support.
   2.3. It'll be even worse for code size since this forces each user to carry
their own library, and now all data has to be duplicated as well in additional
to code. Also because,

3. There's no standard way of doing this AFAICT.

Now (3) is really the main point.
I'm fine with whatever mechanism that allows multiple versions of the code to
be available as long as it requires no more effort/cost from/for the user (and
to a lesser degree the author) of the library.

If one such mechanism is provided by gcc/glibc/binutils so that library writers
don't have to invent their own loading and detection mechanism and won't cause
unnecessary indirection (as cheap as ifunc) and will just work for the user to
either link or dlopen, then I think it doesn't really matter if that's backed
by one file/multiple files or whatever one can come up with.

Currently, the only mechanism available that fits this description AFAICT is
`target_clones`/`ifunc`. Unless there's a roadmap that I'm not aware of to
replace this mechanism with a similar one backed by multiple files I don't
think suggesting such a mechanism is the right approach.

Again, I said in the very first post that I totally agree this won't be the
method to give absolutely the best performance, but neither is `target_clones`.
I also completely agree that this option can be misused and the compiler should
not do it on its own before getting smarter but this is far from the first
option that can be misused and given how cheap memory is and how multiple load
of the same library doesn't take more memory this isn't even closoed to be the
worse misused either.

[Bug c++/87208] dependent name resolution selects a function it should have NEVER considered

[language.lawyer at gmail dot com]

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

Language Lawyer  changed:

   What|Removed |Added

 CC||language.lawyer at gmail dot 
com

--- Comment #4 from Language Lawyer  ---
Dup of Bug 70099?

[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'

[ma...@linux-mips.org]

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

--- Comment #4 from Maciej W. Rozycki  ---
Sigh, I keep forgetting we don't have PC-relative memory access machine
instructions.  We could have had base=x0 encodings allocated for that,
which are otherwise of rather limited use.

Regardless, I think run-time enforcement of the immutability of constant
data is important for some use cases and possibly even required by some
programming languages (Ada?).

[Bug target/95842] arch_names_table and processor_alias_table should be combined

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-June/54
   ||8780.html
   Target Milestone|--- |11.0
   Keywords||patch

--- Comment #2 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548780.html

[Bug tree-optimization/95853] New: Failure to optimize add overflow pattern to __builtin_add_overflow

[gabravier at gmail dot com]

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

Bug ID: 95853
   Summary: Failure to optimize add overflow pattern to
__builtin_add_overflow
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

struct result_struct
{
bool p;
uint64_t r;
};

result_struct size_add_overflow(uint64_t x, uint64_t y)
{
unsigned __int128 z = (unsigned __int128)x + (unsigned __int128)y;
return {z > SIZE_MAX, (size_t)z};
}

This can be optimized to 

result_struct size_add_overflow(uint64_t x, uint64_t y)
{ 
uint64_t result;
return {__builtin_add_overflow(x, y, &result), result};
}

This transformation is done by LLVM, but not by GCC.

[Bug tree-optimization/95852] New: Failure to optimize __builtin_mul_overflow pattern

[gabravier at gmail dot com]

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

Bug ID: 95852
   Summary: Failure to optimize __builtin_mul_overflow pattern
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(unsigned x, unsigned y, unsigned* res)
{
*res = x * y;
return x && ((*res / x) != y);
}

This can be optimized to `return __builtin_mul_overflow(x, y, res);`. This
transformation is done by LLVM, but not by GCC.

[Bug c++/93976] Implement P2082R1, Fixing CTAD for aggregates

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:6b161257f9f8c7a26b7d119ebc32cbbc54d2e508

commit r11-1615-g6b161257f9f8c7a26b7d119ebc32cbbc54d2e508
Author: Jason Merrill 
Date:   Mon Jun 22 15:44:45 2020 -0400

c++: Improve CTAD for aggregates [PR93976]

P2082R1 adjusted the rules for class template argument deduction for an
aggregate to better handle arrays and pack expansions.

gcc/cp/ChangeLog:

PR c++/93976
Implement C++20 P2082R1, Fixing CTAD for aggregates.
* cp-tree.h (TPARMS_PRIMARY_TEMPLATE): Split out from...
(DECL_PRIMARY_TEMPLATE): ...here.
(builtin_guide_p): Declare.
* decl.c (reshape_init_class): Handle bases of a template.
(reshape_init_r): An array with dependent bound takes a single
initializer.
* pt.c (tsubst_default_argument): Shortcut {}.
(unify_pack_expansion): Allow omitted arguments to trailing pack.
(builtin_guide_p): New.
(collect_ctor_idx_types): Give a trailing pack a {} default
argument.  Handle arrays better.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr3.C: New test.
* g++.dg/cpp2a/class-deduction-aggr4.C: New test.

[Bug libstdc++/95851] [10/11 Regression] std::to_chars(p, p, c, 2) segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2020-06-23
  Known to fail||10.1.1, 11.0
  Known to work||9.3.0
   Target Milestone|--- |10.2
 Ever confirmed|0   |1

[Bug libstdc++/95851] New: [10/11 Regression] std::to_chars(p, p, c, 2) segfault

[redi at gcc dot gnu.org]

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

Bug ID: 95851
   Summary: [10/11 Regression] std::to_chars(p, p, c, 2) segfault
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The following has undefined behaviour, trying to write past the end of the
range:

#include 
int main()
{
  char c = 0;
  std::to_chars(&c, &c, c, 2);
}

[Bug fortran/95850] [11 regression] gfortran.fortran-torture/execute/forall_5.f90 fails starting with r11-r11-1595

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Dominique d'Humieres  ---
This should be fixed now.

[Bug lto/95846] Combination of LTO and -Wl, --defsym causes symbol to be resolved as NULL

[cbaylis at gcc dot gnu.org]

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

--- Comment #2 from cbaylis at gcc dot gnu.org ---
Reported to binutils bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=26163

[Bug fortran/95850] New: [11 regression] gfortran.fortran-torture/execute/forall_5.f90 fails starting with r11-r11-1595

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95850
   Summary: [11 regression]
gfortran.fortran-torture/execute/forall_5.f90 fails
starting with r11-r11-1595
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:abcde0a658e17dbbabcb396eaae5a3612e07d401, r11-1595

make -k check-gcc
RUNTESTFLAGS=execute.exp=gfortran.fortran-torture/execute/forall_5.f90

FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O0 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O1 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O2 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O2
-fomit-frame-pointer -finline-functions 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O2
-fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O2
-fbounds-check 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O3 -g 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -Os 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution, -O2
-ftree-vectorize -maltivec 

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
vmx_hw_available69709.c -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -mno-vsx
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-lm -o vmx_hw_available69709.exe
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../..:.:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../..:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.fortran-torture/execute/forall_5.f90
   -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never 
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -w  -O0  
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer

[Bug c++/95849] New: Universal forwarding constructor inheritance resolution issue

[njormrod at fb dot com]

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

Bug ID: 95849
   Summary: Universal forwarding constructor inheritance
resolution issue
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njormrod at fb dot com
  Target Milestone: ---

Universal forwarding constructors have a known oddity: they are a better match
than the copy constructor for non-const objects.

If a derived class inherits its parent's constructors, where the parent has a
universal forwarding constructor, then the derived class's default copy
constructor (having signature `const Derived&`) should likewise be usurped by
the non-const universal-forwarding constructor.

This is not the case in gcc.

Code demonstrating the bug: foo() and bar() should both return 8, but bar()
actually returns 7.

```
struct A {
A(const A&) : x(7) {}

template 
A(U&&) : x(8) {}

int x;
};

int foo() {
A o1(true);
A o2(o1);
return o2.x;
}

struct B : A {
using A::A;
};

int bar() {
B o1(true);
B o2(o1);
return o2.x;
}
```


Godbolt link for gcc: https://gcc.godbolt.org/z/Y_sXD6. Bug is present.
Godbolt link for clang: https://gcc.godbolt.org/z/BFjYph. Bug is present.
Godbolt link for msvc: https://gcc.godbolt.org/z/GQ2z3x. msvc has the correct
behavior.

[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Keywords|wrong-code  |

--- Comment #4 from kargl at gcc dot gnu.org ---
Remove "wrong-code" keyword.

[Bug fortran/95827] ICE in gfc_get_string, at fortran/iresolve.c:70

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch posted for review:

https://gcc.gnu.org/pipermail/fortran/2020-June/054583.html

[Bug fortran/95826] ICE in gfc_match_decl_type_spec, at fortran/decl.c:4290

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch posted for review:

https://gcc.gnu.org/pipermail/fortran/2020-June/054582.html

[Bug gcov-profile/95847] Internal error when processing pFUnit generated files with --coverage

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-23
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The ICE is present in a significant number of tests in the test suite
(run make -k -j16 check-gfortran RUNTESTFLAGS="--target_board=unix
--tool_opts='--coverage'" in the gcc directory).

The change occurred between 2018-11-17 (OK) and 2018-11-24 (ICE).

[Bug c++/89976] missing uninitialized warning for uninitialized struct member (VOPs)

[msebor at gcc dot gnu.org]

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

Bug 49754 Summary: Wuninitialized does not work with structs/unions/arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754

   What|Removed |Added

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

[Bug middle-end/49754] Wuninitialized does not work with structs/unions/arrays

[msebor at gcc dot gnu.org]

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

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=95848
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
GCC 11 (and prior) diagnose both functions in comment #0, I suspect as a result
of r156156:

pr49754.c: In function ‘foo’:
pr49754.c:2:38: warning: ‘x’ is used uninitialized [-Wuninitialized]
2 | struct i foo () { struct i x; return x; }
  |  ^
pr49754.c:2:28: note: ‘x’ declared here
2 | struct i foo () { struct i x; return x; }
  |^
pr49754.c: In function ‘bar’:
pr49754.c:3:28: warning: ‘y’ is used uninitialized [-Wuninitialized]
3 | int bar () { int y; return +y; }
  |^~

Returning larger aggregates started to be diagnosed in r245840.  Passing
structs to other functions by value still isn't diagnosed.  It used to be, but
it stopped  sometime between r143699 and r143725.

See pr95848 that tracks the problem with pass-by-value.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org]

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

Bug 49754 Summary: Wuninitialized does not work with structs/unions/arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754

   What|Removed |Added

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

[Bug middle-end/95848] New: missing -Wuninitialized passing structs by value

[msebor at gcc dot gnu.org]

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

Bug ID: 95848
   Summary: missing -Wuninitialized passing structs by value
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the test case below, -Wuninitialized only detects the first instances of
using an uninitialized struct.  It does not detect passing it as an argument by
value.

$ cat q.c && gcc -O2 -S -Wall q.c
struct S { int i; };

struct S sf (void)
{
  struct S s;
  return s;// -Wuninitialized (good)
}

void fp (const struct S*);

void g (void)
{
  struct S s;
  fp (&s); // -Wuninitialized (good)
}

void fs (struct S);

void h (void)
{
  struct S s;
  fs (s);  // missing -Wuninitialized
}
q.c: In function ‘sf’:
q.c:6:10: warning: ‘s’ is used uninitialized [-Wuninitialized]
6 |   return s;// -Wuninitialized (good)
  |  ^
q.c:5:12: note: ‘s’ declared here
5 |   struct S s;
  |^
q.c: In function ‘g’:
q.c:14:3: warning: ‘s’ may be used uninitialized [-Wmaybe-uninitialized]
   14 |   fp (&s); // -Wuninitialized (good)
  |   ^~~
q.c:9:6: note: by argument 1 of type ‘const struct S *’ to ‘fp’ declared here
9 | void fp (const struct S*);
  |  ^~
q.c:13:12: note: ‘s’ declared here
   13 |   struct S s;
  |^

[Bug fortran/95707] ICE in finish_equivalences, at fortran/trans-common.c:1319

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch.

Backporting further would involve backports from other PRs and is probably
not worth it.  Thus closing.

Thanks for the report!

[Bug fortran/95688] ICE in gfc_get_string, at fortran/iresolve.c:70

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch.

Backporting further would involve backports from other PRs and is probably
not worth it.  Thus closing.

Thanks for the report!

[Bug fortran/95687] ICE in get_unique_hashed_string, at fortran/class.c:508

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch.

Backporting further would involve backports from other PRs and is probably
not worth it.  Thus closing.

Thanks for the report!

[Bug fortran/95689] [8/9/10/11 Regression] ICE in check_sym_interfaces, at fortran/interface.c:2015

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11, and backported to all open branches.

Thanks for the report!

[Bug fortran/95689] [8/9/10/11 Regression] ICE in check_sym_interfaces, at fortran/interface.c:2015

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:4cfdae8e4a96912871865d289a5a817cec68eaa0

commit r8-10325-g4cfdae8e4a96912871865d289a5a817cec68eaa0
Author: Harald Anlauf 
Date:   Sat Jun 20 16:09:45 2020 +0200

PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015

With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer.  We now check that we do not
exceed the enlarged buffer size.

gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.

(cherry picked from commit 62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6)

[Bug fortran/95587] ICE in gfc_target_encode_expr, at fortran/target-memory.c:362

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch and 9-branch. Closing.

Thanks for the report!

[Bug fortran/95689] [8/9/10/11 Regression] ICE in check_sym_interfaces, at fortran/interface.c:2015

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:84323d9fa7526496d844f167f6353e0ec12279e8

commit r9-8693-g84323d9fa7526496d844f167f6353e0ec12279e8
Author: Harald Anlauf 
Date:   Sat Jun 20 16:09:45 2020 +0200

PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015

With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer.  We now check that we do not
exceed the enlarged buffer size.

gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.

(cherry picked from commit 62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6)

[Bug fortran/95587] ICE in gfc_target_encode_expr, at fortran/target-memory.c:362

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:449246af10befa7e973cd6f864138e6cdd5c24e5

commit r9-8692-g449246af10befa7e973cd6f864138e6cdd5c24e5
Author: Harald Anlauf 
Date:   Sat Jun 20 16:05:13 2020 +0200

PR fortran/95587 - ICE in gfc_target_encode_expr, at
fortran/target-memory.c:362

EQUIVALENCE objects are subject to constraints listed in the Fortran 2018
standard, section 8.10.1.1.  These constraints are to be checked
also for CLASS variables.

gcc/fortran/
PR fortran/95587
* match.c (gfc_match_equivalence): Check constraints on
EQUIVALENCE objects also for CLASS variables.

(cherry picked from commit 5eb947601bdce59f2ff26694327ad173c51c2724)

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Thomas Kथà¤nig
:

https://gcc.gnu.org/g:862ea30fcb50735344f853e330ea58025fbe82d3

commit r10-8357-g862ea30fcb50735344f853e330ea58025fbe82d3
Author: Thomas Koenig 
Date:   Tue Jun 23 21:59:47 2020 +0200

Make forall statement in testsuite conforming.

The recent patch for dependency checking introduced one failing test
case for pointer assignments in a forall statement.  This test case
was invalid because of an interdependency in a forall statement.
This patch fixes that by removing that dependency.

gcc/testsuite/ChangeLog:

2020-06-23  Thomas Koenig  

PR fortran/95812
* gfortran.fortran-torture/execute/forall_5.f90: Make forall
statement conforming.

(cherry picked from commit 6f609029c7078fbd29e2f842074e2b99ea099096)

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Thomas Koenig  ---
Fallout is now also fixed.

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
https://gcc.gnu.org/g:6f609029c7078fbd29e2f842074e2b99ea099096

commit r11-1614-g6f609029c7078fbd29e2f842074e2b99ea099096
Author: Thomas Koenig 
Date:   Tue Jun 23 21:59:47 2020 +0200

Make forall statement in testsuite conforming.

The recent patch for dependency checking introduced one failing test
case for pointer assignments in a forall statement.  This test case
was invalid because of an interdependency in a forall statement.
This patch fixes that by removing that dependency.

gcc/testsuite/ChangeLog:

* gfortran.fortran-torture/execute/forall_5.f90: Make forall
statement conforming.

[Bug fortran/95828] ICE in resolve_select_rank, at fortran/resolve.c:9774

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-23
 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
There's a first buffer overflow, fixed by:

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index c53b312f7ed..cc8676b3e03 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9638,7 +9638,7 @@ resolve_select_rank (gfc_code *code, gfc_namespace
*old_ns)
   gfc_namespace *ns;
   gfc_code *body, *new_st, *tail;
   gfc_case *c;
-  char tname[GFC_MAX_SYMBOL_LEN];
+  char tname[GFC_MAX_SYMBOL_LEN + 7];
   char name[2 * GFC_MAX_SYMBOL_LEN];
   gfc_symtree *st;
   gfc_expr *selector_expr = NULL;

However, there's another one elsewhere that probably needs an instrumented
f951.

[Bug lto/95846] Combination of LTO and -Wl, --defsym causes symbol to be resolved as NULL

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
It is a binutils bug.  Please open a binutils bug at

https://sourceware.org/bugzilla/enter_bug.cgi

[Bug tree-optimization/95761] [11 regression] ICE during GIMPLE pass: slp verify_ssa failed

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
I see the test-cases fixed.
Can you still reproduce that?

[Bug c/95777] Allow specifying more than one target options at the same time in target and target_clones attribute

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-23
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

[Bug ipa/95775] Command line argument for target_clones?

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Hey. My opinion is similar to Richi's. If you really want a highly optimized
library, you should rather use a dlopen mechanism with pre-built set of
options.

[Bug middle-end/95830] [11 regression][MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12247 start with gcc-11-1445-g502d63b6d61

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 CC|mliska at suse dot cz  |
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-06-23

--- Comment #2 from Martin Liška  ---
Mine.

[Bug fortran/95847] New: Internal error when processing pFUnit generated files with --coverage

[olebole at debian dot org]

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

Bug ID: 95847
   Summary: Internal error when processing pFUnit generated files
with --coverage
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olebole at debian dot org
  Target Milestone: ---

Created attachment 48776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48776&action=edit
Source file that reproduces the bug

With gcc 9 and 10, compiling the attached file with coverage info raises an
internal error:

$ gfortran-10 -c --coverage funit-bug.f90 
during IPA pass: profile
funit-bug.f90:8:0:

8 |use foo
  | 
internal compiler error: in coverage_begin_function, at coverage.c:656
0x7f6c0275ae0a __libc_start_main
../csu/libc-start.c:308
[…]
$ gfortran-10 --version
GNU Fortran (Debian 10.1.0-3) 10.1.0
[…]
$ gfortran-9 --version
GNU Fortran (Debian 9.3.0-14) 9.3.0

This does not happen with gfortran-8, so it is a regression:

$ gfortran-8 -c --coverage funit-bug.f90
$ gfortran-8 --version
GNU Fortran (Debian 8.4.0-4) 8.4.0

System is Debian 11 testing.
The attached file is derived from a pFUnit generated file where this was
originally observed .

[Bug target/80881] Implement Windows native TLS

[alexandre.nunes at gmail dot com]

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

Alexandre Pereira Nunes  changed:

   What|Removed |Added

 CC||alexandre.nunes at gmail dot 
com

--- Comment #18 from Alexandre Pereira Nunes  
---
I'm working on native TLS for windows targets. The goal is to match clang's
output (the latter has native TLS implemented for quite a while).

[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> (In reply to Dominique d'Humieres from comment #1)
> > The problem seems more serious.
> > 
> > type t
> >   character(len=:, kind=4), pointer :: str2
> > end type t
> > type(t) :: var
> > character(len=:, kind=4), pointer :: str
> > 
> > print *, kind(str), kind(var%str2)
> > str(1:1) = 4_"a"
> > end
> > 
> > result
> > 
> > % ./a.out 
> >4   4
> 
> Yes, there is a serious problem with the Fortran code!
> 
> str is an undefined pointer.  The line 'str(1:1) = 4_"a"'
> is invalid.

In fact, after a quick scan of the Fortran 2018 standard.
The PR is likely invalid.  Allocation on assignment applies
to ALLOCATABLE variables not undefined or disassociated
pointers.

Yep.  Definitely invalid.

Fortran 2018,
10.2.1.2 Intrinsic assignment statement
p. 160

If the variable is a pointer, it shall be associated with a definable
target such that the type, type parameters, and shape of the target and
expr conform.

[Bug c++/95477] [coroutines] coroutine result object not properly freed

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:788b962aa00959e861b45767c5c88ec41ca30c21

commit r11-1613-g788b962aa00959e861b45767c5c88ec41ca30c21
Author: Iain Sandoe 
Date:   Tue Jun 23 10:06:21 2020 +0100

coroutines: Add a cleanup expression for g-r-o when needed [PR95477].

The PR reports that we fail to destroy the object initially created from
the get-return-object call.  Fixed by adding a cleanup when the DTOR is
non-trivial.  In addition, to meet the specific wording that the call to
get_return_object creates the glvalue for the return, we must construct
that in-place in the return object to avoid a second copy/move CTOR.

gcc/cp/ChangeLog:

PR c++/95477
* coroutines.cc (morph_fn_to_coro): Apply a cleanup to
the get return object when the DTOR is non-trivial.

gcc/testsuite/ChangeLog:

PR c++/95477
* g++.dg/coroutines/pr95477.C: New test.
* g++.dg/coroutines/void-gro-non-class-coro.C: New test.

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
The test case is invalid, see

https://gcc.gnu.org/pipermail/fortran/2020-June/054579.html

[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> The problem seems more serious.
> 
> type t
>   character(len=:, kind=4), pointer :: str2
> end type t
> type(t) :: var
> character(len=:, kind=4), pointer :: str
> 
> print *, kind(str), kind(var%str2)
> str(1:1) = 4_"a"
> end
> 
> result
> 
> % ./a.out 
>4   4

Yes, there is a serious problem with the Fortran code!

str is an undefined pointer.  The line 'str(1:1) = 4_"a"'
is invalid.

[Bug lto/95846] New: Combination of LTO and -Wl,--defsym causes symbol to be resolved as NULL

[cbaylis at gcc dot gnu.org]

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

Bug ID: 95846
   Summary: Combination of LTO and -Wl,--defsym causes symbol to
be resolved as NULL
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbaylis at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The following program demonstrates this problem:

==< test1.c >==
#include 

void f(void);
void g(void);

void f(void)
{
  printf("in f()\n");
  g();
  printf("back in f()\n");
}
==< test2.c >==
#include 

void f(void);

void real_g(void)
{
printf("in real_g()\n");
}

int main()
{
real_g();
f();
}
== end ==

$ gcc -Os -c test1.c
$ gcc -O2 -flto -c test2.c
$ gcc -O2 test1.o test2.o -o test -Wl,--defsym,g=real_g
$ ./test
in real_g()
in f()
Segmentation fault (core dumped)

The segfault is caused because there is no real_g symbol and g has been
resolved to NULL.

00401146 :
  401146:   50  push   %rax
  401147:   bf 15 20 40 00  mov$0x402015,%edi
  40114c:   e8 df fe ff ff  callq  401030 
  401151:   e8 aa ee bf ff  callq  0 < oops!
  401156:   bf 10 20 40 00  mov$0x402010,%edi
  40115b:   5a  pop%rdx
  40115c:   e9 cf fe ff ff  jmpq   401030 
  401161:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  401168:   00 00 00 
  40116b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

Seen on Fedora 32 (gcc 10.1.1, binutils 2.34) and Ubuntu 18.04 (gcc 7.5.0,
binutils 2.30)

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #6 from Dominique d'Humieres  ---
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O0 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O1 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O2 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O2
-fbounds-check 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O2
-fomit-frame-pointer -finline-functions 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O2
-fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -O3 -g 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution,  -Os 
FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution, -O2
-ftree-vectorize -maltivec

[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-23
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Dominique d'Humieres  ---
The problem seems more serious.

type t
  character(len=:, kind=4), pointer :: str2
end type t
type(t) :: var
character(len=:, kind=4), pointer :: str

print *, kind(str), kind(var%str2)
str(1:1) = 4_"a"
end

result

% ./a.out 
   4   4

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

[Bug tree-optimization/95836] Failure to remove strchr converted to bool with string literal when bit magic would be much more efficient (and sometimes smaller)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Well, it does, we can't keep it in the IL in that form because the compiler
itself might optimize it away on the assumption that UB doesn't happen.

[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Proposed fix at 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548730.html

Seems to work for me. Thanks!

[Bug tree-optimization/95836] Failure to remove strchr converted to bool with string literal when bit magic would be much more efficient (and sometimes smaller)

[gabravier at gmail dot com]

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

--- Comment #2 from Gabriel Ravier  ---
Yeah I wasn't sure whether this was legitimate, I was just trying to give a
small example here, I dont think doesn't changes anything to how the
optimization is able to work unless GCC has targets where `a << b` with `b >
BITS_IN_A` traps.

[Bug tree-optimization/95845] New: Failure to optimize vector load made in separate operations to single load

[gabravier at gmail dot com]

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

Bug ID: 95845
   Summary: Failure to optimize vector load made in separate
operations to single load
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef float __attribute__((vector_size(8))) v2f32;

v2f32 f(const float *ptr)
{
v2f32 r;
r[0] = ptr[0];
r[1] = ptr[1];
return r;
}

This can be optimized to `return (v2f32){ptr[0], ptr[1]};`. This transformation
is done by LLVM, but not by GCC.

[Bug c++/95629] consteval operator== crashes compiler

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed by r11-1455-g14c831f5ef614aabb6a8c85712fb166600e6cc05

[Bug libstdc++/95832] std::vector specialization leading std::variant ctor treating it as int rather than bool

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
No, that doesn't work for things convertible to pointers.

#include 
struct P { operator void*() const; };
std::variant v{ P{} };

The argument type here is not a pointer, so your suggestion would construct the
bool, which is exactly the case P0602 was designed to prevent.

"Can be converted to bool via conversion to a pointer or function pointer type"
is not practical to detect, and I have no intention of trying. See Bug 93628
for a related problem.

[Bug c++/95844] [11 Regression] ICE: Segmentation fault (in cp_warn_deprecated_use)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
   Last reconfirmed||2020-06-23
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r11-1457-g44492e248cbff60b12f5cbdaa32b265c5e8c9aff

[Bug c++/95844] New: [11 Regression] ICE: Segmentation fault (in cp_warn_deprecated_use)

[asolokha at gmx dot com]

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

Bug ID: 95844
   Summary: [11 Regression] ICE: Segmentation fault (in
cp_warn_deprecated_use)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200621 snapshot (g:47ddb895df311e546a6f54345e18b8749ac50324)
ICEs when compiling the following testcase, extracted from
test/CXX/class/class.compare/class.compare.default/p4.cpp from the clang 10.0.0
test suite, w/ -std=c++20 -Wdeprecated-copy:

namespace std {
  struct strong_ordering {
  };
}

struct F {
  [[deprecated("oh no")]] std::strong_ordering operator<=>(const F&) const =
default;
};
void use_f(F f) {
  void(f == f);
}

% g++-11.0.0 -std=c++20 -Wdeprecated-copy -c uwfljn63.cpp
uwfljn63.cpp: In function 'void use_f(F)':
uwfljn63.cpp:10:13: internal compiler error: Segmentation fault
   10 |   void(f == f);
  | ^
0x100872f crash_signal
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/toplev.c:328
0x9277f3 cp_warn_deprecated_use(tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/decl2.c:5426
0x92fb8e cp_warn_deprecated_use(tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/decl2.c:5393
0x92fb8e mark_used(tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/decl2.c:5547
0x880abb build_over_call
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/call.c:9064
0x888553 build_new_op_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/call.c:6341
0x888d6d build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/call.c:6605
0xa75a0d build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/typeck.c:4280
0x99bf34 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:9777
0x99da2e cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:9914
0x9a09a0 cp_parser_parenthesized_expression_list
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:8031
0x9a11f0 cp_parser_functional_cast
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:29643
0x9b9d44 cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:7219
0x99bd79 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:9609
0x99da2e cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:9914
0x99ddf3 cp_parser_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:10082
0x9a0da8 cp_parser_expression_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:11742
0x9ac443 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:11538
0x9adcf8 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:11889
0x9addd8 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200621/work/gcc-11-20200621/gcc/cp/parser.c:11839

[Bug target/95843] New: Duplicated ISA info in driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

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

Bug ID: 95843
   Summary: Duplicated ISA info in driver-i386.c and
i386-builtins.c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: hubicka at gcc dot gnu.org, ubizjak at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

i386-builtins.c has _isa_names_table to map command-line option to ISA
feature.  driver-i386.c has many conditional statements to map ISA to
command-line option.  _isa_names_table doesn't cover all ISA features
GCC supports.  _isa_names_table should be enhanced to support both
i386-builtins.c and driver-i386.c.

[Bug c++/95768] [11 Regression] -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548683.html

[Bug libstdc++/95832] std::vector specialization leading std::variant ctor treating it as int rather than bool

[fiesh at zefix dot tv]

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

--- Comment #7 from fiesh at zefix dot tv ---
> Not possible to backport to gcc-10, because the front end support
isn't there. That unfortunately means std::variant construction works
differently in each of gcc-9, gcc-10 and master.

Doesn't the new formulation basically revert the change for bool but not pick
bool when given a pointer?  If so, couldn't this be implemented without the
front end considering "pointer to bool" narrowing by checking if the argument
type is a pointer and, if so, not construct the bool?

[Bug target/95676] [armhf] g++ mis-compiles code at -O1 or above

[acoplan at gcc dot gnu.org]

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

Alex Coplan  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Alex Coplan  ---
Looks like the program has undefined behavior (signed integer overflow), so not
a compiler bug.

$ cat test.cc
#include 

bool check_equality()
{
std::chrono::system_clock::time_point
v(std::chrono::system_clock::time_point::min());
msgpack::zone z;
msgpack::object obj(v, z);
return obj.as() == v;
}

int main()
{
return check_equality() ? 42 : 0;
}
$ g++ test.cc -fsanitize=undefined -I msgpack-c/include/ -I boost_1_73_0
$ ./a.out
/usr/include/c++/7/chrono:176:38: runtime error: signed integer overflow:
-9223372037 * 10 cannot be represented in type 'long int'
/usr/include/c++/7/chrono:379:8: runtime error: signed integer overflow:
9223372036709551616 + 145224192 cannot be represented in type 'long int'

I get the same result with clang++ as well.

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Blocks||53947
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-23

--- Comment #1 from Richard Biener  ---
GCC does not yet vectorize stmts without loads (and explicitely rejects
vector types somewhere).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug testsuite/95840] Parallel build fails due to missing "gcc/xgcc"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-23
 Ever confirmed|0   |1

[Bug testsuite/95840] Parallel build fails due to missing "gcc/xgcc"

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
I think on trunk this has been fixed with
g:b19d8aac15649f31a7588b2634411a1922906ea8

2020-06-03  Romain Naour  

* Makefile.in (SELFTEST_DEPS): Move before including language makefile
fragments.

[Bug target/95646] arm-none-eabi function attribute 'cmse_nonsecure_entry' wipes register values with -Os

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

https://gcc.gnu.org/g:5f426554fd804d65509875d706d8b8bc3a48393b

commit r11-1601-g5f426554fd804d65509875d706d8b8bc3a48393b
Author: Andre Simoes Dias Vieira 
Date:   Tue Jun 23 15:20:17 2020 +0100

arm: PR target/95646: Do not clobber callee saved registers with CMSE

As reported in bugzilla when the -mcmse option is used while compiling for
size
(-Os) with a thumb-1 target the generated code will clear the registers
r7-r10.
These however are callee saved and should be preserved accross ABI
boundaries.
The reason this happens is because these registers are made "fixed" when
optimising for size with Thumb-1 in a way to make sure they are not used,
as
pushing and popping hi-registers requires extra moves to and from LO_REGS.

To fix this, this patch uses 'callee_saved_reg_p', which accounts for this
optimisation, instead of 'call_used_or_fixed_reg_p'. Be aware of
'callee_saved_reg_p''s definition, as it does still take call used
registers
into account, which aren't callee_saved in my opinion, so it is a rather
misnoemer, works in our advantage here though as it does exactly what we
need.

Regression tested on arm-none-eabi.

Is this OK for trunk? (Will eventually backport to previous versions if
stable.)

gcc/ChangeLog:
2020-06-19  Andre Vieira  

PR target/95646
* config/arm/arm.c: (cmse_nonsecure_entry_clear_before_return): Use
'callee_saved_reg_p' instead of 'calL_used_or_fixed_reg_p'.

gcc/testsuite/ChangeLog:
2020-06-19  Andre Vieira  

PR target/95646
* gcc.target/arm/pr95646.c: New test.

[Bug target/95842] arch_names_table and processor_alias_table should be combined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-23
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/95842] New: arch_names_table and processor_alias_table should be combined

[hjl.tools at gmail dot com]

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

Bug ID: 95842
   Summary: arch_names_table and processor_alias_table should be
combined
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz, ubizjak at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

i386-builtins.c has arch_names_table to map architecture name to internal
model and a switch statement to map internal processor name to architecture
name.  When a new processor name is added, we need to update 3 different
places.  We should put all these information in processor_alias_table.  We
can update a single place in processor_alias_table to support a new processor.

[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-June/54
   ||8730.html

--- Comment #7 from Alexandre Oliva  ---
Proposed fix at https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548730.html

[Bug testsuite/95416] Several gcc.misc-tests/outputs.exp tests FAIL

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-June/54
   ||8730.html

--- Comment #3 from Alexandre Oliva  ---
Patch with a fix proper at
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548730.html

[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Alexandre Oliva from comment #5)
> but is .dSYM ever generated when no -g is present?

If it was that would e an error, so correctly would cause the test to fail.

That's why I was doing:
   if {[string match "-g*" "$opt"]} {
 set saw_debug 1
   }

If you are going to remove all debug tests, then the .dSYM case would not be
needed indeed

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.1.1
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Priority|P3  |P2

--- Comment #13 from Richard Biener  ---
Fixed.

[Bug fortran/95690] [11 Regression] ICE in set_mem_attributes_minus_bitpos, at emit-rtl.c:2092

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:7d919c33fbd29a996326840dae3b5e093c3190f4

commit r10-8355-g7d919c33fbd29a996326840dae3b5e093c3190f4
Author: Richard Biener 
Date:   Thu Jun 4 13:44:58 2020 +0200

middle-end/95493 - bogus MEM_ATTRS for variable array access

The following patch avoids keeping the inherited MEM_ATTRS when
set_mem_attributes_minus_bitpos is called with a variable ARRAY_REF.
The inherited ones may not reflect the correct offset and neither
does the updated alias-set match the inherited MEM_EXPR.  This all
ends up confusing path-based alias-analysis, causing wrong-code.

The fix is to stop not adopting a MEM_EXPR for certain kinds of
expressions and instead handle everything we can.  There's still
the constant kind trees case which I'm too lazy to look into right
now.  I did refrain from adding SSA_NAME there and instead avoided
calling set_mem_attributes_minus_bitpos when debug expression
expansion ended up expanding a SSA definition RHS which should
already have taken care of setting the appropriate MEM_ATTRS.

It also avoids calling set_mem_attributes on the
DECL_INITIAL of a CONST_DECL which seems pointless since there
cannot be a sensible MEM_EXPR derived from that.  We're overwriting
both other possibly useful info, alias-set and alignment immediately
so the following patch simply removes the call instead of making
the function deal with even more (unexpected) trees that are not
memory accesses.

2020-06-23  Richard Biener  

PR middle-end/95493
PR middle-end/95690
* cfgexpand.c (expand_debug_expr): Avoid calling
set_mem_attributes_minus_bitpos when we were expanding
an SSA name.
* emit-rtl.c (set_mem_attributes_minus_bitpos): Remove
ARRAY_REF special-casing, add CONSTRUCTOR to the set of
special-cases we do not want MEM_EXPRs for.  Assert
we end up with reasonable MEM_EXPRs.
* varasm.c (build_constant_desc): Remove set_mem_attributes call.

* g++.dg/torture/pr95493.C: New testcase.
* g++.dg/torture/pr95493-1.C: Likewise.
* gfortran.dg/pr95690.f90: Likewise.

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:7d919c33fbd29a996326840dae3b5e093c3190f4

commit r10-8355-g7d919c33fbd29a996326840dae3b5e093c3190f4
Author: Richard Biener 
Date:   Thu Jun 4 13:44:58 2020 +0200

middle-end/95493 - bogus MEM_ATTRS for variable array access

The following patch avoids keeping the inherited MEM_ATTRS when
set_mem_attributes_minus_bitpos is called with a variable ARRAY_REF.
The inherited ones may not reflect the correct offset and neither
does the updated alias-set match the inherited MEM_EXPR.  This all
ends up confusing path-based alias-analysis, causing wrong-code.

The fix is to stop not adopting a MEM_EXPR for certain kinds of
expressions and instead handle everything we can.  There's still
the constant kind trees case which I'm too lazy to look into right
now.  I did refrain from adding SSA_NAME there and instead avoided
calling set_mem_attributes_minus_bitpos when debug expression
expansion ended up expanding a SSA definition RHS which should
already have taken care of setting the appropriate MEM_ATTRS.

It also avoids calling set_mem_attributes on the
DECL_INITIAL of a CONST_DECL which seems pointless since there
cannot be a sensible MEM_EXPR derived from that.  We're overwriting
both other possibly useful info, alias-set and alignment immediately
so the following patch simply removes the call instead of making
the function deal with even more (unexpected) trees that are not
memory accesses.

2020-06-23  Richard Biener  

PR middle-end/95493
PR middle-end/95690
* cfgexpand.c (expand_debug_expr): Avoid calling
set_mem_attributes_minus_bitpos when we were expanding
an SSA name.
* emit-rtl.c (set_mem_attributes_minus_bitpos): Remove
ARRAY_REF special-casing, add CONSTRUCTOR to the set of
special-cases we do not want MEM_EXPRs for.  Assert
we end up with reasonable MEM_EXPRs.
* varasm.c (build_constant_desc): Remove set_mem_attributes call.

* g++.dg/torture/pr95493.C: New testcase.
* g++.dg/torture/pr95493-1.C: Likewise.
* gfortran.dg/pr95690.f90: Likewise.

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Fixed, closing.

Thanks for the bug report!

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Thomas Kथà¤nig
:

https://gcc.gnu.org/g:2e4d807085a1cfd68ae79cb1abbe15114964a921

commit r10-8354-g2e4d807085a1cfd68ae79cb1abbe15114964a921
Author: Thomas Koenig 
Date:   Tue Jun 23 08:14:51 2020 +0200

Handle AR_FULL vs. AR_FULL in dependency checking.

Previously, handling of full vs. full references failed to take
AR_FULL vs. AR_FULL into account.  A change in dependency
checking in gcc 10 created a code path that could lead there;
with this patch, this is now correctly handled.

gcc/fortran/ChangeLog:

2020-06-23  Thomas Koenig  

PR fortran/95812
* dependency.c (ref_same_as_full_array): Handle case of AR_FULL
vs. AR_FULL.

gcc/testsuite/ChangeLog:

2020-06-23  Thomas Koenig  

PR fortran/95812
* gfortran.dg/dependency_59.f90: New test.

(cherry picked from commit abcde0a658e17dbbabcb396eaae5a3612e07d401)

[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
but is .dSYM ever generated when no -g is present?

[Bug debug/95841] New: Bad location expression for TLS variable

[horsley1953 at gmail dot com]

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

Bug ID: 95841
   Summary: Bad location expression for TLS variable
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: horsley1953 at gmail dot com
  Target Milestone: ---

In the debuginfo for glibc on fedora 31, I found a location list for a TLS
variable which makes no sense to me. Here is a dump of the DIE:

DIE (0x6d7af4): DW_TAG_compile_unit
   DIE (0x6e4831): DW_TAG_subprogram
  DIE (0x6e4854): DW_TAG_variable
 DW_AT_location(sec_offset) PCrange(0x7f1d329ba0f0-0x7f1d329ba129):
DW_OP_GNU_push_tls_address DW_OP_const8u 80
PCrange(0x7f1d329ba129-0x7f1d329ba1bb): DW_OP_reg6
PCrange(0x7f1d329ba1cb-0x7f1d329ba274): DW_OP_reg6
 DW_AT_name(strp) "replaced_arena"
 DW_AT_decl_column(data1) 0xa
 DW_AT_decl_file(data1) 0x1
 DW_AT_decl_line(data2) 0x2f7
 DW_AT_type(ref4) 0x6dc0ca
 DW_AT_GNU_locviews(sec_offset) 0x10b40e
Previous DIE: 0x6e4831
Next DIE: 0x6e4869

The location expression for the first range has the push_tls operator as the
first thing in the expression, but there is supposed to be a value on the stack
already. It is like the expression is backwards (the variable does appear to be
located at offset 80 in the TLS block).

This is on fedora 31 x86_64:

glibc-common-2.30-11.fc31.x86_64
glibc-2.30-11.fc31.x86_64
glibc-debuginfo-2.30-11.fc31.x86_64

If I compile my own test program with __thread variables, I see their location
expressions as I'd expect them with the constant first, then the push_tls
operator.

The variable above is in the get_free_list() function of arena.c in the malloc
code from glibc.

[Bug testsuite/95840] New: Parallel build fails due to missing "gcc/xgcc"

[enrico.scholz+bugs...@sigma-chemnitz.de]

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

Bug ID: 95840
   Summary: Parallel build fails due to missing "gcc/xgcc"
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enrico.scholz+bugs...@sigma-chemnitz.de
  Target Milestone: ---

Created attachment 48775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48775&action=edit
fixes race in "make -j"

When doing a parallel build of gcc (e.g. for OpenEmbedded and using GNU make
4.2), I get often

| make[1]: /./gcc/xgcc: Command not found
| make[1]: *** [/gcc/cp/Make-lang.in:178: s-selftest-c++] Error 127
| make[1]: *** Waiting for unfinished jobs
| make[1]: Leaving directory '/gcc'
| make: *** [Makefile:4328: all-gcc] Error 2

Makefile does

| include c/Make-lang.in
|   ...
|   C_SELFTEST_DEPS = cc1$(exeext) $(SELFTEST_DEPS)
|   ...
|   s-selftest-c: $(C_SELFTEST_DEPS)
| 
| SELFTEST_DEPS = $(GCC_PASSES) stmp-int-hdrs $(srcdir)/testsuite/selftests

which means that $(SELFTEST_DEPS) are expanded in the language fragment
files before they are defined in the main make file.

Attached patch (against 9.3.0) fixes this.

[Bug tree-optimization/95839] New: Failure to optimize addition of vector elements to vector addition

[gabravier at gmail dot com]

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

Bug ID: 95839
   Summary: Failure to optimize addition of vector elements to
vector addition
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef float __attribute__((vector_size(8))) v2f32;

v2f32 f(v2f32 a, v2f32 b)
{
return (v2f32){a[0] + b[0], a[1] + b[1]};
}

This can be optimized to `return a + b;`. This transformation is done by LLVM,
but not by GCC.

[Bug c++/95838] [10/11 Regression] ICE in lookup_vfn_in_binfo (Segmentation Fault)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Dup

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

[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
Summary|[11 Regression] ICE in  |[10/11 Regression] ICE in
   |lookup_vfn_in_binfo at  |lookup_vfn_in_binfo at
   |gcc/cp/class.c:2459 since   |gcc/cp/class.c:2459 since
   |r11-954-g0ddb93ce77374004   |r11-954-g0ddb93ce77374004
   Target Milestone|11.0|10.2

[Bug c++/95719] [11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #2 from Marek Polacek  ---
*** Bug 95838 has been marked as a duplicate of this bug. ***

[Bug c++/95838] [10/11 Regression] ICE in (Segmentation Fault)

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

  Known to fail||11.0
Summary|[10 Regression] ICE in  |[10/11 Regression] ICE in
   |(Segmentation Fault)|(Segmentation Fault)

--- Comment #2 from Matthias Klose  ---
also seen with trunk 20200616

[Bug c++/95838] [10 Regression] ICE in (Segmentation Fault)

[doko at debian dot org]

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

--- Comment #1 from Matthias Klose  ---
also seen with 20200623:

../watchdog.ii: In member function ‘void g::e()’:
../watchdog.ii:20:5: internal compiler error: Segmentation fault
   20 |   c()
  | ^
0x12f56ac crash_signal
../../src/gcc/toplev.c:328
0x7f9e10e4f7ff ???
./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x922806 lookup_vfn_in_binfo(tree_node*, tree_node*)
../../src/gcc/cp/class.c:2459
0x90f952 build_over_call
../../src/gcc/cp/call.c:8699
0x914077 build_new_method_call_1
../../src/gcc/cp/call.c:10357
0x914378 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.c:10432
0xa4e03c cp_parser_postfix_expression
../../src/gcc/cp/parser.c:7439
0xa50911 cp_parser_unary_expression
../../src/gcc/cp/parser.c:8563
0xa51ca3 cp_parser_cast_expression
../../src/gcc/cp/parser.c:9459
0xa51d90 cp_parser_binary_expression
../../src/gcc/cp/parser.c:9562
0xa52ac9 cp_parser_assignment_expression
../../src/gcc/cp/parser.c:9867
0xa52e66 cp_parser_expression
../../src/gcc/cp/parser.c:10035
0xa56481 cp_parser_expression_statement
../../src/gcc/cp/parser.c:11696
0xa55e3b cp_parser_statement
../../src/gcc/cp/parser.c:11492
0xa568dc cp_parser_statement_seq_opt
../../src/gcc/cp/parser.c:11843
0xa567c0 cp_parser_compound_statement
../../src/gcc/cp/parser.c:11793
0xa69a63 cp_parser_function_body
../../src/gcc/cp/parser.c:23074
0xa69bfd cp_parser_ctor_initializer_opt_and_function_body
../../src/gcc/cp/parser.c:23125
0xa73b20 cp_parser_function_definition_after_declarator
../../src/gcc/cp/parser.c:29016
0xa73947 cp_parser_function_definition_from_specifiers_and_declarator
../../src/gcc/cp/parser.c:28932
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Alexandre Oliva from comment #3)
> Iain,
> 
> Do platforms that use dsymutil support -gsplit-dwarf?

None I am aware of - Darwin should reject -gsplit-dwarf with a diagnostic, so
that configuration should detect missing support correctly there.

> I'm thinking of bringing -g into the gsplit_dwarf variable, so it won't be
> enable without -gsplit-dwarf, and removing other explicit mentions of -g
> from outputs.exp.
> 
> Would this be enough to address the dsymutil left-overs?

I don't think so (hence the code to detect -g* and delete the .dSYM if one is
seen).

==

The motivation for Darwin's 'split' debug is actually different from the
-gsplit-dwarf (and it doesn't solve the object size problem that split dwarf
does).

For the record - the Darwin behaviour is like this;

[when debug is enabled] the static linker [ld64] embeds a list of contributing
object file paths into the executable.  It does not link or include any debug
in the exe (this saves time).

dsymutil [the debug linker] takes the executable, looks up the list of object
files and produces a linked debug object, this is placed into a Darwin file
package (a directory structure with some metadata embedded + the object).  This
is named .dSYM <= but it's a file package, so has to be deleted like a
directory.

On Darwin, debug consumers have two options;

1. Use the table in the exe to pull the debug data directly from the
contributing objects (i.e. never do an actual debug link but just dynamically
satisfy those symbols the user inspects).
  - LLDB and GDB both grok this (newer GDBs might have bit-rotted somewhat
since Adacore is no longer maintaining the Darwin binutils stuff and I am
totally out of cycles to contribute).

2. If the the debug linker has been run and the .dSYM is available, they can
use that.

1) is very efficient for large projects with many object files with long debug
link times, since that stage of linking can be omitted in the
compile/edit/debug loop.

-

BUT, then there's one case where (1) doesn't work - which is when the user
does;

 gcc foo.c bar.o . -g -o x

because the object file created for any source on the command line is
ephemeral, and thus if it's put into the exe that doesn't help - because it
won't be available at debug time.

So Darwin's linker spec force dsymutil to be run for any compile line that
includes a source file, this is a very common circumstance in the test suite,
leading to many .dSYM files that need to be removed.

The patch fragment at comment #1 addresses this for these tests (and Dominque
has a larger patch [which I need to look at] to clean it up in more places in
the test suite).

[Bug c++/95838] New: [10 Regression] ICE in (Segmentation Fault)

[doko at debian dot org]

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

Bug ID: 95838
   Summary: [10 Regression] ICE in (Segmentation Fault)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with the gcc-10 branch 20200616, not with 20200525:

$ cat watchdog.ii
namespace a {
class b {
public:
  virtual ~b();
  virtual void c();
};
} // namespace a
class d {
protected:
  virtual ~d();
};
class f : d, a::b {
public:
  using a::b::c;
};
class g final : f {
  void e();
};
void g::e() {
  c()
};

$ gcc-10 -std=c++17 -Wall -c watchdog.ii 
watchdog.ii: In member function ‘void g::e()’:
watchdog.ii:20:5: internal compiler error: Segmentation fault
   20 |   c()
  | ^
0x7fce9f94b7ff ???
./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7fce9f936e0a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.


Program received signal SIGSEGV, Segmentation fault.
0x00629006 in lookup_vfn_in_binfo(tree_node*, tree_node*) ()
(gdb) bt
#0  0x00629006 in lookup_vfn_in_binfo(tree_node*, tree_node*) ()
#1  0x0061d559 in ?? ()
#2  0x0061eeaf in ?? ()
#3  0x0061f900 in build_new_method_call(tree_node*, tree_node*,
vec**, tree_node*, int, tree_node**, int) ()
#4  0x006fc4fe in ?? ()
#5  0x006e0e5b in ?? ()
#6  0x006e250f in ?? ()
#7  0x006e2823 in ?? ()
#8  0x006e4da9 in ?? ()
#9  0x006ef2a4 in ?? ()
#10 0x006f09f9 in ?? ()
#11 0x006f0ab1 in ?? ()
#12 0x007065a1 in ?? ()
#13 0x00709bae in ?? ()
#14 0x0070aa90 in ?? ()
#15 0x006ed433 in ?? ()
#16 0x00713183 in ?? ()
#17 0x007138a5 in c_parse_file() ()
#18 0x007dc2bc in c_common_parse_file() ()
#19 0x00c30364 in ?? ()
#20 0x00607c3d in toplev::main(int, char**) ()
#21 0x0060b73f in main ()

[Bug c/95835] Wrong line information at Og

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-23
  Component|debug   |c
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||wrong-debug

--- Comment #1 from Richard Biener  ---
In the .gimple dump there's no line 6 on stmt locations but .lower has a new
debug stmt with that line, likely from the goto location of the backedge.

I'm not sure this is "easy" to fix.  Oddly enough at -O0 we don't have
debug stmts and thus this line is not mentioned.

[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
Iain,

Do platforms that use dsymutil support -gsplit-dwarf?

I'm thinking of bringing -g into the gsplit_dwarf variable, so it won't be
enable without -gsplit-dwarf, and removing other explicit mentions of -g from
outputs.exp.

Would this be enough to address the dsymutil left-overs?

[Bug tree-optimization/95487] [10 Regression] ICE: verify_gimple failed (error: invalid vector types in nop conversion) with -O3 -march=skylake-avx512 since r10-1052-gc29c92c789d93848

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.1.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Priority|P3  |P2

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/95308] [10 Regression] ICE: in maybe_canonicalize_mem_ref_addr with -O3 -march=skylake-avx512 since r10-4203-g97c146036750e7cb

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.1.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Fixed.