[Bug c++/97268] Segfault on 11.0.0 20200930

[ext-gcc at burakarslan dot com via Gcc-bugs]

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

--- Comment #2 from Burak Arslan  ---

Sorry about that. Here is the cmdline: 

g++ prog.cc -Wall -Wextra -std=gnu++2a

[Bug c++/97268] Segfault on 11.0.0 20200930

[ext-gcc at burakarslan dot com via Gcc-bugs]

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

--- Comment #3 from Burak Arslan  ---

Sorry about that. Here is the cmdline: 

g++ prog.cc -Wall -Wextra -std=gnu++2a

[Bug c++/97268] 11 Regression] Segfault on 11.0.0 20200930

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|WAITING |NEW
Summary|Segfault on 11.0.0 20200930 |11 Regression] Segfault on
   ||11.0.0 20200930
 CC||msebor at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
OK, confirmed.  It's -Wextra that triggers the following for me:

during GIMPLE pass: *early_warn_uninitialized
t.C: In constructor 'BetterObject::BetterObject(const char*, int,
Handle&) [with bool CACHED = true]':
t.C:63:1: internal compiler error: in gimple_call_arg, at gimple.h:3256
   63 | }
  | ^
0x1a61d17 gimple_call_arg
/home/rguenther/src/gcc3/gcc/gimple.h:3256
0x1a61d6d gimple_call_arg
/home/rguenther/src/gcc3/gcc/gimple.h:3264
0x1a63c4d maybe_warn_pass_by_reference
/home/rguenther/src/gcc3/gcc/tree-ssa-uninit.c:526
0x1a6434d warn_uninitialized_vars
/home/rguenther/src/gcc3/gcc/tree-ssa-uninit.c:643
0x1a693d9 execute_early_warn_uninitialized
/home/rguenther/src/gcc3/gcc/tree-ssa-uninit.c:3018
0x1a6944c execute
/home/rguenther/src/gcc3/gcc/tree-ssa-uninit.c:3053
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

where on a stmt

Object::Object (_2, _3);

we try to access argument 3.  Not sure how readwrite attributes ended up there,
I see them on some libstdc++ functions only.  Maybe some bad sharing
of function type trees?

CCing Martin.

[Bug c++/97268] [11 Regression] ICE in maybe_warn_pass_by_reference at gcc/tree-ssa-uninit.c:514 since r11-1763-g27aebb7d6cf14175

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.2.0
Summary|[11 Regression] Segfault on |[11 Regression] ICE in
   |11.0.0 20200930 |maybe_warn_pass_by_referenc
   ||e at
   ||gcc/tree-ssa-uninit.c:514
   ||since
   ||r11-1763-g27aebb7d6cf14175
 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
  Known to fail||11.0

--- Comment #5 from Martin Liška  ---
Started with Nathan's commit.

[Bug target/89233] [9 Regression] ICE in change_address_1, at emit-rtl.c:2286

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

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

--- Comment #5 from Martin Liška  ---
*** Bug 88082 has been marked as a duplicate of this bug. ***

[Bug target/88082] ICE in change_address_1, at emit-rtl.c:2286

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #4 from Martin Liška  ---
Dup.

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

[Bug target/96879] [11 Regresssion] ICE in native_encode_rtx, at simplify-rtx.c:6482

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

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

--- Comment #2 from Martin Liška  ---
Any progress on this. Are you planning Jakub to suggest the patch?

[Bug target/96879] [11 Regresssion] ICE in native_encode_rtx, at simplify-rtx.c:6482

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-02
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug target/97269] New: [11 Regression] ICE in change_address_1, at emit-rtl.c:2275 since r11-3427-ge94797250b403d66cb3624a594e41faf0dd76617

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

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

Bug ID: 97269
   Summary: [11 Regression] ICE in change_address_1, at
emit-rtl.c:2275 since
r11-3427-ge94797250b403d66cb3624a594e41faf0dd76617
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: richard.sandiford at arm dot com
  Target Milestone: ---
  Host: x86_64-linux
Target: arm-linux-gnueabihf

The following fails:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/20050309-1.c
-fstack-protector -mcpu=cortex-m7 -mpure-code -c
during RTL pass: mach
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/20050309-1.c: In function
‘test’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/20050309-1.c:41:1: internal
compiler error: in change_address_1, at emit-rtl.c:2275
   41 | }
  | ^
0xcc01cd change_address_1
/home/marxin/Programming/gcc2/gcc/emit-rtl.c:2275
0xcc11be replace_equiv_address(rtx_def*, rtx_def*, bool)
/home/marxin/Programming/gcc2/gcc/emit-rtl.c:2545
0xce498c validize_mem(rtx_def*)
/home/marxin/Programming/gcc2/gcc/explow.c:531
0xd1273b emit_move_insn(rtx_def*, rtx_def*)
/home/marxin/Programming/gcc2/gcc/expr.c:3931
0x1c3d582 gen_split_74(rtx_insn*, rtx_def**)
/home/marxin/Programming/gcc2/gcc/config/arm/arm.md:9216
0x1e49f3b split_insns(rtx_def*, rtx_insn*)
/home/marxin/Programming/gcc2/gcc/config/arm/arm.md:9192
0xcc3c4d try_split(rtx_def*, rtx_insn*, int)
/home/marxin/Programming/gcc2/gcc/emit-rtl.c:3834
0x110b3c4 split_insn
/home/marxin/Programming/gcc2/gcc/recog.c:2884
0x110b82d split_all_insns_noflow()
/home/marxin/Programming/gcc2/gcc/recog.c:3046
0x16ca01b arm_reorg
/home/marxin/Programming/gcc2/gcc/config/arm/arm.c:19143
0x11599c0 execute
/home/marxin/Programming/gcc2/gcc/reorg.c:4028
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/97269] [11 Regression] ICE in change_address_1, at emit-rtl.c:2275 since r11-3427-ge94797250b403d66cb3624a594e41faf0dd76617

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-02
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Known to fail||11.0
  Known to work||10.2.0

[Bug tree-optimization/97270] New: [11 Regression] ICE in do_store_flag, at expr.c:12247 since r11-1445-g502d63b6d61415

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

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

Bug ID: 97270
   Summary: [11 Regression] ICE in do_store_flag, at expr.c:12247
since r11-1445-g502d63b6d61415
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: s390x-linux-gnu

One more VEC_COND_EXPR fallout:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/vect-cond-reduc-6.c -O2
-march=z13 -ftree-loop-vectorize -S
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/vect-cond-reduc-6.c: In
function ‘f’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/vect-cond-reduc-6.c:4:1:
internal compiler error: in do_store_flag, at expr.c:12247
4 | f (int *y)
  | ^
0xc66a47 do_store_flag
/home/marxin/Programming/gcc2/gcc/expr.c:12247
0xc59b26 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/marxin/Programming/gcc2/gcc/expr.c:9608
0xac32eb expand_gimple_stmt_1
/home/marxin/Programming/gcc2/gcc/cfgexpand.c:3786
0xac3538 expand_gimple_stmt
/home/marxin/Programming/gcc2/gcc/cfgexpand.c:3847
0xacb9f4 expand_gimple_basic_block
/home/marxin/Programming/gcc2/gcc/cfgexpand.c:5888
0xacd856 execute
/home/marxin/Programming/gcc2/gcc/cfgexpand.c:6572
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97270] [11 Regression] ICE in do_store_flag, at expr.c:12247 since r11-1445-g502d63b6d61415

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-02
  Known to work||10.2.0
  Known to fail||11.0

[Bug sanitizer/97229] pointer-compare sanitizer is very slow due to __asan::IsAddressNearGlobal

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

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

--- Comment #3 from Martin Liška  ---
Created attachment 49298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49298&action=edit
Reduced test-case

There's reduced test-case:

$ gcc pointer-cmp.c -fsanitize=address,pointer-compare &&
ASAN_OPTIONS="detect_invalid_pointer_pairs=2" perf record ./a.out
$ perf report --stdio
...
95.22%  a.outlibasan.so.6.0.0[.] __asan::GetGlobalsForAddress
 2.13%  a.outlibasan.so.6.0.0[.] __sanitizer::internal_memcpy
 0.75%  a.outlibasan.so.6.0.0[.] __sanitizer::BlockingMutex::Lock
 0.60%  a.outlibasan.so.6.0.0[.] __sanitizer::BlockingMutex::Unlock

[Bug sanitizer/97229] pointer-compare sanitizer is very slow due to __asan::IsAddressNearGlobal

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

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

--- Comment #4 from Martin Liška  ---
I've got a hackish patch that tries to resolve that.
Basically, linear iteration of globals is very slow and a better data structure
should be used (I used sorted list), so each lookup is at least O(log N).
I'm going to report that to upstream.

[Bug sanitizer/97229] pointer-compare sanitizer is very slow due to __asan::IsAddressNearGlobal

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

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

--- Comment #5 from Martin Liška  ---
Created attachment 49299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49299&action=edit
Hackish patch candidate

[Bug sanitizer/97229] pointer-compare sanitizer is very slow due to __asan::IsAddressNearGlobal

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
URL||https://github.com/google/s
   ||anitizers/issues/1324

--- Comment #6 from Martin Liška  ---
Waiting for an upstream fix.

[Bug gcov-profile/96913] [10 regression] gcov TOPN streaming is incorrect for shared libraries

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

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

--- Comment #9 from Sergei Trofimovich  ---
(In reply to Sergei Trofimovich from comment #8)
> Should be fixed for gcc-11. Will send a backport to gcc-10 this evening (the
> code changed slightly since gcc-10).

gcc-10 backport sent for review as
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554902.html

[Bug tree-optimization/96979] [9/10/11 Regression] Switch with case values derived from constexpr function takes unreasonable time to compile

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Not planning to backport to GCC 9 branch and older. The code is not 1:1 and I
don't want to introduce a new regression.

[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value

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

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Martin Liska
:

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

commit r9-8968-g7c55364eaaf5f882e80e8943e702081f9648f582
Author: Martin Liska 
Date:   Thu Oct 1 21:28:30 2020 +0200

gcov: fix streaming of HIST_TYPE_IOR histogram type.

gcc/ChangeLog:

PR gcov-profile/64636
* value-prof.c (stream_out_histogram_value): Allow negative
values for HIST_TYPE_IOR.

(cherry picked from commit 1921ebcaf6467996aede69e1bbe32400d8a20fe7)

[Bug gcov-profile/97069] Zero valued #line directive results in excessively large blocks of memory being allocated

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Martin Liska
:

https://gcc.gnu.org/g:20f699a44492f2f43351d19849873d1112ffc7e0

commit r9-8967-g20f699a44492f2f43351d19849873d1112ffc7e0
Author: Martin Liska 
Date:   Mon Sep 21 16:26:10 2020 +0200

gcov: fix streaming corruption

gcc/ChangeLog:

PR gcov-profile/97069
* profile.c (branch_prob): Line number must be at least 1.

gcc/testsuite/ChangeLog:

PR gcov-profile/97069
* g++.dg/gcov/pr97069.C: New test.

(cherry picked from commit 6b4e8bf88f1172ce8561f57b12fb81063b21a78f)

[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #19 from Martin Liška  ---
Resolved.

[Bug gcov-profile/97069] Zero valued #line directive results in excessively large blocks of memory being allocated

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Resolved.

[Bug gcov-profile/97193] [9/10/11 Regression] .gcno files are not written to same directory as the object file

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-3614-gf8dcbea5d2fb17dca3a7de97f15fc49997222365
Author: Martin Liska 
Date:   Fri Sep 25 10:53:26 2020 +0200

GCOV: do not mangle .gcno files.

gcc/ChangeLog:

PR gcov-profile/97193
* coverage.c (coverage_init): GCDA note files should not be
mangled and should end in output directory.

[Bug gcov-profile/97193] [9/10 Regression] .gcno files are not written to same directory as the object file

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] .gcno  |[9/10 Regression] .gcno
   |files are not written to|files are not written to
   |same directory as the   |same directory as the
   |object file |object file
  Known to work||11.0
  Known to fail|11.0|

--- Comment #6 from Martin Liška  ---
Fixed on master so far.

[Bug target/83562] broken destructors of thread_local objects on i686 mingw targets

[ralphengels at gmail dot com via Gcc-bugs]

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

ralphengels at gmail dot com  changed:

   What|Removed |Added

 CC||ralphengels at gmail dot com

--- Comment #4 from ralphengels at gmail dot com  
---
This still is not working causing several boost libraries to fail building when
using mingw-w64 compilers (gcc-9.3 and gcc-10.2).

Everything works fine with the 64 bit compiler but the i686 compiler reports
broken TLS. While we can get around it by disabling the TLS check for
libbost_fiber-mt.dll libboost_stacktrace_windbg_cached-mt.dll is another story
(halts the build if we skip the TLS check).

[Bug gcov-profile/97193] [9/10 Regression] .gcno files are not written to same directory as the object file

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Liska
:

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

commit r10-8843-gf97ef0b2dfdad07db3d564b932c7b7373654b7d4
Author: Martin Liska 
Date:   Fri Sep 25 10:53:26 2020 +0200

GCOV: do not mangle .gcno files.

gcc/ChangeLog:

PR gcov-profile/97193
* coverage.c (coverage_init): GCDA note files should not be
mangled and should end in output directory.

(cherry picked from commit f8dcbea5d2fb17dca3a7de97f15fc49997222365)

[Bug gcov-profile/97193] [9/10 Regression] .gcno files are not written to same directory as the object file

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Martin Liska
:

https://gcc.gnu.org/g:991a376015309ac9b413eeb97d94511908498e9a

commit r9-8969-g991a376015309ac9b413eeb97d94511908498e9a
Author: Martin Liska 
Date:   Fri Sep 25 10:53:26 2020 +0200

GCOV: do not mangle .gcno files.

gcc/ChangeLog:

PR gcov-profile/97193
* coverage.c (coverage_init): GCDA note files should not be
mangled and should end in output directory.

(cherry picked from commit f8dcbea5d2fb17dca3a7de97f15fc49997222365)

[Bug gcov-profile/97193] [9/10 Regression] .gcno files are not written to same directory as the object file

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
Fixed on all branches.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
I confirm it's a minor issue, but I don't see a trivial fix for it.

[Bug c++/81271] gcc/cp/lex.c:116: wrong condition ?

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

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

--- Comment #3 from Nathan Sidwell  ---
fwiw, I was kind of hoping the compiler could spot the test of three adjacent
bits and do a 3-bit extraction and comparison to zero.

[Bug c++/97268] [11 Regression] ICE in maybe_warn_pass_by_reference at gcc/tree-ssa-uninit.c:514 since r11-1763-g27aebb7d6cf14175

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

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

--- Comment #6 from Martin Liška  ---
(In reply to Martin Liška from comment #5)
> Started with Nathan's commit.

r11-1763-g27aebb7d6cf14175

[Bug target/96528] [11 Regression] vector comparisons on ARM

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed by r11-3600.

[Bug tree-optimization/97228] [11 regression] New ICEs on arm since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed by r11-3600.

[Bug target/97012] [SVE] Extend PR96357 to other aarch64-sve.md patterns

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Forgotten that I'd filed a PR for this...

Fixed for trunk by r11-3617, but needs to be backported.

[Bug gcov-profile/96913] [10 regression] gcov TOPN streaming is incorrect for shared libraries

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Sergei Trofimovich
:

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

commit r10-8844-gb843d57c57ac92c9cd38eec7289da2f1ea696f18
Author: Sergei Trofimovich 
Date:   Sun Sep 6 12:13:54 2020 +0100

gcov: fix TOPN streaming from shared libraries

Before the change gcc did not stream correctly TOPN counters
if counters belonged to a non-local shared object.

As a result zero-section optimization generated TOPN sections
in a form not recognizable by '__gcov_merge_topn'.

The problem happens because in a case of multiple shared objects
'__gcov_merge_topn' function is present in address space multiple
times (once per each object).

The fix is to never rely on function address and predicate on TOPN
counter types.

libgcc/ChangeLog:

PR gcov-profile/96913
* libgcov-driver.c (write_one_data): Avoid function pointer
comparison in TOP streaming decision.

(cherry picked from commit 4ecf368f4b4223fb2df4f3887429dfbb48852e38)

[Bug gcov-profile/96913] [10 regression] gcov TOPN streaming is incorrect for shared libraries

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.3

--- Comment #11 from Sergei Trofimovich  ---
Should be fixed for both affected gcc-10 and gcc-11.

[Bug target/97271] New: [ARM MVE]: Wrong code generated for scatter store with writeback intrinsics with -O2.

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

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

Bug ID: 97271
   Summary: [ARM MVE]: Wrong code generated for scatter store with
writeback intrinsics with -O2.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sripar01 at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49300&action=edit
test case

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/work/gnu-work/Release/build-arm-none-eabi/install/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/work/gnu-work/Release/build-arm-none-eabi/install/libexec/gcc/arm-none-eabi/11.0.0/lto-wrapper
Target: arm-none-eabi
Configured with: /work/gnu-work/Release/src/gcc/configure
--target=arm-none-eabi
--prefix=/work/gnu-work/Release/build-arm-none-eabi/install//
--with-gmp=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--with-mpfr=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--with-mpc=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--with-isl=/work/gnu-work/Release/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
--with-multilib-list=rmprofile --with-pkgversion=unknown
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200930 (experimental) (unknown)

$ cat bug.c
#include "arm_mve.h"
void
foo (uint32x4_t * addr, const int offset, int32x4_t value)
{
  vstrwq_scatter_base_wb_s32 (addr, 8, value);
}

$ arm-none-eabi-gcc  bug.c -S -O2 -march=armv8.1-m.main+mve -mfloat-abi=hard -o
-
...
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vldrw.32q3, [r0]
vstrw.u32   q0, [q3, #8]!  ---> (A)
vldr.64 d4, .L3
vldr.64 d5, .L3+8
vldrw.32q3, [r0]
vstrw.u32   q2, [q3, #8]!  ---> (B)
bx  lr
...

Current compiler wrongly generates 2 vstrw assembly instructions, where are
only one is expected.

[Bug target/97271] [ARM MVE]: Wrong code generated for scatter store with writeback intrinsics with -O2.

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada

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

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

--- Comment #14 from Martin Liška  ---
> Yes, it works. I've been using it for some time in out gcc11 package.

PING

[Bug c++/97266] "enum constant in boolean context" warning seems incorrect

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-02

--- Comment #5 from Jonathan Wakely  ---
Neither of those cases are constants, and the warning documentation (and the
actual diagnostic itself) talk about constants.

But there's still no warning for:

  constexpr ValidateFlag v = c;
  bool t = static_cast(v);

which definitely seems inconsistent. I don't know what the intended behaviour
is, but it should be consistent.

[Bug c++/97256] auto function return different result

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #7 from Jonathan Wakely  ---
And closing again.

[Bug target/97269] [11 Regression] ICE in change_address_1, at emit-rtl.c:2275 since r11-3427-ge94797250b403d66cb3624a594e41faf0dd76617

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug fortran/97245] ASSOCIATE intrinsic does not recognize a ponter variable the second time it is used

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-02
 Ever confirmed|0   |1
   Priority|P3  |P4

--- Comment #1 from Dominique d'Humieres  ---
Confirmed since at least GCC7.

[Bug c++/97266] "enum constant in boolean context" warning seems incorrect

[mfarazma.ext at gmail dot com via Gcc-bugs]

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

--- Comment #6 from m farazma  ---
(In reply to Jonathan Wakely from comment #5)
> Neither of those cases are constants, and the warning documentation (and the
> actual diagnostic itself) talk about constants.
> 
> But there's still no warning for:
> 
>   constexpr ValidateFlag v = c;
>   bool t = static_cast(v);
> 
> which definitely seems inconsistent. I don't know what the intended
> behaviour is, but it should be consistent.

When using clang 12 there are no warning messages. We had to 
use "-Wno-int-in-bool-context" to disable the warning on gcc.

[Bug fortran/97272] New: Wrong answer from MAXLOC with character arg

[longb at cray dot com via Gcc-bugs]

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

Bug ID: 97272
   Summary: Wrong answer from MAXLOC with character arg
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

Test case:

> cat test.f90
  program test
  character, allocatable :: a(:)
  integer(8) l, i
  l = 200_8
  allocate (a(l))
  do i = 1, l
  a(i) = 'a'
  end do
  l = l - 1
  a(l) = 'b'
  i = maxloc (a, dim=1, kind=8)
  print *, 'i = ', i, 'a(i) = ', a(i)
  end

Expected behavior (Cray):

> ftn test.f90
> ./a.out
 i =  199 a(i) = b

Incorrect result (gfortran):

> module swap PrgEnv-cray PrgEnv-gnu
> gfortran test.f90
> ./a.out
 i =   200 a(i) = a
> gfortran --version
GNU Fortran (GCC) 10.1.0 20200507 (Cray Inc.)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc

[drikosev at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Ev Drikos  ---
Created attachment 49301
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49301&action=edit
test-case with a module

Hello again,

Here is another test-case with a module.
It's a question if this should fail or pass.
But gcc-8.4 compiles it without errors.

Ev. Drikos

[Bug libstdc++/97273] New: Strange behaviour of unordered_set when vector is included (i686)

[rascmoo at gmail dot com via Gcc-bugs]

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

Bug ID: 97273
   Summary: Strange behaviour of unordered_set when vector is
included (i686)
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rascmoo at gmail dot com
  Target Milestone: ---

Created attachment 49302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49302&action=edit
A few simple source files demonstrating the problem, plus a .ii file generated
on my system

Hello,

I have recently been diagnosing a fault with the 32-bit build of an
application, and this has led me to find some strange behaviour with
unordered_set, when compiling for 32-bit x86 (i686). I have included an example
which demonstrates the behaviour.


Consider the following small program:

#include 
#include 

uint64_t getBegin(const std::unordered_set & set) {
return *set.begin();
}

It returns the first value in a uint64_t unordered_set. This can be compiled
into a shared library with the following command:
g++ -Wall -Wextra -fpic -shared -Os Working.cpp -o libworking.so
This works as intended on all 32 and 64 bit systems which I have tested it on,
and on all optimisation levels.

However, consider the next small program:

#include 

#include 
#include 

uint64_t getBegin(const std::unordered_set & set) {
return *set.begin();
}

The only change is the addition of a "#include ". This ought not to
have any impact on the program, and it ought to work exactly the same. It can
also be compiled into a shared library with the following command:
g++ -Wall -Wextra -fpic -shared -Os Broken.cpp -o libbroken.so

Indeed, when compiled on a 64 bit x86 system there is no difference - both
functions work as intended. However, when compiled either natively on a 32-bit
x86 system, or cross compiled to 32-bit using the "-m32" flag, "*set.begin()"
returns an incorrect value.

I tested both of these with the following simple test program:

#include 
#include 

uint64_t getBegin(const std::unordered_set & set);

int main(void) {
std::unordered_set set({1, 2, 3, 4, 5, 6, 7});
std::cout << getBegin(set) << "\n";
}

Which can be compiled using the following commands (linking to either working
or broken versions respectively):
g++ -Wall -Wextra -Os test.cpp -L. -lworking -o test
g++ -Wall -Wextra -Os test.cpp -L. -lbroken -o test

Both versions work correctly when compiled and running natively on a 64-bit x86
system, (they print "7"). But, when when either compiled with "-m32" on a
64-bit system, or compiled and running natively on a 32-bit x86 system, the
second (broken) variant prints "30064771072". This is certainly not one of the
numbers in the unordered_set.

I have reproduced the problem across several different 32-bit and 64-bit
systems. These are the versions reported by g++ --version, on the systems which
I have tried:

Debian 10 (stable):
g++ (Debian 8.3.0-6) 8.3.0

Debian 11 (testing):
g++ (Debian 10.2.0-9) 10.2.0

Fedora 32 (Workstation Edition):
g++ (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1)

Some source files and a simple makefile, which can reproduce the problem, are
attached.
I have also included the .ii file which is produced when running the following
command, on the broken variant of the function:
g++ -save-temps -m32 -Wall -Wextra -fpic -shared -Os Broken.cpp -o libbroken.so




Other things which I have noticed:

 > The problem happens with optimisation levels O1, O2, O3, Os and Ofast, but
does not occur with O0.
 > The problem occurs whenever vector is included BEFORE unordered_set. If
vector is included after unordered_set, behaviour is correct.
 > When broken, the memory address pointed to by the iterator returned by
begin(), seems to always be wrong by 4 bytes, (4 bytes before the address which
it should be).
 > When I compared the assembly output of the two functions, the offsets in
three movl instructions differ - see below. I assume this is causing the wrong
address to be returned.

Working version:
movl8(%eax), %eax   # MEM[(struct _Hash_node_base * *)set_2(D) + 8B],
MEM[(struct _Hash_node_base * *)set_2(D) + 8B]
movl12(%eax), %edx  # MEM[(const long long unsigned int &)_4 + 8],
MEM[(const long long unsigned int &)_4 + 8]
movl8(%eax), %eax   # MEM[(const long long unsigned int &)_4 + 8],
MEM[(const long long unsigned int &)_4 + 8]

Broken version:
movl8(%eax), %eax   # MEM[(struct _Hash_node_base * *)set_2(D) + 8B],
MEM[(struct _Hash_node_base * *)set_2(D) + 8B]
movl8(%eax), %edx   # MEM[(const long long unsigned int &)_4 + 4],
MEM[(const long long unsigned int &)_4 + 4]
movl4(%eax), %eax   # MEM[(const long long unsigned int &)_4 + 4],
MEM[(const long long unsigned int &)_4 + 4]


If there is any more information about this problem which you require, then
please let me know.
Thank you very much,
Dan Wilson.

[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access

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

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

--- Comment #11 from Tobias Burnus  ---
Cross ref: the submitted patch is at
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555352.html

[Bug libstdc++/97273] [8/9/10/11 Regression] Strange behaviour of unordered_set when vector is included (i686)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||7.5.0
   Target Milestone|--- |8.5
   Last reconfirmed||2020-10-02
  Known to fail||10.2.1, 11.0, 8.4.1, 9.3.1
 Status|UNCONFIRMED |NEW
Summary|Strange behaviour of|[8/9/10/11 Regression]
   |unordered_set when vector   |Strange behaviour of
   |is included (i686)  |unordered_set when vector
   ||is included (i686)
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I've been trying to reduce this a bit. So far I've cut it down to:

#include 
#include 
#include 
#include 
#include 

#include 
#include 

uint64_t getBegin(const std::unordered_set & set) {
return *set.begin();
}

which is less than everything in  and still generates the bad code:

  _3 = MEM[(const long long unsigned int &)_4 + 4];

The problem appeared between gcc 7 and gcc 8, apparently due to something added
in the libstdc++ headers. But I'm not sure yet if the actual bug is in the
compiler or library.

[Bug c++/97268] [11 Regression] ICE in maybe_warn_pass_by_reference at gcc/tree-ssa-uninit.c:514 since r11-1763-g27aebb7d6cf14175

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #7 from Nathan Sidwell  ---
Fixed r 9340d1c97b8

[Bug c/97274] New: Need ability to ensure no warning about tmpnam

[eyalroz at technion dot ac.il via Gcc-bugs]

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

Bug ID: 97274
   Summary: Need ability to ensure no warning about tmpnam
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

If you use tmpnam, or std::tmpnam in C++, you get a linker (not compiler,
linker) warning:

/usr/bin/ld:
CMakeFiles/simpleDrvRuntimePTX.dir/modified_cuda_samples/simpleDrvRuntimePTX/simpleDrvRuntimePTX.cpp.o:
in function `create_ptx_file[abi:cxx11]()':
/home/eyalroz/src/mine/cuda-api-wrappers/examples/modified_cuda_samples/simpleDrvRuntimePTX/simpleDrvRuntimePTX.cpp:105:
warning: the use of `tmpnam' is dangerous, better use `mkstemp'

there should be a way to disable that warning, when invoking the compiler
without separate linking, or simply when invoking the linker. I'm not sure if
this bug should even be filed here, since it's not obvious to me who is
"responsible" for the linker emitting this error.

[Bug c/97274] Need ability to ensure no warning about tmpnam

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

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

--- Comment #1 from Jonathan Wakely  ---
The linker issues the warning, because the symbol in glibc is annotated to
cause a warning. It has nothing to do with GCC.

[Bug c/97274] Need ability to ensure no warning about tmpnam

[eyalroz at technion dot ac.il via Gcc-bugs]

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

--- Comment #2 from Eyal Rozenberg  ---
(In reply to Jonathan Wakely from comment #1)
> The linker issues the warning, because the symbol in glibc is annotated to
> cause a warning. It has nothing to do with GCC.

Hmm. There's still a question of responsibility:

* Supposing at least some part of GCC is aware that a symbol used is annotated
in the library to cause a warning - should it not offer some mechanism for
circumventing that warning? Seeing how it's a "legitimate" standard library
function?
* Otherwise, would this be a bug to file against the linker, or against the
library?

[Bug c/97274] Need ability to ensure no warning about tmpnam

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Eyal Rozenberg from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > The linker issues the warning, because the symbol in glibc is annotated to
> > cause a warning. It has nothing to do with GCC.
> 
> Hmm. There's still a question of responsibility:
> 
> * Supposing at least some part of GCC is aware that a symbol used is

It's not aware, and can't be aware. GCC never sees the contents of libc.so
where the .gnu.warning section is.

> annotated in the library to cause a warning - should it not offer some
> mechanism for circumventing that warning? Seeing how it's a "legitimate"
> standard library function?

GCC has no way to know that, so your supposition is false.

> * Otherwise, would this be a bug to file against the linker, or against the
> library?

If you want a way to tell the linker not to issue such warnings, you need to
request that from the linker. There's no way to provide an option to glibc to
tell it to remove the annotation from the libc.so binary before you link to it. 

This is not a GCC issue.

[Bug fortran/97272] Wrong answer from MAXLOC with character arg

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-02
   Keywords||wrong-code
 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed for the case where the kind argument is present:

  i = maxloc (a, dim=1, kind=8)

or

  i = maxloc (a, dim=1, kind=4)

The issue does not occur when the kind argument is not present:

  i = maxloc (a, dim=1)

[Bug fortran/97272] Wrong answer from MAXLOC with character arg

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested fix:

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 3b3bd8629cd..9e9898c2bbf 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -5211,7 +5211,9 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * se, gfc_expr *
expr, enum tree_code op)
   while (a->next)
{
  b = a->next;
- if (b->expr == NULL || strcmp (b->name, "dim") == 0)
+ if (b->expr == NULL
+ || strcmp (b->name, "dim") == 0
+ || strcmp (b->name, "kind") == 0)
{
  a->next = b->next;
  b->next = NULL;

[Bug bootstrap/92719] MacOS 10.15 Catalina build fails

[nikhil.benesch at gmail dot com via Gcc-bugs]

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

Nikhil Benesch  changed:

   What|Removed |Added

 CC||nikhil.benesch at gmail dot com

--- Comment #3 from Nikhil Benesch  ---
For posterity, I could reproduce this issue even with the suggested
`./configure` arguments, i.e., excluding the `--enable-multilib` option.

The issue for me was that some of the configure checks in the gcc directory
were misfiring because they were unable to find gmp.h, though the top-level
config script had no trouble finding gmp.h. This caused configure to determine
that e.g. strsignal's declaration was missing, when in fact it was gmp.h that
could not be found.

I worked around the issue by using the ./contrib/download_prerequisites script
to build in-tree copies of gmp and friends. I suspect there is still a bug
here, though, when attempting to use the system's libgmp.

[Bug bootstrap/92719] MacOS 10.15 Catalina build fails

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

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Nikhil Benesch from comment #3)
> For posterity, I could reproduce this issue even with the suggested
> `./configure` arguments, i.e., excluding the `--enable-multilib` option.

> I worked around the issue by using the ./contrib/download_prerequisites
> script to build in-tree copies of gmp and friends. I suspect there is still
> a bug here, though, when attempting to use the system's libgmp.

There is no "system libgmp" on macOS, perhaps that is the missing piece of the
puzzle?

You have two ways to do this 
(1) build GMP (and friends) and place them somewhere (then use
--with-gmp=/path/to/gmp/prefix).
(2) build GMP (and friends) in-tree (as you have done).

both techniques work for me on catalina (and indeed on every version of OSX I
test on back to 10.4).  They also work on the unreleased macOS11

[Bug fortran/97272] Wrong answer from MAXLOC with character arg

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-October/055143.html

[Bug bootstrap/92719] MacOS 10.15 Catalina build fails

[nikhil.benesch at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Nikhil Benesch  ---
Ah, sorry, I was imprecise before. By “system gmp” I meant a gmp installed by
Homebrew, as in `brew install gmp`.

I believe this is a third option from the two you listed. (At least, it is on
non-macOS platforms.) without a `—with-gmp-dir` option, Homebrew’s GMP
installation gets automatically picked up by the top level configure script,
but somehow the configure script in the gcc subdirectory can’t find gmp.h.

If you think it’d be worthwhile, I’d be happy to undo the workaround and pull
harder on this thread.

[Bug fortran/95644] IEEE_FMA is missing from the IEEE_ARITHMETIC module

[longb at cray dot com via Gcc-bugs]

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

--- Comment #2 from Bill Long  ---
Any update on a fix for this?  (The original customer is asking.)

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com via Gcc-bugs]

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

--- Comment #19 from Bill Long  ---
On an ia64 Intel target that does not support x87 floating point, it seems that
having IEEE_SUPPORT_DATATYPE (1._10)  return .true. is as error.  If that is
fixed, will the rest of the issue fall into place?

[Bug rtl-optimization/97275] New: Linux kernel cgroup.c internal compiler error (ICE).

[dr.duncan.p.simpson at gmail dot com via Gcc-bugs]

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

Bug ID: 97275
   Summary: Linux kernel cgroup.c internal compiler error (ICE).
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dr.duncan.p.simpson at gmail dot com
  Target Milestone: ---
  Host: amd64-linux-gnu
Target: aarch64-linux-gnu
 Build: 11.0.0 20201002

Created attachment 49303
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49303&action=edit
cgroup.c reduced to compiler ICE generator

The attached file is a reduced version, which tickles the bug for me. Note that
not using -fno-strict-overflow or most other minor changes eliminate the ICE.

In the original version of cgroup.c many of the things which are compile time
constants in my version are values the compiler might not be able to reason
about.

dps@dps-laptop:~/src/kernel/foo$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/aarch64-linux-gnu/11.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../gcc/configure --enable-shared --enable-lto
--enable-languages=all --target=aarch64-linux-gnu
--program-prefix=aarch64-linux-gnu- --with-sysroot=/ --enable-host-shared
--enable-host-lto --with-as=/usr/aarch64-linux-gnu/bin/as
--with-ld=/usr/aarch64-linux-gnu/bin/ld --with-ar=/usr/aarch64-linux-gnu/bin/ar
--with-ranlib=/usr/aarch64-linux-gnu/bin/ranlib : (reconfigured)
../gcc/configure --enable-shared --enable-lto --enable-languages=all
--target=aarch64-linux-gnu --program-prefix=aarch64-linux-gnu- --with-sysroot=/
--enable-host-shared --enable-host-lto --with-as=/usr/aarch64-linux-gnu/bin/as
--with-ld=/usr/aarch64-linux-gnu/bin/ld --with-ar=/usr/aarch64-linux-gnu/bin/ar
--with-ranlib=/usr/aarch64-linux-gnu/bin/ranlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201002 (experimental) (GCC)

[Bug c++/95806] Result of call with reference argument to newed object is cached during constant evaluation

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-02

[Bug c++/95808] Can mismatch non-array new/delete with array new/delete during constant evaluation

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|wrong-code  |accepts-invalid
   Last reconfirmed||2020-10-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c++/97014] Class NTTPs not demangled in the compilation error

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed 47f09ec9717058ada97be33bcbb23ceb6322ba61

[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)

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

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

--- Comment #20 from Sergei Trofimovich  ---
(In reply to Martin Jambor from comment #18)
> I proposed the patch on the mailing list (I guess I should put Martin's name
> at least to the testsuite ChangeLog and probably to both):
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555284.html

Tested the patch against gcc-10.2.0 on original tauthon-2.8.2 test. Works as
well. Thank you!

[Bug c++/96331] Class template argument deduction (CTAD) with Concepts

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-02
   Keywords||rejects-valid

--- Comment #3 from Jonathan Wakely  ---
Reopening then, thanks, Tim.

[Bug c/97276] New: A whole if-block is ignored by avr-gcc 9.3.0

[tre at gmx dot de via Gcc-bugs]

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

Bug ID: 97276
   Summary: A whole if-block is ignored by avr-gcc 9.3.0
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tre at gmx dot de
  Target Milestone: ---

Created attachment 49304
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49304&action=edit
Identical example compiled with avr-gcc 7.5.0 and avr-gcc 9.3.0

Hi,

I have a weird avr-gcc bug that costed me some months to find as I couldn't
believe it's the compiler actually. So, I use the avr-gcc 9.3.0 on Mac OS
10.15.7 to compile a little function used for PWM fading of LEDs. The function
update_pwm_timeslots()
contains an if-block (ll.119-125):

if (last_brightness < 181 && j >= 181) 
{
/* middle interrupt: top 65k */
slot->top = 0xfe00;
slot->mask = ~mask;
++slot;
}

This block seems to be completely ignored by the compilers equal or newer than
avr-gcc 8.3.0, i.e. the block doesn't appear in the assembly. Here is the list
of compilers I tested:

avr-gcc 4.9.4 (working)
avr-gcc 5.5.0 (working)
avr-gcc 6.5.0 (working)
avr-gcc 7.5.0 (working)
avr-gcc 8.4.0 (broken)
avr-gcc 9.3.0 (broken)

The diff between the assemblies (pwm.s) perfectly reveals that the if-block is
skipped by avr-gcc 9.3.0:

277c274
< mov   r15, r31
---
> mov   r9, r31
278a276,305
> j = scalevalue(j, global_pwm.dim);
> mov   r18, r22
> ldi   r19, 0x00   ; 0
> rjmp  .+0 ; 0x1b6 1b4: 
> R_AVR_13_PCREL .text+0x222
> if (j == 255) break;
> cpi   r23, 0xFF   ; 255
> brne  .+0 ; 0x1ba 1b8: 
> R_AVR_7_PCREL  .text+0x1bc
> rjmp  .+0 ; 0x1bc 1ba: 
> R_AVR_13_PCREL .text+0x270
>   if (last_brightness < 181 && j >= 181) 
> ldi   r30, 0xB4   ; 180
> cpr30, r11
> brcc  .+0 ; 0x1c2 1c0: 
> R_AVR_7_PCREL  .text+0x1c4
> rjmp  .+0 ; 0x1c4 1c2: 
> R_AVR_13_PCREL .text+0x24c
> cpi   r23, 0xB5   ; 181
> brcc  .+0 ; 0x1c8 1c6: 
> R_AVR_7_PCREL  .text+0x1ca
> rjmp  .+0 ; 0x1ca 1c8: 
> R_AVR_13_PCREL .text+0x24c
>   slot->top = 0xfe00;
> stX+, r8
> stX, r9
> sbiw  r26, 0x01   ; 1
>   slot->mask = ~mask;
> movw  r30, r24
> com   r30
> com   r31
> adiw  r26, 0x02   ; 2
> stX+, r30
> stX, r31
> sbiw  r26, 0x03   ; 3
>   ++slot;
> adiw  r26, 0x04   ; 4


I attached the example with a Makefile adapted to avr-gcc 7.5.0 and avr-gcc
9.3.0 and the corresponding assembly outputs (pwm.s) and all intermediate
files. The README.txt contains the individual log outputs.

[Bug c/97276] A whole if-block is ignored by avr-gcc 9.3.0

[tre at gmx dot de via Gcc-bugs]

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

--- Comment #1 from David Weese  ---
The README.txt also contains the steps to reproduce the pwm.s assemblies.

[Bug c++/97277] New: Lambda in fold expressions capture arguments are default initialized

[cusimr at amazon dot com via Gcc-bugs]

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

Bug ID: 97277
   Summary: Lambda in fold expressions capture arguments are
default initialized
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cusimr at amazon dot com
  Target Milestone: ---

https://godbolt.org/z/69ah91

#include 
#include 

struct Index {
size_t i;
};

int main() {
std::tuple t{1, 2.f, 3, 4};

Index i{1};
std::apply([i](auto&& ...args) {
(..., [i](auto&& arg) { std::cout << arg + i.i << "\n"; }(args));
}, t);

}

g++ -std=c++17

Expected Output:
2, 3, 4, 5

Actual Output:
2, 2, 3, 4

This bit me today and I found this on Ubuntu 18.04 LTS. I realize this is fixed
as of 8.1 but Ubuntu 18.04 LTS is supported until 2023 meaning it's likely this
bug will persist in the wild for at least 3 more years. Not sure if I should
report this as a bug to Ubuntu or if there's a possibility of a backport fix to
7.5 or even a new 7.6 release.

[Bug libstdc++/97273] [8/9/10/11 Regression] Strange behaviour of unordered_set when vector is included (i686)

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
It looks like the bug is that cp_tree_equal considers __alignof__(FOO) the same
as  alignof(FOO), but they have different semantics ever since the fix for
PR69650.

This manifests here because when  is included before ,
the specialization cache conflates the dependent specialization

   aligned_storage

used in include/bits/stl_vector.h:1726 with the later dependent specialization

   aligned_storage

used in include/ext/aligned_buffer.h:91.  We later instantiate the latter type
with _Tp=uint64_t as part of the implementation of unordered_set, but
4 == alignof(uint64_t) != __alignof__(uint64_t) == 8 on x86 so our assumptions
about the alignment of the type become incoherent.

I think PR88115 reports the same issue.

The following patch to cp_tree_equal seems to fix it:

 gcc/cp/tree.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-) 

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c  
index 8b7c6798ee9..8ed9eed1ea5 100644   
--- a/gcc/cp/tree.c 
+++ b/gcc/cp/tree.c 
@@ -3787,8 +3787,11 @@ cp_tree_equal (tree t1, tree t2) 
return true;
   }

-case SIZEOF_EXPR:  
 case ALIGNOF_EXPR: 
+  if (ALIGNOF_EXPR_STD_P (t1) != ALIGNOF_EXPR_STD_P (t2))  
+   return false;   
+  /* Fall through.  */ 
+case SIZEOF_EXPR:  
   {
tree o1 = TREE_OPERAND (t1, 0); 
tree o2 = TREE_OPERAND (t2, 0);

[Bug c++/97278] New: increment or decrement operator on the same object

[tangyixuan at mail dot dlut.edu.cn via Gcc-bugs]

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

Bug ID: 97278
   Summary: increment or decrement operator on the same object
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

Hi, the parameters of 'func' are based on the values of 'i'. if 'a' is 4, does
it mean that 'i' is increased after '++i' and 'i++'? So, why the value of 'b'
is 2?

$ cat s.cpp

#include 
using namespace std;
int func(int a, int b)
{
cout << a << " " << b <<"\n";
return a << b;
}
int main()
{
int i = 2;
cout << func(++i, i++) << "\n";
};

$ g++ s.cpp
$ ./a.out
4 2
16

$ clang++ s.cpp
$ ./a.out
3 3
24