[Bug c++/92852] New: location references block not in block tree

[marcpawl at gmail dot com]

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

Bug ID: 92852
   Summary: location references block not in block tree
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcpawl at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/Kh3xWR

Add...


#include 
#include 
#include 

 void foo()
 {
 std::ostream& message_stream = std::cout;
 auto data = std::make_tuple(3,4.5,"cd");
 auto format = [&message_stream](auto && x) { message_stream << x ;};
std::apply([&](auto const& ...x){(..., format(x));}, data);
 }

x86-64 gcc (trunk) (Editor #1, Compiler #2) C++
x86-64 gcc (trunk)
-O0 -std=c++17
1

x86-64 gcc (trunk) - 2085ms
#2 with x86-64 gcc (trunk)
: In lambda function:

:12:2: error: location references block not in block tree

   12 |  }

  |  ^

&cout

std::basic_ostream::operator<< (&cout, _1);

during IPA pass: *free_lang_data

:12:2: internal compiler error: verify_gimple failed

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

Compiler returned: 1

[Bug c++/92851] New: Lambda capture of *this with mutable is not mutable

[flast at flast dot jp]

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

Bug ID: 92851
   Summary: Lambda capture of *this with mutable is not mutable
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: flast at flast dot jp
  Target Milestone: ---

GCC rejects assignment to copied *this even lambda is mutable, like a following
code.


void foo() const
{
[*this]() mutable
{
a = 0;
}();
}


https://wandbox.org/permlink/YCzFnI9cDOsPSigf

[Bug c/85055] warn on accessing free memory

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
My analyser reports on this:

pr85055.c: In function ‘f’:
pr85055.c:6:13: warning: use after ‘free’ of ‘foo’ [CWE-416]
[-Wanalyzer-use-after-free]
6 |   return foo[0];
  |  ~~~^~~
  ‘f’: events 1-2
|
|5 |   free(foo);
|  |   ^
|  |   |
|  |   (1) freed here
|6 |   return foo[0];
|  |  ~~
|  | |
|  | (2) use after ‘free’ of ‘foo’; freed at (1)
|

[Bug tree-optimization/80532] warning on pointer access after free

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
My analyzer finds these:

./xgcc -B. -fanalyzer -c ../../src/gcc/testsuite/gcc.dg/analyzer/pr80532.c
-ftime-report
../../src/gcc/testsuite/gcc.dg/analyzer/pr80532.c: In function ‘free_list’:
../../src/gcc/testsuite/gcc.dg/analyzer/pr80532.c:14:28: warning: use after
‘free’ of ‘p’ [CWE-416] [-Wanalyzer-use-after-free]
   14 |   for (p = head; p != 0; p = p->next) /* { dg-warning "use after 'free'
of 'p'" } */
  |  ~~^
  ‘free_list’: events 1-4
|
|   14 |   for (p = head; p != 0; p = p->next) /* { dg-warning "use after
'free' of 'p'" } */
|  |   ^~~~~~
|  |   ||
|  |   |(4) use after ‘free’ of ‘p’; freed at
(3)
|  |   (1) following ‘true’ branch (when ‘p’ is non-NULL)...
|   15 | free (p); /* { dg-message "freed here" } */
|  | 
|  | |
|  | (2) ...to here
|  | (3) freed here
|
../../src/gcc/testsuite/gcc.dg/analyzer/pr80532.c:14:28: note: 8 duplicates
   14 |   for (p = head; p != 0; p = p->next) /* { dg-warning "use after 'free'
of 'p'" } */
  |  ~~^
../../src/gcc/testsuite/gcc.dg/analyzer/pr80532.c: In function ‘foobar’:
../../src/gcc/testsuite/gcc.dg/analyzer/pr80532.c:24:3: warning: double-‘free’
of ‘p’ [CWE-415] [-Wanalyzer-double-free]
   24 |   free (p); /* { dg-warning "double-'free' of 'p'" } */
  |   ^~~~
  ‘foobar’: events 1-2
|
|   22 |   memset (p, 0, n);
|  |   ^~~~
|  |   |
|  |   (1) first ‘free’ here
|   23 |   free (p); /* { dg-message "first 'free' here" } */
|   24 |   free (p); /* { dg-warning "double-'free' of 'p'" } */
|  |   
|  |   |
|  |   (2) second ‘free’ here; first ‘free’ was at (1)
|

[Bug libstdc++/92850] clang has already supported concepts in latest trunk. However it does not define __cpp_concepts macro. I defined it but crashes clang compiler

[euloanty at live dot com]

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

--- Comment #2 from fdlbxtqi  ---
(In reply to Andrew Pinski from comment #1)
> The crash itself should report to llvm project for sure.
> 
> Are you sure concepts are fully implemented in clang?

Yea. I know it is an LLVM bug and should be reported for LLVM project and I
have done that directly to clang concepts author. However, this can still be
useful to check whether ,  implementation in GCC is valid or
not.


"Are you sure concepts are fully implemented in clang?"

Yes, but feature testing macro is missing.

[Bug libstdc++/92850] clang has already supported concepts in latest trunk. However it does not define __cpp_concepts macro. I defined it but crashes clang compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The crash itself should report to llvm project for sure.

Are you sure concepts are fully implemented in clang?

[Bug ipa/92800] IPA escape analysis for structs

[goblock at marvell dot com]

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

Gary Oblock  changed:

   What|Removed |Added

 CC||goblock at marvell dot com

--- Comment #3 from Gary Oblock  ---
What we have started doing at Marvell for mcf is basically a version
of the single-pool scheme of ARM. That is, we'll be turning an array
of structures into a structure of arrays. For the multi-pool
optimization we'll initially be doing an extended version of the
single-pool optimization where instead on a simple index to represent
an array location, we'll use an index and base pair. This approach
yields less performance improvement than ARM's multi-pool
optimization. However, because of being so similar to the single-pool
scheme, it will be expedient to do this before we or others tackle
ARM's more complex transformation.

[Bug c++/92823] Is that possible to optimize C++ exception??????????? I always do not like 2 phases of exception unwind since it does not call destructors.

[euloanty at live dot com]

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

--- Comment #4 from fdlbxtqi  ---
I know it is mostly a clang bug. However, jwakely you can try to use clang to
test your code.

[Bug libstdc++/92850] New: clang has already supported concepts in latest trunk. However it does not define __cpp_concepts macro. I defined it but crashes clang compiler

[euloanty at live dot com]

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

Bug ID: 92850
   Summary: clang has already supported concepts in latest trunk.
However it does not define __cpp_concepts macro. I
defined it but crashes clang compiler
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

#include
#include
#include

int main()
{
std::ranges::contiguous_range auto& vec(std::vector());
}

//fails to compile with  clang++ -o a a.cc -Ofast -std=c++2a -s

a.cc:7:7: error: no member named 'ranges' in namespace 'std'
std::ranges::contiguous_range auto& vec(std::vector());
~^
a.cc:7:41: warning: parentheses were disambiguated as a function declaration
[-Wvexing-parse]
std::ranges::contiguous_range auto& vec(std::vector());
   ^~~~
a.cc:7:42: note: add a pair of parentheses to declare a variable
std::ranges::contiguous_range auto& vec(std::vector());
^
( )
1 warning and 1 error generated.

//crashes with clang++ -o a a.cc -Ofast -std=c++2a -s -D__cpp_concepts=201907L

In file included from a.cc:1:
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:73:10:
error: expected expression
  && requires(add_rvalue_reference_t<_From> (&__f)()) {
 ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:81:10:
error: use of undeclared identifier 'convertible_to'
  && convertible_to<_Tp, common_reference_t<_Tp, _Up>>
 ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:82:10:
error: use of undeclared identifier 'convertible_to'
  && convertible_to<_Up, common_reference_t<_Tp, _Up>>;
 ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:88:10:
error: expected expression
  && requires {
 ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:128:10:
error: expected expression
  && requires(_Lhs __lhs, _Rhs&& __rhs) {
 ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:127:10:
error: use of undeclared identifier 'common_reference_with'
  && common_reference_with<__detail::__cref<_Lhs>, __detail::__cref<_Rhs>>
 ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:144:10:
error: expected expression
  && requires
 ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:153:39:
error: use of undeclared identifier 'convertible_to'
= constructible_from<_Tp, _Tp> && convertible_to<_Tp, _Tp>;
  ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:158:9:
error: use of undeclared identifier 'move_constructible'
  = move_constructible<_Tp>
^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:159:43:
error: use of undeclared identifier 'convertible_to'
  && constructible_from<_Tp, _Tp&> && convertible_to<_Tp&, _Tp>
  ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:160:49:
error: use of undeclared identifier 'convertible_to'
  && constructible_from<_Tp, const _Tp&> && convertible_to
^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:161:48:
error: use of undeclared identifier 'convertible_to'
  && constructible_from<_Tp, const _Tp> && convertible_to;
   ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:175:7:
error: expected expression
  && requires(_Tp&& __t, _Up&& __u) {
 ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:195:13:
error: use of undeclared identifier '__adl_swap'
  requires __adl_swap<_Tp, _Up>
   ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:197:11:
error: use of undeclared identifier 'move_constructible'
  && move_constructible>
 ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/concepts:198:11:
error: use of undeclared identifier 'assignable_from'
  && assignable_from<_Tp, remove_reference_t<_Tp>>)
   

[Bug c++/92831] CWG1299 extend_ref_init_temps_1 punts on COND_EXPRs

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec  6 23:43:45 2019
New Revision: 279069

URL: https://gcc.gnu.org/viewcvs?rev=279069&root=gcc&view=rev
Log:
PR c++/92831
* call.c (build_conditional_expr_1): For ?: with omitted middle
operand use cp_stabilize_reference if arg1 is glvalue_p rather than
just if it is lvalue_p.

* g++.dg/ext/temp-extend1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/temp-extend1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #6 from Peter Bergner  ---
CCing Vlad (and Jeff) for LRA questions below.

Here is a slightly smaller test case that ICEs using -O2
-fstack-protector-strong -mcpu=power8:

typedef union
{
  __ieee128 a;
  int b;
} c;

__ieee128
d (__ieee128 x)
{
  __ieee128 g;
  c h;
  h.a = x;
  g = h.b & 5;
  h.b = g;
  if (g)
return x - x;
  return h.a;
}


After IRA, we have the following:

Disposition:
3:r121 l0   mem8:r133 l066

(insn 44 13 2 2 (set (reg:KF 133)
 (reg:KF 66 2 [ xD.2842 ])) "pr92796.i":9:1 1112
{vsx_movkf_64bit})
(insn 2 44 37 2 (set (reg/v:KF 121 [ xD.2842 ])
 (reg:KF 133)) "pr92796.i":9:1 1112 {vsx_movkf_64bit}
 (expr_list:REG_DEAD (reg:KF 133)))
...


Hard reg 66 is used after insn 2, but since regs 133 and 66 are connected
via a copy, they do not conflict, which is what allows 133 to be assigned
to hard reg 66 (a good thing generally).  This is all fine up to this point.

Since pseudo 121 is spilled, LRA generates reloads for insn 2 and we end
up with the following rtl:


(insn 44 13 53 2 (set (reg:KF 133)
  (reg:KF 66 2 [ xD.2842 ])) "pr92796.i":9:1 1112
{vsx_movkf_64bit})
(insn 53 44 2 2 (set (reg:DI 144)
 (plus:DI (reg/f:DI 110 sfp)
  (const_int 32 [0x20]))) "pr92796.i":9:1 66
{*adddi3})
(insn 2 53 37 2 (set (mem/c:KF (reg:DI 144) [4 %sfpD.2858+-16 S16 A128])
 (reg:KF 133)) "pr92796.i":9:1 1094 {*vsx_le_perm_store_kf}
(expr_list:REG_DEAD (reg:DI 144)))
...



Here is where we run into a problem.  The pattern *vsx_le_perm_store_kf's
source operand constraint "+wa.r", marks the source operand as an
input/output operand.  That now means that pseudo 133 should now be
made to conflict with the hard registers live at that point (ie, 66).
Since pseudo 133 is assigned to hard reg 66, we somehow need to reassign
pseudo 133.  However, LRA seems to think insn 2 satisfies its constraints,
so it happily continues on until we reach the assertion at lra-assigns.c:1646
and we ICE:

for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
  if (lra_reg_info[i].nrefs != 0
  && reg_renumber[i] >= 0
  && overlaps_hard_reg_set_p (lra_reg_info[i].conflict_hard_regs,
  PSEUDO_REGNO_MODE (i), reg_renumber[i]))
gcc_unreachable ();

Vlad (or Jeff), can you point me to where this is supposed to be handled?
I don't think I see where LRA verifies the reg_renumber[regno] values are still
valid with respect to the new pattern constraints for the insns that are
modified by spilling.

lra_reg_info[133].conflict_hard_regs does contain 66, so LRA knows it conflicts
with reg 66, but it never seems to use that information as a sign that pseudo
133 needs reassigning.

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[pinskia at gcc dot gnu.org]

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

--- Comment #23 from Andrew Pinski  ---
(In reply to Maxim Kuvyrkov from comment #21)
> 
> Is there a way to fix the problem gcc-9-branch in less intrusive way?

Could this be an alignment issue?

[Bug go/92810] Compiling GCC go for aarch64_be-marvell-linux-gnu fails

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Testing that (and see what the next failure is)

After the above patch, there are no build failures; I have not tried to run the
testsuite yet.

[Bug tree-optimization/92841] Optimize -fstack-protector-strong code generation a bit

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Yea, if we were to split it, then we'd probably have to add barriers to keep
the scheduler from moving things around.  And if we're adding barriers then the
split is of little value anyway.

[Bug c++/92451] [10 Regression] ICE: Segmentation fault (in add_candidates)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Dec  6 22:12:51 2019
New Revision: 279067

URL: https://gcc.gnu.org/viewcvs?rev=279067&root=gcc&view=rev
Log:
Add test for c++/92451.

This was ICEing from r277865 to r278786.

* g++.dg/overload/error4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/overload/error4.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/92451] [10 Regression] ICE: Segmentation fault (in add_candidates)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug go/92810] Compiling GCC go for aarch64_be-marvell-linux-gnu fails

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Next error:
/bajas/pinskia/src/toolchain-10/scripts/../src/libgo/go/internal/syscall/unix/getrandom_linux.go:35:34:
error: reference to undefined name ‘randomTrap’
   35 |  r1, _, errno := syscall.Syscall(randomTrap,
  |  ^
make[7]: Entering directory
'/bajas/pinskia/src/toolchain-10/build-aarch64_be-marvell-linux-gnu/aarch64_be-marvell-linux-gnu/ilp32/libsanitizer'
Makefile:2826: recipe for target 'internal/syscall/unix.lo' failed
make[5]: *** [internal/syscall/unix.lo] Error 1


go/internal/syscall/unix/getrandom_linux_generic.go looks like it is not being
used.

Something like:
diff --git a/libgo/go/internal/syscall/unix/getrandom_linux_generic.go
b/libgo/go/internal/syscall/unix/getrandom_linux_generic.go
index f70ada31a98..fa41e64116a 100644
--- a/libgo/go/internal/syscall/unix/getrandom_linux_generic.go
+++ b/libgo/go/internal/syscall/unix/getrandom_linux_generic.go
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.

-// +build linux,arm64 linux,nios2 linux,riscv64
+// +build linux,arm64 linux,arm64be linux,nios2 linux,riscv64

 package unix


 CUT 
Testing that (and see what the next failure is)

[Bug c++/92451] [10 Regression] ICE: Segmentation fault (in add_candidates)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed by r278786, will add the test.

[Bug c++/92849] call to 'operator()' incorrectly considered ambiguous, when inherited twice with different type parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Closing thus.

[Bug c++/92849] call to 'operator()' incorrectly considered ambiguous, when inherited twice with different type parameters

[kholdstare0.0 at gmail dot com]

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

--- Comment #3 from Alexander Kondratskiy  ---
I think you're right. I think the bug can be closed.

[Bug c++/92823] Is that possible to optimize C++ exception??????????? I always HATE 2 phases of exception unwind

[euloanty at live dot com]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Richard Biener from comment #1)
> It's called "exception" handling.  If you use an "exception" on the fast path
> you are doing something wrong.

If this succeeds, we will be able to directly use POSIX APIs in C++ with an
exception thrown without ANY wrapper. That will be a great improvement to our
language.

[Bug c++/92823] Is that possible to optimize C++ exception??????????? I always HATE 2 phases of exception unwind

[euloanty at live dot com]

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

--- Comment #2 from fdlbxtqi  ---
(In reply to Richard Biener from comment #1)
> It's called "exception" handling.  If you use an "exception" on the fast path
> you are doing something wrong.

Have you read recent papers about deterministic exceptions? It all depends on
the use case.

I thought the same before. Now I do not.

However, I would like to try these solutions for both. I think the time for GCC
to start a new branch for a deterministic exception TS in C/C++ just like C++
module TS and coroutine TS.

[Bug c++/92849] call to 'operator()' incorrectly considered ambiguous, when inherited twice with different type parameters

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
If name lookup finds the name in multiple base classes, the lookup is
ambiguous. Overload resolution is not done to determine if one function is a
better match than the other.

By pulling them all into the derived class with a using-declaration it means
name lookup finds them all in the same scope, and then applies overload
resolution to find the best one.

So I think GCC is correct.

[Bug c++/92847] [C++20] ambiguous overload for ‘operator==’ ?

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Reduced:

template
struct A {
  A() {}

  template
A(const A&) {}

  bool operator==(const A&) const { return true; }
};

A a;
A b;
auto c = (a == b);

Compiled with -std=gnu++2a:

cmp.cc:13:13: error: ambiguous overload for 'operator==' (operand types are
'A' and 'A')
   13 | auto c = (a == b);
  |   ~ ^~ ~
  |   ||
  |   |A
  |   A
cmp.cc:8:8: note: candidate: 'bool A::operator==(const A&) const [with T
= int]' (reversed)
8 |   bool operator==(const A&) const { return true; }
  |^~~~
cmp.cc:8:8: note: candidate: 'bool A::operator==(const A&) const [with T
= const int]'

[Bug c++/92847] [C++20] ambiguous overload for ‘operator==’ ?

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Although it's still ambiguous with that fixed. There are some known issues with
the default comparisons feature in C++20, this might be one of them.

[Bug c++/92847] [C++20] ambiguous overload for ‘operator==’ ?

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Laurent Stacul from comment #0)
> bool operator==(const A&) { return true; }

This member function should be const.

[Bug c++/92849] call to 'operator()' incorrectly considered ambiguous, when inherited twice with different type parameters

[kholdstare0.0 at gmail dot com]

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

--- Comment #1 from Alexander Kondratskiy  ---
Actually, this might be bogus. If I do an explicit `using`, everything works:

#include 

template 
struct declfunc;

template 
struct declfunc
{
Result operator() (Args...);
};

template 
struct decloverload
: declfunc...
{
using declfunc::operator()...;
};

using overload_set = decloverload;
static_assert(std::is_invocable_v);

Godbolt link: https://godbolt.org/z/VJwPV4

[Bug c++/92831] CWG1299 extend_ref_init_temps_1 punts on COND_EXPRs

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec  6 20:16:27 2019
New Revision: 279064

URL: https://gcc.gnu.org/viewcvs?rev=279064&root=gcc&view=rev
Log:
PR c++/92831 - CWG 1299, not extending temporary lifetime for ?:
* cp-tree.h (extend_ref_init_temps): Add a new argument with NULL
default arg.
* call.c (set_up_extended_ref_temp): Add COND_GUARD argument, pass it
down to extend_ref_init_temps.  Before pushing cleanup, if COND_GUARD
is non-NULL, create a bool temporary if needed, initialize to false
and guard the cleanup with the temporary being true.
(extend_ref_init_temps_1): Add COND_GUARD argument, pass it down
to recursive calls and set_up_extended_ref_temp.  Handle COND_EXPR.
(extend_ref_init_temps): Add COND_GUARD argument, pass it down to
recursive calls and to extend_ref_init_temps_1.

* g++.dg/cpp0x/temp-extend2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/temp-extend2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/testsuite/ChangeLog

[Bug c++/92849] New: call to 'operator()' incorrectly considered ambiguous, when inherited twice with different type parameters

[kholdstare0.0 at gmail dot com]

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

Bug ID: 92849
   Summary: call to 'operator()' incorrectly considered ambiguous,
when inherited twice with different type parameters
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kholdstare0.0 at gmail dot com
  Target Milestone: ---

Minimal test case:

#include 

template 
struct declfunc;

template 
struct declfunc
{
Result operator() (Args...);
};

template 
struct decloverload
: declfunc...
{ };

using overload_set = decloverload;
static_assert(std::is_invocable_v);

Expected result: compilation succeeds. See the godbolt link below, and try it
with clang - clang accepts the code since version 4

Actual result:

/opt/compiler-explorer/gcc-9.2.0/include/c++/9.2.0/type_traits:2336:26: error:
request for member 'operator()' is ambiguous

 2336 |   std::declval<_Fn>()(std::declval<_Args>()...)

  |   ~~~^~

:9:16: note: candidates are: 'Result declfunc::operator()(Args ...) [with Result = void; Args = {int, int}]'

9 | Result operator() (Args...);

  |^~~~

:9:16: note: 'Result declfunc::operator()(Args ...) [with Result = void; Args = {int}]'

:18:24: error: static assertion failed

   18 | static_assert(std::is_invocable_v);

  |   ~^

Compiler returned: 1


Godbolt link with test case as well as '-E' preprocessor output:
https://godbolt.org/z/D9nTBr


I suspect the ambiguity comes from the fact that two call operators are
inherited from the same class (`declfunc` in this case), and the call operators
"look the same" - i.e both are `Result operator() (Args...)`. However since
`declfunc` is instantiated with different template paramaters, the concrete
instances of the call operators are in fact different - Args is `{int}` in one
case and `{int, int}` in another. The compiler mentions this in the error
message. Perhaps the overload check should descend deeper (using the concrete
parameters for `Args...`)

[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Fri, Dec 06, 2019 at 06:48:04PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805
> 
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to kargl from comment #2)
> > Index: gcc/fortran/primary.c
> > ===
> > --- gcc/fortran/primary.c   (revision 279052)
> > +++ gcc/fortran/primary.c   (working copy)
> > @@ -90,16 +90,25 @@ match_kind_param (int *kind, int *is_iso_c)
> >  static int
> >  get_kind (int *is_iso_c)
> >  {
> > +  char c;
> >int kind;
> >match m;
> >  
> >*is_iso_c = 0;
> >  
> > +  c = gfc_peek_ascii_char ();
> > +  if (gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
> > +{
> > +  gfc_error ("Invalid kind type parameter syntax at %C");
> > +  return -1;
> > +}
> > +
> >if (gfc_match_char ('_') != MATCH_YES)
> >  return -2;
> >  
> > -  m = match_kind_param (&kind, is_iso_c);
> > -  if (m == MATCH_NO)
> > +  c = gfc_peek_ascii_char ();
> > +  if ((gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
> > +  || (m = match_kind_param (&kind, is_iso_c)) == MATCH_NO)
> >  gfc_error ("Missing kind-parameter at %C");
> >  
> >return (m == MATCH_YES) ? kind : -1;
> 
> Patch isn't quite correct.  The first gfc_error should probably be removed and
> return -2.
> 

Tested.

Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 279052)
+++ gcc/fortran/primary.c   (working copy)
@@ -90,16 +90,22 @@ match_kind_param (int *kind, int *is_iso_c)
 static int
 get_kind (int *is_iso_c)
 {
+  char c;
   int kind;
   match m;

   *is_iso_c = 0;

+  c = gfc_peek_ascii_char ();
+  if (gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
+return -2;
+
   if (gfc_match_char ('_') != MATCH_YES)
 return -2;

-  m = match_kind_param (&kind, is_iso_c);
-  if (m == MATCH_NO)
+  c = gfc_peek_ascii_char ();
+  if ((gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
+  || (m = match_kind_param (&kind, is_iso_c)) == MATCH_NO)
 gfc_error ("Missing kind-parameter at %C");

   return (m == MATCH_YES) ? kind : -1;

[Bug go/92842] [10 Regression] libgo build failure on i686-gnu

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
Should be fixed now by SVN revision 279062.

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #13 from Ian Lance Taylor  ---
Fixed again.  This time for sure.

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[ian at gcc dot gnu.org]

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

--- Comment #12 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Dec  6 19:52:46 2019
New Revision: 279063

URL: https://gcc.gnu.org/viewcvs?rev=279063&root=gcc&view=rev
Log:
PR go/92820
runtime: only build go-context for x86 GNU/Linux

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/210258

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/Makefile.am
trunk/libgo/Makefile.in

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[ian at gcc dot gnu.org]

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

--- Comment #6 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Dec  6 19:37:39 2019
New Revision: 279062

URL: https://gcc.gnu.org/viewcvs?rev=279062&root=gcc&view=rev
Log:
PR go/29842
runtime: update HURD support for mOS now being embedded

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/210285

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/runtime/os_hurd.go

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
Thank you, Andreas.  I've committed the patch with your changes in the test.

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Dec  6 19:30:37 2019
New Revision: 279061

URL: https://gcc.gnu.org/viewcvs?rev=279061&root=gcc&view=rev
Log:
2019-12-06  Andreas Krebbel  
Vladimir Makarov  

PR rtl-optimization/92176
* lra.c (simplify_subreg_regno): Don't permit unconditional
changing mode for LRA too.

2019-12-06  Andreas Krebbel  
Vladimir Makarov  

PR rtl-optimization/92176
* gcc.target/s390/pr92176.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/s390/pr92176.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug go/92810] Compiling GCC go for aarch64_be-marvell-linux-gnu fails

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
The configure script should work now, but I don't know what other problems you
will encounter.

[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Index: gcc/fortran/primary.c
> ===
> --- gcc/fortran/primary.c (revision 279052)
> +++ gcc/fortran/primary.c (working copy)
> @@ -90,16 +90,25 @@ match_kind_param (int *kind, int *is_iso_c)
>  static int
>  get_kind (int *is_iso_c)
>  {
> +  char c;
>int kind;
>match m;
>  
>*is_iso_c = 0;
>  
> +  c = gfc_peek_ascii_char ();
> +  if (gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
> +{
> +  gfc_error ("Invalid kind type parameter syntax at %C");
> +  return -1;
> +}
> +
>if (gfc_match_char ('_') != MATCH_YES)
>  return -2;
>  
> -  m = match_kind_param (&kind, is_iso_c);
> -  if (m == MATCH_NO)
> +  c = gfc_peek_ascii_char ();
> +  if ((gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
> +  || (m = match_kind_param (&kind, is_iso_c)) == MATCH_NO)
>  gfc_error ("Missing kind-parameter at %C");
>  
>return (m == MATCH_YES) ? kind : -1;

Patch isn't quite correct.  The first gfc_error should probably be removed and
return -2.

[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-06
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 279052)
+++ gcc/fortran/primary.c   (working copy)
@@ -90,16 +90,25 @@ match_kind_param (int *kind, int *is_iso_c)
 static int
 get_kind (int *is_iso_c)
 {
+  char c;
   int kind;
   match m;

   *is_iso_c = 0;

+  c = gfc_peek_ascii_char ();
+  if (gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
+{
+  gfc_error ("Invalid kind type parameter syntax at %C");
+  return -1;
+}
+
   if (gfc_match_char ('_') != MATCH_YES)
 return -2;

-  m = match_kind_param (&kind, is_iso_c);
-  if (m == MATCH_NO)
+  c = gfc_peek_ascii_char ();
+  if ((gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
+  || (m = match_kind_param (&kind, is_iso_c)) == MATCH_NO)
 gfc_error ("Missing kind-parameter at %C");

   return (m == MATCH_YES) ? kind : -1;

[Bug c/92773] [8/9/10 Regression] GCC compilation with big array / header is infinite

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
For the kernel module, I'd suggest just fixing the external tool, so it emits {
{ 0x.., 0x.. } },
lines instead of { 0x.., 0x.. }, lines.

[Bug c/92773] [8/9/10 Regression] GCC compilation with big array / header is infinite

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
So, historical data regarding #c8. Before r211289, it used to print a single
-Wmissing-brace warning, starting with r211289 aka PR53119 it started printing
73 of these + 73 near initialization + 432 in expansion of macro notes.
Starting with r244061 we only emit 73 warnings and no near initialization
warnings and no in expansion of macro notes and that is the case until current
trunk.

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Rather than suppressing the warning via a pragma, would replacing the call to
  deps_add_target (d, "-", 1);
with
  d->targets.push (xstrdup (t));
be a better solution?  Unless I've overlooked something it should have the same
effect because "-" has no path separator in it and so apply_vpath won't do
anything with it and neither will deps_add_target.

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
Here's a slightly more reduced example that reproduces a similar warning:

$ cat pr92828.C && gcc -O2 -S -Wall pr92828.C
extern int f (void);

static const char*
g (unsigned n, const char *t)
{
  for (unsigned i = n; i--; )
{
  if (f ())
{
  const char *p = t + n;
  if (p[1] == '.' && p[2] == '.' && p[3] == '/')
goto not_this_one;
  break;
}

not_this_one:;
}

  return t;
}

void h (unsigned n)
{
  g (n, "-");
}
pr92828.C: In function ‘void h(unsigned int)’:
pr92828.C:11:26: warning: array subscript [2, 4294967297] is outside array
bounds of ‘const char [2]’ [-Warray-bounds]
   11 |if (p[1] == '.' && p[2] == '.' && p[3] == '/')
  |   ~~~^
pr92828.C:11:41: warning: array subscript [3, 4294967298] is outside array
bounds of ‘const char [2]’ [-Warray-bounds]
   11 |if (p[1] == '.' && p[2] == '.' && p[3] == '/')
  |  ~~~^

[Bug tree-optimization/92768] [8/9 Regression] Maybe a wrong code for vector constants

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] Maybe a |[8/9 Regression] Maybe a
   |wrong code for vector   |wrong code for vector
   |constants   |constants

--- Comment #18 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug libgomp/92848] New: [OpenACC] Memory leak for simple 'acc_create', 'acc_delete' sequence

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92848
   Summary: [OpenACC] Memory leak for simple 'acc_create',
'acc_delete' sequence
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

By means of a simple test using the OpenACC Profiling Interface, I noticed that
for a simple 'acc_create', 'acc_delete' sequence, we're leaking the device
memory.  That's bad, of course; often such things are done in a loop (with some
computation in between, of course).

This seems to get fixed as part of Julian's big "OpenACC reference count
overhaul" patch, but we need to understand what exactly is going on (I think I
know), and, quite obviously, we need test cases (I have some).

[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons

[vgupta at synopsys dot com]

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

--- Comment #12 from Vineet Gupta  ---
oops the ARC bug is (PR 92846) not (PR 92845)

[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons

[vgupta at synopsys dot com]

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||vgupta at synopsys dot com

--- Comment #11 from Vineet Gupta  ---
ARC gcc backend suffers from this and I've created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92845 and also a tentative fix
which passes gcc.dg/torture/pr52451.c 

However I'm curious that the test uses qNaN. What is the expected behavior for
sNaN. If you tweak the testcase  slightly as follows:

diff --git a/gcc/testsuite/gcc.dg/torture/pr52451.c
b/gcc/testsuite/gcc.dg/torture/pr52451.c

-  volatile TYPE nan##S = __builtin_nan##S ("");\
+  volatile TYPE nan##S = __builtin_nans##S ("");   \

With that even on ARM (RPI3) it now fails for the "quite" C operations "==" and
"!=" and isless(),isgreater(),islessequal(),isgreaterequal().

Is that expected, OK ? I guess there's no easy to fix this unless hardware
supports the 3 varaints or glibc code has a way to clear exception in certain
cases.

[Bug target/92846] [ARC] gloating point compares not generating Invalid Operand

[vgupta at synopsys dot com]

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

--- Comment #2 from Vineet Gupta  ---
Created attachment 47438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47438&action=edit
proposed fix

Ran full glibc tessuite with this: No regressions
gcc dejagnu test pr52451.c passes too

[Bug fortran/92775] [8/9 Regression] Incorrect expression in DW_AT_byte_stride on an array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] |[8/9 Regression] Incorrect
   |Incorrect expression in |expression in
   |DW_AT_byte_stride on an |DW_AT_byte_stride on an
   |array   |array

--- Comment #7 from Jakub Jelinek  ---
Regression fixed on the trunk, though it would be nice to optimize again the
most common case where we know we don't need to load up descr->span.

[Bug c++/92847] New: [C++20] ambiguous overload for ‘operator==’ ?

[laurent.stacul at gmail dot com]

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

Bug ID: 92847
   Summary: [C++20] ambiguous overload for ‘operator==’ ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: laurent.stacul at gmail dot com
  Target Milestone: ---

Hello,

Compiling the following reproducer with the gcc trunk and the option
-std=gnu++2a (c++2a), I get the following error:

#include 

template
class A {
public:
A() {}

template
A(const A&) {}

bool operator==(const A&) { return true; }
};

int main(int argc, const char *argv[])
{
A a;
A b;
if (a == b) {}
return 0;
}

a.cpp: In function ‘int main(int, const char**)’:
a.cpp:25:11: error: ambiguous overload for ‘operator==’ (operand types are
‘A >’ and
‘A >’)
   25 | if (a == b) {}
  | ~ ^~ ~
  | ||
  | |A>
  | A>
a.cpp:15:10: note: candidate: ‘bool A::operator==(const A&) [with T =
std::__cxx11::basic_string]’
   15 | bool operator==(const A&) {
  |  ^~~~
a.cpp:15:10: note: candidate: ‘bool A::operator==(const A&) [with T =
const std::__cxx11::basic_string]’

When I compile with gcc 9.2, I have no issue. The generated code is the one I
expect (implicit call to the constructor A, std::allocator >
const>::A,
std::allocator > >(A, std::allocator > > const&) then call to the
A, std::allocator
> const>::operator==(A,
std::allocator > const> const&).

Can you tell me which C++ 20 rule I am breaking here ?

Thanks in advance for your reply,
Laurent

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
As elsewhere, the .note should be guarded on Linux or so, either
#ifdef __linux__
or something similar.  And the second thing is that @progbits is only
recognized on some platforms, others need %progbits, but ARM isn't the only
one, e.g. AArch64, SH, microblaze, and I believe SPARC Solaris as need that
too.  Maybe PA too?
Maybe %progbits works everywhere, e.g.
libphobos/libdruntime/config/common/threadasm.S
uses
#if (__linux__ || __FreeBSD__ || __NetBSD__ || __DragonFly__) && __ELF__
.section .note.GNU-stack,"",%progbits
#endif

[Bug target/92846] [ARC] gloating point compares not generating Invalid Operand

[vgupta at synopsys dot com]

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

--- Comment #1 from Vineet Gupta  ---
Test case:

int f(double x, double y)
{
return x > y;  // expected FDCMPF (qNaN, sNaN)
}

int f2(double x, double y)
{
return __builtin_isgreater(x, y);  // expected FDCMP (only sNan)
}

[Bug target/92846] New: [ARC] gloating point compares not generating Invalid Operand

[vgupta at synopsys dot com]

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

Bug ID: 92846
   Summary: [ARC] gloating point compares not generating Invalid
Operand
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vgupta at synopsys dot com
CC: claziss at gcc dot gnu.org, vgupta at synopsys dot com
  Target Milestone: ---

This is similar to issues reported for other targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77918

The FDCMP instructions generated raised Invalid operand only for sNaN. This
causes glibc testsuite failures test-{double,float,...}-iseqsig which test both
qNaN and sNaN and expect either to pass.

[Bug c++/92837] ICE on syntax error in requires clause, in cp_parser_constraint_primary_expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-06
 CC||asutton at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This is an incorrect assumption in cp_parser_constraint_primary_expression.  It
assumes that when doing a tentative parse that the returned expr will always be
error_mark_node if there are any errors, but that is not the case, e.g. if
there is just missing closing ) it can simulate an error which later causes
cp_parse_definitely to fail, yet expr is still not error_mark_node and pce can
still be pce_ok.

[Bug target/92845] New: [ARC] gcc not generating hardware compare instruction FDCMP for -mcpu=hs38_linux

[vgupta at synopsys dot com]

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

Bug ID: 92845
   Summary: [ARC] gcc not generating hardware compare instruction
FDCMP for -mcpu=hs38_linux
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vgupta at synopsys dot com
CC: claziss at gcc dot gnu.org, claziss at gmail dot com
  Target Milestone: ---

Test case:

int f(double x, double y)
{
return x > y;
}

arc-linux-gcc -mcpu=hs38_linux -c -O2 --save-temps

push_s blink
bl @__gtdf2;1
setgt r0, r0, 0
pop_s blink
j_s [blink]

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[iii at linux dot ibm.com]

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

--- Comment #22 from Ilya Leoshkevich  ---
Hello Maxim,

Sorry about that!

I don't think it's possible to simply move jump threading back, since
it's not correct to have it where it used to be.  So I will build and
run the new and the old 400.perlbench on gcc compile farm and see what
else I can do about the difference.

Best regards,
Ilya

[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
(In reply to jules from comment #2)
> I don't think your example is valid

Which one, specifically?

> but I'm not sure it will be fail in
> quite the right way with the current version of my refcount overhaul patch.

> Actually I think the acc_map_data implementation using REFCOUNT_INFINITY is
> probably wrong too.

Maybe, but adjusting that can wait until later.  And in particular,
incrementally.

> I will try changing the implementation as follows:
> 
> - calls to acc_delete with the structured reference count being non-zero (or
> infinity in the case of '#pragma acc declare'd data) should raise an error.

Are you sure about that?  Per my reading as detailed above, that would actually
be valid, and be a no-op.  (That's also what I'm asking about in
, using the very same
text/example.)

> - acc_map_data should use GOMP_MAP_VARS_OPENACC_ENTER_DATA instead of
> forcing the refcount to infinity (i.e., making the behaviour the same as
> "enter data (create)").
> 
> Does that match your understanding of what the behaviour should be?

I still have to look into that one (which may have changed between OpenACC 2.6
and later?), but let's defer that one until later, as mentioned above.

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #21 from Maxim Kuvyrkov  ---
(In reply to iii from comment #18)
> Author: iii
> Date: Mon Oct 28 13:09:54 2019
> New Revision: 277515
> 
> URL: https://gcc.gnu.org/viewcvs?rev=277515&root=gcc&view=rev
> Log:
> Move jump threading before reload

Hi Ilya,

This patch regresses performance of SPEC CPU2006's 400.perlbench on
aarch64-linux-gnu -O3 by 5% with most of the slowdown in the hottest function
S_regmatch (this is for gcc-9-branch).

benchmark,symbol,rel_sample,rel_size,results-0:sample,results-1:sample,results-0:size,results-1:size
400.perlbench,perlbench_base.default, 105,100,9281,9761,1281408,1285488
400.perlbench,[.] S_regmatch, 107,100,3641,3910,16460,16460

Is there a way to fix the problem gcc-9-branch in less intrusive way?

[Bug target/89838] [ARC] ICE building glibc testsuite

[vgupta at synopsys dot com]

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

--- Comment #3 from Vineet Gupta  ---
Can this be closed ?

[Bug libfortran/92836] segfault with inquire()

[jb at gcc dot gnu.org]

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

--- Comment #13 from Janne Blomqvist  ---
To clarify my previous message, instead of

inquire(..., exist=exist)
if (exist) then
   open(...)
else
   ! Handle file not existing
end if

you can do

open(..., status='old', iostat=stat)
if (stat /= o) then
   ! Handle file not existing
end if

If you open a file with status='old', then opening the file will fail if it
doesn't exist, and thus there is no race between checking whether the file
exists with inquire and trying to open it.

Similarly, if you want to make sure that the file is created, i.e. that it
doesn't exist previously, instead of doing

inquire(..., exist=exist)
if (!exist) then
open(...)
else
! Handle if the file does exist
end if

You should do

open(..., status='new', iostat=stat)
if (stat /= 0) then
! Handle file existing
end if

With status='new', the file will be created and opened with O_CREAT|O_EXCL
which is guaranteed to be atomic.

[Bug tree-optimization/92841] Optimize -fstack-protector-strong code generation a bit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The reason for the xor is increased security, shorten the lifetime of the
dangerous value in a register as much as possible, so that e.g. signal handlers
or whatever else don't spill it somewhere from where an exploit could pick it
up.
The xor is done intentionally in the same pattern, so it is never split.

The pattern looks like:
(define_insn "@stack_protect_set_1_"
  [(set (match_operand:PTR 0 "memory_operand" "=m")
(unspec:PTR [(match_operand:PTR 1 "memory_operand" "m")]
UNSPEC_SP_SET))
   (set (match_scratch:PTR 2 "=&r") (const_int 0))
   (clobber (reg:CC FLAGS_REG))]
  ""
  "mov{}\t{%1, %2|%2, %1}\;mov{}\t{%2, %0|%0,
%2}\;xor{l}\t%k2, %k2"
  [(set_attr "type" "multi")])

So, without compromising security, the only thing that could be done is add
pattern which would be similar to the above, except that it would use
match_operand instead of match_scratch for the second set and would use some
input operand which could say be another GPR or a constant and perhaps could
use a mode other than PTR if needed and peephole2 to match it.  I think it
would be a bad idea to try to split it, such that the two modes would be in one
pattern and the mov would be another one, because then e.g. the scheduler could
move it away etc.

[Bug libfortran/92836] segfault with inquire()

[abensonca at gmail dot com]

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

--- Comment #12 from Andrew Benson  ---
(In reply to Thomas Koenig from comment #11)
> (In reply to Andrew Benson from comment #10)
> > (In reply to Thomas Koenig from comment #8)
> > My reasoning for using INQUIRE to check the existence of the file
> > is that if it doesn't exist I want one thread to proceed to create the data
> > for the file (and actually that thread will then spawn another set of nested
> > OpenMP threads to do that work).
> 
> If you look at 12.5.6.1 in F2018, you will find
> 
> If the file to be connected to the unit is the same as the file to which the
> unit is connected, a new connection is not
> established and values for any changeable modes (12.5.2) specified come into
> effect for the established connection;
> the current file position is unaffected. Before any effect on changeable
> modes, a wait operation is performed for
> any pending asynchronous data transfer operations for the specified unit. If
> the POSITION= specifier appears
> in such an OPEN statement, the value specified shall not disagree with the
> current position of the file. If the
> STATUS= specifier is included in such an OPEN statement, it shall be
> specified with the value OLD. Other than
> ERR=, IOSTAT=, and IOMSG=, and the changeable modes, the values of all other
> specifiers in such an OPEN
> statement shall not differ from those in effect for the established
> connection.
> 
> ... so my example was actually not quite correct, because the
> STATUS was wrong.
> 
> However, in order to to do what you describe, maybe an explicit variable
> to hold the file number (or flag) may be better, like this, with
> access guarded by OMP CRITICAL:
> 
> integer :: file_num = -1
> 
> !$omp parallel
> 
> ...
> 
> !$omp critical
>   if (file_num < 0) then
> open (newunit = file_num, file="foo.dat")
> ! Do a lot of other stuff
>   end if
> !$omp end critical
> ! file_num contains something valid here

That seems like a good approach - thanks for the suggestion!

[Bug libfortran/92836] segfault with inquire()

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig  ---
(In reply to Andrew Benson from comment #10)
> (In reply to Thomas Koenig from comment #8)

> > Also, why do you use inquire at all? AFAIK, it is not an error
> > to OPEN a file more than one if you don't change anything, so
> > a simple
> > 
> >   open (10,file="foo.dat",status="unknown")
> > 
> > should, in principle, work even with OpenMP; if it doesn't, this is
> > another bug that needs fixing.
> 
> I haven't tried this. Are you suggesting this as an alternative to using
> INQUIRE?

That is the idea.

> My reasoning for using INQUIRE to check the existence of the file
> is that if it doesn't exist I want one thread to proceed to create the data
> for the file (and actually that thread will then spawn another set of nested
> OpenMP threads to do that work).

If you look at 12.5.6.1 in F2018, you will find

If the file to be connected to the unit is the same as the file to which the
unit is connected, a new connection is not
established and values for any changeable modes (12.5.2) specified come into
effect for the established connection;
the current file position is unaffected. Before any effect on changeable modes,
a wait operation is performed for
any pending asynchronous data transfer operations for the specified unit. If
the POSITION= specifier appears
in such an OPEN statement, the value specified shall not disagree with the
current position of the file. If the
STATUS= specifier is included in such an OPEN statement, it shall be specified
with the value OLD. Other than
ERR=, IOSTAT=, and IOMSG=, and the changeable modes, the values of all other
specifiers in such an OPEN
statement shall not differ from those in effect for the established connection.

... so my example was actually not quite correct, because the
STATUS was wrong.

However, in order to to do what you describe, maybe an explicit variable
to hold the file number (or flag) may be better, like this, with
access guarded by OMP CRITICAL:

integer :: file_num = -1

!$omp parallel

...

!$omp critical
  if (file_num < 0) then
open (newunit = file_num, file="foo.dat")
! Do a lot of other stuff
  end if
!$omp end critical
! file_num contains something valid here

[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[jules at gcc dot gnu.org]

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

--- Comment #2 from jules at gcc dot gnu.org ---
I don't think your example is valid, but I'm not sure it will be fail in quite
the right way with the current version of my refcount overhaul patch. Actually
I think the acc_map_data implementation using REFCOUNT_INFINITY is probably
wrong too.

I will try changing the implementation as follows:

- calls to acc_delete with the structured reference count being non-zero (or
infinity in the case of '#pragma acc declare'd data) should raise an error.

- acc_map_data should use GOMP_MAP_VARS_OPENACC_ENTER_DATA instead of forcing
the refcount to infinity (i.e., making the behaviour the same as "enter data
(create)").

Does that match your understanding of what the behaviour should be?

[Bug c++/59423] Misleading warning when 'enum class' base type unresolved: elaborated-type-specifier for a scoped enum must not use the ‘class’ keyword

[marc at kdab dot com]

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

marc at kdab dot com changed:

   What|Removed |Added

 CC||marc at kdab dot com

--- Comment #2 from marc at kdab dot com ---
Still in GCC 10. The error message and surrounding warning are pointing at
everything _but_ where the error is:

:1:6: warning: elaborated-type-specifier for a scoped enum must not use
the 'class' keyword

1 | enum class IntegerSystem : int8 {};

  |  ^

  |  -

:1:12: error: use of enum 'IntegerSystem' without previous declaration

1 | enum class IntegerSystem : int8 {};

  |^

:1:26: error: expected unqualified-id before ':' token

1 | enum class IntegerSystem : int8 {};

  |  ^

[Bug libfortran/92836] segfault with inquire()

[abensonca at gmail dot com]

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

--- Comment #10 from Andrew Benson  ---
(In reply to Thomas Koenig from comment #8)
> > No. The inquire() is used only to see if the file exists already. If it
> > does, the code branches to read the file, if it does not, the code branches
> > to generate the data for the file and then write it.
> 
> You have to watch out here.
> 
> If you are
> 
> a) using INQUIRE to check if the file exists
> 
> b) using OPEN if it does not
> 
> in a thread, this is classic race condition - separate threads
> may INQUIRE and then try to open, in parallel. This is not atomic,
> and is a classic race condition.
> 
> You should always put such a sequence into OMP CRITICAL.  This has
> the nice side effect that you will also avoid this bug (which should
> be fixed regardless).

It's actually doing a sequence like this:

1) INQUIRE to test for the existence of the file; assuming it does not exist
then:
2) Synchronize access to the file using an OMP CRITICAL section, and a file
lock (the file lock being necessary as this is running with MPI so there are
multiple processes than can be attempting to access the file);
3) INQUIRE again to test the existence of the file (since it's possible that it
just happened to have been created by another thread)
4) Generate data to be written to the file;
5) Open, write, and close the file.
6) Exit the OPENMP CRITICAL section and release the file lock.

This clearly allows multiple threads to INQUIRE in parallel, but I don't think
it allows any race condition on the OPEN. If I'm wrong about that though then I
should fix my code!

> Also, why do you use inquire at all? AFAIK, it is not an error
> to OPEN a file more than one if you don't change anything, so
> a simple
> 
>   open (10,file="foo.dat",status="unknown")
> 
> should, in principle, work even with OpenMP; if it doesn't, this is
> another bug that needs fixing.

I haven't tried this. Are you suggesting this as an alternative to using
INQUIRE? My reasoning for using INQUIRE to check the existence of the file is
that if it doesn't exist I want one thread to proceed to create the data for
the file (and actually that thread will then spawn another set of nested OpenMP
threads to do that work).

[Bug other/92784] [10 regression] ICE when compiling g++.dg/torture/pr59226.C after r278944

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Could be the same thing.  Perhaps you can check what changed with this revision
to start this particular test failing.

[Bug libfortran/92836] segfault with inquire()

[jb at gcc dot gnu.org]

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

--- Comment #9 from Janne Blomqvist  ---
(In reply to Thomas Koenig from comment #8)
> > No. The inquire() is used only to see if the file exists already. If it
> > does, the code branches to read the file, if it does not, the code branches
> > to generate the data for the file and then write it.
> 
> You have to watch out here.
> 
> If you are
> 
> a) using INQUIRE to check if the file exists
> 
> b) using OPEN if it does not
> 
> in a thread, this is classic race condition - separate threads
> may INQUIRE and then try to open, in parallel. This is not atomic,
> and is a classic race condition.
> 
> You should always put such a sequence into OMP CRITICAL.  This has
> the nice side effect that you will also avoid this bug (which should
> be fixed regardless).
> 
> Also, why do you use inquire at all? AFAIK, it is not an error
> to OPEN a file more than one if you don't change anything, so
> a simple
> 
>   open (10,file="foo.dat",status="unknown")
> 
> should, in principle, work even with OpenMP; if it doesn't, this is
> another bug that needs fixing.

The best way in cases like this is usually to skip the inquire, try to open the
file with a suitable value for status=, and if the open fails handle the error.
That avoids the race condition.

That being said, like you say, this is still a case that GFortran should handle
without crashing, so yes it's a bug that should be fixed.

[Bug libgomp/92844] [10 regression] libgomp.fortran/use_device_ptr-optional-2.f90 fails after r279004

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
I think that is or could be a duplicate of PR 92305. See esp. PR 92305 comment
8 (and following) and PR 92305 comment 16.

At least both use type(c_ptr) and optional. I think it makes sense to fix PR
92305 first before digging into this issue, in case it is the same issue.

Any debugging help with PR 92305 is highly welcome.

[Bug tree-optimization/92834] misssed SLP vectorization in LightPixel

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 47437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47437&action=edit
gcc10-pr92834.patch

This untested patch just undoes the fancy way of writing blend operation and
turns it into ?: that we are able to optimize better.

[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-06
   See Also||https://github.com/OpenACC/
   ||openacc-spec/issues/246
   Assignee|unassigned at gcc dot gnu.org  |jules at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Julian, please verify the following against your understanding of OpenACC 2.6
semantics.

I had assumed that that 'acc_delete'/'#pragma acc exit data delete'/etc. should
not be permitted on '#pragma acc declare'd data, and should not be permitted
after 'acc_map_data'.  (Which in GCC are those using REFCOUNT_INFINITY', so
that's easy to detect.)

But, I'm not sure now, after thinking through the following.  ;-\

Because: per my reading, it actually is permissible to call 'acc_delete'/etc.
(dynamic reference counter; "present decrement" action) inside '#pragma acc
data' (structured reference counter).  This "decrements the [...] dynamic
reference counter for 'var', if its value is greater than zero. If the
reference counter is already zero, its value is left unchanged".  The latter
applies here.  "If both reference counters are then zero, a delete action is
performed."  The structured reference counter is left untouched by
'acc_delete', so the data remains mapped; 'acc_delete' actually is a no-op?

#define N 23
  float h[N];

#pragma acc data create(h)
  {
acc_delete(&h, 92); // no-op
// 'h' remains mapped!
  }

[Bug libgomp/92844] New: [10 regression] libgomp.fortran/use_device_ptr-optional-2.f90 fails after r279004

[seurer at gcc dot gnu.org]

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

Bug ID: 92844
   Summary: [10 regression]
libgomp.fortran/use_device_ptr-optional-2.f90 fails
after r279004
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/libgomp/testsuite/libgomp.fortran/use_device_ptr-optional-2.f90
  -B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/gcc-test/libgomp/testsuite/../../include
-I/home/seurer/gcc/gcc-test/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/
  -O  
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp
 
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-lgfortran -foffload=-lgfortran -lquadmath -lm  -o
./use_device_ptr-optional-2.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/libgomp/testsuite/libgomp.fortran/use_device_ptr-optional-2.f90
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/gcc-test/libgomp/testsuite/../../include
-I/home/seurer/gcc/gcc-test/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/
-O
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-lgfortran -foffload=-lgfortran -lquadmath -lm -o
./use_device_ptr-optional-2.exe
PASS: libgomp.fortran/use_device_ptr-optional-2.f90   -O  (test for excess
errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs:.:/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]

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

Backtrace for this error:
#0  0x3fffa38a04d7 in ???
#1  0x3fffa2ff38c8 in ???
FAIL: libgomp.fortran/use_device_ptr-optional-2.f90   -O  execution test
testcase
/home/seurer/gcc/gcc-test/libgomp/testsuite/libgomp.fortran/fortran.exp
completed in 0 seconds

Trying it in gdb (compiled without -O and with -g) I see:

(gdb) run
Starting program: /home/seurer/gcc/build/gcc-test/use_device_ptr-optional-2.exe 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x100014ec in main (argc=, argv=)
  

[Bug libgomp/92843] New: [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92843
   Summary: [OpenACC] Disallow 'acc_delete' etc. for everything
without a dynamic reference count
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

..., which seems easy enough to implement (..., and uncovers some
weirdness...).

WIP patch exists.

[Bug fortran/92775] [8/9/10 Regression] Incorrect expression in DW_AT_byte_stride on an array

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec  6 13:28:59 2019
New Revision: 279045

URL: https://gcc.gnu.org/viewcvs?rev=279045&root=gcc&view=rev
Log:
PR fortran/92775
* trans.h (struct lang_type, struct lang_decl): Remove span member.
(GFC_DECL_SPAN, GFC_TYPE_ARRAY_SPAN): Remove macros.
* trans-array.h (gfc_get_descriptor_offsets_for_info): Add another
argument.
* trans-array.c (gfc_get_descriptor_offsets_for_info): Add SPAN_OFF
argument and initialize *SPAN_OFF to the offset of span field.
* trans-types.c (gfc_get_array_descr_info): Adjust
gfc_get_descriptor_offsets_for_info caller.  Compute elem_size
as base->span instead of TYPE_SIZE_UNIT (etype) constant.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans.h

[Bug libfortran/92836] segfault with inquire()

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #8 from Thomas Koenig  ---

> No. The inquire() is used only to see if the file exists already. If it
> does, the code branches to read the file, if it does not, the code branches
> to generate the data for the file and then write it.

You have to watch out here.

If you are

a) using INQUIRE to check if the file exists

b) using OPEN if it does not

in a thread, this is classic race condition - separate threads
may INQUIRE and then try to open, in parallel. This is not atomic,
and is a classic race condition.

You should always put such a sequence into OMP CRITICAL.  This has
the nice side effect that you will also avoid this bug (which should
be fixed regardless).

Also, why do you use inquire at all? AFAIK, it is not an error
to OPEN a file more than one if you don't change anything, so
a simple

  open (10,file="foo.dat",status="unknown")

should, in principle, work even with OpenMP; if it doesn't, this is
another bug that needs fixing.

[Bug tree-optimization/92834] misssed SLP vectorization in LightPixel

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Created attachment 47436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47436&action=edit
Clang assembly from perf

It is clang9 build
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7d7ee02817ab1ea39a6415862ab7889f5e416598&selectedJob=278948829
it has full logs and binary, too

/builds/worker/fetches/sccache/sccache /builds/worker/fetches/clang/bin/clang++
-o Unified_cpp_gfx_2d2.o -c -flto=thin
-I/builds/worker/workspace/build/src/obj-firefox/dist/system_wrappers -include
/builds/worker/workspace/build/src/config/gcc_hidden.h -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fstack-protector-strong -DMOZILLA_CLIENT -include
/builds/worker/workspace/build/src/obj-firefox/mozilla-config.h
-Qunused-arguments -Qunused-arguments -Wall -Wbitfield-enum-conversion
-Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
-Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits
-Wunreachable-code -Wunreachable-code-return -Wwrite-strings
-Wno-invalid-offsetof -Wclass-varargs -Wfloat-overflow-conversion
-Wfloat-zero-conversion -Wloop-analysis -Wc++1z-compat -Wc++2a-compat -Wcomma
-Wimplicit-fallthrough -Werror=non-literal-null-conversion -Wstring-conversion
-Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare
-Wtautological-unsigned-zero-compare -Wno-error=tautological-type-limit-compare
-Wno-inline-new-delete -Wno-error=type-limits -Wno-error=pessimizing-move
-Wno-error=nonnull -Wno-error=deprecated-declarations -Wno-error=array-bounds
-Wno-error=backend-plugin -Wno-error=return-std-move
-Wno-error=atomic-alignment -Wformat -Wformat-security
-Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option
-Wno-return-type-c-linkage -D_GLIBCXX_USE_CXX11_ABI=0 -fno-sized-deallocation
-fno-aligned-new -fcrash-diagnostics-dir=/builds/worker/artifacts
-fno-strict-aliasing -fno-strict-aliasing -fno-exceptions -fno-rtti
-fno-exceptions -fno-math-errno -pthread -pipe
-I/builds/worker/workspace/build/src/obj-firefox/dist/stl_wrappers -DNDEBUG=1
-DTRIMMED=1 -DUSE_SSE2 -DOS_POSIX=1 -DOS_LINUX=1 -DUSE_CAIRO
-DMOZ2D_HAS_MOZ_CAIRO -DMOZ_ENABLE_FREETYPE -DSTATIC_EXPORTABLE_JS_API
-DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL
-I/builds/worker/workspace/build/src/gfx/2d
-I/builds/worker/workspace/build/src/obj-firefox/gfx/2d
-I/builds/worker/workspace/build/src/obj-firefox/ipc/ipdl/_ipdlheaders
-I/builds/worker/workspace/build/src/ipc/chromium/src
-I/builds/worker/workspace/build/src/ipc/glue
-I/builds/worker/workspace/build/src/gfx/skia
-I/builds/worker/workspace/build/src/gfx/skia/skia
-I/builds/worker/workspace/build/src/obj-firefox/dist/include
-I/builds/worker/workspace/build/src/obj-firefox/dist/include/nspr
-I/builds/worker/workspace/build/src/obj-firefox/dist/include/nss -fPIC -g
-Xclang -load -Xclang
/builds/worker/workspace/build/src/obj-firefox/build/clang-plugin/libclang-plugin.so
-Xclang -add-plugin -Xclang moz-check -O2 -fno-omit-frame-pointer
-funwind-tables -Werror -Wno-error=shadow
-I/builds/worker/workspace/build/src/obj-firefox/dist/include/cairo
-I/usr/include/freetype2  -MD -MP -MF .deps/Unified_cpp_gfx_2d2.o.pp  
Unified_cpp_gfx_2d2.cpp

[Bug fortran/92793] Fortran Location Data for Diagnostic lacks the column number – when passing on to ME

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00207.html

[Bug fortran/92775] [8/9/10 Regression] Incorrect expression in DW_AT_byte_stride on an array

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #5 from Tobias Burnus  ---
Posted patch by Jakub:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00395.html

[Bug go/92842] New: [10 Regression] libgo build failure on i686-gnu

[doko at ubuntu dot com]

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

Bug ID: 92842
   Summary: [10 Regression] libgo build failure on i686-gnu
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at ubuntu dot com
CC: cmang at google dot com
  Target Milestone: ---

trunk 20191205 ftbfs on the Hurd, i686-gnu:

./../../src/libgo/go/runtime/os_hurd.go:42:7: error: reference to undefined
field or method 'mos'
   42 |  if mp.mos.waitsema != 0 {
  |   ^
../../../src/libgo/go/runtime/os_hurd.go:55:4: error: reference to undefined
field or method 'mos'
   55 |  mp.mos.waitsema = uintptr(unsafe.Pointer(sem))
  |^
../../../src/libgo/go/runtime/os_hurd.go:65:48: error: reference to undefined
field or method 'mos'
   65 |   if sem_timedwait((*_sem_t)(unsafe.Pointer(_m_.mos.waitsema)), &ts) !=
0 {
  |^
../../../src/libgo/go/runtime/os_hurd.go:75:46: error: reference to undefined
field or method 'mos'
   75 |   r1 := sem_wait((*_sem_t)(unsafe.Pointer(_m_.mos.waitsema)))
  |  ^
../../../src/libgo/go/runtime/os_hurd.go:89:41: error: reference to undefined
field or method 'mos'
   89 |  if sem_post((*_sem_t)(unsafe.Pointer(mp.mos.waitsema))) != 0 {
  | ^
../../../src/libgo/go/runtime/os_hurd.go:95:21: error: reference to undefined
name '_SC_NPROCESSORS_ONLN'
   95 |  n := int32(sysconf(_SC_NPROCESSORS_ONLN))
  | ^
Makefile:2836: recipe for target 'runtime.lo' failed
make[6]: *** [runtime.lo] Error 1

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[doko at debian dot org]

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

--- Comment #10 from Matthias Klose  ---
that fixes it ...

--- libgo/runtime/go-context.S  (revision 279039)
+++ libgo/runtime/go-context.S  (working copy)
@@ -71,4 +71,8 @@

 #endif

+#if defined(__ARM_EABI__)
+   .section.note.GNU-stack,"",%progbits
+#else
.section.note.GNU-stack,"",@progbits
+#endif

[Bug tree-optimization/92841] New: Optimize -fstack-protector-strong code generation a bit

[bp at alien8 dot de]

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

Bug ID: 92841
   Summary: Optimize -fstack-protector-strong code generation a
bit
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bp at alien8 dot de
  Target Milestone: ---

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

Hi,

I'm building the linux kernel with

gcc (Debian 9.2.1-8) 9.2.1 20190909

and -fstack-protector-strong on x86 and from looking at what it generates, it
could be optimized a little:

# arch/x86/kernel/cpu/scattered.c:48: {
movq%gs:40, %rax# MEM[( long unsigned int
*)40B], tmp125
movq%rax, 16(%rsp)  # tmp125, D.21425
xorl%eax, %eax  # tmp125
movl$6, %eax#, pretmp_35
jmp .L6 #

AFAICT, the stack protector part would load the canary value from the %gs
offset and use a temp register to stick it on the stack and then clear that
temp register, %rax in this case.

As part of further function processing, it would stick a value in that same
register, which makes the previous clearing superfluous.

I'm being told this could be taken care of in a "late peephole". :)

Attaching preprocessed source.

Thx.

[Bug libfortran/92836] segfault with inquire()

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
(In reply to Jerry DeLisle from comment #3)
>   character(len=27) :: c
> Fortran runtime error: Fortran runtime error: End of recordEnd of record

This error I get because 27 characters are not enough — Otherwise, it works
here.


(In reply to Tobias Burnus from comment #6)
> This part looks a bit fishy. Shouldn't this be "if (TRYLOCK (...))"? Without
> "!" – or do I miss something crucial?
> https://www.kernel.org/doc/htmldocs/kernel-locking/API-mutex-trylock.html

In any case, with '!' removed, it seems to deadlock (running the c-length fixed
version of Jerry's code w/ the 'while' + 'end while' lines commented out).
Hence, it is either wrong in a more complicated way – or (likely) I simply
misunderstand how it is supposed to work – or both.

[Bug tree-optimization/92834] misssed SLP vectorization in LightPixel

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
t.C:260:16: missed:   Build SLP failed: incompatible vector types for: patt_288
= (unsigned char) patt_290;
t.C:260:16: note:   old vector type: vector(8) unsigned char
t.C:260:16: note:   new vector type: vector(4) unsigned char

we're also re-trying for all vector sizes even though the above issue
will prevail.

But one of the main issues is likely that we don't pattern match

static inline unsigned umax(unsigned a, unsigned b) {
  return a - ((a - b) & -(a < b));
}

static inline unsigned umin(unsigned a, unsigned b) {
  return a - ((a - b) & -(a > b));
}

I wonder if they desperately searched for sth not handled by GCC ;)

Btw, my copy of clang (OK, 7.0...) doesn't vectorize the color.components[]
compute but only the leading three-component compute involving reverse
sqrt, not vectorized by us because we don't handle BB vectorization of
reductions.  There's duplicate PRs about this.

Which part is important to vectorize?

Also - what flags did you use?  (tried -Ofast -mavx2)

[Bug c++/92831] CWG1299 extend_ref_init_temps_1 punts on COND_EXPRs

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 47434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47434&action=edit
gcc10-pr92831.patch

Untested fix.

[Bug libgomp/92840] New: [OpenACC] Disallow 'acc_unmap_data' for everything other than 'acc_map_data'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92840
   Summary: [OpenACC] Disallow 'acc_unmap_data' for everything
other than 'acc_map_data'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

OpenACC 2.6, 3.2.27. "acc_unmap_data" states that "It is undefined behavior to
call 'acc_unmap_data' with a host address unless that host address was mapped
to device memory using 'acc_map_data'.  We're currently not checking that, but
it's easy enough to do (..., and uncovers some weirdness...).

WIP patch exists.

[Bug libfortran/92836] segfault with inquire()

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #6 from Tobias Burnus  ---
(In reply to Andrew Benson from comment #1)
> Running with -fsanitize=thread (suggested by Tobias) gives:

> WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
> (pid=9982)
>   Mutex M84 acquired here while holding mutex M26 in thread T63:
> #2 insert_unit ../../../gcc-trunk/libgfortran/io/unit.c:244 
> 
>   Mutex M26 previously acquired by the same thread here:
> #2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:332 

I think this part is fine:
1. get_gfc_unit: Get global lock ("unit_lock").
2. Call insert_unit: Get lock in u->lock which is for a particular unit number.
3. get_gfc_unit: unlock global lock
(4. u->lock is unlocked at some later point.)

>   Mutex M26 acquired here while holding mutex M84 in thread T63:
> #2 close_unit_1 ../../../gcc-trunk/libgfortran/io/unit.c:735

close_unit_1:
* Obtain global lock ("unit_lock") – that's line 735
* Unlock the unit-number-specific lock u->lock
* Unlock the global lock.

>   Mutex M84 previously acquired by the same thread here:
> #2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:380 

That's again in get_gfc_unit. Here, I am a bit unsure about the code – but I
have not spend a lot of time on the code:

1. Get global lock (unit_lock)
2. Unit has been found
3. Call the following, i.e. if the outer condition is true,
-> if the lock could not been obtained, unlock 'unit_lock' (to avoid a
deadlock) ? But still return 'p'

  if (p != NULL && (p->child_dtio == 0))
{
  /* Fast path.  */
  if (! TRYLOCK (&p->lock))
{
  /* assert (p->closed == 0); */
  UNLOCK (&unit_lock);
  return p;
}

The TRYLOCK is the one in line 380.

This part looks a bit fishy. Shouldn't this be "if (TRYLOCK (...))"? Without
"!" – or do I miss something crucial?
https://www.kernel.org/doc/htmldocs/kernel-locking/API-mutex-trylock.html

[Bug testsuite/92829] [10 regression] several test case failures starting with r278983

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug libfortran/92836] segfault with inquire()

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #5 from Janne Blomqvist  ---
(In reply to Andrew Benson from comment #1)
> Running with -fsanitize=thread (suggested by Tobias) gives:
> 
> ==
> WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
> (pid=9982)
>   Cycle in lock order graph: M26 (0x7f02bb31c340) => M84 (0x7b58002efee0) => 
> M26
> 
>   Mutex M84 acquired here while holding mutex M26 in thread T63:
> #0 pthread_mutex_lock
> ../../../../gcc-trunk/libsanitizer/sanitizer_common/
> sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a)
> #1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so.
> 5+0x1e25c9)
> #2 insert_unit ../../../gcc-trunk/libgfortran/io/unit.c:244 
> (libgfortran.so.5+0x1e25c9)
> #3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
> 1+0x198a5)
> 
>   Mutex M26 previously acquired by the same thread here:
> #0 pthread_mutex_lock
> ../../../../gcc-trunk/libsanitizer/sanitizer_common/
> sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a)
> #1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so.
> 5+0x1e265c)
> #2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:332 
> (libgfortran.so.5+0x1e265c)
> #3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
> 1+0x198a5)
> 
>   Mutex M26 acquired here while holding mutex M84 in thread T63:
> #0 pthread_mutex_lock
> ../../../../gcc-trunk/libsanitizer/sanitizer_common/
> sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a)
> #1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so.
> 5+0x1e336b)
> #2 close_unit_1 ../../../gcc-trunk/libgfortran/io/unit.c:735 
> (libgfortran.so.5+0x1e336b)
> #3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
> 1+0x198a5)
> 
>   Mutex M84 previously acquired by the same thread here:
> #0 pthread_mutex_trylock ../../../../gcc-trunk/libsanitizer/tsan/
> tsan_interceptors_posix.cpp:1246 (libtsan.so.0+0x4340a)
> #1 __gthread_mutex_trylock ../libgcc/gthr-default.h:758 (libgfortran.so.
> 5+0x1e26f1)
> #2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:380 
> (libgfortran.so.5+0x1e26f1)
> #3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
> 1+0x198a5)
> 
>   Thread T63 (tid=10047, running) created by main thread at:
> #0 pthread_create ../../../../gcc-trunk/libsanitizer/tsan/
> tsan_interceptors_posix.cpp:962 (libtsan.so.0+0x5bb22)
> #1 gomp_team_start ../../../gcc-trunk/libgomp/team.c:839 (libgomp.so.
> 1+0x19eba)
> #2 main  (a.out+0x400ef9)
> 
> SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock)
> ../libgcc/
> gthr-default.h:749 in __gthread_mutex_lock
> ==

FWIW, this is a known problem (don't know if there's a PR for it). As far as
I've been able to see, the problem is that threadsanitizer cannot prove that
the unit locking scheme is correct even though it is.

Of course, it would be nice if we could redesign the locking so that
threadsanitizer would be happy, as then threadsanitizer would be more useful
for us.

[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
So

int main()
{
  long double x;

  // make x pseudo-denormal
  x = 0;

  unsigned char *px = (unsigned char *)&x;
  px[7] = 0x80;

  // set padding
  px[10] = 0x80;
  px[11] = 0x80;
  px[12] = 0x80;
  px[13] = 0x80;
  px[14] = 0x80;
  px[15] = 0x80;

  __builtin_printf("%lf\n", x);
  return 0;
}

shows we're constant folding this to

  __builtin_printf ("%lf\n",
3.36210314311209350626267781732175260259807934484647124011e-4932);

now.  When we put #pragma GCC unroll 16 before your testcases loop we
get the following (unrolling and constant folding happens after the
"bad" transform)

main ()
{
   [local count: 82570746]:
  printf ("%02x ", 128);
  printf ("%02x ", 128);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 128);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  __builtin_putchar (10);
  return 0;

[Bug c/36941] gcc does not reject invalid cast

[clyon at gcc dot gnu.org]

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

--- Comment #11 from Christophe Lyon  ---
Author: clyon
Date: Fri Dec  6 10:54:46 2019
New Revision: 279039

URL: https://gcc.gnu.org/viewcvs?rev=279039&root=gcc&view=rev
Log:
[testsuite][aarch64] type_redef_11.c: Update expected diagnostics.

After the fix for PR c/36941 and PR c/88827 (r278976), this test emits
a different error message and needs an update.

2019-12-06  Christophe Lyon  

PR c/36941
PR c/88827
* gcc.target/aarch64/sve/acle/general-c/type_redef_11.c: Update
expected diagnostics.



Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/type_redef_11.c

[Bug c/88827] Rejects valid program using &* operator combination.

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon  ---
Author: clyon
Date: Fri Dec  6 10:54:46 2019
New Revision: 279039

URL: https://gcc.gnu.org/viewcvs?rev=279039&root=gcc&view=rev
Log:
[testsuite][aarch64] type_redef_11.c: Update expected diagnostics.

After the fix for PR c/36941 and PR c/88827 (r278976), this test emits
a different error message and needs an update.

2019-12-06  Christophe Lyon  

PR c/36941
PR c/88827
* gcc.target/aarch64/sve/acle/general-c/type_redef_11.c: Update
expected diagnostics.



Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/type_redef_11.c

[Bug demangler/85309] demangler failed with signal 11

[lyberta at lyberta dot net]

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

Lyberta  changed:

   What|Removed |Added

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

--- Comment #2 from Lyberta  ---
Yes. Doesn't crash anymore.

[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits

[andysem at mail dot ru]

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

andysem at mail dot ru changed:

   What|Removed |Added

 CC||andysem at mail dot ru

--- Comment #1 from andysem at mail dot ru ---
I'd like to draw attention to the case of 80-bit long double on x86. When I
added support for it in Boost.Atomic I noticed that it would usually be passed
in an xmm register, where the lower 10 bytes contained value and the upper 6
contained undefined padding. Given that gcc stores and loads the full xmm
register, this means that clearing the storage prior to storing the value is
not enough (the random padding will be stored in the storage and break
cmpxchg16b). In Boost.Atomic I had to clear the padding after storing the
value, and this code is brittle because I have to know when long double value
is 10 bytes (note that sizeof(long double) returns 16 on x86-64 and 12 on
x86-32).

I don't know if anything was done about it in recent gcc versions. Maybe the
compiler could provide an intrinsic to clear any possible padding bits of a
type? That would be useful not only for long double, but for structs with
padding bits, because it allows to use memcpy to copy the value (which is
arguably more efficient) and only clear padding when accepting the value from
the user.

[Bug ipa/92809] [10 regression] error: calls_comdat_local is set outside of a comdat group

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Jan Hubicka  ---
This one works for me and should be fixed now by
2019-12-05  Jan Hubicka  

* ipa-inline-transform.c (inline_call): Fix maintenatnce of
comdat_local

[Bug tree-optimization/92839] New: Normalize memory address to same base in non-loop code

[fxue at os dot amperecomputing.com]

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

Bug ID: 92839
   Summary: Normalize memory address to same base in non-loop code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

If possible, IVOPTs can transform memory accesses to make them use same base,
which can decrease register pressure in loop. But it does not handle memory
address that is not an iv, or in a pure non-loop code.

Consider the following example, compile with -O3, we can find that data[b + ?]
will use same base register. But if we remove the line "for (i = 0; i < n; i++,
b++)" to make it be non-loop code, data[b + ?] will use different bases, with
result that we have to consume 10 register as bases, which is a much higher
register pressure. And since live ranges of these base registers cross function
call, most of them will be spilled to memory.

int data[100];

int fn();

void foo(int b, int n)
{
  int i;

  for (i = 0; i < n; i++, b++)  // remove the statement to be non-loop 
{
  data[b + 1] += 1;
  data[b + 3] += 3;
  data[b + 5] += 5;
  data[b + 7] += 7;
  data[b + 9] += 9;
  data[b + 11] += 11;
  data[b + 13] += 13;
  data[b + 15] += 15;
  data[b + 17] += 17;
  data[b + 19] += 19;

  fn ();

  data[b + 1] -= 1;
  data[b + 3] -= 3;
  data[b + 5] -= 5;
  data[b + 7] -= 7;
  data[b + 9] -= 9;
  data[b + 11] -= 11;
  data[b + 15] -= 13;
  data[b + 17] -= 15;
  data[b + 19] -= 19;
}
}

[Bug c++/92838] ICE (internal compiler error) calling lambda object with requires clause (in in dependent_type_p)

[sw6ueyz at gmail dot com]

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

--- Comment #1 from sw6ueyz at gmail dot com ---
Sorry.. you need not add "-I/opt/wandbox/boost-1.71.0/gcc-head/include" in
command line (this code does not use any include files.. I just copied command
line from wandbox.org test bed)

[Bug c++/92838] New: ICE (internal compiler error) calling lambda object with requires clause (in in dependent_type_p)

[sw6ueyz at gmail dot com]

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

Bug ID: 92838
   Summary: ICE (internal compiler error) calling lambda object
with requires clause (in in dependent_type_p)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sw6ueyz at gmail dot com
  Target Milestone: ---

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

// this code generates ICE in g++
//
// command line :
//  g++ prog.cc -Wall -Wextra -I/opt/wandbox/boost-1.71.0/gcc-head/include
-std=gnu++2a
//
// test link :
// https://godbolt.org/z/yeZ-Mc



template< class _Type >
auto foo( _Type&& )
{
if ( []() requires ( sizeof( _Type ) == 4U ) { return true; }() )
return true;
else
return false;
}


int main()
{
foo( 0 );

return 0;
}



/*
error log :


prog.cc: In instantiation of 'foo(_Type&&) [with _Type = int]::':
prog.cc:5:10:   required from 'auto foo(_Type&&) [with _Type = int]'
prog.cc:14:9:   required from here
prog.cc:5:26: internal compiler error: in dependent_type_p, at cp/pt.c:26007
5 | if ( []() requires ( sizeof( _Type ) == 4U ) { return true; }() )
  |  ^~~
0x5a08f0 dependent_type_p(tree_node*)
../../source/gcc/cp/pt.c:26007
0x739417 cxx_sizeof_or_alignof_type(tree_node*, tree_code, bool, bool)
../../source/gcc/cp/typeck.c:1687
0x6f3098 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19188
0x6f1114 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:18814
0x6ecf8d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:18814
0x6ecf8d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18472
0x61bef2 satisfy_constraint_r
../../source/gcc/cp/constraint.cc:2500
0x61c668 satisfy_constraint
../../source/gcc/cp/constraint.cc:2576
0x61d8e4 satisfy_declaration_constraints
../../source/gcc/cp/constraint.cc:2594
0x61dbd8 constraint_satisfaction_value
../../source/gcc/cp/constraint.cc:2709
0x61dbd8 constraints_satisfied_p(tree_node*)
../../source/gcc/cp/constraint.cc:2730
0x671cb4 maybe_add_lambda_conv_op(tree_node*)
../../source/gcc/cp/lambda.c:1052
0x6f0d5f tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:18784
0x6f35d4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:20154
0x6f228f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19404
0x6f228f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19404
0x6ecf8d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:18814
0x6ecf8d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18472
0x6ee3b4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:17558
0x6ee3b4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18454
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
*/

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #5 from Andreas Krebbel  ---
Since this currently prevents bootstrapping for z13 or higher on IBM Z I would
prefer to have a quick solution. Would it be acceptable to disable the warning
in mkdeps.c via pragma for now?

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

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

--- Comment #7 from Andreas Krebbel  ---
Created attachment 47432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47432&action=edit
Updated testcase

This is an updated testcase with the changes I propose.

Your testcase works fine. However, I would propose two minor adjustments:

- add -mzarch to enable the vector instructions also in a testsuite run with
-m31. The testcase does not trigger the problem on -m31 for other reasons but
that way it would at least have to the chance to.

- scan also for the element index in vsteb to be 0. With the proper index there
is a chance that code with vsteb is actually correct.

[Bug c++/92823] Is that possible to optimize C++ exception??????????? I always HATE 2 phases of exception unwind

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
It's called "exception" handling.  If you use an "exception" on the fast path
you are doing something wrong.