[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
(In reply to Martin Liška from comment #1)
> Please provide a pre-processed soure file (-E option).

The output of gcc -E for this build is empty, so sure looks like the crash
is in the preprocessor.

[Bug demangler/88629] Regression lead to Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt

[prajwapa at in dot ibm.com via Gcc-bugs]

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

prajwapa at in dot ibm.com changed:

   What|Removed |Added

 CC||prajwapa at in dot ibm.com

--- Comment #12 from prajwapa at in dot ibm.com ---
Could someone please let me know, in which binutils version is this fixed?(In
reply to Cheng Wen from comment #10)
> (In reply to Trupti Pardeshi from comment #9)
> 
> This bug can be reproduced in the commit version
> ebb8004a18a3808d7197762faf3c5aaeae82371f.
> 
> But now is fixed.

Could you please let me know, in which binutils version is this fixed?

Thanks.

[Bug demangler/88783] integer overflow in libiberty, heap overflow will be triggered in nm

[prajwapa at in dot ibm.com via Gcc-bugs]

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

prajwapa at in dot ibm.com changed:

   What|Removed |Added

 CC||prajwapa at in dot ibm.com

--- Comment #7 from prajwapa at in dot ibm.com ---
Kindly let me know, if this bug is going to be fixed in binutils and in which
version?

[Bug tree-optimization/98138] BB vect fail to SLP one case

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

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

--- Comment #8 from Kewen Lin  ---
Created attachment 49942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49942=edit
vectorized with altivec built-in functions

[Bug tree-optimization/98138] BB vect fail to SLP one case

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

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

--- Comment #7 from Kewen Lin  ---
(In reply to Richard Biener from comment #6)
> Starting from the loads is not how SLP discovery works so there will be
> zero re-use of code.  Sure - the only important thing is you end up
> with a valid SLP graph.
> 
> But going back to the original testcase and the proposed vectorization
> for power - is that faster in the end?
> 

Good question. I coded foo2 and foo3 with altivec built-in functions as the
proposals, foo2 is for the original version (#c0) and foo3 is for the
sub-optimial version (#c4), they have been verified with some random inputs to
ensure the functionality. 

I evaluated the timings on Power8/Power9/Power10(pre) with option -Ofast and
corresponding -mcpu=power{8,9,10} for the build. Using foo1 (scalar version) as
the baseline 100, do the normalization, the speed-ups look below (more bigger,
more better):

foo1   foo2 foo3
P8  100   163.26   164.97
P9  100   101.15   101.60
P10 100   172.42   159.10

The evaluation shows the vectorized versions can have big gains on Power8 and
Power10, but the gain is trivial on Power9.  I tried to evaluate P8 executable
on P9, it didn't have any remarkable differences. There are some known issues
on P9 for fp/vect intensive workloads, it's probably due to that since the
vectorized versions are full of vector codes. Sigh, we might have to make
different costs for P9 but that's another story. Btw, I tried to run P9
executable on P10, it can also gains that much like what we have in P10 row. So
it's profitable to vectorize this as P8 and P10 testing show.

> For the "rewrite" of the vectorizer into all-SLP we do have to address
> that "interleaving scheme not carried out as interleaving" at some point,
> but that's usually for loop vectorization - for BB vectorization all
> we have is optimize_slp.  I have patches that would build the vector load
> SLP node (you still have to kill that 'build from scalars' thing to make
> it trigger ).  But then we end up with a shared vector load node and
> N extract/splat operations at the 'scalar' points.  It's not entirely
> clear to me how to re-arrange the SLP graph at that point.
> 

Great, it's good to know we can end up with a shared vector load node. It looks
we can further simplify the graph on top of it, for #c4 simplified case,
assuming we have two shared vector load nodes
  N1 = 
  N2 = 

1) If all lanes of one shared vector load node only works with all lanes of
another shared vector load nodes, we can move up (postpone) the extract/splat
operations.  For this case, we needs 4 extract/splat for p1's lanes, 4
extract/splat for p2's lanes, 4 minus for {T,T,T,T} /T=a{0,1,2,3}/, it can be
simplified to one shared node N3 = N1 - N2 (1 minus) and 4 extract/splat.

2) And then we have the shared vector node , before it's going
to extract/splat to {T,T,T,T} /T=a{0,1,2,3}/, it can check all the uses of
extract/splat lanes, try to detect some pattern and further simplify. For this
case, it can be permuted to , do the minus/plus and the
permutations to get the nodes N4 <_13, _14, _13, _14> and N5 <_15, _16, _15,
_16> to save the need of extract/splat.

3) Further we can detect the pattern on SLP graph and skip the need to gen 
N4 and N5, but gen <_13, _14, _15, _16> and repeat the minus/plus and
permutations for the required t1/t2/t3/t4 computation.

> Btw, on current trunk the simplified testcase no longer runs into the
> 'scalar operand' build case but of course vectorization is thought to be
> not profitable.  pattern recog of the plus/minus subgraphs may help
> (not sure if ppc has those as instruction, x86 has).

You meant the simplified case in #c4? I re-based the latest trunk (r11-6601)
but still suffered the 'scalar operand' build, unfortunately ppc doesn't
support that kind of instructions, sigh.

> 
> That said, "failure" to identify the common (vector) load is known
> and I do have experimental patches trying to address that but did
> not yet arrive at a conclusive "best" approach.

Thanks for the information!

[Bug c++/98620] SFINAE code in class specialization generates warnings

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/98620] SFINAE code in class specialization generates warnings

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:814299a9d49c25ae2e8d00ec619559b71833871a

commit r11-6606-g814299a9d49c25ae2e8d00ec619559b71833871a
Author: Marek Polacek 
Date:   Mon Jan 11 11:44:36 2021 -0500

c++: -Wmissing-field-initializers in unevaluated ctx [PR98620]

This PR wants us not to warn about missing field initializers when
the code in question takes places in decltype and similar.  Fixed
thus.

gcc/cp/ChangeLog:

PR c++/98620
* typeck2.c (process_init_constructor_record): Don't emit
-Wmissing-field-initializers warnings in unevaluated contexts.

gcc/testsuite/ChangeLog:

PR c++/98620
* g++.dg/warn/Wmissing-field-initializers-2.C: New test.

[Bug target/98612] _mm_comieq_sd has wrong semantics

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:240f0a490dae0fb9ef72fa21a93e8088d17fb682

commit r11-6605-g240f0a490dae0fb9ef72fa21a93e8088d17fb682
Author: liuhongt 
Date:   Mon Jan 11 14:47:49 2021 +0800

Delete dead code in ix86_expand_sse_comi.

d->flag is always 0 for builtins located in
BDESC_FIRST (comi,COMI,...)
...
BDESC_END (COMI, PCMPESTR)

gcc/ChangeLog:
PR target/98612
* config/i386/i386-builtins.h (BUILTIN_DESC_SWAP_OPERANDS):
Deleted.
* config/i386/i386-expand.c (ix86_expand_sse_comi): Delete
dead code.

[Bug analyzer/98628] [11 Regression] ICE in get_or_create_cluster, at analyzer/store.cc:2040 since r11-6513-gbe6c485b24f2b47a

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/98628] [11 Regression] ICE in get_or_create_cluster, at analyzer/store.cc:2040 since r11-6513-gbe6c485b24f2b47a

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r11-6603-gab88f3607233376c3145c320e92e71943a495bb5
Author: David Malcolm 
Date:   Mon Jan 11 20:23:41 2021 -0500

analyzer: fix ICE merging dereferencing unknown ptrs [PR98628]

gcc/analyzer/ChangeLog:
PR analyzer/98628
* store.cc (binding_cluster::make_unknown_relative_to): Don't mark
dereferenced unknown pointers as having escaped.

gcc/testsuite/ChangeLog:
PR analyzer/98628
* gcc.dg/analyzer/pr98628.c: New test.

[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0

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

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

--- Comment #1 from Sergei Trofimovich  ---
I also found a similar crash (from `RTL pass: expand` for some reason) in
print_mem_ref:

```c++
struct QQmlRefCount {
  void release() const;
  virtual ~QQmlRefCount();
};
QQmlRefCount::~QQmlRefCount() {}
void QQmlRefCount::release() const { delete this; }
struct QQmlJavaScriptExpression {
  virtual int sourceLocation();
};
struct QQmlBoundSignalExpression : QQmlJavaScriptExpression, QQmlRefCount {};
struct QQmlProfilerDefinitions {
  enum RangeType { HandlingSignal };
};
struct QQmlProfiler : QQmlProfilerDefinitions {
  struct RefLocation {
RefLocation() {
  switch (locationType)
  case HandlingSignal:
boundSignal->release();
}
RangeType locationType;
QQmlBoundSignalExpression *boundSignal;
  };
  void startCompiling() { RefLocation(); }
};
struct QQmlCompilingProfiler {
  QQmlProfiler QQmlCompilingProfiler_profiler;
  QQmlCompilingProfiler(int *) {
QQmlCompilingProfiler_profiler.startCompiling();
  }
};
int notifyComplete_blob;
void QQmlDataBlobnotifyComplete() {
  QQmlCompilingProfiler prof(_blob);
}
```

```
$ x86_64-pc-linux-gnu-g++ -O2 -std=c++1z -c a.cpp.cpp

during RTL pass: expand
In function 'void QQmlDataBlobnotifyComplete()':
Segmentation fault
5 | QQmlRefCount::~QQmlRefCount() {}
  |^
0x120986f crash_signal
../../gcc/gcc/toplev.c:327
0x7fbb6ee06b6f ???
   
/usr/src/debug/sys-libs/glibc-2.32-r7/glibc-2.32/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x9122bb print_mem_ref
../../gcc/gcc/c-family/c-pretty-print.c:1851
0x912c07 c_pretty_printer::unary_expression(tree_node*)
../../gcc/gcc/c-family/c-pretty-print.c:2005
0x596063 dump_expr
../../gcc/gcc/cp/error.c:2421
...
```

I poked slightly at the crash in gdb:

print_mem_ref():
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c-pretty-print.c#l1812

(gdb) call debug_generic_expr(e)
MEM[(struct QQmlBoundSignalExpression * *) + 8B]

(gdb) call debug_generic_expr(arg)
D.2397

1836   const bool addr = TREE_CODE (arg) == ADDR_EXPR;
1837   if (addr)
1838 {
1839   arg = TREE_OPERAND (arg, 0);
1840   if (byte_off == 0)
1841 {
1842   pp->expression (arg);
1843   return;
1844 }
1845 }

Does not match as an address and falls through (should it?).

1847   tree access_type = TREE_TYPE (e);
1848   if (TREE_CODE (access_type) == ARRAY_TYPE)
1849 access_type = TREE_TYPE (access_type);
1850   tree arg_type = TREE_TYPE (TREE_TYPE (arg));
1851   if (TREE_CODE (arg_type) == ARRAY_TYPE)
1852 arg_type = TREE_TYPE (arg_type);

(gdb) call debug_generic_expr(access_type)
struct QQmlBoundSignalExpression *

(gdb) call TREE_CODE (access_type)
$1 = POINTER_TYPE

(gdb) call debug_generic_expr(TREE_TYPE (arg))
struct RefLocation

(gdb) call TREE_TYPE (TREE_TYPE (arg))
$3 = (tree) 0x0

Null deref at '1851   if (TREE_CODE (arg_type) == ARRAY_TYPE)'.

[Bug c++/98620] SFINAE code in class specialization generates warnings

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Posted to ML.

[Bug gcov-profile/98631] New: exception hit once reported twice

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

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

Bug ID: 98631
   Summary: exception hit once reported twice
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I've got the following complaint: with the attached testcase (m.C):

$ g++ -fprofile-arcs -ftest-coverage -g m.C
$ ./a.out 
caught
$ gcov m.C
File 'm.C'
Lines executed:90.91% of 11
Creating 'm.C.gcov'
$ less m.C.gcov
-:0:Source:m.C
-:0:Graph:m.gcno
-:0:Data:m.gcda
-:0:Runs:1
-:1:struct S {
1:2:  S() {
1:3:foo ();
1:4:bar ();
#:5:  }
1:6:  void foo () { }
1:7:  void bar () { throw 1; }
-:8:};
-:9:
-:   10:int
1:   11:main ()
-:   12:{
-:   13:  try {
1:   14:S s;
2:   15:  } catch(...) {
1:   16:__builtin_printf ("caught\n");
-:   17:  }
1:   18:}

this shows that line 15 was executed twice, which seems dubious.  Then this
doesn't play well with tools like "perf stat" -- it results in two uprobes.

$ less m.C
struct S {
  S() {
foo ();
bar ();
  }
  void foo () { }
  void bar () { throw 1; }
};

int
main ()
{
  try {
S s;
  } catch(...) {
__builtin_printf ("caught\n");
  }
}

[Bug tree-optimization/98629] [11 Regression] ice during GIMPLE pass: widening_mul

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 49941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49941=edit
gcc11-pr98629.patch

Untested fix.

[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare

[erozen at microsoft dot com via Gcc-bugs]

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

Eugene Rozenfeld  changed:

   What|Removed |Added

 CC||erozen at microsoft dot com

--- Comment #1 from Eugene Rozenfeld  ---
Created attachment 49940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49940=edit
[PATCH] Optimize combination of comparisons to dec+compare

The patch has been approved by Richard Biener.

[Bug c/98630] New: Seg-fault when using a goto after condition (if)

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

Bug ID: 98630
   Summary: Seg-fault when using a goto after condition (if)
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: k.even-mendoza at imperial dot ac.uk
  Target Milestone: ---

The following code snippet:

unsigned b=0; 
unsigned d=0;
static unsigned g = 1;
unsigned foo (unsigned ui1, unsigned ui2 ) { return (ui2 == 0) ? (ui1) : (ui1 %
ui2); }
unsigned j() {
  {
unsigned *k = 
unsigned *m = 
unsigned **n = 
unsigned ***o = 
if (g)
  ;
else
p : {
  if (foo(2, *k)) {
***o = 0;
return 2;
  }
}
  }
  goto p;
}
int main() { j(); }

When compiling with GCC-10 (gcc-10 (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0):
> gcc-10 -w -O2 r.c -pedantic -Wall -Wextra 
> ./a.out 
> Segmentation fault (core dumped)

The program in llvm, gcc-9, gcc-8, and gcc-7 exit without any output.  
> clang-11 -w -O0 r.c -pedantic -Wall -Wextra -fsanitize=undefined
> ./a.out
> 
or:
> clang-11 -w -O2 r.c -pedantic -Wall -Wextra
> ./a.out
> 
or:
> gcc-9 -w -O2 r.c -pedantic -Wall -Wextra 
> ./a.out

[Bug tree-optimization/98629] [11 Regression] ice during GIMPLE pass: widening_mul

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
Summary|ice during GIMPLE pass: |[11 Regression] ice during
   |widening_mul|GIMPLE pass: widening_mul
   Last reconfirmed||2021-01-11
   Priority|P3  |P1
   Target Milestone|--- |11.0
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
  Component|c   |tree-optimization

--- Comment #2 from Jakub Jelinek  ---
Indeed, started with my r11-6580-g9febe9e4be7812519258ea3ed4f38bbc1a61624b
change.

[Bug jit/98586] libgccjit crashes with segmentation fault on failed gcc_assert

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

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

--- Comment #3 from David Malcolm  ---
Patch posted as
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563266.html

[Bug c/98629] ice during GIMPLE pass: widening_mul

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
Jakub's best advice sought.

[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library

[kartikmohta at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Kartik Mohta  ---
This is a simple example to demonstrate the problem I've noticed in a bigger
program. Do the inlining limits depend on the size of the TU?

[Bug c/98629] New: ice during GIMPLE pass: widening_mul

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 98629
   Summary: ice during GIMPLE pass: widening_mul
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this reduced C code:

unsigned int a;
int b, c;
void d() {
  unsigned int *e = 
  (a /= a |= b) - (0 <= (*e += *e)) * (c *= *e);
}

does this with recent gcc trunk:

$ /home/dcb/gcc/results.20210111/bin/gcc -c -w -O2 bug689.c
during GIMPLE pass: widening_mul
bug689.c: In function ‘d’:
bug689.c:3:6: internal compiler error: Segmentation fault
3 | void d() {
  |  ^
0xcd63f9 crash_signal(int)
../../trunk.git/gcc/toplev.c:327
0xe7b538 gimple_code(gimple const*)
../../trunk.git/gcc/gimple.h:1782
0xe7b538 is_gimple_assign(gimple const*)
../../trunk.git/gcc/gimple.h:2529
0xe7b538 gimple_assign_cast_p(gimple const*)
../../trunk.git/gcc/gimple.h:2870

The bug first seems to appear sometime between date 20210108
and today i.e. 20210111.

Hashes for those dates are bdcde15045027195 and 9a6c37e6ae520534.
with 32 commits between them.

Jakub's recent changes to widening_mul look a likely candidate.
I don't see much point in doing a git bisect, although I can
if requested.


Jakub's

[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.

[patrick.pelissier at gmail dot com via Gcc-bugs]

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

Patrick Pelissier  changed:

   What|Removed |Added

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

--- Comment #12 from Patrick Pelissier  ---
stdc-predef.h fixes the issue.

[Bug c/98627] GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c/98627] GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[noring at nocrew dot org via Gcc-bugs]

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

Fredrik Noring  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #6 from Fredrik Noring  ---
Then I would suggest it's a bug that GCC doesn't reject -march=68000
in combination with linux. Unsuspecting projects use this, and in fact
it almost works except for random crashes every now and then, which is
a grave quality problem to be sure.

[Bug target/91598] [8/9 regression] 60% speed drop on neon intrinsic loop

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #7 from Wilco  ---
Fixed in GCC9 and trunk. Given the regression is so large, it is worth
backporting.

The other issue is that assembler statements (and likely any RTL instruction
without specified latencies) are badly scheduled. Honoring all known latencies
and assuming a reasonable default latency otherwise would be a better approach.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

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

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

--- Comment #13 from Vladimir Makarov  ---
Thank you for reducing the test.

I've reproduced the problem and started working on it.  I think the fix will be
ready on this week.

[Bug other/89701] Provide -fcf-protection=branch,return

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2021-01-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed.  While we support -fcf-protection=branch and -fcf-protection=return,
-fcf-protection=branch,return gives an error:

xgcc: error: unknown Control-Flow Protection Level ‘branch,return’
xgcc: note: valid arguments to ‘-fcf-protection=’ are: branch check full none
retur

[Bug c/98627] GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #5 from Andreas Schwab  ---
Anything but linux.

[Bug c/98627] GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[noring at nocrew dot org via Gcc-bugs]

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

Fredrik Noring  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Fredrik Noring  ---
Well, GCC accepts -march=68000 as a valid option and so it doesn't seem to make
sense that it then proceeds to generate code for something incompatible like
the 68020. As far as I understand, other targets such as MIPS don't behave like
that: a MIPS III compiler can generate code for MIPS I without problems, for
instance.

What target(s) would you recommend for the compiler to (completely and without
exceptions) honour the given -march=68000 option?

[Bug analyzer/98628] [11 Regression] ICE in get_or_create_cluster, at analyzer/store.cc:2040 since r11-6513-gbe6c485b24f2b47a

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from David Malcolm  ---
Thanks; I can reproduce it and am debugging it now.

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[andrea.corallo at arm dot com via Gcc-bugs]

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

--- Comment #7 from Andrea Corallo  ---
Thanks Martin, I can confirm that also the bootstrap is back okay.

Re: [Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[Andrea Corallo via Gcc-bugs]

Thanks Martin, I can confirm that also the bootstrap is back okay.

[Bug c/98627] GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #3 from Andreas Schwab  ---
m68k-linux requires m68020+, you cannot combine that with -march=68000.

[Bug c/98627] GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[noring at nocrew dot org via Gcc-bugs]

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

--- Comment #2 from Fredrik Noring  ---
To obtain the object file I can run the command

m68k-unknown-linux-gnu-gcc -O1 -march=68000 -c -o address-error.o
address-error.c

with a cross-compiler made using the Gentoo package sys-devel/crossdev having
the target m68k-unknown-linux-gnu.

[Bug analyzer/98628] [11 Regression] ICE in get_or_create_cluster, at analyzer/store.cc:2040 since r11-6513-gbe6c485b24f2b47a

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-11
 CC||marxin at gcc dot gnu.org
Summary|internal compiler error: in |[11 Regression] ICE in
   |get_or_create_cluster, at   |get_or_create_cluster, at
   |analyzer/store.cc:2040  |analyzer/store.cc:2040
   ||since
   ||r11-6513-gbe6c485b24f2b47a
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Reduced test-case:

$ cat misc.i
struct chanset_t help_subst_chan;
struct chanset_t *help_subst_chan_0_0;
struct chanset_t {
  struct chanset_t *next;
  char dname[];
} help_subst() {
  char *writeidx;
  for (;; help_subst_chan = *help_subst_chan_0_0) {
my_strcpy(help_subst_chan.next->dname);
if (help_subst_chan_0_0) {
  writeidx++;
  *writeidx++ = ' ';
}
  }
}

[Bug c/98627] GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
How did you configure the compiler?

[Bug tree-optimization/98602] Failure to optimise vector “x > -100 ? x : -100” to MAX_EXPR

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:48c7f5b88116c894d76209db0f47216ed5ccd333

commit r11-6595-g48c7f5b88116c894d76209db0f47216ed5ccd333
Author: Richard Sandiford 
Date:   Mon Jan 11 18:03:21 2021 +

aarch64: Add support for unpacked SVE mult, max and min

This patch makes the SVE_INT_BINARY_IMM patterns support
unpacked arithmetic, covering MUL, SMAX, SMIN, UMAX and UMIN.
For min and max, the type suffix must be taken from the element
size rather than the container size.

The XFAILs are due to PR98602.

gcc/
* config/aarch64/aarch64-sve.md (3)
(@aarch64_pred_)
(*post_ra_3): Extend from
SVE_FULL_I
to SVE_I.

gcc/testsuite/
PR testsuite/98602
* g++.target/aarch64/sve/max_1.C: New test.
* g++.target/aarch64/sve/min_1.C: Likewise.
* gcc.target/aarch64/sve/mul_2.c: Likewise.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
Zero allocations should be diagnosed by -Walloc-zero.  The option is disabled
by default to avoid false positives for calls to malloc(0) emitted by GCC in
some cases.  The test case in comment #0 isn't diagnosed even when -Walloc-zero
is explicitly set is a bug.  It should be diagnosed, and I think for VLAs the
warning should be enabled in -Wall to help detect potential aliasing
violations).

Some uses of zero length arrays that aren't VLAs are diagnosed by
-Wzero-length-bounds (enabled by -Warray-bounds).  I posted a patch in November
to enhance their detection, including VLAs, but it never got reviewed.  I
expect to resubmit it for GCC 12.  With that patch, the test case in comment #0
is diagnosed as long as the array is either accessed or passed as an argument
to a function that might use it.

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|8.5 |9.4
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #11 from Jonathan Wakely  ---
Fixed for 9.4, but I do not plan to backport it to gcc-8.

[Bug libstdc++/96083] Clang can't compile : error: use of undeclared identifier '__builtin_sprintf'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |9.4
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
Fixed for 9.4 and 10.3

The gcc-9 branch commit didn't show up here, but was r9-9173

[Bug target/29517] Exception handling not thread-safe on AIX5.x and HP-UX

[tony.reix at atos dot net via Gcc-bugs]

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

Tony Reix  changed:

   What|Removed |Added

 CC||tony.reix at atos dot net

--- Comment #12 from Tony Reix  ---
This test no more fails on AIX 7.1 with GCC 8.4.0-5 provided by BullFreeware.
http://www.bullfreeware.com/?searching=true=gcc%208.4===false=false=5

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|11.0|8.5

--- Comment #12 from Jonathan Wakely  ---
Fixed for 8.5 and 9.4 and 10.3

The gcc-9 commit didn't show up here but was r9-9172

[Bug libstdc++/65480] libstdc++-prettyprinters/libfundts.cc test failures on powerpc64

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|11.0|8.5

--- Comment #6 from Jonathan Wakely  ---
Fixed for 8.5 and 9.4 and 10.3

The gcc-9 commit didn't show up here but was r9-9172

[Bug sanitizer/98623] sanitizer does not diagnose when passing pointers to arrays of incorrect run-time length

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The middle end doesn't do anything with pointers to arrays yet but I agree
handling those would be a useful enhancement.  I don't see the benefit of
diagnosing the case in comment #0 where the array is bigger than the bound
indicates.  I do see the value of diagnosing this form:

extern void f(int n, double (*x)[n]);

int main()
{
double a[10];
f(11, );
}

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:2204b4121fa9cddb89dd52a8a0754a1ae0666efb

commit r8-10720-g2204b4121fa9cddb89dd52a8a0754a1ae0666efb
Author: Jonathan Wakely 
Date:   Wed Dec 2 21:39:08 2020 +

libstdc++: Fix std::any pretty printer [PR 68735]

This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.

libstdc++-v3/ChangeLog:

PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to_name):
New helper function to get the name of a function from its
address.
(StdExpAnyPrinter.__init__): Use it.

(cherry picked from commit dc2b372ed1b1e9af6db45051cff95478c7616807)

[Bug libstdc++/65480] libstdc++-prettyprinters/libfundts.cc test failures on powerpc64

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:2204b4121fa9cddb89dd52a8a0754a1ae0666efb

commit r8-10720-g2204b4121fa9cddb89dd52a8a0754a1ae0666efb
Author: Jonathan Wakely 
Date:   Wed Dec 2 21:39:08 2020 +

libstdc++: Fix std::any pretty printer [PR 68735]

This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.

libstdc++-v3/ChangeLog:

PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to_name):
New helper function to get the name of a function from its
address.
(StdExpAnyPrinter.__init__): Use it.

(cherry picked from commit dc2b372ed1b1e9af6db45051cff95478c7616807)

[Bug analyzer/98628] internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2040

[ortmann at posteo dot de via Gcc-bugs]

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

--- Comment #1 from Michael Ortmann  ---
Created attachment 49939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49939=edit
The preprocessed file (*.i*) that triggers the bug

[Bug analyzer/98628] New: internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2040

[ortmann at posteo dot de via Gcc-bugs]

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

Bug ID: 98628
   Summary: internal compiler error: in get_or_create_cluster, at
analyzer/store.cc:2040
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: ortmann at posteo dot de
  Target Milestone: ---

Version: gcc (GCC) 11.0.0 20210110 (experimental)

System type: GNU/Linux kernel 5.10.5 glibc 2.32

Options given when GCC was configured/built:
--prefix=/home/michael/opt/gcc-11-20210110 --enable-languages=c
--disable-multilib --with-system-zlib

Trigger:

git clone https://github.com/eggheads/eggdrop.git
cd eggdrop/
git checkout 94d2a4fabfd47deb8d3ae59bea769eb3e792ef07
CC="/home/michael/opt/gcc-11-20210110/bin/gcc -fanalyzer" ./configure 
make config
make

Note: eggdrop requires tcl to be installed also.

Compiler output:

[...]
/home/michael/opt/gcc-11-20210110/bin/gcc -fanalyzer -g -O2 -pipe -Wall -I..
-I..  -DHAVE_CONFIG_H -I/usr/include -g3 -DDEBUG -DDEBUG_ASSERT -DDEBUG_MEM
-DDEBUG_DNS  -c misc.c
during IPA pass: analyzer
misc.c:958:25: internal compiler error: in get_or_create_cluster, at
analyzer/store.cc:2040
  958 | *writeidx++ = ' ';
  | ^
0x76f191 ana::store::get_or_create_cluster(ana::region const*)
../../gcc/analyzer/store.cc:2040
0x11b92f9 ana::binding_cluster::make_unknown_relative_to(ana::binding_cluster
const*, ana::store*, ana::store_manager*)
../../gcc/analyzer/store.cc:1326
0x11bac4e ana::binding_cluster::can_merge_p(ana::binding_cluster const*,
ana::binding_cluster const*, ana::binding_cluster*, ana::store*,
ana::store_manager*, ana::model_merger*)
../../gcc/analyzer/store.cc:1208
0x11bb746 ana::store::can_merge_p(ana::store const*, ana::store const*,
ana::store*, ana::store_manager*, ana::model_merger*)
../../gcc/analyzer/store.cc:2111
0x1189e4c ana::region_model::can_merge_with_p(ana::region_model const&,
ana::program_point const&, ana::region_model*) const
../../gcc/analyzer/region-model.cc:2954
0x117fa0a ana::program_state::can_merge_with_p(ana::program_state const&,
ana::program_point const&, ana::program_state*) const
../../gcc/analyzer/program-state.cc:1083
0x116f36d
ana::exploded_graph::maybe_process_run_of_before_supernode_enodes(ana::exploded_node*)
../../gcc/analyzer/engine.cc:2735
0x1170657 ana::exploded_graph::process_worklist()
../../gcc/analyzer/engine.cc:2443
0x11724bb ana::impl_run_checkers(ana::logger*)
../../gcc/analyzer/engine.cc:4739
0x11732ce ana::run_checkers()
../../gcc/analyzer/engine.cc:4810
0x1165c58 execute
../../gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [Makefile:83: misc.o] Error 1
make[1]: Leaving directory '/tmp/eggdrop/src'
make: *** [Makefile:251: debug] Error 2

[Bug c/98627] New: GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[noring at nocrew dot org via Gcc-bugs]

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

Bug ID: 98627
   Summary: GCC emits unaligned memory access instructions causing
address error exceptions with the 68000 architecture
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noring at nocrew dot org
  Target Milestone: ---

The 68000 architecture requires that (16-bit) word and (32-bit) long memory
accesses are aligned with even addresses, but GCC frequently emits code that
breaks this when compiling with optimisations (O1 or higher). This causes
address error exceptions, which are fatal errors that crash programs.

For example, consider

struct s { char a, b, c, d, e; };
struct s f(char a)
{
return (struct s) { .a = a, .d = 'd' };
}

that GCC with O1 will compile into

 :
   0:   2049moveal %a1,%a0
   2:   202f 0004   movel %sp@(4),%d0
   6:   42a9 0001   clrl %a1@(1)/* <<<--- unaligned long clear */
   a:   1280moveb %d0,%a1@
   c:   137c 0064 0003  moveb #100,%a1@(3)
  12:   4e75rts

where offset 6 has "clrl %a1@(1)", which is an unaligned 32-bit long clear. GCC
can emit several similar variants of this, for example unaligned 16-bit word
clears, and possibly others.

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

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

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

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

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

commit r11-6593-gcbe9758ff494d55d558a2a0c5e8702c50fcebdf0
Author: Martin Liska 
Date:   Mon Jan 11 14:01:07 2021 +0100

Properly release symtab::m_clones.

gcc/ChangeLog:

PR jit/98615
* symtab-clones.h (clone_info::release): Release
symtab::m_clones with ggc_delete as it's a GGC memory.

[Bug c++/98626] UBSAN: vec.h:591:30: runtime error: member access within null pointer of type 'struct vec'

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-11
 Ever confirmed|0   |1

[Bug c++/98626] New: UBSAN: vec.h:591:30: runtime error: member access within null pointer of type 'struct vec'

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

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

Bug ID: 98626
   Summary: UBSAN: vec.h:591:30: runtime error: member access
within null pointer of type 'struct vec'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

I see the following with UBSAN compiler:

$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/mod-decl-2_a.C -c
-fmodules-ts
...
$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/mod-decl-2_b.C -c
-fmodules-ts
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/mod-decl-2_b.C:4:1:
error: cannot import module in its own purview
4 | import bob; // { dg-error "cannot import module.* in its own purview" }
  | ^~
In module imported at
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/mod-decl-2_b.C:4:1:
bob: note: module ‘bob’ declared here
/home/marxin/Programming/gcc2/gcc/cp/typeck.c:4024:33: runtime error: member
call on null pointer of type 'struct vec'
#0 0x1403445 in cp_build_function_call_vec(tree_node*, vec**, int, tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/typeck.c:4024
#1 0xfdd5bf in module_add_import_initializers()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:18995
#2 0xdc20f9 in start_objects
/home/marxin/Programming/gcc2/gcc/cp/decl2.c:3745
#3 0xdc4b3b in generate_ctor_or_dtor_function
/home/marxin/Programming/gcc2/gcc/cp/decl2.c:4310
#4 0xdccb6c in c_parse_final_cleanups()
/home/marxin/Programming/gcc2/gcc/cp/decl2.c:5234
#5 0x15ae87f in c_common_parse_file()
/home/marxin/Programming/gcc2/gcc/c-family/c-opts.c:1233
#6 0x2ccb435 in compile_file /home/marxin/Programming/gcc2/gcc/toplev.c:457
#7 0x2cd3e17 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2193
#8 0x2cd441a in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2332
#9 0x59b3bff in main /home/marxin/Programming/gcc2/gcc/main.c:39
#10 0x76ce5151 in __libc_start_main (/lib64/libc.so.6+0x28151)
#11 0xa82bdd in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1plus+0xa82bdd)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug c++/98624] UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-11

[Bug c++/98625] UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98624
   Last reconfirmed||2021-01-11
 Status|UNCONFIRMED |NEW

[Bug c++/98625] New: UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1

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

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

Bug ID: 98625
   Summary: UBSAN: gcc/cp/module.cc:977:15: runtime error: left
shift of negative value -1
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

Seen with:

$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/enum-1_a.C -c
-fmodules-ts
$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/enum-1_b.C -c
-fmodules-ts
...
/home/marxin/Programming/gcc2/gcc/cp/module.cc:977:15: runtime error: left
shift of negative value -1
#0 0xf3402f in bytes_in::wi()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:977
#1 0xfeacc4 in bytes_in::wu()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:997
#2 0xf5fa20 in trees_in::core_vals(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:6537
#3 0xf673c7 in trees_in::tree_node_vals(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:7148
#4 0xf7d365 in trees_in::tree_value()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:8996
#5 0xf7f047 in trees_in::tree_node(bool)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:9214
#6 0xfa7a98 in trees_in::read_enum_def(tree_node*, tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:12203
#7 0xfa96dd in trees_in::read_definition(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:12401
#8 0xfbe6df in module_state::read_cluster(unsigned int)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:14905
#9 0xfd59a9 in module_state::load_section(unsigned int, binding_slot*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:18036
#10 0xfdb7b7 in lazy_load_binding(unsigned int, tree_node*, tree_node*,
binding_slot*) /home/marxin/Programming/gcc2/gcc/cp/module.cc:18718
#11 0x101d434 in name_lookup::search_namespace_only(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/name-lookup.c:918
#12 0x101f47f in name_lookup::search_unqualified(tree_node*,
cp_binding_level*) /home/marxin/Programming/gcc2/gcc/cp/name-lookup.c:1149
#13 0x1061c02 in lookup_name_1
/home/marxin/Programming/gcc2/gcc/cp/name-lookup.c:7910
#14 0x1061da7 in lookup_name(tree_node*, LOOK_where, LOOK_want)
/home/marxin/Programming/gcc2/gcc/cp/name-lookup.c:7930
#15 0xd8d60f in lookup_name(tree_node*, LOOK_want)
/home/marxin/Programming/gcc2/gcc/cp/name-lookup.h:413
#16 0x110d10c in cp_parser_lookup_name
/home/marxin/Programming/gcc2/gcc/cp/parser.c:29285
#17 0x10f7949 in cp_parser_class_name
/home/marxin/Programming/gcc2/gcc/cp/parser.c:24618
#18 0x110e73b in cp_parser_constructor_declarator_p
/home/marxin/Programming/gcc2/gcc/cp/parser.c:29636
#19 0x10ccefe in cp_parser_decl_specifier_seq
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14988
#20 0x10c99dd in cp_parser_simple_declaration
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14260
#21 0x10c9937 in cp_parser_block_declaration
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14207
#22 0x10c907a in cp_parser_declaration
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14078
#23 0x10c9381 in cp_parser_toplevel_declaration
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14107
#24 0x109cc1e in cp_parser_translation_unit
/home/marxin/Programming/gcc2/gcc/cp/parser.c:4936
#25 0x116c842 in c_parse_file()
/home/marxin/Programming/gcc2/gcc/cp/parser.c:45121
#26 0x15ae6d5 in c_common_parse_file()
/home/marxin/Programming/gcc2/gcc/c-family/c-opts.c:1211
#27 0x2ccb435 in compile_file
/home/marxin/Programming/gcc2/gcc/toplev.c:457
#28 0x2cd3e17 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2193
#29 0x2cd441a in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2332
#30 0x59b3bff in main /home/marxin/Programming/gcc2/gcc/main.c:39
#31 0x76ce5151 in __libc_start_main (/lib64/libc.so.6+0x28151)
#32 0xa82bdd in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1plus+0xa82bdd)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug c++/98624] New: UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'

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

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

Bug ID: 98624
   Summary: UBSAN: gcc/cp/module.cc:5895:29: runtime error: member
call on null pointer of type 'struct module_state'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

Seen with UBSAN compiler:

$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/align-type-1_a.C -c
-fmodules-ts
/home/marxin/Programming/gcc2/gcc/cp/module.cc:5895:29: runtime error: member
call on null pointer of type 'struct module_state'
#0 0xf56fc4 in trees_out::core_vals(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:5895
#1 0xf67347 in trees_out::tree_node_vals(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:7141
#2 0xf6cd92 in trees_out::decl_value(tree_node*, depset*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:7753
#3 0xfb2a97 in depset::hash::find_dependencies()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:13199
#4 0xfd1f35 in module_state::write(elf_out*, cpp_reader*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:17568
#5 0xfe1ab8 in finish_module_processing(cpp_reader*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:19747
#6 0xdcc2d1 in c_parse_final_cleanups()
/home/marxin/Programming/gcc2/gcc/cp/decl2.c:5178
#7 0x15ae87f in c_common_parse_file()
/home/marxin/Programming/gcc2/gcc/c-family/c-opts.c:1233
#8 0x2ccb435 in compile_file /home/marxin/Programming/gcc2/gcc/toplev.c:457
#9 0x2cd3e17 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2193
#10 0x2cd441a in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2332
#11 0x59b3bff in main /home/marxin/Programming/gcc2/gcc/main.c:39
#12 0x76ce5151 in __libc_start_main (/lib64/libc.so.6+0x28151)
#13 0xa82bdd in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1plus+0xa82bdd)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug testsuite/98622] [11 regression] new test case pr98273.C in r11-6577 doesn't work

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Note that Python tests are optional and you likely see the UNRESOLVED message
as you don't have python3 (or pytest module) installed.

[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

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

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

--- Comment #4 from David Malcolm  ---
I set them so that each stmt has a unique id, unique across all functions.  I
was assuming from the comments I quoted above in gimple.h that this is safe to
do, but it sounds like from your comment that WPA makes assumptions that the
uids don't change.  If that's the case, then I need to rethink things, and the
gimple.h comments probably need updating (or WPA needs to allow for uids to
change, but maybe that's hard to do?)

[Bug sanitizer/98623] New: sanitizer does not diagnose when passing pointers to arrays of incorrect run-time length

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 98623
   Summary: sanitizer does not diagnose when passing pointers to
arrays of incorrect run-time length
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

In the following example, there is no run-time error with -fsanitize=undefined
although the pointer types for the second argument are required to point to
compatible types and it is UB when variably modified types have non-matching
lengths when they are required to be compatible (6.7.6.2p6). From a practical
point of view, this would very desirable as it would close the last loop-hole
that prevents one from having proper bounds checking when using pointers to
VLAs.

(In this case, but not in general, it should also be possible to emit an error
at compile time.)


extern void f(int n, double (*x)[n]);

int main()
{
double a[10];
f(9, );
}

[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?

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

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

--- Comment #1 from Tobias Burnus  ---
Also related to this issue:
https://gcc.gnu.org/pipermail/fortran/2021-January/055581.html:

In my understanding (see linked email and spec quote in comment 0),
CFI_type_signed_char is an integer type – and, hence, it should not be handled
at the following place – as pointed out by Harris Snyder in that email:

'CFI_establish' in libgfortran/runtime/ISO_Fortran_binding.c, circa line 348:

  if (type == CFI_type_char || type == CFI_type_ucs4_char ||
  type == CFI_type_signed_char || type == CFI_type_struct ||
  type == CFI_type_other)
dv->elem_len = elem_len;


The value is later used for the stride multiplier (sm) – hence, it causes
problems if it is set wrongly (to 0).

TESTCASE: See linked email.

[Bug c++/98481] [10/11 Regression] std::vector::size_type as return type gets tagged with abi:cxx11

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

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

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

https://gcc.gnu.org/g:3dd0d3ee1d2a988e7f3a3e8f009fcf328f16d2ed

commit r11-6592-g3dd0d3ee1d2a988e7f3a3e8f009fcf328f16d2ed
Author: Jakub Jelinek 
Date:   Thu Jan 7 17:47:18 2021 +0100

c++, abi: Fix abi_tag attribute handling [PR98481]

In GCC10 cp_walk_subtrees has been changed to walk template arguments.
As the following testcase, that changed the mangling of some functions.
I believe the previous behavior that find_abi_tags_r doesn't recurse into
template args has been the correct one, but setting *walk_subtrees = 0
for the types and handling the types subtree walking manually in
find_abi_tags_r looks too hard, there are a lot of subtrees and details
what
should and shouldn't be walked, both in tree.c (walk_type_fields there,
which is static) and in cp_walk_subtrees itself.

The following patch abuses the fact that *walk_subtrees is an int to
tell cp_walk_subtrees it shouldn't walk the template args.

Co-authored-by: Jason Merrill 

gcc/cp/ChangeLog:

PR c++/98481
* class.c (find_abi_tags_r): Set *walk_subtrees to 2 instead of 1
for types.
(mark_abi_tags_r): Likewise.
* decl2.c (min_vis_r): Likewise.
* tree.c (cp_walk_subtrees): If *walk_subtrees_p is 2, look through
typedefs.

gcc/testsuite/ChangeLog:

PR c++/98481
* g++.dg/abi/abi-tag24.C: New test.

[Bug c++/98620] SFINAE code in class specialization generates warnings

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Can be fixed like this:

--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1563,6 +1563,7 @@ process_init_constructor_record (tree type, tree init,
int nested, int flags,

  /* Warn when some struct elements are implicitly initialized.  */
  if ((complain & tf_warning)
+ && !cp_unevaluated_operand
  && !EMPTY_CONSTRUCTOR_P (init))
warning (OPT_Wmissing_field_initializers,
 "missing initializer for member %qD", field);
@@ -1593,6 +1594,7 @@ process_init_constructor_record (tree type, tree init,
int nested, int flags,
  /* Warn when some struct elements are implicitly initialized
 to zero.  */
  if ((complain & tf_warning)
+ && !cp_unevaluated_operand
  && !EMPTY_CONSTRUCTOR_P (init))
warning (OPT_Wmissing_field_initializers,
 "missing initializer for member %qD", field);

[Bug testsuite/98622] New: [11 regression] new test case pr98273.C in r11-6577 doesn't work

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

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

Bug ID: 98622
   Summary: [11 regression] new test case pr98273.C in r11-6577
doesn't work
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:4e275dccfc2467b3fe39012a3dd2a80bac257dd0, r11-6577



UNRESOLVED: could not find Python interpreter and (or) pytest module for
pr98273.C

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

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

commit r9-9168-gb1dba8a228e7d9497d2ddbd012b4343f99b87823
Author: Jonathan Wakely 
Date:   Fri Nov 29 14:47:03 2019 +

libstdc++: improve how pretty printers find node types (PR 91997)

This fixes two related problems.

The iterators for node-based containers use nested typedefs such as
std::list::iterator::_Node to denote their node types. As reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1053438 those typedefs are
not always present in the debug info. That means the pretty printers
cannot find them using gdb.lookup_type (via the find_type helper).
Instead of looking up the nested typedefs this patch makes the printers
look up the actual class templates directly.

A related problem (and the original topic of PR 91997) is that GDB fails
to find types via gdb.lookup_type when printing a backtrace from a
non-C++ functiion: https://sourceware.org/bugzilla/show_bug.cgi?id=25234
That is also solved by not looking up the nested typedef.

PR libstdc++/91997
* python/libstdcxx/v6/printers.py (find_type): Fail more gracefully
if we run out of base classes to look at.
(llokup_templ_spec, lookup_node_type): New utilities to find node
types for node-based containers.
(StdListPrinter.children, NodeIteratorPrinter.__init__)
(NodeIteratorPrinter.to_string, StdSlistPrinter.children)
(StdSlistIteratorPrinter.to_string,
StdRbtreeIteratorPrinter.__init__)
(StdMapPrinter.children, StdSetPrinter.children)
(StdForwardListPrinter.children): Use lookup_node_type instead of
find_type.
(StdListIteratorPrinter.__init__,
StdFwdListIteratorPrinter.__init__):
Pass name of node type to NodeIteratorPrinter constructor.
(Tr1HashtableIterator.__init__): Rename argument.
(StdHashtableIterator.__init__): Likewise. Use lookup_templ_spec
instead of find_type.
* testsuite/libstdc++-prettyprinters/59161.cc: Remove workaround
for
_Node typedef not being present in debuginfo.
* testsuite/libstdc++-prettyprinters/91997.cc: New test.

(cherry picked from commit 9d50a6a78509b42b3c2b2264da1a0d2c4b151d66)

[Bug libstdc++/96083] Clang can't compile : error: use of undeclared identifier '__builtin_sprintf'

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:93beee71a5ba5ee97a072d94780b140ae159fd74

commit r10-9250-g93beee71a5ba5ee97a072d94780b140ae159fd74
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:50:34 2020 +

libstdc++: Only use __builtin_sprintf if supported [PR 96083]

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprintf if necessary.

(cherry picked from commit 96d9670e88333d8896a5d2f2bb0403c1e2ad19ab)

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

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

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

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

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

commit r10-9249-g4fd49da23bf579b84940bd96bf942bd99cfa187a
Author: Jonathan Wakely 
Date:   Wed Dec 2 21:39:08 2020 +

libstdc++: Fix std::any pretty printer [PR 68735]

This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.

libstdc++-v3/ChangeLog:

PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to_name):
New helper function to get the name of a function from its
address.
(StdExpAnyPrinter.__init__): Use it.

(cherry picked from commit dc2b372ed1b1e9af6db45051cff95478c7616807)

[Bug libstdc++/65480] libstdc++-prettyprinters/libfundts.cc test failures on powerpc64

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-9249-g4fd49da23bf579b84940bd96bf942bd99cfa187a
Author: Jonathan Wakely 
Date:   Wed Dec 2 21:39:08 2020 +

libstdc++: Fix std::any pretty printer [PR 68735]

This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.

libstdc++-v3/ChangeLog:

PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to_name):
New helper function to get the name of a function from its
address.
(StdExpAnyPrinter.__init__): Use it.

(cherry picked from commit dc2b372ed1b1e9af6db45051cff95478c7616807)

[Bug c++/98620] SFINAE code in class specialization generates warnings

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-01-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||diagnostic

[Bug tree-optimization/98455] [11 Regression] ICE: verify_gimple failed (error: invalid 'PHI' argument; error: incompatible types in 'PHI' argument 2) since r11-5642-gc961e94901eb793b

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

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

--- Comment #3 from Richard Biener  ---
The issue is you are leaving the virtual PHI arguments NULL and thus
ssa_redirect_edge runs into

if (def == NULL_TREE)
  continue;

but then later flush_pending_stmts expects a 1:1 correspondence of PHI
and argument per edge.  The fix is to either put in bare gimple_vop (cfun)
symbols (you'll rename later anyway) in the PHI argument place or try
to make the CFG workers deal with missing arguments.

Note missing args are not really valid.  After if-to-switch:

   :
  # .MEM_2 = PHI <.MEM_3(D)(3), .MEM_2(7), .MEM_3(D)(2), .MEM_2(9), .MEM_2(5),
(6)>
  # uc$1_12 = PHI <2.0e+0(3), uc$1_12(7), 2.0e+0(2), 0.0(9), uc$1_12(5),
uc$1_12(6)>
:
  if (io_6(D) == 0)

note the missing MEM argument in the edge from 6 to 5

[Bug tree-optimization/95731] Failure to optimize a >= 0 && b >= 0 to (a | b) >= 0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 49938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49938=edit
gcc11-pr95731.patch

Untested fix.

[Bug c/98621] New: ICE: x from g referenced in f

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

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

Bug ID: 98621
   Summary: ICE: x from g referenced in f
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

Here is an error-recovery ICE:

$ cat test.c
int f() {
  int g(x) int x;
  int a[x];
}
$ aarch64-elf-gcc -c test.c
test.c: In function 'g':
test.c:4:1: error: expected declaration specifiers before '}' token
4 | }
  | ^
test.c:3:7: error: declaration for parameter 'a' but no such parameter
3 |   int a[x];
  |   ^
test.c:5: error: expected '{' at end of input
test.c: In function 'f':
test.c:4:1: error: expected declaration or statement at end of input
4 | }
  | ^
test.c:1:5: internal compiler error: x from g referenced in f
1 | int f() {
  | ^
0xeae7e0 convert_nonlocal_reference_op
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:1163
0x1181546 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/alecop01/toolchain/src/gcc/gcc/tree.c:12095
0xaa2a6c walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:202
0xaa384e walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:596
0xaa3b2c walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:51
0xaa38ca walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:605
0xaa3b2c walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:51
0xea87ca walk_body
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:811
0xea8857 walk_function
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:822
0xea8857 walk_all_functions
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:887
0xeb3bf1 lower_nested_functions(tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:3698
0x8d883b cgraph_node::analyze()
/home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:676
0x8db7d2 analyze_functions
/home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:1235
0x8dcc87 symbol_table::finalize_compilation_unit()
/home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:2513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

[emil at tywoniak dot eu via Gcc-bugs]

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

--- Comment #19 from Emil Jiří Tywoniak  ---
(In reply to Emil Jiří Tywoniak from comment #18)
> (In reply to Christophe Lyon from comment #17)
> > Any chance you can try with a toolchain using binutils-2.35?
> > 
> > As I indicated in https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966
> > there's a related bug fix in binutils-2.35, but Arm's 2020-q2 toolchain
> > still uses 2.34.50.20200226.
> 
> Issue in my project is not present anymore with 2020 Q4 release, which packs
> GNU ld (GNU Arm Embedded Toolchain 10-2020-q4-major) 2.35.1.20201028. Will
> test example from Comment #11. My apologies for not reading threads more
> carefully

I have now tested the bad branch from Comment #11 and did not replicate the bug
with the Q4 toolchain (specifically, the Systick handler in .lst is exactly the
same as in the good branch excerpt in Comment #11)

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

[emil at tywoniak dot eu via Gcc-bugs]

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

--- Comment #18 from Emil Jiří Tywoniak  ---
(In reply to Christophe Lyon from comment #17)
> Any chance you can try with a toolchain using binutils-2.35?
> 
> As I indicated in https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966
> there's a related bug fix in binutils-2.35, but Arm's 2020-q2 toolchain
> still uses 2.34.50.20200226.

Issue in my project is not present anymore with 2020 Q4 release, which packs
GNU ld (GNU Arm Embedded Toolchain 10-2020-q4-major) 2.35.1.20201028. Will test
example from Comment #11. My apologies for not reading threads more carefully

[Bug tree-optimization/98455] [11 Regression] ICE: verify_gimple failed (error: invalid 'PHI' argument; error: incompatible types in 'PHI' argument 2) since r11-5642-gc961e94901eb793b

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
What happens here:

if-to-switch conversion happens:

(gdb) pcfun
void n4 (int io, int vb)
{
  double uc$1;
  double uc[2];

   :
  if (io_6(D) == 0)
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # uc$1_12 = PHI <2.0e+0(3), uc$1_12(7), 2.0e+0(2), 0.0(9), uc$1_12(5),
uc$1_12(6)>
:
  if (io_6(D) == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  switch (vb_8(D))  [INV], case 0:  [INV], case 1: 
[INV]>

   :
:
  goto ; [INV]

   :
:
  goto ; [INV]

}

as seen, uc$1_12 = PHI <..., uc$1_12(6), ...> is properly fixed.

The pass uses TODO_cleanup_cfg that corrupts the CFG in
gimple_make_forwarder_block

EMERGENCY DUMP:

void n4 (int io, int vb)
{
  double uc$1;
  double uc[2];

   :

   :
  # uc$1_12 = PHI <2.0e+0(2), uc$1_12(5), (4), uc$1_12(3), 0.0(6)> <- HERE
:
  if (io_6(D) == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  switch (vb_8(D))  [INV], case 0:  [INV], case 1: 
[INV]>

   :
:
  goto ; [INV]

   :
:
  goto ; [INV]

}

@Richi: What am I doing wrong?

[Bug tree-optimization/98117] [8/9/10 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

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

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

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

https://gcc.gnu.org/g:69894ce172412996c10c89838717980ede7c9003

commit r10-9247-g69894ce172412996c10c89838717980ede7c9003
Author: Richard Biener 
Date:   Mon Dec 7 10:29:07 2020 +0100

tree-optimization/98117 - fix range set by vectorization on niter IVs

This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration
count value causing wrong range info for the vector IV.  There's
still the case of VF == 1 where if we don't know whether we hit the
above case we cannot emit a range.

2020-12-07  Richard Biener  

PR tree-optimization/98117
* tree-vect-loop-manip.c (vect_gen_vector_loop_niters):
Properly handle degenerate niter when setting the vector
loop IV range.

* gcc.dg/torture/pr98117.c: New testcase.

(cherry picked from commit cdcbef3c3310a14f2994982b44cb1f8e14c77232)

[Bug c++/98620] New: SFINAE code in class specialization generate warnings

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

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

Bug ID: 98620
   Summary: SFINAE code in class specialization generate warnings
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

Following code compiled in any gcc>=5, C++11 or higher, and
-Wmissing-field-initializers generate compiler warning:

g++ -std=c++20 -Wmissing-field-initializers

#include 

template 
struct TmpArray
{
   T arr[1];
};

template 
struct is_non_narrowing_conversion : std::false_type
{};

template 
struct is_non_narrowing_conversion<
Src, Dst,
decltype(void(TmpArray{{ std::declval() }}))
> : std::true_type
{};

struct mystruct
{
int a;
void * b;
};


void test_nok()
{
is_non_narrowing_conversion::type v;
}

SFINAE is used here only to detect if a code compiles, and code inside the
decltype should not generate warnings.

Also this is inconsistent, because when SFINAE is used in function template the
warning is not generated:
template 
auto is_non_narrowing_conversion_func_impl(Src&&, int)
   -> decltype((TmpArray{{ std::declval() }}, std::true_type{}));

template 
auto is_non_narrowing_conversion_func_impl(Src&&, ...)
   -> std::false_type;

template 
using is_non_narrowing_conversion_v2 =
decltype(is_non_narrowing_conversion_func_impl(std::declval(), 0));

void test_ok()
{
is_non_narrowing_conversion_v2 v;
}

[Bug tree-optimization/97623] [9 Regression] Extremely slow O2 compile (>>O(n^2))

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.2.0
  Known to work||10.2.1
Summary|[9/10 Regression] Extremely |[9 Regression] Extremely
   |slow O2 compile (>>O(n^2))  |slow O2 compile (>>O(n^2))

--- Comment #23 from Richard Biener  ---
Backported to GCC 10 - I'm not planning to backport further.

[Bug tree-optimization/97623] [9/10 Regression] Extremely slow O2 compile (>>O(n^2))

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

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

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

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

commit r10-9246-geddcb627ccfbd97e025cf366cc3f3bad76211785
Author: Richard Biener 
Date:   Tue Nov 3 15:03:41 2020 +0100

tree-optimization/97623 - Avoid PRE hoist insertion iteration

We are not really interested in PRE opportunities exposed by
hoisting but only the other way around.  So this moves hoist
insertion after PRE iteration finished and removes hoist
insertion iteration alltogether.

It also guards access to NEW_SETS properly.

2020-11-11  Richard Biener  

PR tree-optimization/97623
* tree-ssa-pre.c (insert): Move hoist insertion after PRE
insertion iteration and do not iterate it.
(create_expression_by_pieces): Guard NEW_SETS access.
(insert_into_preds_of_block): Likewise.

* gcc.dg/tree-ssa/ssa-hoist-3.c: Adjust.
* gcc.dg/tree-ssa/ssa-hoist-7.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-30.c: Likewise.

[Bug tree-optimization/97623] [9/10 Regression] Extremely slow O2 compile (>>O(n^2))

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

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

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

https://gcc.gnu.org/g:0fd6247a3014038af349db3a01748b5dc17d87a0

commit r10-9245-g0fd6247a3014038af349db3a01748b5dc17d87a0
Author: Richard Biener 
Date:   Fri Oct 30 13:32:32 2020 +0100

tree-optimization/97623 - avoid excessive insert iteration for hoisting

This avoids requiring insert iteration for back-to-back hoisting
opportunities as seen in the added testcase.  For the PR at hand
this halves the number of insert iterations retaining only
the hard to avoid PRE / hoist insert back-to-backs.

2020-10-30  Richard Biener  

PR tree-optimization/97623
* tree-ssa-pre.c (insert): First do hoist insertion in
a backward walk.

* gcc.dg/tree-ssa/ssa-hoist-7.c: New testcase.

(cherry picked from commit 82ff7e3426ea926d090777173977f8bedd086816)

Re: [Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[Andrea Corallo via Gcc-bugs]

Thank you for looking into it!  I tried my self but with no success

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[andrea.corallo at arm dot com via Gcc-bugs]

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

--- Comment #4 from Andrea Corallo  ---
Thank you for looking into it!  I tried my self but with no success

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #3 from Martin Liška  ---
I've got a patch candidate.
Thanks for the report!

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast' since r11-6083-gb7dfc2074c78415d451eb34d1608016c80b1c41a

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

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

--- Comment #17 from Nathan Sidwell  ---
libcody should be being built with -fno-exceptions -fno-rtti, that it isn;t
suggests I'm configuring it wrong.

[Bug target/98612] _mm_comieq_sd has wrong semantics

[guillaume.piolat at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Guillaume Piolat  ---
My reasoning for reporting (while it is minor) is the following:
- it might not be a conscious choice from GCC developers
- this is the only intrinsics I've found in mmx/sse/sse2 for which GCC has
different semantics than ICC and clang. 
- clang wiki define intel intrinsics as the "portable API" between compilers
- people will copy/paste intel intrinsics code between compilers. So fixing it
is breaking, but leaving it is also breaking
- in any case it is surprising

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

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

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

--- Comment #2 from Martin Liška  ---
g:895fdc1f4c9

[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

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

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

--- Comment #3 from Martin Liška  ---
> 
> The analyzer updates the gimple stmt uids; if I disable this updating the
> crash doesn't happen.

Hm, why do you update them in LTO WPA phase?
Note that they are used by cgraph_edges to point to a proper GIMPLE statement.

[Bug tree-optimization/91403] GCC fails with ICE.

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0

--- Comment #9 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/91403] GCC fails with ICE.

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:84684e0f78c20c51492722a5b95cda778ad77073

commit r11-6589-g84684e0f78c20c51492722a5b95cda778ad77073
Author: Richard Biener 
Date:   Mon Jan 11 12:04:32 2021 +0100

tree-optimization/91403 - avoid excessive code-generation

The vectorizer, for large permuted grouped loads, generates
inefficient intermediate code (cleaned up only later) that runs
into complexity issues in SCEV analysis and elsewhere.  For the
non-single-element interleaving case we already put a hard limit
in place, this applies the same limit to the missing case.

2021-01-11  Richard Biener  

PR tree-optimization/91403
* tree-vect-data-refs.c (vect_analyze_group_access_1): Cap
single-element interleaving group size at 4096 elements.

* gcc.dg/vect/pr91403.c: New testcase.

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

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

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #20 from Bernd Edlinger  ---
should be fixed now.

Thanks!

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

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

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Bernd Edlinger :

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

commit r11-6588-g6ebf79fcd4cfb43353e6a000f700b07295e78026
Author: Bernd Edlinger 
Date:   Thu Jan 7 09:37:32 2021 +0100

testsuite: Fix test failures from outputs.exp [PR98225]

The .ld1_args file is not created when HAVE_GNU_LD is false.
The ltrans0.ltrans_arg file is not created when the make jobserver
is available, so remove the MAKEFLAGS variable.
Add an exception for *.gcc_args files similar to the
exception for *.cdtor.* files.
Limit both exceptions to targets that define EH_FRAME_THROUGH_COLLECT2.
That means although the test case does not use C++ constructors
or destructors it is still using dwarf2 frame info.

2021-01-11  Bernd Edlinger  

PR testsuite/98225
* gcc.misc-tests/outputs.exp: Unset MAKEFLAGS.
Expect .ld1_args only when GNU LD is used.
Add an exception for *.gcc_args files.

[Bug middle-end/85811] Invalid optimization with fmax, fabs and nan

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

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

--- Comment #12 from Richard Biener  ---
Possibly could be backported even if not a regression but I guess the
wrong-code is really restricted to cases we don't hit in the wild.

That said, not objecting if anybody wants to backport to GCC 10.

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

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

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

--- Comment #5 from nsz at gcc dot gnu.org ---
(In reply to Wilco from comment #3)
> I fixed this in GCC10:
> https://gcc.gnu.org/git/?p=gcc.git=commit;
> h=7d3b27ff12610fde9d6c4b56abc70c6ee9b6b3db
> 
> So this just needs to be backported.

thanks, i'll try that, i'm still looking for
a simple workaround in glibc, this affects
this code in elf_get_dynamic_info:

...
  63   else if ((d_tag_utype) DT_VERSIONTAGIDX (dyn->d_tag) <
DT_VERSIONTAGNUM)
  64 info[VERSYMIDX (dyn->d_tag)] = dyn;
  65   else if ((d_tag_utype) DT_EXTRATAGIDX (dyn->d_tag) < DT_EXTRANUM)
  66 info[DT_EXTRATAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
  67  + DT_VERSIONTAGNUM] = dyn;
  68   else if ((d_tag_utype) DT_VALTAGIDX (dyn->d_tag) < DT_VALNUM)
  69 info[DT_VALTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
  70  + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn;
  71   else if ((d_tag_utype) DT_ADDRTAGIDX (dyn->d_tag) < DT_ADDRNUM)
  72 info[DT_ADDRTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
  73  + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
...

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

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

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

--- Comment #4 from nsz at gcc dot gnu.org ---
(In reply to Florian Weimer from comment #1)
> Is the test case really valid? It involves an out-of-bounds array access,
> after all.

sorry you are right the indexes are too far, a better test is

long n;
struct s { long a[100]; };
extern struct s obj __attribute__((visibility("hidden")));
void foo()
{
  long *a = obj.a;
  a[n - 0x7000] = n;
  a[0x7000 - n + 99] = n;
}

(i wanted to have an example with both + and - offset)
it compiles to

foo:
adrpx0, :got:n
adrpx2, obj-15032385536
add x2, x2, :lo12:obj-15032385536
adrpx1, obj+15032386328
ldr x0, [x0, #:got_lo12:n]
add x1, x1, :lo12:obj+15032386328
ldr x0, [x0]
neg x3, x0, lsl 3
str x0, [x2, x0, lsl 3]
str x0, [x3, x1]
ret

[Bug rtl-optimization/98619] aarch64: ICE (verify_flow_info failed)

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

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

--- Comment #1 from Richard Biener  ---
We might be able to CFG cleanup this to a non-goto asm [unless the 'goto'
invokes
semantic differences elsewhere]

[Bug tree-optimization/98598] Missed opportunity to optimize dependent loads in loops

[jiangning.liu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #11 from Jiangning Liu  
---
(In reply to rguent...@suse.de from comment #8)
> On Sat, 9 Jan 2021, jiangning.liu at amperecomputing dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598
> > 
> > --- Comment #7 from Jiangning Liu  > com> ---
> > (In reply to rguent...@suse.de from comment #6)
> > > On January 9, 2021 4:17:17 AM GMT+01:00, "jiangning.liu at amperecomputing
> > > dot com"  wrote:
> > > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598
> > > >
> > > >--- Comment #5 from Jiangning Liu  > > >com> ---
> > > >> It has to be done with care of course, cost modeling is difficult
> > > >> (we need to have a good estimate of n and m or need to version
> > > >> the whole nest).  That said, usually we attempt the reverse
> > > >transform.
> > > >
> > > >Before tuning the cost model good enough, we may implement this
> > > >optimization by
> > > >adding a new optimization command line option. This won't hurt gcc,
> > > >right?
> > > 
> > > New options not enabled by default tend to bitrot, be broken from the 
> > > start
> > > and won't be used by the lazy user. So I see no point in doing that. 
> > > 
> > 
> > Understand. I mean we can enable it by default eventually, but we need to
> > implement and tune it step by step. It is unrealistic to work out the best 
> > cost
> > model at the very beginning.
> 
> Sure.  The "easiest" thing is to rely on a profile from PGO, we did
> have some transforms only enabled by -fprofile-use by default.  That is,
> the cost model needs to be conservative, esp. if you introduce dynamic
> allocation for this.  In the end I guess only a variant that versions
> the nest on the size of the temporary will be good enough to not trigger
> OOM or excessive overhead for small sizes anyway.

People usually don't use PGO unless they can't find any better static compiler
switches. This optimization should always benefit performance if we can tune
the cost model good enough. It is true that the temp memory size needs to be
checked to avoid OOM, which is one of the runtime overheads.

[Bug rtl-optimization/98619] New: aarch64: ICE (verify_flow_info failed)

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

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

Bug ID: 98619
   Summary: aarch64: ICE (verify_flow_info failed)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat test.c
int a() {
  int *b;
  asm goto("" : "=mk"(b) : : : c);
d:
c:
}
$ aarch64-elf-gcc -c test.c
test.c: In function 'a':
test.c:6:1: error: too many outgoing branch edges from bb 2
6 | }
  | ^
during RTL pass: reload
test.c:6:1: internal compiler error: verify_flow_info failed
0x897451 verify_flow_info()
/home/alecop01/toolchain/src/gcc/gcc/cfghooks.c:269
0xcd9d55 execute_function_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.c:2054
0xcd9e80 do_per_function
/home/alecop01/toolchain/src/gcc/gcc/passes.c:1687
0xcda01b execute_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.c:2096
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/98526] [10/11 Regression] Double-counting of reduction cost

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:04bff1bbfc11a974342c0eb0c0d65d902e36e82e

commit r11-6587-g04bff1bbfc11a974342c0eb0c0d65d902e36e82e
Author: Richard Biener 
Date:   Mon Jan 11 11:47:46 2021 +0100

tree-optimization/98526 - fix vectorizer reduction cost

This fixes a double-counting in the reduction cost when vectorizing
the reduction through the regular vectorizable_* functions.

2021-01-11  Richard Biener  

PR tree-optimization/98526
* tree-vect-loop.c (vect_model_reduction_cost): Remove costing
of the actual reduction op for the regular case.
(vectorizable_reduction): Cost the stmts
vect_transform_reduction produces here.

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

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

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

Wilco  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||wilco at gcc dot gnu.org
   Last reconfirmed||2021-01-11
 Status|UNCONFIRMED |NEW

--- Comment #3 from Wilco  ---
I fixed this in GCC10:
https://gcc.gnu.org/git/?p=gcc.git=commit;h=7d3b27ff12610fde9d6c4b56abc70c6ee9b6b3db

So this just needs to be backported.

[Bug tree-optimization/98598] Missed opportunity to optimize dependent loads in loops

[jiangning.liu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #10 from Jiangning Liu  
---
(In reply to Hongtao.liu from comment #9)
> It looks like a SOA/AOC opt opportunity which is discussed in
> https://gcc.gnu.org/wiki/
> cauldron2015?action=AttachFile=view=Olga+Golovanevsky_+Memory+Layou
> t+Optimizations+of+Structures+and+Objects.pdf
> 
> And i remember there's someone working on enabling SOA/AOS opt in GCC.

No. The key difference is the optimization opportunity here doesn't rely on LTO
at all. It is purely a local optimization within a function instead.