[Bug tree-optimization/101540] CONSTRUCTOR for vector(1) should just be VCE

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-07-21
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.  forwprop has simplify_vector_constructor for example.

[Bug tree-optimization/101541] Missing ABSU detection at gimple

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-21

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

[Bug c/101545] New: [[nodiscard]]: Incorrect warning when creating a function alias

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

Bug ID: 101545
   Summary: [[nodiscard]]: Incorrect warning when creating a
function alias
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colomar.6.4.3 at gmail dot com
  Target Milestone: ---

The following code never discards that `42`, passing it to the caller of
foobar() (in a different translation unit), and forcing it to read the value.
The warnings about an ignored [[nodiscard]] are therefore incorrect.

I put the contents of the header in the same source file just for simplicity.


$ cat nodiscard.c 
[[nodiscard]] int foo(void);

[[gnu::copy(foo)]] extern __typeof__(foo) bar;

[[nodiscard]] int foobar(void);


int foo(void)
{
return 42;
}

int foobar(void)
{
return bar();  /* This will return 42 */
}

[[gnu::alias("foo")]] [[gnu::copy(foo)]] extern __typeof__(foo) bar;


$ cc -Wall -Wextra -std=c2x -c nodiscard.c 
nodiscard.c:3:1: warning: 'nodiscard' attribute directive ignored
[-Wattributes]
3 | [[gnu::copy(foo)]] extern __typeof__(foo) bar;
  | ^
nodiscard.c:18:1: warning: 'nodiscard' attribute directive ignored
[-Wattributes]
   18 | [[gnu::alias("foo")]] [[gnu::copy(foo)]] extern __typeof__(foo) bar;
  | ^

[Bug c/101545] [[nodiscard]]: Incorrect warning when creating a function alias

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Alejandro Colomar  ---
The same code with [[gnu::warn_unused_result]] instead of [[nodiscard]] doesn't
trigger the warning.

[Bug tree-optimization/101512] [11/12 Regression] ICE in maybe_trim_constructor_store, at tree-ssa-dse.c:379

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Richard Biener  ---
So we have

VIEW_CONVERT_EXPR(<<< Unknown tree: compound_literal_expr
V D.2844 = {(long unsigned int) n ()}; >>>)[n ()]

but fail to mark D.2844 TREE_ADDRESSABLE.  That's because
c_common_mark_addressable_vec only looks through an outermost
C_MAYBE_CONST_EXPR
but we see

VIEW_CONVERT_EXPR(<<< Unknown tree:
c_maybe_const_expr

  <<< Unknown tree: compound_literal_expr
V D.2844 = {(long unsigned int) n ()}; >>> >>>)

[Bug tree-optimization/101512] [11/12 Regression] ICE in maybe_trim_constructor_store, at tree-ssa-dse.c:379

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
While the ICE in DSE happens only with GCC 11+ the bogus GIMPLE IL is latent on
older branches as well, including GCC 8.5.

[Bug c++/101516] [9/10/11/12 Regression] ICE in finish_omp_reduction_clause, at cp/semantics.c:6075

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:aea199f96cf116ba4c81426207acde371556610c

commit r12-2432-gaea199f96cf116ba4c81426207acde371556610c
Author: Jakub Jelinek 
Date:   Wed Jul 21 09:38:59 2021 +0200

c++: Ensure OpenMP reduction with reference type references complete type
[PR101516]

The following testcase ICEs because we haven't verified if reduction decl
has reference type that TREE_TYPE of the reference is a complete type,
require_complete_type on the decl doesn't ensure that.

2021-07-21  Jakub Jelinek  

PR c++/101516
* semantics.c (finish_omp_reduction_clause): Also call
complete_type_or_else and return true if it fails.

* g++.dg/gomp/pr101516.C: New test.

[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:b136b7a78774107943fe94051c42b5a968a3ad3f

commit r12-2433-gb136b7a78774107943fe94051c42b5a968a3ad3f
Author: Jakub Jelinek 
Date:   Wed Jul 21 09:45:02 2021 +0200

openmp: Fix up omp_check_private [PR101535]

The target data construct shouldn't affect omp_check_private, unless
the decl there is privatized (use_device_* clauses).  The routine
had some code for that, but it just did continue; in a loop that looped
only if the region type is one of selected 4 kinds, so effectively resulted
in return false; instead of looping again.  And not diagnosing lastprivate
(or reduction etc.) on a variable that is private to containing parallel
results in ICEs later on, as there is no original list item to which store
the last result.
The target construct is unclear as it has an implicit parallel region
and it is not obvious if the data privatization clauses on the construct
shall be treated as data privatization on the implicit parallel or just
on the target.  For now treat those as privatization on the implicit
parallel, but treat map clauses as shared on the implicit parallel.

2021-07-21  Jakub Jelinek  

PR middle-end/101535
* gimplify.c (omp_check_private): Properly skip ORT_TARGET_DATA
contexts in which decl isn't privatized and for ORT_TARGET return
false if decl is mapped.

* c-c++-common/gomp/pr101535-1.c: New test.
* c-c++-common/gomp/pr101535-2.c: New test.

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

  Component|c++ |target
Summary|[OpenMP] 'declare target'   |[OpenMP][AMDGCN][nvptx] C++
   |block around class –|offloading: unresolved
   |unresolved _Znwm =  |_Znwm = "operator
   |"operator new(unsigned  |new(unsigned long)"
   |long)"  |
 Target||nvptx-none,amdgcn-amdhsa
 CC|cltang at gcc dot gnu.org  |ams at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
Looking at it more closely, the problem seems to be that
  libstdc++{.so,.a}
does not exist for neither nvptx nor amdgcn – and the ME handles this
correctly.

The question is what's needed to get better libstdc++ support – either full
support or like with libgfortran for nvptx stripped-down minimal version.

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah.  For this exact case even just libsupc++.a would be enough, but I bet for
other cases we can't away without libstdc++.  Would be nice if it could be
configured in some embed-ish way to make it smaller, stuff like std::filesystem
on the offloading target is unlikely to be useful etc.
Exceptions aren't supported either, are they.  And I think at least in OpenMP
5.2 that is allowed, throwing an exception in offloading region may be treated
like #pragma omp error at(runtime) severity(fatal).

[Bug c++/101516] [9/10/11/12 Regression] ICE in finish_omp_reduction_clause, at cp/semantics.c:6075

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:ae2ce6aadbfd211162b4232e413f9fc2ba873cb4

commit r11-8791-gae2ce6aadbfd211162b4232e413f9fc2ba873cb4
Author: Jakub Jelinek 
Date:   Wed Jul 21 09:38:59 2021 +0200

c++: Ensure OpenMP reduction with reference type references complete type
[PR101516]

The following testcase ICEs because we haven't verified if reduction decl
has reference type that TREE_TYPE of the reference is a complete type,
require_complete_type on the decl doesn't ensure that.

2021-07-21  Jakub Jelinek  

PR c++/101516
* semantics.c (finish_omp_reduction_clause): Also call
complete_type_or_else and return true if it fails.

* g++.dg/gomp/pr101516.C: New test.

(cherry picked from commit aea199f96cf116ba4c81426207acde371556610c)

[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:076930b9690ac3564638636f6b13bbb6bc608aea

commit r11-8792-g076930b9690ac3564638636f6b13bbb6bc608aea
Author: Jakub Jelinek 
Date:   Wed Jul 21 09:45:02 2021 +0200

openmp: Fix up omp_check_private [PR101535]

The target data construct shouldn't affect omp_check_private, unless
the decl there is privatized (use_device_* clauses).  The routine
had some code for that, but it just did continue; in a loop that looped
only if the region type is one of selected 4 kinds, so effectively resulted
in return false; instead of looping again.  And not diagnosing lastprivate
(or reduction etc.) on a variable that is private to containing parallel
results in ICEs later on, as there is no original list item to which store
the last result.
The target construct is unclear as it has an implicit parallel region
and it is not obvious if the data privatization clauses on the construct
shall be treated as data privatization on the implicit parallel or just
on the target.  For now treat those as privatization on the implicit
parallel, but treat map clauses as shared on the implicit parallel.

2021-07-21  Jakub Jelinek  

PR middle-end/101535
* gimplify.c (omp_check_private): Properly skip ORT_TARGET_DATA
contexts in which decl isn't privatized and for ORT_TARGET return
false if decl is mapped.

* c-c++-common/gomp/pr101535-1.c: New test.
* c-c++-common/gomp/pr101535-2.c: New test.

(cherry picked from commit b136b7a78774107943fe94051c42b5a968a3ad3f)

[Bug c++/101516] [9/10 Regression] ICE in finish_omp_reduction_clause, at cp/semantics.c:6075

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] ICE |[9/10 Regression] ICE in
   |in  |finish_omp_reduction_clause
   |finish_omp_reduction_clause |, at cp/semantics.c:6075
   |, at cp/semantics.c:6075|

--- Comment #5 from Jakub Jelinek  ---
Fixed for 11.2 and trunk so far.

[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-07-21

--- Comment #4 from Jakub Jelinek  ---
Fixed for 11.2 and trunk so far.

[Bug c/101546] New: Sporadic issue during compiling a code with a '--save-temps' option

[filip.bascarevic at siemens dot com via Gcc-bugs]

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

Bug ID: 101546
   Summary: Sporadic issue during compiling a code with a
'--save-temps' option
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: filip.bascarevic at siemens dot com
  Target Milestone: ---

Created attachment 51185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51185&action=edit
Patch file for the --save-temps bug

Dear GCC community, 

We saw one problem in a GCC 11.1.0. We faced sporadic issue during compiling a
code with a '--save-temps' option. Generally the gcc.exe creates temporary
files containing all include-paths and call internally cc1.exe but in the gcc
10.2.0 these files have random names but in a gcc 11.1.0 names are not random
(it is .args.0). So during parallel compilation it can happen that the file can
be overwritten. Problematic part of a code is at path "gcc-11.1.0/gcc/gcc.c"

Source :Gcc.c
/* Create a temporary @file name.  */

static char *make_at_file (void)
{
  static int fileno = 0;
  char filename[20];
  const char *base, *ext;

  if (!save_temps_flag)  <- skipped for -save-temps
return make_temp_file (""); <- This function generate a random file name

  base = dumpbase;
  if (!(base && *base))
base = dumpdir;
  if (!(base && *base))
base = "a";

  sprintf (filename, ".args.%d", fileno++);  <- fixed file name
  ext = filename;

  if (base == dumpdir && dumpdir_trailing_dash_added)
ext++;

  return concat (base, ext, NULL);
}

For us we prepared a fix and it seems it works. If you agree with our solution
you can also apply this patch in a next versions of the GCC. The patch is in
the attachment.

With best regards,
MSc. Filip Bascarevic

Siemens, s.r.o.
ADV D EU CZ AE AC 4
Anglicke nabrezi 2434/1
301 00 Plzen, Czech Republic 
filip.bascare...@siemens.com

[Bug analyzer/101547] New: [12 Regression] ICE: Segmentation fault (in c_tree_printer)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 101547
   Summary: [12 Regression] ICE: Segmentation fault (in
c_tree_printer)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-12.0.0-alpha20210718 snapshot (g:6ae8aac19cdbdbd96d90f86e4d8505fe121bdf06)
ICEs when compiling the following testcase w/ -fanalyzer:

char *
fopen (const char *restrict, const char *restrict);

void
k2 (void)
{
  char *setfiles[1];
  int i;

  setfiles[i] = fopen ("", "");
}

% gcc-12.0.0 -fanalyzer -c zlrtucfi.c
during IPA pass: analyzer
zlrtucfi.c:10:15: internal compiler error: Segmentation fault
   10 |   setfiles[i] = fopen ("", "");
  |   ^~~~
0xe3c9af crash_signal
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/toplev.c:328
0x860ab0 c_tree_printer
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/c/c-objc-common.c:305
0x860ab0 c_tree_printer
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/c/c-objc-common.c:258
0x1aa776d pp_format(pretty_printer*, text_info*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/pretty-print.c:1475
0x11f810b ana::evdesc::event_desc::formatted_print(char const*, ...) const
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/pending-diagnostic.cc:64
0x1a34c36 ana::warning_event::get_desc(bool) const
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/checker-path.cc:887
0x1a34482 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/checker-path.cc:149
0x1a47605 ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/checker-path.h:571
0x1a47605 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/diagnostic-manager.cc:1192
0x1a4af37 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/diagnostic-manager.cc:1095
0x1a47ba1 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/diagnostic-manager.cc:1146
0x11eef0d ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:4986
0x11efd80 ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:5043
0x11e0e48 execute
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/analyzer-pass.cc:87

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[ams at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Stubbs  ---
The standalone amdgcn configuration does not support C++. There are a number of
technical reasons why it doesn't Just Work, but basically it comes down to
no-one ever working on it. Our customers were primarily interested in Fortran
with C second.

C++ offloading works fine provided that there are no library calls or
exceptions.

Ignoring unsupported C++ language features, for now, I don't think there's any
reason why libstdc++ would need to be cut down. We already build the full
libgfortran for amdgcn. System calls that make no sense on the GPU were
implemented as stubs in Newlib (mostly returning some reasonable errno value),
and it would be straight-forward to implement more the same way.

I believe static constructors work (libgfortran uses some), but exception
handling does not. I'm not sure what other exotica C++ might need?

As for exceptions, set-jump-long-jump is not implemented because there was no
call for it and I didn't know how to handle the GCN register files properly.
Not only are they variable-sized, they're also potentially very large: ranging
from ~6KB up to ~65KB, I think (102 32-bit scalar, and 256 2048-bit vector
registers, for single-threaded mode, but only 80 scalar and 24 vector registers
in maximum occupancy mode, in which case per-thread stack space is also quite
limited). I'm not sure now the other exception implementations work.

[Bug tree-optimization/101548] New: dependence analysis fails with .MASK_STORE

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101548
   Summary: dependence analysis fails with .MASK_STORE
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We fail to vectorize (with -fno-trapping-math in case COND_ADD is not
available)

double a[1024], b[1024];

void foo ()
{
  for (int i = 0; i < 1024; ++i)
if (b[i] < 3.)
  a[i] += b[i];
}

the loop is if-converted to

   [local count: 1063004409]:
  # i_13 = PHI 
  # ivtmp_6 = PHI 
  _1 = b[i_13];
  _2 = a[i_13];
  _3 = _1 + _2;
  _24 = _1 < 3.0e+0;
  _25 = &a[i_13];
  .MASK_STORE (_25, 64B, _24, _3);
  i_9 = i_13 + 1;
  ivtmp_4 = ivtmp_6 - 1;
  if (ivtmp_4 != 0)
goto ; [98.99%]
  else
goto ; [1.01%]

but then dependence analysis fails:

(compute_affine_dependence
  ref_a: b[i_13], stmt_a: _1 = b[i_13];
  ref_b: *_25, stmt_b: .MASK_STORE (_25, 64B, _24, _3);
) -> no dependence
(compute_affine_dependence
  ref_a: a[i_13], stmt_a: _2 = a[i_13];
  ref_b: *_25, stmt_b: .MASK_STORE (_25, 64B, _24, _3);
) -> dependence analysis failed
t3.c:7:12: missed:   versioning for alias required: can't determine dependence
between a[i_13] and *_25
consider run-time aliasing test between a[i_13] and *_25

and then

t3.c:5:21: note:   === vect_prune_runtime_alias_test_list ===
t3.c:5:21: note:   can tell at compile time that a[i_13] and *_25 alias
t3.c:7:12: missed:   not vectorized: compilation time alias: _2 = a[i_13];
.MASK_STORE (_25, 64B, _24, _3);

and we give up.  But the may-dependence does not prevent vectorization.

[Bug tree-optimization/101548] dependence analysis fails with .MASK_STORE

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Richard Biener  ---
It works with

void foo (double * __restrict a, double *b)
{
  for (int i = 0; i < 1024; ++i)
{
  double tem = a[i];
  if (b[i] < tem)
a[i] = tem + b[i];
}
}

and

   [local count: 1063004409]:
  # i_20 = PHI 
  # ivtmp_19 = PHI 
  _1 = (long unsigned int) i_20;
  _2 = _1 * 8;
  _3 = a_11(D) + _2;
  tem_12 = *_3;
  _4 = b_13(D) + _2;
  _5 = *_4;
  _6 = _5 + tem_12;
  _34 = _5 < tem_12;
  .MASK_STORE (_3, 64B, _34, _6);
  i_15 = i_20 + 1;
  ivtmp_18 = ivtmp_19 - 1;
  if (ivtmp_18 != 0)
goto ; [98.99%]
  else
goto ; [1.01%]

so this is likely a duplicate of the old issue of refs based on a pointer
(which .MASK_STORE with &a[i] is) wrt refs based not on a pointer (a[i]).

[Bug c++/100493] Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes

[gcc at bmevers dot de via Gcc-bugs]

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

Benno Evers  changed:

   What|Removed |Added

 CC||gcc at bmevers dot de

--- Comment #1 from Benno Evers  ---
I can confirm this issue; working around it was the biggest single piece of
work we had to do when upgrading our codebase to C++20.

[Bug target/100208] amdgcn fails to build with llvm-mc from llvm12

[ams at gcc dot gnu.org via Gcc-bugs]

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

Andrew Stubbs  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Stubbs  ---
I think this issue should be resolved now.

(Other reasons why GCC fails with LLVM 12 still exist).

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Andrew Stubbs from comment #3)
> C++ offloading works fine provided that there are no library calls or
> exceptions.

There's no reason std::pair, std::tuple, std::optional and types like that
shouldn't work.

Just making it possible to compile with -fno-rtti -fno-exceptions would be a
start, and would avoid the need for exception handling. Libstdc++ headers
already work fine with those options, and it should be possible to build the
library itself that way (or it's a bug that can be fixed).

> Ignoring unsupported C++ language features, for now, I don't think there's
> any reason why libstdc++ would need to be cut down. We already build the
> full libgfortran for amdgcn. System calls that make no sense on the GPU were
> implemented as stubs in Newlib (mostly returning some reasonable errno
> value), and it would be straight-forward to implement more the same way.

But it's a waste of space in the .so to build lots of symbols that use the
stubs.

There are other reasons it might be nice to be able to configure libstdc++ for
something in between a full hosted environment and a minimal freestanding one.

> I believe static constructors work (libgfortran uses some), but exception
> handling does not. I'm not sure what other exotica C++ might need?

Ideally, __cxa_atexit and __cxa_thread_atexit for static and thread-local
destructors, but we can survive without them (and have not-fully-conforming
destruction ordering).

[Bug libstdc++/101527] The implementation of std::common_iterator::operator== seems to be wrong

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
I find it surprising, but the CWG consensus seems to be that a friend defined
inline in the class body is "a member declaration of the befriended class".

[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-21
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Brooks Moses from comment #0)
> But sequence_buffer is more broken than that: it also has another
> constructor, sequence_buffer(sequence_buffer&) that has different semantics:
> it flushes the source first. So if you only ever use non-const
> sequence_buffer objects, never modify a copied-from object, and never do
> anything that would call the sequence_buffer(const sequence_buffer&)
> constructor, it will appear to work. And that's what this test was relying
> on.

This constructor is similar to how std::auto_ptr "worked" and it was the source
of numerous defect reports and problems. It was removed from the standard years
ago and replaced with something that worked.

> we don't have any code
> that uses __gnu_cxx::sequence_buffer or __gnu_cxx::rope

I doubt anybody does. It's ancient and not really maintained now.

We can probably make it move-aware though.

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[ams at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Stubbs  ---
[Note: all of my comments refer to the amdgcn case. nvptx has somewhat
different support in this area.]

(In reply to Jonathan Wakely from comment #4)
> But it's a waste of space in the .so to build lots of symbols that use the
> stubs.

DSOs are not supported. This is strictly for static linking only.

> There are other reasons it might be nice to be able to configure libstdc++
> for something in between a full hosted environment and a minimal
> freestanding one.

If it isn't a horrible hack, like libgfortran minimal mode, then fine.

> > I believe static constructors work (libgfortran uses some), but exception
> > handling does not. I'm not sure what other exotica C++ might need?
> 
> Ideally, __cxa_atexit and __cxa_thread_atexit for static and thread-local
> destructors, but we can survive without them (and have not-fully-conforming
> destruction ordering).

Offload kernels are just fragments of programs, so this is tricky in those
cases. Libgomp explicitly calls _init_array and _fini_array as single-threaded
kernel launches. Actually, it's not clear that deconstruction is in any way
interesting, given that code running on the GPU has no external access and the
resources are all released when the host program exits.

Similarly, C++ threads are not interesting in the GPU-offload case. There are a
fixed number or threads launched on entry and they are managed by libgomp. In
theory it would be possible to code gthreads/libstdc++ to use them in
standalone mode, but really that mode only exists to facilitate compiler
testing.

[Bug debug/101473] debug_line info depends on toolchain path

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from Richard Biener  ---
I think it is a bug - -fdebug-prefix-map should be fully reflected in the LTO
IL and thus we should not end up creating un-remapped references to files (we
should not create many references to files late anyway).

In particular we're remapping all files when streaming locations to LTO.  But
yes, we're explicitely _not_ streaming the -f*-prefix-map arguments since
we'd have a hard time using them when they do not agree between TUs.

Your lto-test shows the difference is in the LTRANS DWARF CU header:

@@ -215,7 +215,7 @@
 <9b>   DW_AT_producer: (indirect string, offset: 0x1c7): GNU GIMPLE
10.3.0 -mtune=generic -march=x86-64 -g -O2 -fno-openmp -fno-openacc -fno-pie
-fcf-protection=none -ffat-lto-objects -fuse-linker-plugin -fltrans
 <9f>   DW_AT_language: 12  (ANSI C99)
DW_AT_name: (indirect string, offset: 0x1b2): 
-   DW_AT_comp_dir: (indirect string, offset: 0x263):
/tmp/lto-test/src0
+   DW_AT_comp_dir: (indirect string, offset: 0x263):
/tmp/lto-test/src1
DW_AT_ranges  : 0x40
DW_AT_low_pc  : 0x0
DW_AT_stmt_list   : 0xe8

and with DWARF5 in addition in the directory table:

  The Directory Table (offset 0x10a, lines 1, columns 1):
   EntryName
-  0(indirect line string, offset: 0xd): /tmp/lto-test/src0
+  0(indirect line string, offset: 0xd): /tmp/lto-test/src1

so indeed the prefix remapping is needed at link-time - the link time
CWD aka DW_AT_comp_dir might also not agree with the CWD at compile time.

Thus my suggestion would be to indeed add -f*-prefix-map to LDFLAGS,
at least I can't think of a good solution to the above issue.  Eventually
picking a random TU and copying the CWD from its compile-time to the
link-time CUs would work.  Or somehow not specifying a compilation-dir
at all for those CUs?

[Bug target/101428] [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand

[belagod at gcc dot gnu.org via Gcc-bugs]

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

Tejas Belagod  changed:

   What|Removed |Added

 CC||belagod at gcc dot gnu.org
   Last reconfirmed||2021-07-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Tejas Belagod  ---
Is it legal to let the flag output operand '=@ccge' overlap with the
corresponding clobbered operand 'cc'? As a general rule, the extended asm spec
says I/O operands can't overlap with the clobber list -
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers.

Also, CMP on AArch64 does not have a form that matches with "=m" constraint for
the output. So I don't think its valid code, but the compiler shouldn't ICE,
therefore confirmed as a bug.

[Bug debug/101473] debug_line info depends on toolchain path

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from Jakub Jelinek  ---
I think in DWARF for compilation units DW_AT_comp_dir is not optional.

[Bug target/101549] New: [12 Regression] internal compiler error: in extract_insn, at recog.c:2769

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 101549
   Summary: [12 Regression] internal compiler error: in
extract_insn, at recog.c:2769
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c 
#include 

unsigned int
test_mm_crc32_u8(unsigned int CRC, unsigned char V)
{
  return _mm_crc32_u8(CRC, V);
}   
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -msse4 -mno-crc32
/tmp/x.c: In function ‘test_mm_crc32_u8’:
/tmp/x.c:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 16 15 22 2 (set (reg:SI 84 [ D.24970 ])
(unspec:SI [
(reg:SI 89)
(subreg:QI (reg:SI 90) 0)
] UNSPEC_CRC32)) "./include/smmintrin.h":829:10 -1
 (nil))
during RTL pass: vregs
/tmp/x.c:7:1: internal compiler error: in extract_insn, at recog.c:2769
0x125686e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/export/gnu/import/git/gitlab/x86-gcc/gcc/rtl-error.c:108
0x12568af _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/export/gnu/import/git/gitlab/x86-gcc/gcc/rtl-error.c:116
0x11fd163 extract_insn(rtx_insn*)
/export/gnu/import/git/gitlab/x86-gcc/gcc/recog.c:2769
0xe5d4cf instantiate_virtual_regs_in_insn
/export/gnu/import/git/gitlab/x86-gcc/gcc/function.c:1611
0xe5eb4c instantiate_virtual_regs
/export/gnu/import/git/gitlab/x86-gcc/gcc/function.c:1985
0xe5ec1c execute
/export/gnu/import/git/gitlab/x86-gcc/gcc/function.c:2034
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-cfl-2 gcc]$

[Bug analyzer/101550] New: -Wanalyzer-file-leak false positive with an array of pointers, open and fdopen.

[amatej at redhat dot com via Gcc-bugs]

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

Bug ID: 101550
   Summary: -Wanalyzer-file-leak false positive with an array of
pointers, open and fdopen.
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: amatej at redhat dot com
  Target Milestone: ---

Hello, I have the following program:
--
#include 
#include 
#include 
#include 

typedef struct {
FILE *foo_file;
} Foo;

FILE*
open_target_file()
{
int fd = open("some.txt", O_CREAT|O_TRUNC|O_RDWR, 0666);
if (fd == -1) {
return NULL;
}

FILE *f = fdopen(fd, "w+b");
if (f == NULL) {
close(fd);
return NULL;
}

return f;
}

void
prepare_next_transfer(Foo **targets)
{
Foo *a1 = targets[0];

a1->foo_file = open_target_file();

if (a1->foo_file != NULL) {
fclose(a1->foo_file);
}
}

int
main() {
Foo a1 = {NULL};
Foo *data[] = {&a1, NULL};
prepare_next_transfer(data);
}
--

When I run:
$ gcc program.c -fanalyzer
I get:

In function ‘prepare_next_transfer’:
program.c:34:11: warning: leak of ‘f’ [CWE-401] [-Wanalyzer-malloc-leak]
   34 | if (a1->foo_file != NULL) {
  | ~~^~
  ‘prepare_next_transfer’: events 1-2
|
|   28 | prepare_next_transfer(Foo **data)
|  | ^
|  | |
|  | (1) entry to ‘prepare_next_transfer’
|..
|   32 | a1->foo_file = open_target_file();
|  |~~
|  ||
|  |(2) calling ‘open_target_file’ from
‘prepare_next_transfer’
|
+--> ‘open_target_file’: events 3-9
   |
   |   11 | open_target_file()
   |  | ^~~~
   |  | |
   |  | (3) entry to ‘open_target_file’
   |..
   |   14 | if (fd == -1) {
   |  |~
   |  ||
   |  |(4) following ‘false’ branch (when ‘fd != -1’)...
   |..
   |   18 | FILE *f = fdopen(fd, "w+b");
   |  |   ~
   |  |   |
   |  |   (5) ...to here
   |  |   (6) allocated here
   |   19 | if (f == NULL) {
   |  |~
   |  ||
   |  |(7) assuming ‘f’ is non-NULL
   |  |(8) following ‘false’ branch (when ‘f’ is
non-NULL)...
   |..
   |   24 | return f;
   |  |~
   |  ||
   |  |(9) ...to here
   |
<--+
|
  ‘prepare_next_transfer’: events 10-11
|
|   32 | a1->foo_file = open_target_file();
|  |^~
|  ||
|  |(10) returning to ‘prepare_next_transfer’ from
‘open_target_file’
|   33 |
|   34 | if (a1->foo_file != NULL) {
|  | 
|  |   |
|  |   (11) ‘f’ leaks here; was allocated at (6)
|

I think this is a false positive since ‘f’ is returned from ‘open_target_file’
assigned to ‘a1->foo_file‘ and fclosed, there should be no leak.

It goes away if fopen is used instead of open and fdopen or if the array of
pointers is not used.

I am using gcc-11.1.1-6.fc35.x86_64.

Thank you for your work.

[Bug middle-end/101551] New: [offloading] Differences in diagnostics etc.

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101551
   Summary: [offloading] Differences in diagnostics etc.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

There are differences in diagnostics etc. depending on whether offloading is
disabled or enabled, as we already had found in

"openacc: Warnings for strange partitioning choices for parallel regions" and
following.

Additionally, I just noticed that calling 'lang_hooks.decl_printable_name
(current_function_decl, 2)' in 'gcc/omp-offload.c:execute_oacc_device_lower'
for an OpenACC 'routine' 'void ROUTINE (float)', for C that returns 'ROUTINE',
for C++ 'ROUTINE(float)' for offloading enabled and 'void ROUTINE(float)'
otherwise (notice difference regarding return type), for corresponding Fortran
'routine_' for offloading enabled and 'routine' otherwise (notice difference in
'_' suffix).

Low priority certainly, but would be nice to fix/unify at some point, because
this occasionally necessitates special care when writing testcases.

[Bug c++/98821] modules : c++tools configures with CC but code fragments assume CXX.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:e4d306cf706eef83f99d510c308eda1539d05875

commit r12-2436-ge4d306cf706eef83f99d510c308eda1539d05875
Author: Iain Sandoe 
Date:   Tue Jul 20 14:00:38 2021 +0100

c++tools, configury: Configure with C++; test checking status [PR98821].

The c++tools configure fragments need to be built with a C++ compiler.

In addition, the stand-alone server uses diagnostic mechanisms in common
with GCC, but needs to define implementations for gcc_assert and
supporting output functions.

Signed-off-by: Iain Sandoe 

PR c++/98821 - modules : c++tools configures with CC but code fragments
assume CXX.

PR c++/98821

c++tools/ChangeLog:

* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Configure using C++.  Pull logic to
detect enabled checking modes; default to release
checking.
* server.cc (AI_NUMERICSERV): Define a fallback value.
(gcc_assert): New.
(gcc_unreachable): New.
(fancy_abort): Only build when checking is enabled.

Co-authored-by: Jakub Jelinek 

[Bug gcov-profile/101552] New: [GCOV] Wrong coverage with "for( )" statement

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 101552
   Summary: [GCOV] Wrong coverage with "for( )" statement
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ clang -v
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/wangyang/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ cat test.c
extern int strcmp(const char *, const char *);
extern char *strcpy(char *, const char *);
extern void abort(void);
extern void exit(int);

void *buf[20];

void __attribute__((noinline)) sub2(void) { __builtin_longjmp(buf, 1); }

int main() {
  char *p = (char *)__builtin_alloca(20);

  strcpy(p, "test");

  if (__builtin_setjmp(buf)) {
if (strcmp(p, "test") != 0)
  abort();

exit(0);
  }

  {
int *q = (int *)__builtin_alloca(p[2] * sizeof(int));
printf("Excuted!\n");
int i;

for (i = 0; i < p[2]; i++)
  q[i] = 0;

while (1)
  sub2();
  }
}

$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw
test.c; ./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov
show a.out -instr-profile=test.profdata test.c > test.lcov; cat test.lcov
Excuted!
1|   |#include
2|   |extern int strcmp(const char *, const char *);
3|   |extern char *strcpy(char *, const char *);
4|   |extern void abort(void);
5|   |extern void exit(int);
6|   |
7|   |void *buf[20];
8|   |
9|  1|void __attribute__((noinline)) sub2(void) {
__builtin_longjmp(buf, 1); }
   10|   |
   11|  1|int main() {
   12|  1|  char *p = (char *)__builtin_alloca(20);
   13|  1|
   14|  1|  strcpy(p, "test");
   15|  1|
   16|  1|  if (__builtin_setjmp(buf)) {
   17|  1|if (strcmp(p, "test") != 0)
   18|  0|  abort();
   19|  1|
   20|  1|exit(0);
   21|  1|  }
   22|  0|
   23|  0|  {
   24|  0|int *q = (int *)__builtin_alloca(p[2] * sizeof(int));
   25|  0|printf("Excuted!\n");
   26|  0|int i;
   27|  0|
   28|115|for (i = 0; i < p[2]; i++)
   29|115|  q[i] = 0;
   30|  0|
   31|  1|while (1)
   32|  1|  sub2();
   33|  0|  }
   34|  0|}



line 16 was executed twice, line 24 to 26 was executed once and line 28 was
executed 116 times.

[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
This should work:

--- a/libstdc++-v3/include/ext/rope
+++ b/libstdc++-v3/include/ext/rope
@@ -203,6 +203,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::copy(__x._M_buffer, __x._M_buffer + __x._M_buf_count, _M_buffer);
   }

+  // Non-const "copy" modifies the parameter - yuck
   sequence_buffer(sequence_buffer& __x)
   {
__x.flush();
@@ -213,6 +214,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   sequence_buffer(_Sequence& __s)
   : _M_prefix(&__s), _M_buf_count(0) { }

+  // Non-const "copy" modifies the parameter - yuck
   sequence_buffer&
   operator=(sequence_buffer& __x)
   {
@@ -230,7 +232,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::copy(__x._M_buffer, __x._M_buffer + __x._M_buf_count, _M_buffer);
return *this;
   }
-  
+
+#if __cplusplus >= 201103L
+  sequence_buffer(sequence_buffer&& __x) : sequence_buffer(__x) { }
+  sequence_buffer& operator=(sequence_buffer&& __x) { return *this = __x;
}
+#endif
+
   void
   push_back(value_type __x)
   {

[Bug middle-end/101551] [offloading] Differences in diagnostics etc.

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Thomas Schwinge  ---
Similarly, when calling 'lang_hooks.decl_printable_name (current_function_decl,
2)' in 'gcc/omp-offload.c:execute_oacc_device_lower' for:

#pragma acc routine
template  T
ROUTINE(int val)
{ [...] }

..., for 'ROUTINE' instantiated that returns 'ROUTINE(int)float'
for offloading enabled and 'T ROUTINE(int) [with T = float]' otherwise.

[Bug bootstrap/101553] New: [12 Regression] armhf builds broken on -Werror=array-bounds

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101553
   Summary: [12 Regression] armhf builds broken on
-Werror=array-bounds
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-linux-gnueabihf

All builds (cross and native) of arm-none-linux-gnueabihf are currently broken
and have been for a while now.

I believe it's g:a110855667782dac7b674d3e328b253b3b3c919b but haven't been able
to easily confirm as that patch can no longer be easily reverted.


Failure is in libatomic build:

hecking for suffix of object files... In file included from 
gcc/libatomic/config/arm/host-config.h:4,
 from  gcc/libatomic/libatomic_i.h:232,
 from  gcc/libatomic/gexch.c:25:
 gcc/libatomic/gexch.c: In function ‘libat_exchange’:
 gcc/libatomic/config/linux/arm/host-config.h:42:34: error: array subscript 0
is outside array bounds of ‘unsigned int[0]’ [-Werror=array-bounds]
   42 | #define __kernel_helper_version (*(unsigned int *)0x0ffc)
  | ~^~~~
 gcc/libatomic/config/linux/arm/host-config.h:104:26: note: in expansion of
macro ‘__kernel_helper_version’
  104 | # define IFUNC_COND_2   (__kernel_helper_version >= 5)
  |  ^~~
 gcc/libatomic/config/linux/arm/host-config.h:169:57: note: in expansion of
macro ‘IFUNC_COND_2’
  169 | # define MAYBE_HAVE_ATOMIC_CAS_8(IFUNC_COND_1 | IFUNC_COND_2)
  | ^~~~
 gcc/libatomic/libatomic_i.h:40:25: note: in expansion of macro
‘MAYBE_HAVE_ATOMIC_CAS_8’
   40 | #define C2_(X,Y)X ## Y
  | ^
 gcc/libatomic/libatomic_i.h:41:25: note: in expansion of macro ‘C2_’
   41 | #define C2(X,Y) C2_(X,Y)
  | ^~~
 gcc/libatomic/gexch.c:58:10: note: in expansion of macro ‘C2’
   58 | if (!C2(MAYBE_HAVE_ATOMIC_CAS_,N)) break;   \
  |  ^~
 gcc/libatomic/gexch.c:120:25: note: in expansion of macro ‘LARGER’
  120 | case 5 ... 7: L8:   LARGER(8);  /* FALLTHRU */
  | ^~

[Bug bootstrap/101553] [12 Regression] armhf builds broken on -Werror=array-bounds

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug gcov-profile/101552] [GCOV] Wrong coverage with "for( )" and setjmp

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Yang Wang  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Yang Wang  ---
Sorry, I entered the wrong website...

[Bug analyzer/101547] [12 Regression] ICE: Segmentation fault (in c_tree_printer)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug driver/101546] Sporadic issue during compiling a code with a '--save-temps' option

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
  Component|c   |driver
 CC||aoliva at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2021-07-21

--- Comment #1 from Richard Biener  ---
The whole point is that with -save-temps temporary filenames become
deterministic.  GCC 11 in addition changed how those auxiliary filenames are
chosen.  Can you share two different example compiler commands that end up
creating conflicting names?

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Richard Biener  ---
IIRC libstdc++ had a freestanding mode that could serve as base.

[Bug target/101549] [12 Regression] internal compiler error: in extract_insn, at recog.c:2769

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Target||x86_64-*-* i?86-*-*

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jonathan Wakely  ---
Yes, --disable-libstdcxx-hosted will build the freestanding version of
libstdc++

[Bug sanitizer/100878] enabling UBSAN leads to false positive `'this' pointer is null` when casting lambda to function pointer

[mail at milianw dot de via Gcc-bugs]

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

Milian Wolff  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||11.1.0
  Known to work||12.0
 Resolution|--- |FIXED

--- Comment #2 from Milian Wolff  ---
ah great, then I guess we can mark this as fixed.

[Bug debug/101473] debug_line info depends on toolchain path

[tonyb at cybernetics dot com via Gcc-bugs]

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

--- Comment #21 from tonyb at cybernetics dot com ---
I tried adding -f*-prefix-map to LDFLAGS in Yocto, and that makes everything I
tested binary reproducible, except for some shared libraries in /lib and
/usr/lib because libtool filters out the -f*-prefix-map flags when linking *.so
libraries, but that is not a gcc issue.  Since that seems like a viable
solution, I will continue the discussion with the Yocto people.

Thanks for your help!

[Bug gcov-profile/101554] New: [GCOV] The coverage of "for" goes wrong.

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 101554
   Summary: [GCOV] The coverage of "for" goes wrong.
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 


$ cat test.c
#include
int a[251];
int __attribute__((noinline)) t(int i) {
  if (i == 0)
exit(0);
  if (i > 255)
abort();
}
int main() {
  unsigned int i;
  for (i = 0;; i++) {
a[i] = t((unsigned char)(i + 5));
  }
}


$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
libgcov profiling error:/home/wangyang/coverage/test/test.gcda:overwriting an
existing profile data with a different timestamp
File 'test.c'
Lines executed:88.89% of 9
Creating 'test.c.gcov'

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:int a[251];
  252:3:int __attribute__((noinline)) t(int i) {
  252:4:  if (i == 0)
1:5:exit(0);
  251:6:  if (i > 255)
#:7:abort();
  251:8:}
1:9:int main() {
-:   10:  unsigned int i;
1:   11:  for (i = 0;; i++) {
  252:   12:a[i] = t((unsigned char)(i + 5));
-:   13:  }
-:   14:}

Line 11 was executed 252 times

[Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 51186
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51186&action=edit
gcc12-pr101539.patch

So, I've tried to play with the __is_layout_compatible trait, here is the
result.  There is one known bug, the C++ FE unfortunately removes zero sized
bit-fields early, for layout compatibility we need them (and now just that they
were present but how many as well and their types).  Can we not remove them or
remove them when the FE parses the whole TU?

The testcase also contains various cornercases where layout-compatibility as
currently defined is just weird.

[Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jakub Jelinek  ---
As for __builtin_is_corresponding_member, could be perhaps implemented as
varargs FE builtin and only check during folding it has exactly two arguments
that are pointer to data members with layout-compatible types and standard
layout structs.
For constexpr, especially if we can see unfolded PMR address which says which
FIELD_DECL it is implementing it shouldn't be hard, but it seems that it can't
be always folded at compile time, we can have cases where we need to decide at
runtime.
#include 
struct A { int a; long long b; int c; int e; int d; };
struct B { int a; long long b; long long c; int d; };
bool
foo (int A::*x, int B::*y)
{
  return std::is_corresponding_member (x, y);
}
This should return true if called e.g. with &A::a, &B::a, but not with &A::d,
&B::d.  So I guess at compile time we need to check if the types (int in this
case twice) is layout-compatible and whether A and B are standard-layout
structure types, but then actually at compile time need to compare the
OFFSET_TYPEs for equality and compare it against pre-computed value of an upper
bound for the initial common sequence of the two types.
The U and V structs show that it is harder though, at least the offset would be
dependent on the type of the field.

No plans on my side to work on the pointer interconvertibility on my side.

[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Brooks Moses from comment #0)
> This started failing with a recent Clang change
> (https://github.com/llvm/llvm-project/commit/
> 7d2d5a3a6d7aaa40468c30250bf6b0938ef02c08), described as "Apply P1825 as
> Defect Report from C++11 up to C++20".  See
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html for the
> defect report details.  I would guess that GCC will be applying a similar
> change.

GCC 11 already implemented that, see PR 91427 and the commit
https://gcc.gnu.org/g:1722e2013f05f1f1f99379dbaa0c0df356da731f

The for that commit says:

Discussion on the CWG reflector about how to avoid breaking the PR91212
test
in the new model settled on the model of doing only a single overload
resolution, with the variable treated as an xvalue that can bind to
non-const lvalue references.  So this patch implements that approach.  The
implementation does not use the existing LOOKUP_PREFER_RVALUE flag, but
instead sets a flag on the representation of the static_cast turning the
variable into an xvalue.

which says that calling sequence_buffer(sequence_buffer&) here is intended,
which is why we didn't see any change in the ext/rope/4.cc test when GCC
implemented it.

I still think we want to make sequence_buffer move-aware, so that you get the
same behaviour for:

template T f(T x) { return x; }
template T g(T x) { return std::move(x); }

when passed a sequence_buffer.

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||skpgkp2 at gmail dot com

--- Comment #20 from H.J. Lu  ---
This has been fixed in GCC 12.  Sunil, can you submit a GCC patch to
add testcases to cover this?

[Bug c++/101555] New: Compile slowdown in tree PRE

[wsnyder at wsnyder dot org via Gcc-bugs]

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

Bug ID: 101555
   Summary: Compile slowdown in tree PRE
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wsnyder at wsnyder dot org
  Target Milestone: ---

Running

   g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

as

   g++ -I. -c -Os -ftime-report -o /dev/null Vara___024root__114_0.cpp

takes 297 CPU seconds.

On clang version 10.0.0-4ubuntu1 it takes 37 seconds total.

In GCC, 276 of 297 seconds are in the "tree PRE" stage. Splitting the large
function into roughly three pieces (Vara___024root__114_0.cpp, _1 and _2)
the "tree PRE" stage takes 12.7, 7.8 and 3.9 seconds (totalling 24.4).
Therefore I suspect some O(n^2) issue in tree PRE.

Note removing -Os makes gcc much faster, but still signifcantly slower than
clang.

This issue was originally reported using gcc 8.2.0 by Matheus Cavalcante 
at https://github.com/verilator/verilator/issues/3072

[Bug gcov-profile/101556] New: [GCOV] Wrong coverage that may be caused by "ASM" and "volatile"

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 101556
   Summary: [GCOV] Wrong coverage that may be caused by "ASM" and
"volatile"
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 

$ cat test.c
#include
#include
volatile int cnt = 0;
__attribute__((noinline, noclone)) static int last(void) {
  return ++cnt % 5 == 0;
}

__attribute__((noinline, noclone)) static void do_it(void) {
  asm volatile("" : : "r"(&cnt) : "memory");
}

__attribute__((noinline, noclone)) static void f1(void) {
  printf("Enter function\n");
  for (;; do_it()) {
printf("Enter loop\n");
if (last())
  break;
  }
  do_it(); /* { dg-final { gdb-test . "cnt" "5" } } */
}

void (*volatile fnp1)(void) = f1;

int main() {
  asm volatile("" : : "r"(&fnp1) : "memory");
  fnp1();
}

$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
Enter loop
Enter loop
Enter loop
Enter loop
Enter loop
File 'test.c'
Lines executed:100.00% of 15
Creating 'test.c.gcov'

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:#include
-:3:volatile int cnt = 0;
5:4:__attribute__((noinline, noclone)) static int last(void) {
5:5:  return ++cnt % 5 == 0;
-:6:}
-:7:
5:8:__attribute__((noinline, noclone)) static void do_it(void) {
5:9:  asm volatile("" : : "r"(&cnt) : "memory");
5:   10:}
-:   11:
5:   12:__attribute__((noinline, noclone)) static void f1(void) {
4:   13:  for (;; do_it()) {
5:   14:printf("Enter loop\n");
5:   15:if (last())
1:   16:  break;
-:   17:  }
1:   18:  do_it(); /* { dg-final { gdb-test . "cnt" "5" } } */
1:   19:}
-:   20:
-:   21:void (*volatile fnp1)(void) = f1;
-:   22:
1:   23:int main() {
1:   24:  asm volatile("" : : "r"(&fnp1) : "memory");
1:   25:  fnp1();
-:   26:}

Coverage of line 12 should be 1 and line 13 should be executed 5 times

[Bug target/87743] Vectorizer doesn't support conversion of different sizes

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||skpgkp2 at gmail dot com

--- Comment #8 from H.J. Lu  ---
This has been fixed in GCC 12.  Sunil, please submit a GCC patch to
add a testcase.

[Bug c++/101555] Compile slowdown in tree PRE

[wsnyder at wsnyder dot org via Gcc-bugs]

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

--- Comment #1 from Wilson Snyder  ---
Created attachment 51187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51187&action=edit
Examples and runtimes

[Bug target/91602] GCC fails to build for riscv in a combined tree due to misconfigured leb128 support

[belyshev at depni dot sinp.msu.ru via Gcc-bugs]

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

Serge Belyshev  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #15 from Serge Belyshev  ---
(In reply to Serge Belyshev from comment #12)
> Testing a patch that removes in-tree gas version checks along with resulting
> dead code.

Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575744.html

[Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jakub Jelinek  ---
I think the implementation of is_corresponding_member heavily depends on
layout-compatibility ensuring the same sizes and alignments of the members,
otherwise
any comparison of the OFFSET_TYPE values (which just hold at runtime byte
offset from the start of struct and at compile time hold also the type of the
pointed non-static data member and type of the object the offset is relative
to) is going to be a nighmare.  So I think we first need a clarification of the
standard for the various alignas cases or the [[no_unique_address]] cases that
are shown e.g. in the #c1 testcase and only when we can count on the
corresponding members to have the exact same offset we can move further on.

[Bug c++/101557] New: the value of '' is not usable in a constant expression

[federico.kircheis at gmail dot com via Gcc-bugs]

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

Bug ID: 101557
   Summary: the value of '' is not usable in a constant
expression
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.kircheis at gmail dot com
  Target Milestone: ---

Consider following snippet



struct node {
const char* d;
const node& left;
const node& right;
};

constexpr const node Null = node{"",Null,Null};

constexpr const node a 
{
"a",
node
{
"b",
node{"e",Null,Null},
node{"d",Null,Null},
},
node{"c",Null,Null},
};

constexpr int mysize(const node& n) noexcept{
return (&n == &Null) ? 0 : 1 + mysize(n.left) + mysize(n.right); 
}

constexpr auto size0 = mysize(Null);
static_assert(size0 == 0, "");
constexpr auto size1 = mysize(node{"c", Null, Null});
static_assert(size1 == 1, "");

constexpr auto size2 = mysize(node
{
"b",
node{"e",Null,Null},
node{"d",Null,Null},
});
static_assert(size2 == 3, "");


// this line does not compile
constexpr auto size3 = mysize(a);
static_assert(size3 == 5, "");



The expression `constexpr auto size3 = mysize(a);` does not compile with the
error message


:41:30:   in 'constexpr' expansion of 'mysize(a)'
:25:42:   in 'constexpr' expansion of 'mysize((* & n.node::left))'
:41:32: error: the value of '' is not usable in a constant
expression
   41 | constexpr auto size3 = mysize(a);
  |^
:22:1: note: '' was not declared 'constexpr'
   22 | };
  | ^
Compiler returned: 1




A similar effect can be achieved with


constexpr node b = a.left;


with following error


:45:23: error: the value of '' is not usable in a constant
expression
   45 | constexpr node b2 = a.left;
  |   ^~~~
:22:1: note: '' was not declared 'constexpr'
   22 | };
  | ^
Compiler returned: 1


even if



constexpr node b = a;


compiles without warnings.


Generally accessing subobjects should not be an issue, for example

struct sub{};

struct node2{
const sub& s;
};
constexpr const node2 n2{
sub{}
};
constexpr auto s = n2.s;


also compiles without issues

[Bug c++/101558] New: Abnormal behavior with -O3 : warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]

[franco at francocorbelli dot com via Gcc-bugs]

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

Bug ID: 101558
   Summary: Abnormal behavior with -O3 : warning: writing 8 bytes
into a region of size 0 [-Wstringop-overflow=]
   Product: gcc
   Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: franco at francocorbelli dot com
  Target Milestone: ---

Created attachment 51188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51188&action=edit
Snippet of "strange" behavior

On GCC 10.3.0 on Ubuntu 21

(...)COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0-1ubuntu1'
(...)Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1)

I get problems porting software from previous versions (8.x). 
In particular, there is a warning message of this kind

"
In member function ‘unzDT& unzDT::operator=(const unzDT&)’,
inlined from ‘int main()’ at unz.cpp:27:9:
unz.cpp:11:8: warning: writing 8 bytes into a region of size 0
[-Wstringop-overflow=]
   11 | struct unzDT
  |^
unz.cpp: In function ‘int main()’:
unz.cpp:13:12: note: at offset 0 to object ‘unzDT::date’ with size 8 declared
here
   13 |   uint64_t date;
  |   

"

It is reproducible with the attached snippet, by compiling with -O3
g++ -O3 unz.cpp -o unz

If you want to see more "oddities" try to change the size of
sha1decompressedhex from 8 to 7

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #271 from dave.anglin at bell dot net ---
On 2021-07-21 2:32 a.m., me at larbob dot org wrote:
> Reading symbols from
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol 
> number
> 7215 references nonexistent SHT_SYMTAB_SHNDX section
> Can't read symbols from
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in
> wrong format
This seems to be a problem with the symbol table in cc1.  It's not a problem
with the dwarf info.

Can readelf read symbols?  What does file command show?  If you strip cc1, does
gdb start?

disasm $pc-16,$pc+16 should show faulting instruction.

[Bug libstdc++/101527] The implementation of std::common_iterator::operator== seems to be wrong

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #3 from 康桓瑋  ---
(In reply to Jonathan Wakely from comment #2)
> I find it surprising, but the CWG consensus seems to be that a friend
> defined inline in the class body is "a member declaration of the befriended
> class".

Hey Jonathan, I just found out that std::counted_iterator also has the same
friend access issue.


#include 

int main() {
  std::counted_iterator it1;
  std::counted_iterator it2;
  return it1 == it2;
}

https://godbolt.org/z/jGT5jhbWz

[Bug c++/101557] the value of '' is not usable in a constant expression

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
clang++ rejects it similarly.
pr101557.C:40:16: error: constexpr variable 'size3' must be initialized by a
constant expression
constexpr auto size3 = mysize(a);
   ^   ~
pr101557.C:22:45: note: read of temporary is not allowed in a constant
expression outside the expression that created the temporary
Wonder if this isn't related to the recently posted PR100976 patch.

[Bug c++/100493] Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug target/101559] New: RISCV -- incorrect label address when using -O2

[joel.porquet at gmail dot com via Gcc-bugs]

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

Bug ID: 101559
   Summary: RISCV -- incorrect label address when using -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel.porquet at gmail dot com
  Target Milestone: ---

The GNU construct `&&label` supposedly allows the programmer to get the address
corresponding to a label. When compiling for RISCV, the correct address is
computed when compiling with -O0 but not with -O2.

Here is an example code where a label's address is properly computed:
https://godbolt.org/z/qnEafeY6f. As you can see, the address corresponding to
label `.L2` is properly retrieved using `lui` followed by `addi` and placed
into register `a5`.

Now, when the same code is compiled with `-O2`, the address is not properly
computed: https://godbolt.org/z/n8zbbTnhb. As you can see, the label `.L2` is
now placed at the very beginning of the function and points onto the function's
first instruction. As a result, the computed address will not correspond to
where the label was placed in the original code.

Is that a bug, or am I missing something? Thanks!

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[sirl at gcc dot gnu.org via Gcc-bugs]

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

Franz Sirl  changed:

   What|Removed |Added

  Attachment #51164|0   |1
is obsolete||

--- Comment #7 from Franz Sirl  ---
Created attachment 51189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51189&action=edit
More complete trial patch to overhaul ASM_CPU_SPEC

This patch should be more complete now. It does the following basic things:

 - Only pass -many to the assembler when -massembler-any is given
 - Unify the non-AIX (for now) asm_cpu spec settings into rs6000-cpus.def.
Currently this uses a "static inline" function because I developed on GCC10, on
GCC11 and later using a constexpr would be much nicer.

Now, the other stuff to reliably handle -many would need some gas support,
where I likely need some help, because I've no expertise there.

First, I suggest to introduce 2 assembler warning options:

 -wany-duplicates: Warn if the mnemonic to assemble has duplicates because of
-many, this should limit the warnings to the most difficult cases. In the patch
it's automatically enabled when -massembler-any is used.
 -wany-strict: Warn if any mnemonic to assemble is only fulfilled because of
-many.

And also some additional/changed options for .machine:

 .machine "resetsticky": Reset the sticky flags (eg. VSX, AltiVec, ANY)
 .machine "pushsticky": Push CPU+sticky settings, reset the sticky flags
 .machine "push": Change to push CPU+sticky, keep the sticky flags
 .machine "pop": Change to pop CPU+sticky

The attached patch tries to make use of such a TBD change to gas.

Alternatively, gas could be changed to have -madditive-sticky and/or '.machine
"additive-sticky"' to make any '.machine "realcpu"' reset the sticky flags and
they have to be re-added again afterwards if needed. Maybe this push/pop-less
solution would be even easier to handle in the compiler?

What do you think? I hope I addressed most of your concerns, suggestions
welcome.

[Bug target/101559] RISCV -- incorrect label address when using -O2

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
That isn't a bug.  If you aren't actually using the &&label value eventually to
goto *ptr to it, there might be no cfg edges to a basic block that starts with
that label, it can be during optimizations moved around, and while the compiler
will usually try to keep it close to where it appeared originally, it is
certainly not guaranteed.

[Bug bootstrap/101553] [12 Regression] armhf builds broken on -Werror=array-bounds

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Patch was posted on 7/9 but hasn't yet been reviewed:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574880.html

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

[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #9 from Martin Sebor  ---
*** Bug 101553 has been marked as a duplicate of this bug. ***

[Bug c++/101557] the value of '' is not usable in a constant expression

[federico.kircheis at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Federico Kircheis  ---
clang does not reject it:

https://godbolt.org/z/8Mq1e3o3j

[Bug c++/101557] the value of '' is not usable in a constant expression

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Federico Kircheis from comment #2)
> clang does not reject it:
> 
> https://godbolt.org/z/8Mq1e3o3j

clang 11 does reject it but clang 12 does NOT reject it.

[Bug c++/101557] the value of '' is not usable in a constant expression

[federico.kircheis at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Federico Kircheis  ---
Indeed.
I just checked the latest versions.

I wonder if there is a common cause that makes this recursive data structure
harder to evaluate at compile time.

[Bug target/101559] RISCV -- incorrect label address when using -O2

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #2 from Andreas Schwab  ---


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

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||joel.porquet at gmail dot com

--- Comment #13 from Andreas Schwab  ---
*** Bug 101559 has been marked as a duplicate of this bug. ***

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

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

--- Comment #272 from Larkin Nickle  ---
(In reply to dave.anglin from comment #271)
> On 2021-07-21 2:32 a.m., me at larbob dot org wrote:
> > Reading symbols from
> > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
> > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol 
> > number
> > 7215 references nonexistent SHT_SYMTAB_SHNDX section
> > Can't read symbols from
> > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in
> > wrong format
> This seems to be a problem with the symbol table in cc1.  It's not a problem
> with the dwarf info.
> 
> Can readelf read symbols?  What does file command show?  If you strip cc1,
> does gdb start?

On system with a modern `file`:

cc1: ELF 32-bit MSB executable, IA-64, version 1 (HP-UX), dynamically linked,
interpreter /usr/lib/hpux32/uld.so:/usr/lib/hpux32/dld.so, with debug_info, not
stripped, too many notes (256)

Readelf is seemingly able to read them.

> 
> disasm $pc-16,$pc+16 should show faulting instruction.

(gdb) disas $pc-16,$pc+16
Dump of assembler code from 0x54af7e1 to 0x54af801:
   0x054af7e1:  st8 [r41]=r0
   0x054af7e2:  nop.i 0x0;;
   0x054af7f0:  [MMI]   ld1.a r87=[r14]
=> 0x054af7f1:  st8 [r47]=r59
   0x054af7f2:  nop.i 0x0
   0x054af800:  [MMI]   st4 [r46]=r0;;
End of assembler dump.

This issue happens in stage3.

[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:8edb61420502c62fa2cccdd98876a9aa039b72a6

commit r12-2437-g8edb61420502c62fa2cccdd98876a9aa039b72a6
Author: Jonathan Wakely 
Date:   Wed Jul 21 15:29:19 2021 +0100

libstdc++: Make __gnu_cxx::sequence_buffer move-aware [PR101542]

The PR explains that Clang trunk now selects a different constructor
when a non-const sequence_buffer is returned in a context where it
qualifies as an implicitly-movable entity. Because lookup is first
performed using an rvalue, the sequence_buffer(const sequence_buffer&)
constructor gets chosen, which makes a copy instead of a "pseudo-move"
via the sequence_buffer(sequence_buffer&) constructor. The problem isn't
seen with GCC because as noted in the r11-2412 commit log, GCC actually
implements a slightly modified rule that avoids breaking exactly this
type of code.

This patch adds a move constructor to sequence_buffer, so that implicit
or explicit moves will have the same effect, calling the
sequence_buffer(sequence_buffer&) constructor. A move assignment
operator is also added to make move assignment work similarly.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/101542
* include/ext/rope (sequence_buffer): Add move constructor and
move assignment operator.
* testsuite/ext/rope/101542.cc: New test.

[Bug target/101559] RISCV -- incorrect label address when using -O2

[joel.porquet at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Joël Porquet  ---
Thanks for the quick replies and the clear explanation!

I'm a little bummed because this construct enabled me to write --what I
considered to be-- clean code for a bootloader. As shown below, I could
temporarily change the exception vector with a label's address located further
down, which corresponds to the restoration of the previous exception vector. If
any operation in between fails, we just skip ahead and ignore the rest.

```
static void setup_pmp(void)
{
uintptr_t otvec;

/* Ignore possible exception if some PMP registers are not implemented */
otvec = csr_read_write(CSR_MTVEC, &&restore_mtvec);

/* Reset configuration */
csr_write(CSR_PMPCFG0, 0);

/* Range for M-mode bootloader */
...

restore_mtvec:
csr_write(CSR_MTVEC, otvec);
}
```

This code unfortunately doesn't work because the label's address
(`restore_mtvec`) is moved to the beginning of the function and it goes into an
infinite loop if an exception is raised.

The only other way to write this code effectively seems to be to do it fully in
assembly, like they do in BBL
(https://github.com/riscv/riscv-pk/blob/66d7fcb56d6a4cd4879922f184bb2274918ac3cd/bbl/bbl.c#L53),
which I was trying to avoid since it felt pretty ugly :(

Do you see any alternative apart from the switch to assembly code?

Thanks in advance for your time.

[Bug tree-optimization/101558] Abnormal behavior with -O3 : warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/96963] [10 Regression] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||franco at francocorbelli dot 
com

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

[Bug target/101560] New: ICE building 526.blender_r with -Ofast -flto -march=znver2 since r12-1958-gedafb35bdad

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101560
   Summary: ICE building 526.blender_r with -Ofast -flto
-march=znver2 since r12-1958-gedafb35bdad
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

When building SPEC 2017 FPrate benchmark 526.blender_r with -Ofast -g
-flto -march=znver2 -mtune=znver2 I see the following ICE:

blender/source/blender/blenloader/intern/readfile.c: In function 'do_versions':
blender/source/blender/blenloader/intern/readfile.c:7595:1: internal compiler
error: in lra_assign, at lra-assigns.c:1649
 7595 | }
  | ^
0xb77d20 lra_assign(bool&)
/home/mjambor/gcc/mine/src/gcc/lra-assigns.c:1649
0xb724c4 lra(_IO_FILE*)
/home/mjambor/gcc/mine/src/gcc/lra.c:2387
0xb2d369 do_reload
/home/mjambor/gcc/mine/src/gcc/ira.c:5932
0xb2d369 execute
/home/mjambor/gcc/mine/src/gcc/ira.c:6118
Please submit a full bug report...


Note that the assert is triggered only with checking, so release-build
compilers do not see it.

I have bisected it down to:

commit edafb35bdadf309ebb9d1eddc5549f9e1ad49c09
Author: H.J. Lu 
Date:   Wed Jun 2 07:15:45 2021 -0700

x86: Convert CONST_WIDE_INT/CONST_VECTOR to broadcast

1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTOR
operands to vector broadcast from an integer with AVX.
2. Add ix86_gen_scratch_sse_rtx to return a scratch SSE register which
won't increase stack alignment requirement and blocks transformation by
the combine pass.
[...rest of the commit message trimmed...]

At this point I do not plan to attempt to come up with a reduced
testcase.

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[segher at gcc dot gnu.org via Gcc-bugs]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
(In reply to Franz Sirl from comment #7)
> Created attachment 51189 [details]
> More complete trial patch to overhaul ASM_CPU_SPEC
> 
> This patch should be more complete now. It does the following basic things:

If it does a few things, it should be a few patches, not one.

>  - Only pass -many to the assembler when -massembler-any is given

Interesting idea!  I wonder how well that works, how many programs will
need to use that new flag (for their inline assembler code).

>  - Unify the non-AIX (for now) asm_cpu spec settings into rs6000-cpus.def.
> Currently this uses a "static inline" function because I developed on GCC10,
> on GCC11 and later using a constexpr would be much nicer.
> 
> Now, the other stuff to reliably handle -many would need some gas support,
> where I likely need some help, because I've no expertise there.
> 
> First, I suggest to introduce 2 assembler warning options:
> 
>  -wany-duplicates: Warn if the mnemonic to assemble has duplicates because
> of -many, this should limit the warnings to the most difficult cases. In the
> patch it's automatically enabled when -massembler-any is used.
>  -wany-strict: Warn if any mnemonic to assemble is only fulfilled because of
> -many.

You'll have to discuss this on binut...@sourceware.org .

> And also some additional/changed options for .machine:
> 
>  .machine "resetsticky": Reset the sticky flags (eg. VSX, AltiVec, ANY)
>  .machine "pushsticky": Push CPU+sticky settings, reset the sticky flags
>  .machine "push": Change to push CPU+sticky, keep the sticky flags
>  .machine "pop": Change to pop CPU+sticky

Why would you want this concept?  It is mixing .machine selection with
other things.

> The attached patch tries to make use of such a TBD change to gas.
> 
> Alternatively, gas could be changed to have -madditive-sticky and/or
> '.machine "additive-sticky"' to make any '.machine "realcpu"' reset the
> sticky flags and they have to be re-added again afterwards if needed. Maybe
> this push/pop-less solution would be even easier to handle in the compiler?
> 
> What do you think? I hope I addressed most of your concerns, suggestions
> welcome.

I don't think it is a good idea to add workaround upon workaround to avoid
some of the not-so-useful behaviours of -many.  Instead, we should just
not use -many?

[ Cc: Alan, for the binutils side of things ]

[Bug target/101560] [12 Regression] ICE building 526.blender_r with -Ofast -flto -march=znver2 since r12-1958-gedafb35bdad

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE building 526.blender_r  |[12 Regression] ICE
   |with -Ofast -flto   |building 526.blender_r with
   |-march=znver2 since |-Ofast -flto -march=znver2
   |r12-1958-gedafb35bdad   |since r12-1958-gedafb35bdad
   Keywords||ice-on-valid-code
   Target Milestone|--- |12.0

[Bug target/101560] [12 Regression] ICE building 526.blender_r with -Ofast -flto -march=znver2 since r12-1958-gedafb35bdad

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Might be the same as PR 101504 even.

[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #5 from Jonathan Wakely  ---
Should be fixed now.

[Bug bootstrap/101553] [12 Regression] armhf builds broken on -Werror=array-bounds

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Tamar Christina  ---
Thanks, I didn't see the patch, I've pinged the maintainers.

[Bug target/101469] wrong code with "-O2 -fPIE" for SH

[rin at NetBSD dot org via Gcc-bugs]

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

--- Comment #6 from Rin Okuyama  ---
(In reply to Rin Okuyama from comment #3)
> If that peephole is removed, GCC 10.3 generates working codes.
> 
> NetBSD/shle built by this compiler works fine as far as I can see.
> I'm carrying out full regression tests of NetBSD on this system.
> (It takes about a day to finish.)

It took more time due to minor troubles for my side, but it finished.
Fallout from this bug is fixed, whereas no new regressions are observed!

Thanks,
rin

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

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

--- Comment #273 from John Buddery  ---
If you go back a bit further, is there a speculative load of one of those
registers
 (probably r47 / r59 ) ?
A speculative load will have a .s I think.

I believe ILL_REGNAT should actually be a SEGV, not SIGILL - not sure why
that's the signal being generated.

[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:b937dbf2577e0fa3018c562312da7b08bbe72d70

commit r12-2438-gb937dbf2577e0fa3018c562312da7b08bbe72d70
Author: Martin Sebor 
Date:   Wed Jul 21 10:48:55 2021 -0600

Adjust macro to avoid warning [PR101379].

Resolves:
PR bootstrap/101379 - libatomic arm build failure after r12-2132 due to
-Warray-bounds on a constant address

libatomic/ChangeLog:
PR bootstrap/101379
* config/linux/arm/host-config.h (__kernel_helper_version): New
function.  Adjust shadow macro.

[Bug target/101559] RISCV -- incorrect label address when using -O2

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jakub Jelinek  ---
You can make the compiler believe it could use computed goto to that label but
actually not do that, say by
  void *volatile ptr = &&label;
  int volatile cond = 0;
  if (cond)
goto *ptr;
But even this would just have an edge from that computed goto and because of
volatile it wouldn't know if the condition is never true.

Or gcc supports asm goto, where the inline asm would do that csr_read_write
part (before GCC 11 asm goto couldn't have output operands) and that would make
the compiler take branching from the inline asm to the label as possibility.

[Bug fortran/101514] ICE: out of memory allocating 18446744073709551600 bytes

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:c2b15fe27e6a0e42b108111d51acce69628593b4

commit r12-2439-gc2b15fe27e6a0e42b108111d51acce69628593b4
Author: Harald Anlauf 
Date:   Wed Jul 21 18:54:00 2021 +0200

Fortran: ICE, OOM while calculating sizes of derived type array components

gcc/fortran/ChangeLog:

PR fortran/101514
* target-memory.c (gfc_interpret_derived): Size of array component
of derived type can only be computed here for explicit shape.
* trans-types.c (gfc_get_nodesc_array_type): Do not dereference
NULL pointers.

gcc/testsuite/ChangeLog:

PR fortran/101514
* gfortran.dg/pr101514.f90: New test.

[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Sebor  ---
Patch committed in r12-2438.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

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

--- Comment #274 from Larkin Nickle  ---
Created attachment 51190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51190&action=edit
disas of cc1 with more context

Here's `disas $pc-256,$pc+256`'s output.

[Bug tree-optimization/101558] Abnormal behavior with -O3 : warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]

[franco at francocorbelli dot com via Gcc-bugs]

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

--- Comment #2 from Franco Corbelli  ---
Thank you, I spend about two days tinkering with Ubuntu's default compiler.

At least I know I'm not completely crazy

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[sirl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Franz Sirl  ---
(In reply to Segher Boessenkool from comment #8)
> I don't think it is a good idea to add workaround upon workaround to avoid
> some of the not-so-useful behaviours of -many.  Instead, we should just
> not use -many?

As I understand it -many is just one variation of the general problem with the
sticky flags. If we remove -many from the assembler, there are still other
sticky flags like -mvsx. Turning of any sticky flag is currently not supported
by the assembler AFAICS. So for example it's impossible to switch from a VSX
supporting assembler mode to an assembler mode without VSX via the .machine
pseudo-op. Or did I misread the the assembler source?

[Bug target/101549] [12 Regression] internal compiler error: in extract_insn, at recog.c:2769

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r12-2440-g7aa28dbc371cf3c09c05c68672b00d9006391595
Author: H.J. Lu 
Date:   Wed Jul 21 05:15:55 2021 -0700

x86: Remove OPTION_MASK_ISA_SSE4_2 from CRC32 _builtin functions

Since

commit 39671f87b2df6a1894cc11a161e4a7949d1ddccd
Author: H.J. Lu 
Date:   Thu Apr 15 05:59:48 2021 -0700

x86: Use crc32 target option for CRC32 intrinsics

enabled OPTION_MASK_ISA_CRC32 for -msse4 and removed TARGET_SSE4_2 check
in sse4_2_crc32 pattens, remove OPTION_MASK_ISA_SSE4_2 from CRC32
_builtin functions.

gcc/

PR target/101549
* config/i386/i386-builtin.def: Remove OPTION_MASK_ISA_SSE4_2
from CRC32 _builtin functions.

gcc/testsuite/

PR target/101549
* gcc.target/i386/crc32-6.c: New test.

[Bug target/101561] New: -msse4 -mno-crc32 doesn't disable CRC32 intrinsics

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 101561
   Summary: -msse4 -mno-crc32 doesn't disable CRC32 intrinsics
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-2 tmp]$ cat x.c
#include 

unsigned int
test_mm_crc32_u8(unsigned int CRC, unsigned char V)
{
  return _mm_crc32_u8(CRC, V);
}   
[hjl@gnu-cfl-2 tmp]$ gcc -S -O2 -msse4 -mno-crc32 x.c
[hjl@gnu-cfl-2 tmp]$

[Bug target/101549] [12 Regression] internal compiler error: in extract_insn, at recog.c:2769

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 12.  GCC 11 failed to disable CRC32 with -mno-crc32 (PR 101561).

[Bug target/101561] -msse4 -mno-crc32 doesn't disable CRC32 intrinsics

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

  Known to work||12.0
   Last reconfirmed||2021-07-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
This is fixed in GCC 12 by r12-12 and r12-2440.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #275 from dave.anglin at bell dot net ---
On 2021-07-21 12:55 p.m., me at larbob dot org wrote:
> Here's `disas $pc-256,$pc+256`'s output.
Maybe r47 contains garbage.

[Bug c/101562] New: [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682

[gscfq--- via Gcc-bugs]

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

Bug ID: 101562
   Summary: [9/10/11/12 Regression] ICE in insert, at
wide-int.cc:682
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7, at -O2+ :

(gcc here configured with --enable-checking=yes)
(helpful warning with -O2 -Wall, but not with -O1 -Wall)
(-> array subscript is above array bounds)


$ cat z1.c
struct S { char c; };
void g (struct S a, struct S b);
void f ()
{
  struct S x[1];
  x[0].c = 0;
  x[1].c = 1;
  g (x[0], x[1]);
  return;
}


$ gcc-6 -c z1.c -O2
$ gcc-12-20210718 -c z1.c -O1
$
$ gcc-12-20210718 -c z1.c -O2
during RTL pass: combine
z1.c: In function 'f':
z1.c:10:1: internal compiler error: in insert, at wide-int.cc:682
   10 | }
  | ^
0x11ad9c1 wi::insert(generic_wide_int const&,
generic_wide_int const&, unsigned int, unsigned int)
../../gcc/wide-int.cc:682
0x17f6c2e try_combine
../../gcc/combine.c:2839
0x17f9860 combine_instructions
../../gcc/combine.c:1269
0x17f9860 rest_of_handle_combine
../../gcc/combine.c:14873
0x17f9860 execute
../../gcc/combine.c:14918

[Bug rtl-optimization/101562] [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
  Component|c   |rtl-optimization

[Bug c++/101563] New: ICE in lookup_template_class_1, at cp/pt.c:10184

[gscfq--- via Gcc-bugs]

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

Bug ID: 101563
   Summary: ICE in lookup_template_class_1, at cp/pt.c:10184
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(in addition to g++.dg/template/mem-spec1.C)


$ cat z1.cc
namespace N {
  template struct A
  {
template struct B {};
A() { B b; }
  };
  template<> template
  struct A::B
  {
~B() {}
  };
  A x;
  A::B y;
}


$ g++-12-20210718 -c z1.cc
z1.cc: In instantiation of 'N::A<  >::A() [with
 = int]':
z1.cc:12:10:   required from here
z1.cc:5:18: internal compiler error: in lookup_template_class_1, at
cp/pt.c:10184
5 | A() { B b; }
  |  ^
0x98a861 lookup_template_class_1
../../gcc/cp/pt.c:10184
0x98a861 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:10230
0x98b14d tsubst_aggr_type
../../gcc/cp/pt.c:13577
0x9753d7 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:15450
0x98cb91 tsubst_decl
../../gcc/cp/pt.c:14747
0x9755bf tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:15369
0x998171 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18236
0x995852 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18479
0x993b75 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18120
0x995852 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18479
0x979d49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18106
0x979d49 instantiate_body
../../gcc/cp/pt.c:25869
0x97b477 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26162
0x9bd42b instantiate_pending_templates(int)
../../gcc/cp/pt.c:26241
0x82cac1 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4991