[Bug c++/101990] [12 Regression] ICE after parse error with concepts

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started to ICE since r10-5014-g861d4af8d82819a8.

[Bug other/101984] [12 Regression] gimple-ssa-warn-access memory leak

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug sanitizer/101978] thread sanitizer false positive when condition variable

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-08-20
 Ever confirmed|0   |1

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

[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored

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

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

--- Comment #24 from Martin Liška  ---
> Correct, but `--help` and `--version` are formatted for humans, not machines.
> This can lead to false positives or negatives.  It forces every application
> that
> calls gcov and wants to support wide range of versions to embed its copy of
> knowledge about gcov's development history.  And `--help` won't tell if `-x`
> works with `--json-format`, that's why `--version` needs to be used as well.

I see your point, but I would rather recommend doing a "configure check", I
mean having
a bash snippet that tests various features.

[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored

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

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

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

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

commit r12-3038-gb777f228b481ae881a7fbb09de367a053740932c
Author: Martin Liska 
Date:   Tue Aug 17 16:24:26 2021 +0200

gcov: fix output location for JSON mode.

PR gcov-profile/89961

gcc/ChangeLog:

* gcov.c (make_gcov_file_name): Rewrite using std::string.
(mangle_name): Simplify, do not used the second argument.
(strip_extention): New function.
(get_md5sum): Likewise.
(get_gcov_intermediate_filename): Handle properly -p and -x
options.
(output_gcov_file): Use string type.
(generate_results): Likewise.
(md5sum_to_hex): Remove.

[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||11.2.0
  Known to work||12.0

--- Comment #26 from Martin Liška  ---
Fixed on master so far, I'm planning to do a backport to gcc-11 branch.

[Bug target/95566] x86 instruction selection --- some REX prefixes unnecessary

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #2 from Hongtao.liu  ---
(In reply to Andrew Pinski from comment #1)
> Reduced testcase:
> int f(unsigned short *a, unsigned long long d)
> {
> return *a == (d>>48);
> }
> 
>  CUT 
> of the compilers I have compared, only ICX can do this:
> shrq$48, %rsi
> xorl%eax, %eax
> cmpw%si, (%rdi)
> sete%al
> retq

Failed to match this instruction:
(set (reg:QI 93)
(eq:QI (lshiftrt:DI (reg:DI 95)
(const_int 48 [0x30]))
(zero_extend:DI (mem:HI (reg:DI 94) [1 *a_6(D)+0 S2 A16]

guess we can drop the zero_extend here, but still 3 instruction vs 3
instruction, just some codesize optimization.

[Bug target/101935] [12 Regression] 538.imagick_r LTO -Ofast regression on Zen2 and Kabylake caused by r12-2666-g29f0e955c97

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
We can reproduce it on our local znver2 and skylake client.

[Bug target/101935] [12 Regression] 538.imagick_r LTO -Ofast regression on Zen2 and Kabylake caused by r12-2666-g29f0e955c97

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-08-20
 Status|UNCONFIRMED |NEW

[Bug analyzer/101980] [12 regressions] many test case failures after r12-3002

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug go/101994] New: go1: internal compiler error: in return_statement, at go/go-gcc.cc:2318

[lebedev.k.m at gmail dot com via Gcc-bugs]

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

Bug ID: 101994
   Summary: go1: internal compiler error: in return_statement, at
go/go-gcc.cc:2318
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: lebedev.k.m at gmail dot com
CC: cmang at google dot com
  Target Milestone: ---

docker run -it gcc:11 bash
root@6c5083a4faa6:/# git clone https://github.com/chrislusf/seaweedfs
Cloning into 'seaweedfs'...
remote: Enumerating objects: 46106, done.
remote: Counting objects: 100% (1097/1097), done.
remote: Compressing objects: 100% (536/536), done.
remote: Total 46106 (delta 700), reused 835 (delta 535), pack-reused 45009
Receiving objects: 100% (46106/46106), 39.24 MiB | 1.54 MiB/s, done.
Resolving deltas: 100% (32436/32436), done.
root@6c5083a4faa6:/# cd seaweedfs/weed/storage/needle_map
root@6c5083a4faa6:/seaweedfs/weed/storage/needle_map# go test
go: downloading github.com/google/btree v1.0.0
go: downloading github.com/syndtr/goleveldb v1.0.0
go: downloading github.com/spf13/viper v1.4.0
go: downloading github.com/prometheus/client_golang v1.11.0
go: downloading github.com/golang/protobuf v1.4.3
go: downloading google.golang.org/grpc v1.29.1
go: downloading google.golang.org/protobuf v1.26.0-rc.1
go: downloading github.com/fsnotify/fsnotify v1.4.9
go: downloading github.com/hashicorp/hcl v1.0.0
go: downloading github.com/magiconair/properties v1.8.1
go: downloading github.com/mitchellh/mapstructure v1.1.2
go: downloading github.com/pelletier/go-toml v1.7.0
go: downloading github.com/spf13/afero v1.6.0
go: downloading github.com/spf13/cast v1.3.0
go: downloading github.com/spf13/jwalterweatherman v1.1.0
go: downloading github.com/spf13/pflag v1.0.3
go: downloading gopkg.in/yaml.v2 v2.3.0
go: downloading github.com/prometheus/common v0.26.0
go: downloading github.com/prometheus/client_model v0.2.0
go: downloading github.com/beorn7/perks v1.0.1
go: downloading github.com/cespare/xxhash v1.1.0
go: downloading github.com/prometheus/procfs v0.6.0
go: downloading google.golang.org/genproto v0.0.0-20200608115520-7c474a2e3482
go: downloading github.com/golang/snappy v0.0.4
go: downloading github.com/cespare/xxhash/v2 v2.1.1
go: downloading golang.org/x/net v0.0.0-20210813160813-60bc85c4be6d
go: downloading golang.org/x/sys v0.0.0-20210817142637-7d9622a276b7
go: downloading golang.org/x/text v0.3.6
go: downloading github.com/matttproud/golang_protobuf_extensions v1.0.1
# github.com/chrislusf/seaweedfs/weed/storage/needle_map
[github.com/chrislusf/seaweedfs/weed/storage/needle_map.test]
go1: internal compiler error: in return_statement, at go/go-gcc.cc:2318
0x16a3ed7 internal_error(char const*, ...)
???:0
0x727013 fancy_abort(char const*, int, char const*)
???:0
0x7f4369 Return_statement::do_get_backend(Translate_context*)
???:0
0x7a5033 Block::get_backend(Translate_context*)
???:0
0x7e26cc Block_statement::do_get_backend(Translate_context*)
???:0
0x7a5033 Block::get_backend(Translate_context*)
???:0
0x7a5c33 Function::build(Gogo*, Named_object*)
???:0
0x7af247 Gogo::write_globals()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
note: module requires Go 1.17
FAILgithub.com/chrislusf/seaweedfs/weed/storage/needle_map [build failed]

[Bug target/101981] GCC10 produces bigger asm for simple switch than GCC7 - cortexM4

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |target
 Target|cortex-m4   |arm
  Build|-Os |

--- Comment #1 from Richard Biener  ---
It's likely caused by switch lowering where costing for such special cases is
going to be interesting at least.

[Bug go/101994] go1: internal compiler error: in return_statement, at go/go-gcc.cc:2318

[lebedev.k.m at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Konstantin Lebedev  ---
go build -gccgoflags "-v"
# github.com/chrislusf/seaweedfs/weed/storage/needle_map
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gccgo
Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)
COLLECT_GCC_OPTIONS='-c' '-O2' '-g' '-m64'
'-fdebug-prefix-map=/tmp/go-build2182021944=/tmp/go-build'
'-gno-record-gcc-switches'
'-fgo-pkgpath=github.com/chrislusf/seaweedfs/weed/storage/needle_map' '-o'
'/tmp/go-build2182021944/b001/_go_.o' '-I'
'/tmp/go-build2182021944/b001/_importcfgroot_' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' '/tmp/go-build2182021944/b001/'
 /usr/local/libexec/gcc/x86_64-linux-gnu/11.2.0/go1 ./compact_map.go ./memdb.go
./needle_value.go ./needle_value_map.go -quiet -dumpdir $WORK/b001/ -dumpbase
_go_.go -dumpbase-ext .go -m64 -mtune=generic -march=x86-64 -g
-gno-record-gcc-switches -O2 -version
-fdebug-prefix-map=/tmp/go-build2182021944=/tmp/go-build
-fgo-pkgpath=github.com/chrislusf/seaweedfs/weed/storage/needle_map -I
$WORK/b001/_importcfgroot_ -L/usr/local/lib/gcc/x86_64-linux-gnu/11.2.0
-L/usr/local/lib/gcc/x86_64-linux-gnu/11.2.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/local/lib/gcc/x86_64-linux-gnu/11.2.0/../../.. -o /tmp/ccoXHlsb.s
GNU Go (GCC) version 11.2.0 (x86_64-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.1.0, MPFR version
3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Go (GCC) version 11.2.0 (x86_64-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.1.0, MPFR version
3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
go1: internal compiler error: in return_statement, at go/go-gcc.cc:2318
0x16a3ed7 internal_error(char const*, ...)
???:0
0x727013 fancy_abort(char const*, int, char const*)
???:0
0x7f4369 Return_statement::do_get_backend(Translate_context*)
???:0
0x7a5033 Block::get_backend(Translate_context*)
???:0
0x7e26cc Block_statement::do_get_backend(Translate_context*)
???:0
0x7a5033 Block::get_backend(Translate_context*)
???:0
0x7a5c33 Function::build(Gogo*, Named_object*)
???:0
0x7af247 Gogo::write_globals()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
note: module requires Go 1.17

[Bug tree-optimization/101991] bit_and or bit_ior with an invariant inside loop is not pulled out of the loop

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-08-20

--- Comment #1 from Richard Biener  ---
   [local count: 955630225]:
  # r_11 = PHI 
  r_8 = e_7(D) & r_11;

I wonder if this is sth for phiopt to pattern match.  In principle VN
would need to figure (for PRE) that the PHI translated d_3(D) & e_7(D)
is equal to r_8.  So the "trick" (aka pattern-matching) could be done
during phi_translation.

But then both look like a hack.  Curiously when we do

int f(int t, int d, int e)
{
  int r = d & e;
  for(int i = 0; i < t; i++)
r &= e;
  return r;
}

aka "peel" one iteration, then CCP is what eliminates the in-loop AND.
Ah, that's because we simplify d & e & e since we optimistically start
with just the entry edge value.  And that remains so.  With PRE
we're not fully re-doing VN of PHIs but phi-translation seeks to
re-use existing value-numbers where possible, so a programmatic approach
doesn't work here.

[Bug tree-optimization/101993] Potential vectorization opportunity when condition checks array address

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2021-08-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We can vectorize this with masked moves when using AVX2.  clang seems to simply
remove the test completely - C seems to guarantee that a + i is a valid pointer
if any of a + i is accessed and thus a + i is never NULL.

But then - just don't write such stupid checks?  What real-world code was
this testcase created from?

There is currently no optimization phase that would use loop info to elide NULL
pointer checks and I'm not sure where I'd put such.  Note the argument for
GCC would be that the access *(a + i) infers that a + i does not "overflow"
to another object (including NULL).  That's sth the points-to solver would
assume here (but the points-to solver is bad at tracking NULL).

[Bug c++/101988] [12 Regression] Accepts invalid new-expression of array of deduced class template

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Jonathan Wakely  ---
Started to be accepted with r12-1933:

c++: DR2397 - auto specifier for * and & to arrays [PR100975]

[Bug c++/61105] [constexpr] accepts-invalid with new-expression in constant expression

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

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

--- Comment #9 from Jonathan Wakely  ---
Richard's comment 0 testcase gives an error since r238909 (as Martin noted).

Martin's comment 6 testcase gives an error since r12-388:

c++: Remove GCC12 FIXME for DR1312

This patch removes a FIXME I left for myself for GCC 12, along with
adjusting the relevant test.

[Bug tree-optimization/96481] SLP fail to vectorize VEC_COND_EXPR pattern.

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

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

--- Comment #5 from Richard Biener  ---
so one interesting speciality of this testcase is that the ifs switch between
two scalar values and overall there's no control flow effect.  That is, for the
issue of splitting the dataref groups which we currently do on a BB granularity
we could solve this by not splitting groups when we are sure all members of the
group are either executed or not executed (which is the real intent of this
splitting).

In fact the current dataref_group compute seems to be useful only for
making sure to split groups _inside_ BBs at suitable points and the
cross-BB split is ensured by vect_analyze_data_ref_accesses.  We'd need
to enhance the dataref_group computation to be conservative for
cross-BB groups to relax the latter (and for outer loop vect compute it
there as well).  The simplest correctness fix is to ensure the group_id
is bumped when going from one BB to the next.

That would help this case up to encountering the PHIs/ifs which
we only vectorize when they are in the same BB.

inline unsigned opt(unsigned a, unsigned b, unsigned c, unsigned d) {
return a > b ? c : d;
}

void opt( unsigned * __restrict dst, const unsigned *pa, const unsigned *pb,
const unsigned *pc, const unsigned  *pd )
{
  unsigned tem = opt(*pa++, *pb++, *pc++, *pd++);
  unsigned tem1 = opt(*pa++, *pb++, *pc++, *pd++);
  unsigned tem2 = opt(*pa++, *pb++, *pc++, *pd++);
  unsigned tem3 = opt(*pa++, *pb++, *pc++, *pd++);
  *dst++ = tem;
  *dst++ = tem1;
  *dst++ = tem2;
  *dst++ = tem3;
}

ends up with

  _35 = {iftmp.24_22, iftmp.24_23, iftmp.24_24, iftmp.24_25};
  vectp.30_34 = dst_26(D);
  MEM  [(unsigned int *)vectp.30_34] = _35;

SLP discovery stops at the PHIs which are spread out (and there's still
the loads spread as well).

[Bug c/101995] New: regression built-in memset missed-optimization arm -Os

[dumoulin.thibaut at gmail dot com via Gcc-bugs]

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

Bug ID: 101995
   Summary: regression built-in memset missed-optimization arm -Os
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dumoulin.thibaut at gmail dot com
  Target Milestone: ---

For cortex-m4 -Os, GCC10 produces bigger assembly code than GCC7 when memset is
called.

Here is the C code example to trigger the regression:

```C
#include 
#include 

struct foo_t {
  int a;
  int b;
  int c;
  int d;
};

/* Random function modifying foo with another value than 0 */
void doStuff(struct foo_t *foo) {
  foo->b = foo->a + foo->c;
}

void twoLinesFunction(struct foo_t *foo) {
  /* R0 is saved in GCC10 but not in GCC7 */
  memset(foo, 0x00, sizeof(struct foo_t));
  doStuff(foo);
}

int main(void) {
  struct foo_t foo;
  twoLinesFunction(&foo);
  return 0;
}
```

compile command: `gcc -Os -mcpu=cortex-m4`

GCC7.3.1 produces:
```asm
:
push{r3, lr}
movsr2, #16
movsr1, #0
bl  8168 
ldmia.w sp!, {r3, lr}
b.w 8104 
```

While GCC10.3.0 produces:
```asm
:
push{r4, lr}
movsr2, #16
mov r4, r0--> backup r0
movsr1, #0
bl  8174 
mov r0, r4--> restore r0
ldmia.w sp!, {r4, lr}
b.w 810c 
```

Main function remains the same.

The builtin memset function does not change R0 so there is no need to save it
and restore it later. GCC7 is more efficient.
GCC10 should not backup R0 for this builtin function in this case, it produces
slower code.

There is this PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61241 which is
also referring to this behavior with a patch to implement the optimization but
I'm not sure when this optimization has been wiped out.

[Bug tree-optimization/101993] Potential vectorization opportunity when condition checks array address

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongyu Wang  ---
(In reply to Richard Biener from comment #1)
> We can vectorize this with masked moves when using AVX2.  clang seems to
> simply remove the test completely - C seems to guarantee that a + i is a
> valid pointer
> if any of a + i is accessed and thus a + i is never NULL.
> 
> But then - just don't write such stupid checks?  What real-world code was
> this testcase created from?

It came from 538.imagick_r

---
#define GetPixelIndex(indexes) \
  ((indexes == (const unsigned short *) NULL) ? 0 : (*(indexes)))

for (v=0; v < (ssize_t) kernel->height; v++) {
  for (u=0; u < (ssize_t) kernel->width; u++, k--) {
if ( IsNaN(*k) ) continue;
result.red += (*k)*k_pixels[u].red;
result.green   += (*k)*k_pixels[u].green;
result.blue+= (*k)*k_pixels[u].blue;
result.opacity += (*k)*k_pixels[u].opacity;
if ( image->colorspace == CMYKColorspace)
  result.index += (*k)*GetPixelIndex(k_indexes+u);
  }
  k_pixels += virt_width;
  k_indexes += virt_width;
}
---

I extracted it to a small test in https://godbolt.org/z/G5h6nWvb5
which can be vectorized by clang but not gcc due to such pattern.

> 
> There is currently no optimization phase that would use loop info to elide
> NULL pointer checks and I'm not sure where I'd put such.  Note the argument
> for
> GCC would be that the access *(a + i) infers that a + i does not "overflow"
> to another object (including NULL).  That's sth the points-to solver would
> assume here (but the points-to solver is bad at tracking NULL).

[Bug tree-optimization/96481] SLP fail to vectorize VEC_COND_EXPR pattern.

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

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

--- Comment #6 from Richard Biener  ---
double a[2];
typedef double v2df __attribute__((vector_size(16)));
void foo (v2df x, v2df y, v2df z, v2df w)
{
  double a0, a1;
  a0 = x[0] < y[0] ? z[0] : w[0];
  a1 = x[1] < y[1] ? z[1] : w[1];
  a[0] = a0;
  a[1] = a1;
}

is maybe a testcase that only has the PHI / gimple_cond parts preventing full
vectorization.

I've pushed a patch that should allow experimenting with relaxing the BB split
of the dataref groups but I'm wondering about a good testcase to motivate
fixing that on its own.

[Bug ipa/101949] [11/12 Regression] git miscompiled with -flto -fipa-pta since r11-5061-g85ebbabd85e03bdc

[boris2.9 at gmail dot com via Gcc-bugs]

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

Boris Carvajal  changed:

   What|Removed |Added

 CC||boris2.9 at gmail dot com

--- Comment #8 from Boris Carvajal  ---
I just want to add that running 'git ls-tree HEAD' inside a git repo is also
bugged, there is no crash here but the file names in the output are corrupted.

A Gentoo user experiencing something similar reported that adding
'-ffat-lto-objects' resolves the problem.
(https://github.com/InBetweenNames/gentooLTO/pull/776)

[Bug debug/101905] [9/10/11/12 Regression] Missed debug information for global register variable

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

So like this (untested except for the testcase)?

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

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

https://gcc.gnu.org/g:12f22906d3c025e7edb60e3264dc9cd27a49e3e1

commit r12-3043-g12f22906d3c025e7edb60e3264dc9cd27a49e3e1
Author: Harald Anlauf 
Date:   Fri Aug 20 13:38:00 2021 +0200

Fortran - use temporary char buffer for passing HOST_WIDE_INT to gfc_error

gcc/fortran/ChangeLog:

PR fortran/100950
* simplify.c (substring_has_constant_len): Fix format string of
gfc_error, pass HOST_WIDE_INT bounds values via char buffer.

[Bug ipa/101949] [11/12 Regression] git miscompiled with -flto -fipa-pta since r11-5061-g85ebbabd85e03bdc

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

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

--- Comment #9 from Martin Liška  ---
All right, so I investigated more, with a new dbg counter in
gimple_call_arg_flags the following flags are updated:

combine: flags=0, modref_flags=0
# .MEM_817 = VDEF <.MEM_816>
_35 = check_connected (iterate_ref_map2, &rm, &opt);

combine: flags=0, modref_flags=0
# .MEM_68 = VDEF <.MEM_67>
_29 = check_connected (iterate_ref_map2, &rm, &opt);

where arg == 0, so IPA MOD ref claims that iterate_ref_map2 is '(EAF_NOCLOBBER
| EAF_NOESCAPE)' which is likely the problem.

[Bug target/95964] AArch64 arm_neon.h arithmetic functions lack appropriate attributes

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

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
There are some lingering aarch64-simd-builtins.def entries
that use “, ALL”, so I think we should keep this open until
they've all been converted.  The testcase was just an example,
rather than the single motivating case.

[Bug ipa/101949] [11/12 Regression] git miscompiled with -flto -fipa-pta since r11-5061-g85ebbabd85e03bdc

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

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

--- Comment #10 from Martin Liška  ---
Created attachment 51328
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51328&action=edit
LTRANS IPA PTA dump - good

[Bug ipa/101949] [11/12 Regression] git miscompiled with -flto -fipa-pta since r11-5061-g85ebbabd85e03bdc

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

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

--- Comment #11 from Martin Liška  ---
Created attachment 51329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51329&action=edit
LTRANS IPA PTA dump - bad

[Bug target/95962] Inefficient code for simple arm_neon.h iota operation

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

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Tamar Christina from comment #1)
> We generate the correct code at -O3 but not -O2.
> 
> At -O3 we generate
> 
> foo:
> adrpx0, .LC0
> sub sp, sp, #16
> ldr q0, [x0, #:lo12:.LC0]
> add sp, sp, 16
> ret
> 
> where the problem seems to be at at -O2 store merging has broken up the
> construction of `array` into two separate memory accesses:
> 
>   MEM  [(int *)&array] = 4294967296;
>   MEM  [(int *)&array + 8B] = 12884901890;
> 
> whereas at -O3 we still have a single assignment:
> 
>   MEM  [(int *)&array] = { 0, 1, 2, 3 };
> 
> I'm not sure even if we made these loads gimple level if that would help.
> we'd still have the explicit MEMs created by store merging.
If we folded them to gimple loads, the gimple optimisers should replace
the MEM with an assignment of the VECTOR_CST { 0, 1, 2, 3 } to an SSA name,
with the function returning the SSA name.

expand will convert this back into a memory access, in the form of
an RTL constant pool load.  But that will avoid the stack temporary
and thus the pointless stack adjustments.

[Bug ipa/101949] [11/12 Regression] git miscompiled with -flto -fipa-pta since r11-5061-g85ebbabd85e03bdc

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

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

--- Comment #12 from Richard Biener  ---
> cat gcc/testsuite/gcc.dg/lto/pr101949_0.c
/* { dg-lto-do run } */
/* { dg-lto-options { "-O2 -fipa-pta -flto -flto-partition=1to1" } } */

extern int bar (int (*)(int *), int *);

static int x;

static int __attribute__ ((noinline)) foo (int *p)
{
  *p = 1;
  x = 0;
  return *p;
}

int main ()
{
  if (bar (foo, &x) != 0)
__builtin_abort ();
  return 0;
}
> cat gcc/testsuite/gcc.dg/lto/pr101949_1.c
int __attribute__((noinline,noclone)) bar (int (*fn)(int *), int *p)
{
  return fn (p);
}

[Bug ipa/101949] [11/12 Regression] git miscompiled with -flto -fipa-pta since r11-5061-g85ebbabd85e03bdc

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

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

--- Comment #13 from Richard Biener  ---
When modref claims that bar doesn't write to 'fn' that confuses IPA PTA since
internally it treats calling a function as "writing" to the argument space of
all functions the function pointer points to.

I'm not sure if it makes much sense to maintain any EAF_* flags when the
argument is called, maybe we can drop to varying here in modref?  For PTA
it's really difficult since there may be data and functions in points-to
sets so we can't easily "ignore" EAF_* flags for some arguments but not
others.  Also consider function pointers passed through a void * argument.

[Bug ipa/101949] [11/12 Regression] git miscompiled with -flto -fipa-pta since r11-5061-g85ebbabd85e03bdc

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Liška  ---
Let me write a patch for it.

[Bug target/101981] GCC10 produces bigger asm for simple switch than GCC7 - cortexM4

[dumoulin.thibaut at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Thibaut M.  ---
I'm not sure to understand your statement.

It looks like the switch lowering is wrong here because it takes now more time
with the new GCC than the previous one. Is looks like a regression.

[Bug middle-end/101995] regression built-in memset missed-optimization arm -Os

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||needs-bisection, ra

--- Comment #1 from Richard Biener  ---
The RA used to know how to rematerialize a register from the memset return
value.
Sth made that no longer work it seems.

[Bug tree-optimization/101993] Potential vectorization opportunity when condition checks array address

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Fri, 20 Aug 2021, wwwhhhyyy333 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101993
> 
> --- Comment #2 from Hongyu Wang  ---
> (In reply to Richard Biener from comment #1)
> > We can vectorize this with masked moves when using AVX2.  clang seems to
> > simply remove the test completely - C seems to guarantee that a + i is a
> > valid pointer
> > if any of a + i is accessed and thus a + i is never NULL.
> > 
> > But then - just don't write such stupid checks?  What real-world code was
> > this testcase created from?
> 
> It came from 538.imagick_r
> 
> ---
> #define GetPixelIndex(indexes) \
>   ((indexes == (const unsigned short *) NULL) ? 0 : (*(indexes)))
> 
> for (v=0; v < (ssize_t) kernel->height; v++) {
>   for (u=0; u < (ssize_t) kernel->width; u++, k--) {
> if ( IsNaN(*k) ) continue;
> result.red += (*k)*k_pixels[u].red;
> result.green   += (*k)*k_pixels[u].green;
> result.blue+= (*k)*k_pixels[u].blue;
> result.opacity += (*k)*k_pixels[u].opacity;
> if ( image->colorspace == CMYKColorspace)
>   result.index += (*k)*GetPixelIndex(k_indexes+u);
>   }
>   k_pixels += virt_width;
>   k_indexes += virt_width;
> }
> ---
> 
> I extracted it to a small test in https://godbolt.org/z/G5h6nWvb5
> which can be vectorized by clang but not gcc due to such pattern.

I see - thanks.  Maybe the opportunity can be realized by
invariant motion, for

  for (i = 0; i < n; ++i)
if (ptr + i != 0)
  ...

hoist any NULL check on a POINTER_PLUS_EXPR with invariant pointer
part as a NULL check on the invariant pointer.  Possibly doing by
replacing all if (ptr + offset != 0) by if (ptr != 0) and then
relying on unswitching of invariant conditions.

That said, I'm sure this is viewed as too aggressive ... ?

[Bug debug/101905] [9/10/11/12 Regression] Missed debug information for global register variable

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #9 from rguenther at suse dot de  ---
On Fri, 20 Aug 2021, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101905
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |ASSIGNED
>Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot 
> gnu.org
> 
> --- Comment #8 from Jakub Jelinek  ---
> Created attachment 51327
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51327&action=edit
> gcc12-pr101905.patch
> 
> So like this (untested except for the testcase)?

Yes, exactly.

[Bug middle-end/101996] New: libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1

[bqq3z3afgj at bcco4 dot anonbox.net via Gcc-bugs]

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

Bug ID: 101996
   Summary: libatomic: RISC-V 64: Infinite recursion in
__atomic_compare_exchange_1
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bqq3z3afgj at bcco4 dot anonbox.net
  Target Milestone: ---

On Alpine Linux Edge, we noticed a stack overflow in
__atomic_compare_exchange_1 in libatomic.so. The generated RV64
assembler for the __atomic_compare_exchange_1 symbol looks as follows:

1e40 <__atomic_compare_exchange_1@plt>:
1e40:   3e17auipc   t3,0x3
1e44:   2a0e3e03ld  t3,672(t3) # 50e0
<__atomic_compare_exchange_1+0x2312>
1e48:   000e0367jalrt1,t3
1e4c:   0013nop

2dce <__atomic_compare_exchange_1>:
2dce:   1141addisp,sp,-16
2dd0:   4701li  a4,0
2dd2:   4695li  a3,5
2dd4:   e406sd  ra,8(sp)
2dd6:   86aff0efjal ra,1e40
<__atomic_compare_exchange_1@plt>
2dda:   60a2ld  ra,8(sp)
2ddc:   0141addisp,sp,16
2dde:   8082ret

It seems to me that __atomic_compare_exchange_1 calls itself recursively
via __atomic_compare_exchange_1@plt each time adding a new stackframe in
2dce, 2ddc (which pops the stack frame) is never reached due to the
recursive invocation in 2dd6. Thus ultimatly causing a stack overflow.

One theory on the #gcc IRC was that riscv claims to have atomic_*
builtins but ends up not generating them thus causing the infinite
recursion.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
   
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-alpine-linux-musl/10.3.1/lto-wrapper
Target: riscv64-alpine-linux-musl
Configured with:
/home/buildozer/aports-dev/main/gcc/src/gcc-10.3.1_git20210625/configure
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--build=riscv64-alpine-linux-musl --host=riscv64-alpine-linux-musl
--target=riscv64-alpine-linux-musl --with-pkgversion='Alpine
10.3.1_git20210625' --enable-checking=release --disable-fixed-point
--disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror
--disable-symvers --enable-__cxa_atexit --enable-default-pie
--enable-default-ssp --enable-cloog-backend
--enable-languages=c,c++,objc,go,fortran --with-arch=rv64gc --with-abi=lp64d
--enable-autolink-libatomic --disable-libquadmath --disable-libssp
--disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared
--enable-threads --enable-tls --disable-libitm --with-system-zlib
--with-linker-hash-style=gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.1 20210625 (Alpine 10.3.1_git20210625)

Downstream bug report:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/12817

[Bug target/101981] GCC10 produces bigger asm for simple switch than GCC7 - cortexM4

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-08-20
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Martin Liška  ---
I'll take a look.

[Bug fortran/101997] New: [9 regression] ICE after r9-8665 at gcc/toplev.c:326

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

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

Bug ID: 101997
   Summary: [9 regression] ICE after r9-8665 at gcc/toplev.c:326
   Product: gcc
   Version: 9.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:abfe42c1fb66a534290bd0a808c2d90842ee848b, r9-8665
make  -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/pr95091.f90"
FAIL: gfortran.dg/pr95091.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pr95091.f90   -O  (test for excess errors)
# of unexpected failures2


spawn -ignore SIGHUP
/home3/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../gfortran
-B/home3/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../
-B/home3/seurer/gcc/git/build/gcc-9-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-9-test/gcc/testsuite/gfortran.dg/pr95091.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -fsecond-underscore -S -o pr95091.s
*** buffer overflow detected ***:
/home3/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../f951
terminated
f951: internal compiler error: Aborted
0x109133b3 crash_signal
/home/seurer/gcc/git/gcc-9-test/gcc/toplev.c:326
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gfortran.dg/pr95091.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pr95091.f90   -O  (test for excess errors)
Excess errors:
*** buffer overflow detected ***:
/home3/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../f951
terminated
f951: internal compiler error: Aborted
0x109133b3 crash_signal
/home/seurer/gcc/git/gcc-9-test/gcc/toplev.c:326


commit abfe42c1fb66a534290bd0a808c2d90842ee848b (HEAD, refs/bisect/bad)
Author: Harald Anlauf 
Date:   Sun Jun 7 14:47:24 2020 +0200

PR fortran/95091 - Buffer overflows with submodules and long symbols

[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
Worksforme:

29ae <__atomic_compare_exchange_1@@LIBATOMIC_1.0>:
29ae:   0ffffence
29b2:   0005c683lbu a3,0(a1)
29b6:   ff857893andia7,a0,-8
29ba:   891dandia0,a0,7
29bc:   050esllia0,a0,0x3
29be:   0ff00713li  a4,255
29c2:   0008b783ld  a5,0(a7)
29c6:   00a71733sll a4,a4,a0
29ca:   00a696b3sll a3,a3,a0
29ce:   00a61633sll a2,a2,a0
29d2:   fff74e13not t3,a4
29d6:   00fe7833and a6,t3,a5
29da:   00f77333and t1,a4,a5
29de:   00c86833or  a6,a6,a2
29e2:   02d31363bne t1,a3,2a08
<__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x5a>
29e6:   1008b32flr.dt1,(a7)
29ea:   00f31663bne t1,a5,29f6
<__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x48>
29ee:   1908beafsc.dt4,a6,(a7)
29f2:   fe0e9ae3bnezt4,29e6
<__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x38>
29f6:   40f30833sub a6,t1,a5
29fa:   879amv  a5,t1
29fc:   fc081de3bneza6,29d6
<__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x28>
2a00:   0ffffence
2a04:   4505li  a0,1
2a06:   8082ret
2a08:   00a7d7b3srl a5,a5,a0
2a0c:   00f58023sb  a5,0(a1)
2a10:   0ffffence
2a14:   4501li  a0,0
2a16:   8082ret

[Bug c++/101764] ICE for constexpr if within fold expression within lambda expression within a template

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/101988] [12 Regression] Accepts invalid new-expression of array of deduced class template

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug libstdc++/90787] filesystem tests fail if file permissions are not supported

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

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

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

https://gcc.gnu.org/g:29b2fd371f18169141e20b90effa7205db68fb11

commit r12-3045-g29b2fd371f18169141e20b90effa7205db68fb11
Author: Jonathan Wakely 
Date:   Fri Aug 20 14:51:06 2021 +0100

libstdc++: Skip filesystem tests that depend on permissions [PR90787]

Tests that depend on filesystem permissions FAIL if run on Windows or as
root. Add a helper function to detect those cases, so the tests can skip
those checks gracefully.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/90787
* testsuite/27_io/filesystem/iterators/directory_iterator.cc:
Use new __gnu_test::permissions_are_testable() function.
*
testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc:
Likewise.
* testsuite/27_io/filesystem/operations/exists.cc: Likewise.
* testsuite/27_io/filesystem/operations/is_empty.cc: Likewise.
* testsuite/27_io/filesystem/operations/remove.cc: Likewise.
* testsuite/27_io/filesystem/operations/remove_all.cc: Likewise.
* testsuite/27_io/filesystem/operations/status.cc: Likewise.
* testsuite/27_io/filesystem/operations/symlink_status.cc:
Likewise.
* testsuite/27_io/filesystem/operations/temp_directory_path.cc:
Likewise.
*
testsuite/experimental/filesystem/iterators/directory_iterator.cc:
Likewise.
*
testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc:
Likewise.
* testsuite/experimental/filesystem/operations/exists.cc:
Likewise.
* testsuite/experimental/filesystem/operations/is_empty.cc:
Likewise.
* testsuite/experimental/filesystem/operations/remove.cc:
Likewise.
* testsuite/experimental/filesystem/operations/remove_all.cc:
Likewise.
*
testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Likewise.
* testsuite/util/testsuite_fs.h
(__gnu_test::permissions_are_testable):
New function to guess whether testing permissions will work.

[Bug libstdc++/90787] filesystem tests fail if file permissions are not supported

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk but I'll backport it too.

[Bug target/101981] GCC10 produces bigger asm for simple switch than GCC7 - cortexM4 since r8-2701-g9dc3d6a96167b4c8

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

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

Martin Liška  changed:

   What|Removed |Added

 Target|arm |arm, x86_64
 Status|ASSIGNED|NEW
Summary|GCC10 produces bigger asm   |GCC10 produces bigger asm
   |for simple switch than GCC7 |for simple switch than GCC7
   |- cortexM4  |- cortexM4 since
   ||r8-2701-g9dc3d6a96167b4c8

--- Comment #4 from Martin Liška  ---
I can confirm the minor regression that started with r8-2701-g9dc3d6a96167b4c8
(aka switch lowering made on the TREE level).

One can also see it on x86_64-linux:

gcc-7
switchFunction:
.LFB0:
.cfi_startproc
movl%edi, %eax
cmpl$2, %edi
movl$-1, %edx
cmovnb  %edx, %eax
ret
.cfi_endproc

gcc-12
switchFunction:
.LFB0:
.cfi_startproc
movl%edi, %eax
testl   %edi, %edi
je  .L2
cmpl$1, %edi
movl$-1, %edx
cmovne  %edx, %eax

Note the test-case is quite special as the shorter version does:

int switchFunction(int foo) {
  switch (foo) {
  case 0:
return foo;
  case 1:
return foo;
  default:
return -1;
  }
}

that's trick that's used.

[Bug c++/101998] New: false positive: taking address of rvalue

[peciva at fit dot vut.cz via Gcc-bugs]

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

Bug ID: 101998
   Summary: false positive: taking address of rvalue
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peciva at fit dot vut.cz
  Target Milestone: ---

Following code refuses to compile (on g++ 7.5 and 11.2):

struct Nested {
int payload;
};

struct Main {
const Nested* nested;
int payload;
Main(const Nested* n) : nested(n) {}
};

void f(const Main& s)
{
}

int main() {
f(Main(&(const Nested&)Nested()));  // <- workaround
f(Main(&Nested()));  // <- fails here
return 0; 
}


Error message: "error: taking address of rvalue"

I am not c++ expert, but the code seems perfectly meaningful to me. Structure
Main and Nested are both constructed before the call to f and both of them are
destructed after the execution of f. No dangling pointer to destructed
temporary. Both structures (Main, Nested) are temporaries and I do not see a
real reason why the compilation should fail. Maybe, if Main and Nested
instances are both temporaries, the error should not be emitted and compilation
shall proceed (?). But I am not expert.

Such constructions of temporary nested structures and passing pointers to main
structure constructor are often used when programming with c++ Vulkan API, for
instance.

[Bug c/101999] New: strdup on `gcc -std=c99` gives segfault

[piertoni at protonmail dot com via Gcc-bugs]

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

Bug ID: 101999
   Summary: strdup on `gcc -std=c99` gives segfault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piertoni at protonmail dot com
  Target Milestone: ---

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

strdup is not a part of -std=c99 but the following reproducer program compiles
and gives segfault.

```
#include 
#include 

int main() {
const char *words[] = {"hi", "I", "Am", "testing"};
for (int i=0; i < 4; i++)
{
char * copy = strdup(words[i]);
printf("%s", copy);
}
}
```

Compiled on x86_64 GNU/Linux with: 
`gcc -std=c99 bug.c && ./a.out`

gives warnings:
`
bug.c: In function ‘main’:
bug.c:9:23: warning: implicit declaration of function ‘strdup’; did you mean
‘strcmp’? [-Wimplicit-function-declaration]
 char * copy = strdup(words[i]);
   ^~
   strcmp
bug.c:9:23: warning: initialization of ‘char *’ from ‘int’ makes pointer from
integer without a cast [-Wint-conversion]
`
and Segfault as a result.

The same compiles correctly if -std=c99 is not used or if strdup is specified
as

`extern char *strdup(const char *s)`

Also clang with same options compiles correctly (giving appropriate warnings).


Result of `gcc -v`:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

[Bug c++/101998] false positive: taking address of rvalue

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The C++ standard forbids it, that's why GCC gives an error.

"The operand of the unary & operator shall be an lvalue of some type T."

[Bug c++/102000] New: Defaulted consteval default constructor that performs no initialization is not rejected

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 102000
   Summary: Defaulted consteval default constructor that performs
no initialization is not rejected
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/Te3nY7YeW and discussion at
https://cpplang.slack.com/archives/C21PKDHSL/p1629467874085000.
```C++
struct X{
  int i;
  consteval X() = default;
};
constexpr void f() {
  [[maybe_unused]] X x_f;
}
int main () {
  [[maybe_unused]] X x_main;
  []() consteval { f(); }();
}
```

```
An immediate invocation shall be a constant expression. --
https://eel.is/c++draft/expr.const#13.sentence-3

Lots of wording in between...

2 A variable or temporary object o is constant-initialized if
(2.1) either it has an initializer or its default-initialization results in
some initialization being performed, and
-- https://eel.is/c++draft/expr.const#2
7 To default-initialize an object of type T means:
(7.3) Otherwise, no initialization is performed.
-- https://eel.is/c++draft/dcl.init.general#7
```

```
[W]hether it's defaulted or not, `i` is uninitialized so it should reject both.
```

[Bug c++/102000] Defaulted consteval default constructor that performs no initialization is not rejected

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-08-20

[Bug c++/97566] [[no_unique_address]] causes miscompiles when mixed with EBO in constexpr context

[soap at gentoo dot org via Gcc-bugs]

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

David Seifert  changed:

   What|Removed |Added

 CC||soap at gentoo dot org

--- Comment #7 from David Seifert  ---
(In reply to Jason Merrill from comment #3)
> Fixed for GCC 11.

Thanks for the fix Jason! Could we possibly get a backport to 10, seeing that
it's needed for building chromium? It appears very related to PR98463, which
was backported to GCC 10.

[Bug target/101922] mips: illegal instruction at -O3 with -mmsa -mloongson-mmi

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #2 from Xi Ruoyao  ---
A "legal" testcase w/o UB (and may have some usage in practice):

typedef __INT8_TYPE__ i8;
typedef __INT32_TYPE__ i32;

i8 d[16];

i32 f(i32 x) {
  int i;
  for (i = 0; i < 16; i++) {
__INT32_TYPE__ t = (__INT32_TYPE__) d[i] >> 31;
x &= t;
  }
  return x;
}

[Bug libstdc++/102001] New: Consider using CLOCK_MONOTONIC_RAW for chrono::steady_clock

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

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

Bug ID: 102001
   Summary: Consider using CLOCK_MONOTONIC_RAW for
chrono::steady_clock
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

CLOCK_MONOTONIC can be adjusted by NTP, CLOCK_MONTONIC_RAW can't (but is
linux-specific).

[Bug c++/102000] Defaulted consteval default constructor that performs no initialization is not rejected

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
Can https://bugs.llvm.org/show_bug.cgi?id=51560 be fixed as part of this?

[Bug target/101981] GCC10 produces bigger asm for simple switch than GCC7 - cortexM4 since r8-2701-g9dc3d6a96167b4c8

[dumoulin.thibaut at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Thibaut M.  ---
Thanks Martin!
Do you think it can be patched?

[Bug target/101876] [s390x] vector builtin vec_permi fails to resolve with #pragma GCC target

[mhillen at linux dot ibm.com via Gcc-bugs]

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

--- Comment #3 from Marius Hillenbrand  ---
The issue is caused by inconsistent alignment of vector_types between the types
(a) expected or returned by builtin functions and (b) the typedef in the
example code. In the failing cases, there's a mismatch of 16-Byte and 8-Byte
(compliant with the ABI) alignment. In the successful cases, either both use
16-Byte or 8-Byte alignment.

When gcc starts, s390_init_builtins defines builtin functions with their
corresponding type information. That includes vector builtins. While creating
the builtin types for these builtins, when gcc starts with -march < z13, then
s390_vector_alignment defers to default_vector_alignment, which results in
natural alignment. That results in 16-Byte alignment of the 16-Byte vectors.
Once the pragma switched to an arch level with VX support (TARGET_VX and
TARGET_VX_ABI are true), then s390_vector_alignment selects 8-Byte alignment in
accordance with the vector ABI.

The C++ example (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101877) ICEs
because two structurally identical vector types have different canonical types
(as a result of the different alignment?!).

[Bug target/101877] [s390x] ICE: canonical types differ for identical types when #pragma GCC target enables vector support

[mhillen at linux dot ibm.com via Gcc-bugs]

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

Marius Hillenbrand  changed:

   What|Removed |Added

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

--- Comment #2 from Marius Hillenbrand  ---
Debugging confirmed that this is a duplicate of 101876. Closing this bug in
favor of the former.

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

[Bug target/101876] [s390x] vector builtin vec_permi fails to resolve with #pragma GCC target

[mhillen at linux dot ibm.com via Gcc-bugs]

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

--- Comment #4 from Marius Hillenbrand  ---
*** Bug 101877 has been marked as a duplicate of this bug. ***

[Bug c++/102002] New: spec requires typename can be dropped when used as template function return type consisting of template parameter which is at global scope

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

Bug ID: 102002
   Summary: spec requires typename can be dropped when used as
template function return type consisting of template
parameter  which is at global scope
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

Spec considers *typename* can be dropped when there is no ambiguous of
regarding identifier as type. And
example(https://timsong-cpp.github.io/cppwp/temp.res#general-example-5) shows
this OK.

   template T::R f();//OK, return type of a function declaration at
global scope

However, all compilers including GCC, clang, MSVC++ complains missing typename
because 

error: need ‘typename’ before ‘T::R’ because ‘T’ is a dependent scope
1 | template T::R f();
  |   ^
  |   typename 



Here I quote spec(https://timsong-cpp.github.io/cppwp/temp.res#general-4.1):
   A qualified or unqualified name is said to be in a type-only context if it
is the terminal name of
a typename-specifier, nested-name-specifier, elaborated-type-specifier,
class-or-decltype
...

I understand this relaxation of enforcing *typename* is not so critical. Still
it is nice to strictly follow spec.

[Bug c/101999] strdup on `gcc -std=c99` gives segfault

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
The implicit declaration doesn't match the signature of called function, which
results in undefined behaviour.

[Bug tree-optimization/86723] not optimizing with bswap, that casts to int aftwards

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/102002] spec requires typename can be dropped when used as template function return type consisting of template parameter which is at global scope

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
You need to use -std=c++20.

[Bug target/101971] M68k: ICE: Tried to convert PC relative branch to absolute jump

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

Giulio Benetti  changed:

   What|Removed |Added

 CC||thomas.petazzoni@free-elect
   ||rons.com

--- Comment #6 from Giulio Benetti  ---
Hello Andreas,

I've checked in Linux and it seems still supported as COLDFIRE and then:
- M5206
- M5206e
- M520x
- etc.

Do you mean m68k-linux target in gcc? And if yes, can you please point me which
PR or commit SHA1 drops Coldfire support and makes it compatible only with
68020+?

This way I can disable its support in Buildroot but I need to document.

Thanks in advance

[Bug target/101916] SH4 ICE: Segmentation fault signal terminated program cc1

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #2 from Giulio Benetti  ---
Created attachment 51332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51332&action=edit
Pre-processed mime.c(mime.i)

Here is preprocessed mime.c file(mime.i) to help you fix the bug.
Hope this is enough, otherwise ask me and I'll provide what you need.

Thank you

[Bug target/101922] mips: illegal instruction at -O3 with -mmsa -mloongson-mmi

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Xi Ruoyao  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577849.html

[Bug target/101915] Microblaze ICE: in extract_insn, at recog.c:2770

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #4 from Giulio Benetti  ---
Created attachment 51333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51333&action=edit
Pre-processed par_ops.c(par_ops.i)

As suggested by Thomas here is pre-processed par_ops.c(par_ops.i) to help you
fix the bug.
Hope this is enough, otherwise ask me and I'll provide what you need.

Thank you

[Bug target/101952] SH4 ICE: Error: unaligned opcodes detected in executable segment

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #2 from Giulio Benetti  ---
Created attachment 51334
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51334&action=edit
Pre-processed btDantzigLCP.cpp(btDantzigLCP.ii)

As suggested by Thomas here is pre-processed btDantzigLCP.cpp(btDantzigLCP.ii)
to help you fix the bug.
btDantzigLCP.S follows.
Hope this is enough, otherwise ask me and I'll provide what you need.

Thank you

[Bug target/101952] SH4 ICE: Error: unaligned opcodes detected in executable segment

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #3 from Giulio Benetti  ---
Created attachment 51335
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51335&action=edit
Pre-processed btDantzigLCP.cpp(btDantzigLCP.s)

Here is the assembler file too.

[Bug target/101915] Microblaze ICE: in extract_insn, at recog.c:2770

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #5 from Giulio Benetti  ---
Created attachment 51336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51336&action=edit
Pre-processed par_ops.c(par_ops.s)

Here is the assembler file too.

[Bug target/101916] SH4 ICE: Segmentation fault signal terminated program cc1

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #3 from Giulio Benetti  ---
Created attachment 51337
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51337&action=edit
Pre-processed mime.c(mime.s)

Here is the assembler file too.

[Bug tree-optimization/83022] malloc & memset -> calloc is not always an optimization

[i at maskray dot me via Gcc-bugs]

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

Fangrui Song  changed:

   What|Removed |Added

 CC||i at maskray dot me

--- Comment #5 from Fangrui Song  ---
void *my_malloc(size_t size, int my_flags)
{
  void* point = malloc(size);
  if (my_flags & 32) memset(point, 0, size);
  return point;
}
=>
my_malloc(unsigned long, int):
mov esi, 1
jmp calloc

---

If GCC supports -fsanitize=memory, note that this transformation should be
disabled as well to not lose error checking.

[Bug tree-optimization/83022] malloc & memset -> calloc is not always an optimization

[i at maskray dot me via Gcc-bugs]

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

--- Comment #6 from Fangrui Song  ---
The issue succeeded to waste some time of MySQL developers BTW: 
http://smalldatum.blogspot.com/2017/11/a-new-optimization-in-gcc-5x-and-mysql.html

[Bug go/101994] go1: internal compiler error: in return_statement, at go/go-gcc.cc:2318

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-08-20
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Ian Lance Taylor  ---
Fix is https://golang.org/cl/343873.  Test case is
https://golang.org/cl/343874.

[Bug target/101882] modulus with input and output set to a hard register

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Assignee present -> ASSIGNED.

[Bug fortran/102003] New: [PDT] Length of character component not simplified

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

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

Bug ID: 102003
   Summary: [PDT] Length of character component not simplified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

We should be able to simplify at compile time the following code:

  type pdt(n)
 integer, len :: n = 8
 character(len=n) :: c
  end type pdt
  type(pdt(42)) :: p
  integer, parameter :: m = len (p% c)  ! rejected
  print *, len (p% c) == 42 ! works, but not simplified
end

Instead we currently get:

foo.f90:6:27:

6 |   integer, parameter :: m = len (p% c)  ! rejected
  |   1
Error: Cannot convert UNKNOWN to INTEGER(4) at (1)

(The code is accepted by Intel.)

[Bug c/101964] using scanf makes compiler never terminate

[mateusmoraisdias3 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mateus Morais Dias de Souza  ---
I figured it out. My build script was something like this:
```bash
set -e
gcc main.c -o main
./main
```
for some reason gcc was not warning about my unseen error, then it ran the
program (because I forgot that it was encoded to run after building) and I
didn't notice. Running directly the gcc line into the terminal didn't show me
the warning too. But anyway, problem solved.
Sorry for openning a false-positive issue. Closing it now.

[Bug fortran/101997] [9 regression] ICE after r9-8665 at gcc/toplev.c:326

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Can you get more details on where the buffer overflow actually occurs?
I cannot reproduce it on x86_64-pc-linux-gnu even running f951 under valgrind.

The original testcase in pr95091 would have ICEd anyway, and
the blamed commit was supposed to fix that.

If we cannot fix the present regression - assuming it is restricted
to 9-only - we could just remove the testcase.

[Bug target/101882] modulus with input and output set to a hard register

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

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

--- Comment #3 from Segher Boessenkool  ---
(In reply to Marek Polacek from comment #2)
> Assignee present -> ASSIGNED.

Hrm, this used to work automatically when you press "take"?  What changed?

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

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Sergey Belyshev :

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

commit r12-3047-g7cad8a8f9f7bfa8e98f6a0615541f589fd1d3fc1
Author: Serge Belyshev 
Date:   Fri Jul 16 10:52:33 2021 +0300

configure: drop version checks for in-tree gas [PR91602]

Special-casing checks for in-tree gas features is unnecessary since
r17 which made configure-gcc depend on all-gas, and thus making
alternate code path in gcc_GAS_CHECK_FEATURE for in-tree gas
redundant.

Along the way this fixes PR 91602, which is caused by incorrect guess
of leb128 support presence in RISC-V.

First patch removes alternate code path in gcc_GAS_CHECK_FEATURE and
related code, the rest are further cleanups.  Patches 2 and 3 in
series make no functional changes, thus configure is unchanged.

gcc/ChangeLog:

PR target/91602
* acinclude.m4 (_gcc_COMPUTE_GAS_VERSION,
_gcc_GAS_VERSION_GTE_IFELSE)
(gcc_GAS_VERSION_GTE_IFELSE): Remove.
(gcc_GAS_CHECK_FEATURE): Do not handle in-tree case specially.
* configure.ac: Remove gcc_cv_gas_major_version,
gcc_cv_gas_minor_version.
Remove remaining checks for in-tree assembler.
* configure: Regenerate.

[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

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

--- Comment #17 from Serge Belyshev  ---
Fixed.

[Bug debug/99090] gsplit-dwarf broken on riscv64-linux

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

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

Bug 91602 Summary: GCC fails to build for riscv in a combined tree due to 
misconfigured leb128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602

   What|Removed |Added

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

[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||8.2.0
  Known to fail||9.1.0
   Target Milestone|--- |9.5
Summary|regression built-in memset  |[9/10/11/12 Regression]
   |missed-optimization arm -Os |regression built-in memset
   ||missed-optimization arm -Os

[Bug libstdc++/80196] fenv_t not declared

[bneumeier at gmail dot com via Gcc-bugs]

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

Brett Neumeier  changed:

   What|Removed |Added

 CC||bneumeier at gmail dot com

--- Comment #13 from Brett Neumeier  ---
I ran into this issue with:

--build=aarch64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu


I applied this patch from Yujie Yang, on comment 20 of PR 100017, and it fixed
the issue for me.

diff --git a/configure b/configure
index 6157a8c87fb..2a4a05b4edf 100755
--- a/configure
+++ b/configure
@@ -16653,7 +16653,7 @@ else
 fi


-RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET"
+RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET -nostdinc++"

 { $as_echo "$as_me:${as_lineno-$LINENO}: checking where to find the target ar"
>&5
 $as_echo_n "checking where to find the target ar... " >&6; }
diff --git a/configure.ac b/configure.ac
index 2ff48941754..01ecc8c42d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3515,7 +3515,7 @@ ACX_CHECK_INSTALLED_TARGET_TOOL(STRIP_FOR_TARGET, strip)
 ACX_CHECK_INSTALLED_TARGET_TOOL(WINDRES_FOR_TARGET, windres)
 ACX_CHECK_INSTALLED_TARGET_TOOL(WINDMC_FOR_TARGET, windmc)

-RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET"
+RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET -nostdinc++"

 GCC_TARGET_TOOL(ar, AR_FOR_TARGET, AR, [binutils/ar])
 GCC_TARGET_TOOL(as, AS_FOR_TARGET, AS, [gas/as-new])

[Bug target/99410] Nios II Error: branch offset out of range

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #4 from Giulio Benetti  ---
It's not git package but belle-sip package that fails to build.
I'm going to add .i and .s file soon.

[Bug target/99410] Nios II Error: branch offset out of range

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #5 from Giulio Benetti  ---
Disabling parallel build it turns out that the file where it hangs is:
src/grammars/belle_sip_messageParser.c

So I'm going to add .i and .s attachments for it.

[Bug target/99410] Nios II Error: branch offset out of range

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #6 from Giulio Benetti  ---
Created attachment 51338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51338&action=edit
Pre-processed belle_sip_messageParser.c(belle_sip_messageParser.i)

[Bug libstdc++/80196] fenv_t not declared

[gr.audio at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Guillaume  ---
OK, this patch fixes it for me as well.

[Bug target/99410] Nios II Error: branch offset out of range

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #7 from Giulio Benetti  ---
Created attachment 51339
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51339&action=edit
Pre-processed belle_sip_messageParser.c(belle_sip_messageParser.s)

[Bug c++/102002] spec requires typename can be dropped when used as template function return type consisting of template parameter which is at global scope

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from qingzhe huang  ---
Thank you and my apology.

[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-08-21
 Target|arm |arm, aarch64
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
On x86_64 for some reason it works in GCC 9+; tested with " -Os
-mstringop-strategy=libcall" and adding noinline to doStuff just to force to
make sure it does not inline.

Anyways confirmed, worked in GCC 8.2.0 for both aarch64 and arm but does not
work in GCC 9.

[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os

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

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

--- Comment #3 from Andrew Pinski  ---
REG_RETURNED is no longer there.

Looks like there is an extra move which caused the code to be different.

For aarch64 we have:
(insn 18 4 2 2 (set (reg:DI 94)
(reg:DI 0 x0 [ foo ])) "/app/example.cpp":17:42 47 {*movdi_aarch64}
 (nil))
(insn 2 18 3 2 (set (reg/v/f:DI 90 [ foo ])
(reg:DI 94)) "/app/example.cpp":17:42 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 94)
(nil)))
Before the call to memset.

[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os

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

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

--- Comment #4 from Andrew Pinski  ---
Note I suspect it is r9-3594 is what makes the difference here. Also this is
just very fragile really.

[Bug analyzer/101980] [12 regressions] many test case failures after r12-3002

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Ankur saini :

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

commit r12-3052-ge92d0ff6b5e6d4b95c04fc3e326d40efeb136086
Author: Ankur Saini 
Date:   Thu Aug 19 19:54:56 2021 +0530

analyzer: Fix PR analyzer/101980

2021-08-19  Ankur Saini  

gcc/analyzer/ChangeLog:
PR analyzer/101980
* diagnostic-manager.cc
(diagnostic_manager::prune_for_sm_diagnostic):
Use
caller_model only when the supergraph_edge doesn't exixt.
(diagnostic_manager::prune_for_sm_diagnostic):
Likewise.
* engine.cc (exploded_graph::create_dynamic_call): Rename to...
(exploded_graph::maybe_create_dynamic_call): ...this, return call
creation status.
(exploded_graph::process_node): Handle calls which were not
dynamically
discovered.
* exploded-graph.h (exploded_graph::create_dynamic_call): Rename
to...
(exploded_graph::maybe_create_dynamic_call): ...this.
* region-model.cc (region_model::update_for_gcall): New param, use
it
to push call to frame.
(region_model::update_for_call_superedge): Pass callee function to
update_for_gcall.
* region-model.h (region_model::update_for_gcall): New param.

gcc/testsuite/ChangeLog:
PR analyzer/101980
* gcc.dg/analyzer/function-ptr-2.c : Add issue for double 'free'.
* gcc.dg/analyzer/malloc-callbacks.c : Fix xfail testcase.

[Bug c++/101998] false positive: taking address of rvalue

[peciva at fit dot vut.cz via Gcc-bugs]

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

--- Comment #2 from Jan Pečiva  ---
I see. Thanks!