[Bug tree-optimization/95717] [9 Regression] ICE during GIMPLE pass: vect: verify_ssa failed since r9-5325-gf25507d041de4df6

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE   |[9 Regression] ICE during
   |during GIMPLE pass: vect:   |GIMPLE pass: vect:
   |verify_ssa failed since |verify_ssa failed since
   |r9-5325-gf25507d041de4df6   |r9-5325-gf25507d041de4df6
  Known to work||10.1.1
   Priority|P3  |P2

[Bug tree-optimization/95717] [9/10 Regression] ICE during GIMPLE pass: vect: verify_ssa failed since r9-5325-gf25507d041de4df6

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8359-gf3a27a610b0eb9a7ea76f61b4fecf7e66e86a3e1
Author: Richard Biener 
Date:   Wed Jun 17 14:57:59 2020 +0200

tree-optimization/95717 - fix SSA update for vectorizer epilogue

This fixes yet another issue with the custom SSA updating in the
vectorizer when we copy from the non-if-converted loop.  We must
not mess with current defs before we updated the BB copies.

2020-06-17  Richard Biener  

PR tree-optimization/95717
* tree-vect-loop-manip.c (slpeel_tree_duplicate_loop_to_edge_cfg):
Move BB SSA updating before exit/latch PHI current def copying.

* g++.dg/torture/pr95717.C: New testcase.

(cherry picked from commit d0909f5858ad81e6d8b73fa6193be19cb5e6ed7b)

[Bug tree-optimization/95856] New: [11 Regression] error: definition in block 2 follows the use since r11-1582-gcf07eea8429c923b

[marxin at gcc dot gnu.org]

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

Bug ID: 95856
   Summary: [11 Regression] error: definition in block 2 follows
the use since r11-1582-gcf07eea8429c923b
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---

Reduced from blender SPEC2017 benchmark:

$ cat space_graph.i
typedef struct {
  float xmin, xmax;
} rctf;

typedef struct {
  rctf tot;
} View2D;

View2D graph_main_area_draw_v2d;

void get_graph_keyframe_extents();

void
graph_main_area_draw() {
  get_graph_keyframe_extents();
  graph_main_area_draw_v2d.tot.xmin -= 10.0f;
  graph_main_area_draw_v2d.tot.xmax += 10.0f;
}

$ gcc -O3 space_graph.i -c
space_graph.i: In function 'graph_main_area_draw':
space_graph.i:14:1: error: definition in block 2 follows the use
   14 | graph_main_area_draw() {
  | ^~~~
for SSA_NAME: vect__1.5_9 in statement:
vect__4.7_12 = vect__1.5_9 + vect_cst__10;
during GIMPLE pass: slp
space_graph.i:14:1: internal compiler error: verify_ssa failed
0xfcee12 verify_ssa(bool, bool)
/home/marxin/Programming/gcc/gcc/tree-ssa.c:1208
0xce0a45 execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1992
0xce178c do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1640
0xce178c execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2039
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/95856] [11 Regression] error: definition in block 2 follows the use since r11-1582-gcf07eea8429c923b

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-24
  Known to fail||11.0
  Known to work||10.1.0

[Bug fortran/31593] Invariant DO loop variables and subroutines

[tobi at gcc dot gnu.org]

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

Tobias Schlüter  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Keywords||rejects-valid, wrong-code

--- Comment #5 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548779.html

[Bug c/95857] New: Silencing an unused label warning with (void)&&label; can make gcc segfault

[pskocik at gmail dot com]

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

Bug ID: 95857
   Summary: Silencing an unused label warning with (void)&&label;
can make gcc segfault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

Created attachment 48777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48777&action=edit
preprocessed reproducer that crashes gcc >= 8.1 at -O2/-O3/-Os

In certain more complex contexts and with optimization on (>= -O2), silencing
-Wunused-label warnings  with
(void)&&label; will make gcc segfault.

The attached example ( https://gcc.godbolt.org/z/iEhgL2 ) obtained with creduce
 crashes gcc >= 8.1 when compiled at -O2/-O3/-Os.

I haven't observed the bug in older versions of gcc.

[Bug fortran/95858] New: [11 Regression] gcc/testsuite/gfortran.fortran-torture/execute/forall_5.f90 fails since r11-1595-gabcde0a658e17dbb

[marxin at gcc dot gnu.org]

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

Bug ID: 95858
   Summary: [11 Regression]
gcc/testsuite/gfortran.fortran-torture/execute/forall_
5.f90 fails since r11-1595-gabcde0a658e17dbb
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Since the revision the test-case fails:

$ gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.fortran-torture/execute/forall_5.f90
&& ./a.out 
STOP 3

[Bug middle-end/95746] ice during GIMPLE pass: reassoc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

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

[Bug rtl-optimization/95859] New: Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

[tobi at gcc dot gnu.org]

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

Bug ID: 95859
   Summary: Statically true asserts not recognized as such with
-O2, but with -O1, -Og, -O3
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tobi at gcc dot gnu.org
  Target Milestone: ---

With -O2 compiling for x86-64, the compiler doesn't recognize that a number of
assertions in the code are true and they end up as function calls in the
assembly output.  They are removed with -O1, -Og, -O3 but not with -O2 or -O2 +
"all the additional compiler flags for -O3 given in the documentation" (that's
a documentation bug on top of this misoptimization).

The asserts look something like this in the assembled form:
   template 
   assertion(int n) {
  assert(n == N);
   }
and are only called with compile-time constant arguments, i.e. assertion<3>(3)
and the like.

The final output from the tree passes contains the assertion calls at all
optimization levels, so the rtl optimizers appear to perform worst in -O2 in
this particular case.  I don't see why the calls couldn't be removed before
lowering to RTL.

I'm not sure how to extract preprocessed output form the compiler explorer, but
will provide it once I can put my hands on a recent gcc.

Source code reproduced below, the compiler explorer link is here:
https://godbolt.org/z/REJDhy

#include 

struct m34 {
float m[3][4];
};
typedef Eigen::Transform
unalignedTrafo3d;
using Trafo3d = unalignedTrafo3d;


Trafo3d func34(m34 mat)
{
using mapType = Eigen::Map>;

// should compile to a conversion of 12 floats to double.
auto mR = Trafo3d{ mapType{ (float*)mat.m }.cast() };
return mR;
}

[Bug target/95753] [11 Regression] ICE when building the Linux Kernel for ARM64 (internal compiler error: ‘global_options’ are modified in local context)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed with g:7f967bd2a7ba156ede3fbb147e66dea5fb7137a6.

[Bug fortran/95858] [11 Regression] gcc/testsuite/gfortran.fortran-torture/execute/forall_5.f90 fails since r11-1595-gabcde0a658e17dbb

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
Seen on arm and aarch64 too.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #25 from Martin Liška  ---
(In reply to David Binderman from comment #24)
> Is this error message related ?
> 
> /home/dcb/gcc/results.20200611/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/
> xsaveoptintrin.h:55:9: internal compiler error: Error: global_options are
> modified in local context
> 
>55 | #pragma GCC pop_options
>   | ^~~
> 0xe6fefe cl_optimization_compare(gcc_options*, gcc_options*)
>   /home/dcb/gcc/working/gcc/options-save.c:0
> 0x97c7b9 handle_pragma_pop_options(cpp_reader*)
>   ../../trunk.git/gcc/c-family/c-pragma.c:1090
> 0x7a0565 cp_parser_pragma(cp_parser*, pragma_context, bool*)
>   ../../trunk.git/gcc/cp/parser.c:43983
> 0x79d432 cp_parser_toplevel_declaration(cp_parser*)
>   ../../trunk.git/gcc/cp/parser.c:13502
> 
> It seems to be a preprocessor crash, so I don't know how to reduce
> the test case.

Yes, it's definitely related.
Please attach -E file and a command line.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #26 from Martin Liška  ---
One more arc-linux case:

{ OPT_LEVELS_SIZE, OPT_mcase_vector_pcrel, NULL, 1 },
{ OPT_LEVELS_SIZE, OPT_msize_level_, NULL, 3 },
{ OPT_LEVELS_SIZE, OPT_mmillicode, NULL, 1 },
{ OPT_LEVELS_3_PLUS_SPEED_ONLY, OPT_msize_level_, NULL, 0 },
{ OPT_LEVELS_3_PLUS_SPEED_ONLY, OPT_malign_call, NULL, 1 },

[Bug ipa/95859] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-06-24
  Component|rtl-optimization|ipa
 Status|UNCONFIRMED |WAITING
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
Hmm, from the compiler explorer link it looks like the functions are called
with
runtime values so whether the assertion holds is not known.  Now the question
is why we don't inline them.

We need preprocessed source to investigate.

[Bug fortran/95858] [11 Regression] gcc/testsuite/gfortran.fortran-torture/execute/forall_5.f90 fails since r11-1595-gabcde0a658e17dbb

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
This has been fixed in the testsuite with g:6f609029c7078fbd29e2f842074e2b9

[Bug tree-optimization/95856] [11 Regression] error: definition in block 2 follows the use since r11-1582-gcf07eea8429c923b

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

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

[Bug c/95857] [8/9/10/11 Regression] Silencing an unused label warning with (void)&&label; can make gcc segfault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
   Priority|P3  |P2
   Keywords||ice-on-valid-code
Summary|Silencing an unused label   |[8/9/10/11 Regression]
   |warning with (void)&&label; |Silencing an unused label
   |can make gcc segfault   |warning with (void)&&label;
   ||can make gcc segfault
Version|unknown |8.4.0
  Known to work||7.4.0

[Bug c++/95860] New: Wrong "looser exception specification" when a class has 2 prospective destructors.

[okannen at gmail dot com]

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

Bug ID: 95860
   Summary: Wrong "looser exception specification" when a class
has 2 prospective destructors.
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: okannen at gmail dot com
  Target Milestone: ---

Tested with gcc --version:
gcc (GCC) 10.1.1 20200613
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The following code should compile:

struct A {
virtual ~A() =default;
};

template 
struct B 
:A
{
~ B() =default; //destructor 1
~ B() requires (C) =default;//destructor 2

};

int main(){
B b;
}
The destructor of B is the "destrurcor 2". Nevertheless, GCC complains
that "destructor 1" has a looser exception specification than the base
destructor:

test.cpp: In instantiation of ‘struct B’:
test.cpp:144:10:   required from here
test.cpp:138:2: error: looser exception specification on overriding virtual
function ‘B::~B() [with bool C = true]’
  138 |  ~ B() =default;
  |  ^
test.cpp:131:10: note: overridden function is ‘virtual constexpr A::~A()
noexcept’
  131 |  virtual ~A() =default;
  |  ^

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com]

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

--- Comment #27 from David Binderman  ---
(In reply to Martin Liška from comment #25)
> Yes, it's definitely related.
> Please attach -E file and a command line.

Problem stills exists in the g++ compiler dated 20200623, but anything 
I do to reduce the problem makes it go away ;-<

Confirmation sought that the stack backtrace I provided shows
that the problem is a bug in the pre-processor. 

If so, -E isn't going to help.

[Bug middle-end/95810] Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:01e10b0ee77e82cb331414c569e02dc7a2c4999e

commit r11-1620-g01e10b0ee77e82cb331414c569e02dc7a2c4999e
Author: Jakub Jelinek 
Date:   Wed Jun 24 10:40:02 2020 +0200

fold-const: Fix A <= 0 ? A : -A folding [PR95810]

We folded A <= 0 ? A : -A into -ABS (A), which is for signed integral types
incorrect - can invoke on INT_MIN UB twice, once on ABS and once on its
negation.

The following patch fixes it by instead folding it to (type)-ABSU (A).

2020-06-24  Jakub Jelinek  

PR middle-end/95810
* fold-const.c (fold_cond_expr_with_comparison): Optimize
A <= 0 ? A : -A into (type)-absu(A) rather than -abs(A).

* gcc.dg/ubsan/pr95810.c: New test.

[Bug target/95861] New: popcnt --- unnecessary leading xor instruction

[zero at smallinteger dot com]

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

Bug ID: 95861
   Summary: popcnt --- unnecessary leading xor instruction
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zero at smallinteger dot com
  Target Milestone: ---

Created attachment 48778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48778&action=edit
sample code

Consider the attached code, compiled with -O3 -mpopcnt.  The assembly produced
in gcc 9.3 is below (the same code is generated by gcc 10.x at godbolt).

foo(unsigned long long):
xor eax, eax
popcnt  rax, rdi
ret


The popcnt instruction will overwrite rax.  Whether eax is cleared with xor has
no effect.  No xor instruction should be emitted in this case.  For reference,
trunk clang emits this code instead:

foo(unsigned long long):# @foo(unsigned long
long)
popcnt  rax, rdi
ret


This second code sample is as expected.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #28 from Martin Liška  ---
> Confirmation sought that the stack backtrace I provided shows
> that the problem is a bug in the pre-processor.

No, the problem is in C parser.

> 
> If so, -E isn't going to help.

Please attach it.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com]

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

--- Comment #29 from David Binderman  ---
Maybe I've been slightly less than clear, but to quote myself:
>anything I do to reduce the problem makes it go away

So I can't provide a small test case, or output from -E, for this.

I suggest I wait until the rest of the bug is solved, retest
and go from there.

My apologies for the lack of clarity.

[Bug target/95861] popcnt --- unnecessary leading xor instruction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
This is very much intentional, please see PR62011 for the reason.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #30 from Martin Liška  ---
(In reply to David Binderman from comment #29)
> Maybe I've been slightly less than clear, but to quote myself:
> >anything I do to reduce the problem makes it go away

Ah, ok!

> 
> So I can't provide a small test case, or output from -E, for this.
> 
> I suggest I wait until the rest of the bug is solved, retest
> and go from there.
> 
> My apologies for the lack of clarity.

What's the project where you see the issue?

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #41 from Martin Liška  ---
The patch survives PGO bootstrap of GCC and it shrinks size of gcda
file from 17MB to 12MB.

And compression can achieve the following:

zstd: 3.3 MB

$ time zstd *
real0m0.082s
user0m0.068s
sys0m0.013s

gzip: 3.3 MB

$ time gzip *
real0m0.357s
user0m0.328s
sys0m0.029s

So using compression is a very promising approach.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com]

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

--- Comment #31 from David Binderman  ---
(In reply to Martin Liška from comment #30)
> What's the project where you see the issue?

Chatterino2, in fedora rawhide.

Be warned, you will need my environment for gcc to see the problem.

More thought suggests that in a usual crash, I get a preprocessed
file, because I have -freport-bug switched on.

In this case, source code file gcc/options-save.c
explicitly calls routine internal_error, which doesn't produce a 
preprocessed file and so I cannot make progress.

I am busy with other stuff right now, but by the weekend, I should be
able to enhance routine internal_error to produce a preprocessed source
code file and so we can make progress.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #32 from Martin Liška  ---
> I am busy with other stuff right now, but by the weekend, I should be
> able to enhance routine internal_error to produce a preprocessed source
> code file and so we can make progress.

Thank you very much. I'll wait for a test-case by you ;)

[Bug tree-optimization/95862] New: Failure to optimize usage of __builtin_mul_overflow to small __int128-based check

[gabravier at gmail dot com]

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

Bug ID: 95862
   Summary: Failure to optimize usage of __builtin_mul_overflow to
small __int128-based check
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(int32_t a, int32_t b)
{
uint64_t r;
return __builtin_mul_overflow (a, b, &r);
}

This can be optimized to `return ((__uint128_t)(a * (__int128_t)b) >> 64) & 1;`
(idk if this might invoke UB, but rn at least it generates much better code on
x86 than what GCC currently generates for the example I gave). This
transformation is done by LLVM, but not by GCC.

[Bug tree-optimization/95856] [11 Regression] error: definition in block 2 follows the use since r11-1582-gcf07eea8429c923b

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1621-gd32708e796504eaeaad7d19990909204d74f9ba3
Author: Richard Biener 
Date:   Tue Jun 23 13:59:20 2020 +0200

tree-optimization/95856 fix vect_stmt_dominates_stmt_p at BB region
boundary

The following adjusts vect_stmt_dominates_stmt_p to honor out-of-region
stmts we run into which have UID -1u.

2020-06-24  Richard Biener  

PR tree-optimization/95856
* tree-vectorizer.c (vect_stmt_dominates_stmt_p): Honor
region marker -1u.

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

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[rguenth at gcc dot gnu.org]

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

Bug 95856 Summary: [11 Regression] error: definition in block 2 follows the use 
since r11-1582-gcf07eea8429c923b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95856

   What|Removed |Added

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

[Bug tree-optimization/95856] [11 Regression] error: definition in block 2 follows the use since r11-1582-gcf07eea8429c923b

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug target/95842] arch_names_table and processor_alias_table should be combined

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1623-g3fb2c2f4d0a43b96e9e4907db952e57a5cbe61ef
Author: H.J. Lu 
Date:   Tue Jun 23 12:49:32 2020 -0700

x86: Fold arch_names_table into processor_alias_table

In i386-builtins.c, arch_names_table is used to to map architecture name
string to internal model.  A switch statement is used to map internal
processor name to architecture name string and internal priority.

model and priority are added to processor_alias_table so that a single
entry contains architecture name string, internal processor name,
internal model and internal priority.  6 entries are appended for
i386-builtins.c, which have special architecture name strings: amd,
amdfam10h, amdfam15h, amdfam17h, shanghai and istanbul, and pta_size is
adjusted to exclude them.  Entries which are not used by i386-builtins.c
have internal model 0.  P_PROC_DYNAMIC is added to internal priority to
make entries with dynamic architecture name string or priority.

PR target/95842
* common/config/i386/i386-common.c (processor_alias_table): Add
processor model and priority to each entry.
(pta_size): Updated with -6.
(num_arch_names): New.
* common/config/i386/i386-cpuinfo.h: New file.
* config/i386/i386-builtins.c (feature_priority): Removed.
(processor_model): Likewise.
(_arch_names_table): Likewise.
(arch_names_table): Likewise.
(_isa_names_table): Replace P_ZERO with P_NONE.
(get_builtin_code_for_version): Replace P_ZERO with P_NONE.  Use
processor_alias_table.
(fold_builtin_cpu): Replace arch_names_table with
processor_alias_table.
* config/i386/i386.h: Include "common/config/i386/i386-cpuinfo.h".
(pta): Add model and priority.
(num_arch_names): New.

[Bug target/95842] arch_names_table and processor_alias_table should be combined

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed.

[Bug tree-optimization/95863] New: Failure to detect table-based ctz implementation

[gabravier at gmail dot com]

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

Bug ID: 95863
   Summary: Failure to detect table-based ctz implementation
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(unsigned x)
{
static const char table[32] = {0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15,
25, 17, 4, 8, 31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9};
return table[((unsigned)((x & -x) * 0x077CB531U)) >> 27];
}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838 claims to optimize this code
to `return __builtin_ctz(x)`, but this does not occur.

[Bug target/95864] New: [11 Regression] GCN offloading execution regressions after commit f062c3f11505b70c5275e5bc0e52f3e441f8afbc "amdgcn: Switch to HSACO v3 binary format"

[tschwinge at gcc dot gnu.org]

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

Bug ID: 95864
   Summary: [11 Regression] GCN offloading execution regressions
after commit f062c3f11505b70c5275e5bc0e52f3e441f8afbc
"amdgcn: Switch to HSACO v3 binary format"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: target
  Assignee: ams at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jules at gcc dot gnu.org
  Target Milestone: ---
Target: gcn

I'm seeing the following GCN offloading execution regressions after commit
f062c3f11505b70c5275e5bc0e52f3e441f8afbc "amdgcn: Switch to HSACO v3 binary
format":

PASS: libgomp.c/../libgomp.c-c++-common/for-5.c (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-5.c execution test

libgomp: GCN fatal error: Asynchronous queue error
Runtime message: HSA_STATUS_ERROR_INVALID_ISA: The instruction set
architecture is invalid.

WARNING: program timed out.
FAIL: libgomp.c/../libgomp.c-c++-common/for-5.c execution test

Same for C++.

PASS: libgomp.c/../libgomp.c-c++-common/for-6.c (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-6.c execution test

Same as above, same for C++.

@@ -3456,9 +3460,11 @@ PASS: libgomp.fortran/optional-map.f90   -O1 
execution test
PASS: libgomp.fortran/optional-map.f90   -O2  (test for excess errors)
PASS: libgomp.fortran/optional-map.f90   -O2  execution test
PASS: libgomp.fortran/optional-map.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.fortran/optional-map.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: libgomp.fortran/optional-map.f90   -O3 -g  (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.fortran/optional-map.f90   -O3 -g  execution test
PASS: libgomp.fortran/optional-map.f90   -Os  (test for excess errors)
PASS: libgomp.fortran/optional-map.f90   -Os  execution test

Same as above.

@@ -4323,9 +4329,11 @@ PASS: libgomp.fortran/target1.f90   -O1  execution
test
PASS: libgomp.fortran/target1.f90   -O2  (test for excess errors)
PASS: libgomp.fortran/target1.f90   -O2  execution test
PASS: libgomp.fortran/target1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.fortran/target1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: libgomp.fortran/target1.f90   -O3 -g  (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.fortran/target1.f90   -O3 -g  execution test
PASS: libgomp.fortran/target1.f90   -Os  (test for excess errors)
PASS: libgomp.fortran/target1.f90   -Os  execution test

Same as above.


That's testing the default multilib on "Advanced Micro Devices, Inc. [AMD/ATI]
Fiji [Radeon R9 FURY / NANO Series] (rev ca)" hardware.  (I haven't tested
anything else.)

There seems to be some bug?


But also:


The error reporting seems "strange"?


We shouldn't run into a timeout?  (Missing unlocking on error path?)

[Bug libstdc++/95851] [10/11 Regression] std::to_chars(p, p, c, 2) segfault

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1624-gbe50843754b4c4d47f0d628a84b3dbf2a4145a43
Author: Jonathan Wakely 
Date:   Tue Jun 23 22:47:58 2020 +0100

libstdc++: Fix std::to_chars buffer overflow (PR 95851)

The __detail::__to_chars_2 function assumes it won't be called with zero
values. However, when the output buffer is empty the caller doesn't
handle zero values correctly, and calls __to_chars_2 with a zero value,
resulting in an overflow of the empty buffer.

The __detail::__to_chars_i function should just return immediately for
an empty buffer, and otherwise ensure zero values are handled properly.

libstdc++-v3/ChangeLog:

PR libstdc++/95851
* include/std/charconv (__to_chars_i): Check for zero-sized
buffer unconditionally.
* testsuite/20_util/to_chars/95851.cc: New test.

[Bug debug/95865] New: Wrong line information at Og

[massarelli at diag dot uniroma1.it]

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

Bug ID: 95865
   Summary: Wrong line information at Og
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: massarelli at diag dot uniroma1.it
  Target Milestone: ---

$ cat a.c
int g_4 = 3, a;
int *b() {
  if (g_4)
return &g_4; //line 4
  a = 0;
  return &g_4; //line 6
}

$ cat -n a.c
 1  int g_4 = 3, a;
 2  int *b() {
 3if (g_4)
 4  return &g_4; //line 4
 5a = 0;
 6return &g_4; //line 6
 7  }
 8  int main() { b(); }

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

$ gdb -v
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git

$ gcc -Og -g -o out a.c

$ gdb out
Reading symbols from out...done.
(gdb) b main
Breakpoint 1 at 0x40049f: file a.c, line 8.
(gdb) r
Starting program: out 
Breakpoint 1, main () at a.c:8
8   int main() { b(); }
(gdb) s
b () at a.c:3
3 if (g_4)
(gdb) p g_4
$1 = 3
(gdb) s
6 return &g_4; //line 6
(gdb) s
0x77a05b97 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)

[Bug pch/64117] warning control #pragmas in precompiled headers are not obeyed for template code

[fsmoke at mail dot ru]

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

fsmoke  changed:

   What|Removed |Added

 CC||fsmoke at mail dot ru

--- Comment #4 from fsmoke  ---
Problem persists in gcc 9.3.

very very sadly

[Bug tree-optimization/95866] New: vectorized shift with scalar argument not correctly costed

[rguenth at gcc dot gnu.org]

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

Bug ID: 95866
   Summary: vectorized shift with scalar argument not correctly
costed
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

int x[4];
void foo(int i)
{
  i = (i+1) & 31;
  x[0] = (x[0] << i) + i;
  x[1] = (x[1] << i) + i;
  x[2] = (x[2] << i) + i;
  x[3] = (x[3] << i) + i;
}

for this testcase we're not correctly assessing that we leave the
scalar computation for (i+1) & 31 around for the generated
vectorized shift by a scalar argument.  Since we're in need of
the vector of { i,... } for the vectorized add we ideally should
simply use lane zero for the shift operand rather than the original
SSA name as we do.  Currently:

  _22 = {i_14(D), i_14(D), i_14(D), i_14(D)};
  vect_cst__23 = _22;
  vect_cst__24 = { 1, 1, 1, 1 };
  vect__1.6_25 = vect_cst__23 + vect_cst__24;
  vect_cst__26 = { 31, 31, 31, 31 };
  vect_i_15.7_27 = vect__1.6_25 & vect_cst__26;
  _1 = i_14(D) + 1;
  i_15 = _1 & 31;
  vect__2.5_21 = MEM  [(int *)&x];
  vect__3.8_28 = vect__2.5_21 << i_15;
  vect__4.9_29 = vect__3.8_28 + vect_i_15.7_27;
  MEM  [(int *)&x] = vect__4.9_29;
  return;

where arguably we should have done the (i+1) & 31 compute with scalars
and broadcast the result.  Assembly:

foo:
.LFB0:
.cfi_startproc
leal1(%rdi), %eax
movdqa  x(%rip), %xmm1
movd%edi, %xmm3
andl$31, %eax
pshufd  $0, %xmm3, %xmm0
paddd   .LC0(%rip), %xmm0
movq%rax, %xmm2
pand.LC1(%rip), %xmm0
pslld   %xmm2, %xmm1
paddd   %xmm1, %xmm0
movaps  %xmm0, x(%rip)
ret

which is really bad.  Even with that optimization simulated by using
'i' as provided by the function argument we generate

foo:
.LFB0:
.cfi_startproc
movdqa  x(%rip), %xmm1
movslq  %edi, %rax
movd%edi, %xmm3
movq%rax, %xmm2
pshufd  $0, %xmm3, %xmm0
pslld   %xmm2, %xmm1
paddd   %xmm1, %xmm0
movaps  %xmm0, x(%rip)
ret

so RTL optimizations do not recover here either.  combine sees

(insn 8 3 9 2 (set (reg:DI 89 [ i ])
(sign_extend:DI (reg/v:SI 86 [ i ]))) "t.c":5:16 147
{*extendsidi2_rex64}
 (nil))
(insn 10 9 11 2 (set (reg:V4SI 90 [ vect__2.6 ])
(ashift:V4SI (reg:V4SI 91 [ MEM  [(int *)&x] ])
(reg:DI 89 [ i ]))) "t.c":5:16 3739 {ashlv4si3} 
 (expr_list:REG_DEAD (reg:V4SI 91 [ MEM  [(int *)&x] ])
(expr_list:REG_DEAD (reg:DI 89 [ i ])
(nil
(insn 11 10 12 2 (set (reg:V4SI 92)
(vec_duplicate:V4SI (reg/v:SI 86 [ i ]))) "t.c":5:22 5169
{*vec_dupv4si}
 (expr_list:REG_DEAD (reg/v:SI 86 [ i ])
(nil)))
(insn 12 11 13 2 (set (reg:V4SI 93 [ vect__3.7 ])
(plus:V4SI (reg:V4SI 90 [ vect__2.6 ])
(reg:V4SI 92))) "t.c":5:22 3545 {*addv4si3}

so the opportunity to "back-propagate" the vec_duplicate for the shift
isn't appearant - nor would it ever consider such thing.

So we probably should try to fix this in the vectorizer.  IIRC this support
for non-external/constant scalar shift args is reasonably new (g:49eab32e6e7).
Also if there's a vector-vector shift we should probably prefer that if
we already have a vector.

[Bug tree-optimization/95866] vectorized shift with scalar argument not correctly costed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-24
 Ever confirmed|0   |1
   Keywords||missed-optimization
 Blocks||53947
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/95867] New: Failure to optimize successive multiplications of ___uint128_t

[gabravier at gmail dot com]

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

Bug ID: 95867
   Summary: Failure to optimize successive multiplications of
___uint128_t
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

__uint128_t f(__uint128_t n)
{
return
n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n;
}

This can be optimized to 

__uint128_t f2(__uint128_t n)
{
__uint128_t tmp = n * n;
tmp = (tmp * tmp) * n;
tmp *= tmp;
tmp *= tmp;
tmp *= tmp;
tmp = (tmp * tmp) * n;
tmp = (tmp * tmp) * n;
tmp *= tmp;
return (tmp * n) * tmp;
}

This transformation is done by LLVM, but not by GCC.

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[gabravier at gmail dot com]

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

--- Comment #1 from Gabriel Ravier  ---
PS : Of course this can be optimized in the general case, I was only giving an
example here, I wouldn't want only the pattern of 653 successive
multiplications to be optimized

[Bug fortran/95868] New: Derived-type deferred-length character component handling broken

[burnus at gcc dot gnu.org]

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

Bug ID: 95868
   Summary: Derived-type deferred-length character component
handling broken
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The following program fails with an ICE or a segfault.

Issues I observed:

* For the ICE, the issue seems to be:
  gfc_conv_loop_setup() calls
gfc_add_loop_ss_code (loop, loop->ss, false, where)
  expr = ss_info->expr;
 case GFC_SS_SCALAR:
  gfc_conv_expr (&se, expr);
  → The ICE occur because expr == NULL and expr is dereferenced.

  I am not sure whether it is the following code, but it sets
  ss-info->expr and I bet ss.end == NULL in my testcase, but I
  have not check it: 
gfc_walk_array_ref()
  if (ref->type == REF_SUBSTRING)
{
  ss = gfc_get_scalar_ss (ss, ref->u.ss.start);
  ss = gfc_get_scalar_ss (ss, ref->u.ss.end);
}
and the second argument is the 'expr'.


* For derived-type deferred strings, one often has the intcst "0" in the tree.
  for gfc_conv_expr_descriptor, for the simple case, that's handled
  (search: deferred_array_component).
  However, for the complicated case, one might end up with
"0 = 0;"
  which the gimplifier does not like.
  I am not sure whether the patch is correct, but it fixes one testcase
  for me (not shown, OpenMP one) and looks more sensible. I am not sure
  whether VAR_P(se->string_length) makes sense and when it gets set or
  defined. 

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 54e1107c711..6da8c6d5595 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7551,15 +7551,14 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
   /* Set the string_length for a character array.  */
   if (expr->ts.type == BT_CHARACTER)
{
- se->string_length =  gfc_get_expr_charlen (expr);
- if (VAR_P (se->string_length)
- && expr->ts.u.cl->backend_decl == se->string_length)
-   tmp = ss_info->string_length;
- else
-   tmp = se->string_length;
-
- if (expr->ts.deferred)
-   gfc_add_modify (&se->pre, expr->ts.u.cl->backend_decl, tmp);
+ tmp = gfc_get_expr_charlen (expr);
+ if (!VAR_P (expr->ts.u.cl->backend_decl))
+   se->string_length = (expr->ts.deferred ? ss_info->string_length
+  : tmp);
+ else if (expr->ts.deferred
+  && se->string_length != expr->ts.u.cl->backend_decl)
+   gfc_add_modify (&se->pre, expr->ts.u.cl->backend_decl,
+   ss_info->string_length);
}

   /* If we have an array section, are assigning  or passing an array

--
implicit none
type t
  character(len=:), allocatable :: str(:)
end type t
type (t) :: var
character(len=:), allocatable :: str(:)
integer :: i

allocate(character(len=3) :: str(3))
str(:) = ["abc", "def", "ghi"]
!call dummy(str)! OK
!call dummy(str(2:))! OK
!call dummy(str(:)(2:)) ! (1) ICE

!call sub1(str) ! OK
!call sub2(str(2:)) ! (2) Segfault at runtime
!call sub3(str(:)(2:))  ! (3) ICE

var%str = ["abc", "def", "ghi"]
!call sub1(var%str)! (4) Fails at runtime ('stop 1')
!call sub2(var%str(2:))! (5) Fails at runtime ('stop 1')
!call sub3(var%str(:)(2:)) ! ICE
deallocate(str,var%str)
contains
  subroutine dummy(x)
character(len=1), dimension(*) :: x
  end
  subroutine sub1(x)
character(len=*), dimension(*) :: x
if (len(x) /= 3) stop 1
if (any (x(1:3) /= ["abc", "def", "ghi"])) stop 2
  end
  subroutine sub2(x)
character(len=*), dimension(*) :: x
if (len(x) /= 3) stop 3
if (any (x(1:2) /= ["def", "ghi"])) stop 4
  end
  subroutine sub3(x)
character(len=*), dimension(*) :: x
if (len(x) /= 2) stop 5
if (any (x(1:3) /= ["bc", "ef", "hi"])) stop 6
  end
end

[Bug target/95259] Duplicated codes in libgcc, driver-i386.c and i386-builtins.c

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:1890f2f0e210ef515c39728c54151372d36dd187

commit r11-1627-g1890f2f0e210ef515c39728c54151372d36dd187
Author: H.J. Lu 
Date:   Mon May 18 05:58:41 2020 -0700

x86: Move cpuinfo.h from libgcc to common/config/i386

Both x86 backend and libgcc define enum processor_features.  libgcc sets
enum processor_feature and x86 backend checks enum processor_feature.
They are very easy out of sync and it has happened multiple times in the
past.

1. Move cpuinfo.h from libgcc to common/config/i386 so that we can share
the same enum processor_features in x86 backend and libgcc.
2. Change __cpu_features2 to an array to support more processor features.
3. Add more processor features to enum processor_features.

gcc/

PR target/95259
* common/config/i386/cpuinfo.h: New file.
(__processor_model): Moved from libgcc/config/i386/cpuinfo.h.
(__processor_model2): New.
(CHECK___builtin_cpu_is): New.  Defined as empty if not defined.
(has_cpu_feature): New function.
(set_cpu_feature): Likewise.
(get_amd_cpu): Moved from libgcc/config/i386/cpuinfo.c.  Use
CHECK___builtin_cpu_is.  Return AMD CPU name.
(get_intel_cpu): Moved from libgcc/config/i386/cpuinfo.c.  Use
Use CHECK___builtin_cpu_is.  Return Intel CPU name.
(get_available_features): Moved from libgcc/config/i386/cpuinfo.c.
Also check FEATURE_3DNOW, FEATURE_3DNOWP, FEATURE_ADX,
FEATURE_ABM, FEATURE_CLDEMOTE, FEATURE_CLFLUSHOPT, FEATURE_CLWB,
FEATURE_CLZERO, FEATURE_CMPXCHG16B, FEATURE_CMPXCHG8B,
FEATURE_ENQCMD, FEATURE_F16C, FEATURE_FSGSBASE, FEATURE_FXSAVE,
FEATURE_HLE, FEATURE_IBT, FEATURE_LAHF_LM, FEATURE_LM,
FEATURE_LWP, FEATURE_LZCNT, FEATURE_MOVBE, FEATURE_MOVDIR64B,
FEATURE_MOVDIRI, FEATURE_MWAITX, FEATURE_OSXSAVE,
FEATURE_PCONFIG, FEATURE_PKU, FEATURE_PREFETCHWT1, FEATURE_PRFCHW,
FEATURE_PTWRITE, FEATURE_RDPID, FEATURE_RDRND, FEATURE_RDSEED,
FEATURE_RTM, FEATURE_SERIALIZE, FEATURE_SGX, FEATURE_SHA,
FEATURE_SHSTK, FEATURE_TBM, FEATURE_TSXLDTRK, FEATURE_VAES,
FEATURE_WAITPKG, FEATURE_WBNOINVD, FEATURE_XSAVE, FEATURE_XSAVEC,
FEATURE_XSAVEOPT and FEATURE_XSAVES
(cpu_indicator_init): Moved from libgcc/config/i386/cpuinfo.c.
Also update cpu_model2.
* common/config/i386/i386-cpuinfo.h (processor_vendor): Add
Add VENDOR_CENTAUR, VENDOR_CYRIX and VENDOR_NSC.
(processor_features): Moved from gcc/config/i386/i386-builtins.c.
Renamed F_XXX to FEATURE_XXX.  Add FEATURE_3DNOW, FEATURE_3DNOWP,
FEATURE_ADX, FEATURE_ABM, FEATURE_CLDEMOTE, FEATURE_CLFLUSHOPT,
FEATURE_CLWB, FEATURE_CLZERO, FEATURE_CMPXCHG16B,
FEATURE_CMPXCHG8B, FEATURE_ENQCMD, FEATURE_F16C,
FEATURE_FSGSBASE, FEATURE_FXSAVE, FEATURE_HLE, FEATURE_IBT,
FEATURE_LAHF_LM, FEATURE_LM, FEATURE_LWP, FEATURE_LZCNT,
FEATURE_MOVBE, FEATURE_MOVDIR64B, FEATURE_MOVDIRI,
FEATURE_MWAITX, FEATURE_OSXSAVE, FEATURE_PCONFIG,
FEATURE_PKU, FEATURE_PREFETCHWT1, FEATURE_PRFCHW,
FEATURE_PTWRITE, FEATURE_RDPID, FEATURE_RDRND, FEATURE_RDSEED,
FEATURE_RTM, FEATURE_SERIALIZE, FEATURE_SGX, FEATURE_SHA,
FEATURE_SHSTK, FEATURE_TBM, FEATURE_TSXLDTRK, FEATURE_VAES,
FEATURE_WAITPKG, FEATURE_WBNOINVD, FEATURE_XSAVE, FEATURE_XSAVEC,
FEATURE_XSAVEOPT, FEATURE_XSAVES and CPU_FEATURE_MAX.
(SIZE_OF_CPU_FEATURES): New.
* config/i386/i386-builtins.c (processor_features): Removed.
(isa_names_table): Replace F_XXX with FEATURE_XXX.
(fold_builtin_cpu): Change __cpu_features2 to an array.

libgcc/

PR target/95259
* config/i386/cpuinfo.c: Don't include "cpuinfo.h".  Include
"common/config/i386/i386-cpuinfo.h" and
"common/config/i386/cpuinfo.h".
(__cpu_features2): Changed to array.
(get_amd_cpu): Removed.
(get_intel_cpu): Likewise.
(get_available_features): Likewise.
(__cpu_indicator_init): Call cpu_indicator_init.
* config/i386/cpuinfo.h: Removed.

[Bug target/95864] [11 Regression] GCN offloading execution regressions after commit f062c3f11505b70c5275e5bc0e52f3e441f8afbc "amdgcn: Switch to HSACO v3 binary format"

[ams at gcc dot gnu.org]

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

--- Comment #1 from Andrew Stubbs  ---
I'm aware of these issues.

I fixed all the test failures that were definitely bugs in the HSACOv3
implementation, and the ones that remain appear to be either latent bugs
uncovered by the new driver configuration, or possibly even not our problem.

Of course, I could be mistaken, but I won't find out until I find time to look
closer.

[Bug target/95259] Duplicated codes in libgcc, driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed for GCC 11.

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[andrea.corallo at arm dot com]

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

--- Comment #4 from Andrea Corallo  ---
"aoliva at gcc dot gnu.org"  writes:

> --- Comment #3 from Alexandre Oliva  ---
> akrl, any clue as to where this .out is coming from in your runs?  I get .exe
> in my arm test runs; I don't see anything that selects .out, only .exe; and 
> the
> driver disregards the .exe suffix in executable output, regardless of 
> platform,
> when recognizing that the single source has the same basename as the linker
> output.

Hi Alexandre,

Apologies I guess the provided example was not the best.

Here what I've specifically for the mentioned testcase, this is the
compiler invocation:

.../build/gcc/xgcc -B.../build/gcc/
.../src/gcc/gcc/testsuite/gcc.target/arm/memset-inline-1.c gcc_tg.o
-march=armv8.1-m.main -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -save-temps -O2 -fno-inline -ffat-lto-objects
-fno-ident -specs=rdimon.specs -Wa,-mno-warn-deprecated
-Wl,-Ttext-segment=0x0050 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main
-Wl,-wrap,abort -lm -o ./memset-inline-1.exe

The assembly file generated is called
'memset-inline-1-memset-inline-1.s' but IIUC the expected one by proc
'scan-assembler-not' (scanasm.exp:92) is 'memset-inline-1.s' (I'm just
printing $output_file).

Hope it helps.

  Andrea

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Not really __uint128_t related.  Since PR18589 we perform such optimizations on
floating point multiply, and on signed integers we punt on reassociation
because of the undefined signed overflow issues (the proposal to do a very late
reassoc that would essentially turn on -fwrapv from that point onwards or at
least turn rewritten expressions into unsigned ones has not materialized yet),
but for unsigned integral types we could indeed replace those with the minimal
number of multiplications.
Or alternatively we could do that in forwprop1, which can handle similar case
for addition into multiplications, though I guess only reassoc will be able to
handle it if it isn't just one variable as the multiplication operands, but
several.
return x * x * y * z * x * z * x * w * w * u * x * z * y * w * u * x * x * w *
w * w;
etc.

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-24
   Keywords||missed-optimization

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
It's done through POWI internally, I guess we could open the internal function
to also operate on integers...

As for overflow for a multiplication chain of the same operand there shouldn't
be any issue, but not sure how far we should go with signed arithmetic support
early (for the late reassoc the idea is still to set flag_wrapv = 1).

We could carefully handle some cases by ensuring to only perform
"safe" linearization and for the resulting chains adjust operand sorting
to only perform "safe" commutations (basically not sort, only optimize
trailing constants / cancellations).

[Bug target/95864] [11 Regression] GCN offloading execution regressions after commit f062c3f11505b70c5275e5bc0e52f3e441f8afbc "amdgcn: Switch to HSACO v3 binary format"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug ipa/95859] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

[tobi at gcc dot gnu.org]

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

--- Comment #2 from Tobias Schlüter  ---
Created attachment 48779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48779&action=edit
Preprocessed source x86 (32bit)

Here's preprocessed source for x86 (32 bit).  This shows the same behavior as
verified with the compiler explorer.

[Bug target/95843] Duplicated ISA info in driver-i386.c and i386-builtins.c

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1629-g6c35d16a3925958b3a22426de0cb8e04f654b6dd
Author: H.J. Lu 
Date:   Wed Jun 24 04:39:16 2020 -0700

x86: Share _isa_names_table and use cpuinfo.h

Both driver-i386.c and libgcc use CPUID to detect the processor name
as well as available ISAs.  To detect the same processor or ISAs, the
same detection logic is duplicated in 2 places.  Sometimes only one place
was up to date or got it right.  Sometimes both places got it wrong.

1. Add common/config/i386/i386-isas.h to define _isa_names_table.
2. Use isa_names_table to auto-generate ISA command-line options.
3. Use isa_names_table to auto-generate __builtin_cpu_supports tests.
4. Use common/config/i386/cpuinfo.h to check available ISAs and detect
newer Intel processors in driver-i386.c and builtin_target.c.
5. Detection of AMD processors and older processors in driver-i386.c is
unchanged.

gcc/

PR target/95843
* common/config/i386/i386-isas.h: New file.  Extracted from
gcc/config/i386/i386-builtins.c.
(_isa_names_table): Add option.
(ISA_NAMES_TABLE_START): New.
(ISA_NAMES_TABLE_END): Likewise.
(ISA_NAMES_TABLE_ENTRY): Likewise.
(isa_names_table): Defined with ISA_NAMES_TABLE_START,
ISA_NAMES_TABLE_END and ISA_NAMES_TABLE_ENTRY.  Add more ISAs
from enum processor_features.
* config/i386/driver-i386.c: Include
"common/config/i386/cpuinfo.h" and
"common/config/i386/i386-isas.h".
(has_feature): New macro.
(host_detect_local_cpu): Call cpu_indicator_init to get CPU
features.  Use has_feature to detect processor features.  Call
Call get_intel_cpu to get the newer Intel CPU name.  Use
isa_names_table to generate command-line options.
* config/i386/i386-builtins.c: Include
"common/config/i386/i386-isas.h".
(_arch_names_table): Removed.
(isa_names_table): Likewise.

gcc/testsuite/

PR target/95843
* gcc.target/i386/builtin_target.c: Include ,
../../../common/config/i386/i386-cpuinfo.h and
../../../common/config/i386/cpuinfo.h.
(check_amd_cpu_model): Removed.
(check_intel_cpu_model): Likewise,
(CHECK___builtin_cpu_is): New.
(gcc_assert): New.  Defined as assert.
(gcc_unreachable): New.  Defined as abort.
(inline): New.  Defined as empty.
(ISA_NAMES_TABLE_START): Likewise.
(ISA_NAMES_TABLE_END): Likewise.
(ISA_NAMES_TABLE_ENTRY): New.
(check_features): Include
"../../../common/config/i386/i386-isas.h".
(check_detailed): Call cpu_indicator_init.  Always call
check_features.  Call get_amd_cpu instead of check_amd_cpu_model.
Call get_intel_cpu instead of check_intel_cpu_model.

[Bug target/95774] __builtin_cpu_is can't detect cooperlake

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:403e166b974f53982d78efdd70938d05b6983b2a

commit r11-1630-g403e166b974f53982d78efdd70938d05b6983b2a
Author: H.J. Lu 
Date:   Fri Jun 19 21:17:26 2020 -0700

x86: Add Cooper Lake detection with AVX512BF16

All Sky Lake family processors have the same CPUID model number, 0x55.
The differences are Cascade Lake has AVX512VNNI and Cooper Lake has
AVX512VNNI + AVX512BF16.  Check AVX512BF16 for Cooper Lake.

PR target/95774
* common/config/i386/cpuinfo.h (get_intel_cpu): Add Cooper Lake
detection with AVX512BF16.

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
What I find interesting is a similar case with the division instead of the
addition. Clang compiles it to:

divps   %xmm1, %xmm0
retq

Considering that we have [a0, a1, 0, 0] / [b0, b1, 0, 0], this will surely fire
invalid operation exception. I have explicitly avoided generation of division
using 4-element DIVPS for v2sf operands exactly due to this issue.

[Bug libstdc++/95851] [10/11 Regression] std::to_chars(p, p, c, 2) segfault

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8360-gff5c8fe44a98025c1e700cfc033247965e293869
Author: Jonathan Wakely 
Date:   Tue Jun 23 22:47:58 2020 +0100

libstdc++: Fix std::to_chars buffer overflow (PR 95851)

The __detail::__to_chars_2 function assumes it won't be called with zero
values. However, when the output buffer is empty the caller doesn't
handle zero values correctly, and calls __to_chars_2 with a zero value,
resulting in an overflow of the empty buffer.

The __detail::__to_chars_i function should just return immediately for
an empty buffer, and otherwise ensure zero values are handled properly.

libstdc++-v3/ChangeLog:

PR libstdc++/95851
* include/std/charconv (__to_chars_i): Check for zero-sized
buffer unconditionally.
* testsuite/20_util/to_chars/95851.cc: New test.

(cherry picked from commit be50843754b4c4d47f0d628a84b3dbf2a4145a43)

[Bug ipa/95859] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

[tobi at gcc dot gnu.org]

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

--- Comment #3 from Tobias Schlüter  ---
ps here's the compiler explorer link for the preprocessed test. 
https://godbolt.org/z/zDw5JQ

I tried manually reducing it, but couldn't easily get below the 1000kib limit.

[Bug target/95843] Duplicated ISA info in driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/95774] __builtin_cpu_is can't detect cooperlake

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/95660] get_intel_cpu in cpuinfo.c contains unnecessary check for brand_id

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:134f7c941929b3d099322a89928c04e5ac69267e

commit r11-1631-g134f7c941929b3d099322a89928c04e5ac69267e
Author: H.J. Lu 
Date:   Fri Jun 12 16:33:23 2020 -0700

x86: Remove brand ID check for Intel processors

Brand ID was a feature that briefly existed in some Pentium III and
Pentium 4 CPUs.  The CPUs that had non-zero brand ID still have had
valid family/model.  Brand ID just gives a marketing name for the CPU.
Remove the extra code for brand ID check.

gcc/

PR target/95660
* common/config/i386/cpuinfo.h (get_intel_cpu): Remove brand_id.
(cpu_indicator_init): Likewise.
* config/i386/driver-i386.c (host_detect_local_cpu): Updated.

gcc/testsuite/

PR target/95660
* gcc.target/i386/builtin_target.c (check_detailed): Updated.

[Bug target/95660] get_intel_cpu in cpuinfo.c contains unnecessary check for brand_id

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed for GCC 11.

[Bug fortran/95869] New: ICE when "target parallel" construct used with "if" clause in Fortran

[kcy at codesourcery dot com]

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

Bug ID: 95869
   Summary: ICE when "target parallel" construct used with "if"
clause in Fortran
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kcy at codesourcery dot com
  Target Milestone: ---

Compiling the following program results in an ICE:

program target_parallel_if
  implicit none

  integer, parameter :: N = 100
  integer, parameter :: LIMIT = 60
  integer :: i, j
  integer, dimension(N) :: a = (/ (i, i = 1,N) /)
  do j = 1, N
!$omp target parallel if(j .lt. LIMIT) map(tofrom: a(1:N))
do i = 1, N
  a(i) = a(i) + 1
end do
!$omp end target parallel
end do
end program

$ x86_64-none-linux-gnu-gfortran target_parallel_if.f90 -O -fopenmp -S -o
target_parallel_if.s 
target_parallel_if.f90:9:0:

9 | !$omp target parallel if(j .lt. LIMIT) map(tofrom: a(1:N))
  | 
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2830
0xf6c765 gimplify_var_or_parm_decl
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:2830
0xf9efdc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:14071
0xf76084 gimplify_modify_expr
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:5782
0xf9d09b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:13612
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf696fc gimplify_statement_list
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1869
0xf9ef01 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:14055
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf67d53 gimplify_bind_expr
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1424
0xf9ddfc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:13812
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf696fc gimplify_statement_list
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1869
0xf9ef01 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:14055
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf67d53 gimplify_bind_expr
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1424
0xf9ddfc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:13812
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf65136 gimplify_and_add(tree_node*, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:486
0xf6960a gimplify_loop_expr
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1843
0xf9de1d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:13816
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The issue seems to have been present since GCC 8. In GCC 7, it also ICEs but
with a different backtrace:

$ x86_64-none-linux-gnu-gfortran target_parallel_if.f90 -O -fopenmp -S -o
target_parallel_if.s
f951: internal compiler error: in parse_omp_structured_block, at
fortran/parse.c:5096
0x89fec2 parse_omp_structured_block 
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/fortran/parse.c:5096 
0x8a02f5 parse_executable   
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/fortran/parse.c:5345 
0x89f541 parse_do_block 
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/fortran/parse.c:4649 
0x8a0280 parse_executable   
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/fortran/parse.c:5299 
0x8a0c04 par

[Bug c++/95870] New: ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[viktor.rosendahl at bmw dot de]

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

Bug ID: 95870
   Summary: ICE(segmentation fault) in most_general_template(), in
gcc/cp/pt.c
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: viktor.rosendahl at bmw dot de
  Target Milestone: ---

Created attachment 48780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48780&action=edit
Selfcontained example (preprocessed cource code)

I can reproduce this bug with the following gcc versions:
9.3.0
10.1.0
11.0.0 20200624 (experimental) [this was built with revision eb0ff770e29 from
git://gcc.gnu.org/git/gcc.git, which was the tip of the master branch on 24th
of June, 2020]

The bug does not happen with:
7.5.0

I have not tested any 8.x version.

All compilers were built from pristine sources, no patches added.

My system is a x86_64 machine with Ubuntu 18.04.4 LTS.

I configured all compiler builds like this:
./configure --disable-multilib --prefix=/home/viktor/gcc-bin-9.3.0
--enable-languages=c,c++

Steps to reproduce:
xz -dc preproc_example4.ii.xz > preproc_example4.ii
g++  -c -pipe -O2 -Wall -std=c++17 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG
-DQT_GUI_LIB -DQT_CORE_LIB  -o obj/example4.o preproc_example4.ii

I get the following output (with gcc-9.3.0):
example4.cpp: In instantiation of ‘BungleFooBar::BungleFooBar() [with U =
FailFoo; V = BotchFoo]’:
example4.cpp:44:22:   required from here
example4.cpp:17:5: internal compiler error: Segmentation fault
   17 | MACRO_FOOBAR(foofoobar, bar);
  | ^
0xb8ff1f crash_signal
../.././gcc/toplev.c:326
0x6e4260 most_general_template(tree_node*)
../.././gcc/cp/pt.c:23652
0x6e457d enclosing_instantiation_of
../.././gcc/cp/pt.c:13424
0x701c53 tsubst_function_decl
../.././gcc/cp/pt.c:12943
0x6fe2b8 tsubst_decl
../.././gcc/cp/pt.c:13464
0x6f9ee7 tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:14365
0x70263a lookup_template_class_1
../.././gcc/cp/pt.c:9483
0x70263a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../.././gcc/cp/pt.c:9771
0x700e5d tsubst_aggr_type
../.././gcc/cp/pt.c:12764
0x6f9cbf tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:14447
0x6fe940 tsubst_decl
../.././gcc/cp/pt.c:13731
0x6f9ee7 tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:14365
0x6f42ce tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17173
0x6f2378 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17088
0x6f24ec tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17389
0x6f24ec tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17389
0x6f5885 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17073
0x6f5885 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:18301
0x6f7775 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:19666
0x6f618e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:18918
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/95871] New: Duplicated error message : "the value is not usable in a constant expression"

[haoxintu at gmail dot com]

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

Bug ID: 95871
   Summary: Duplicated error message : "the value is not usable in
a constant expression"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This code, bug.cc, GCC emits two duplicated error messages in "the value of ‘a’
is not usable in a constant expression".

$cat bug.cc
long a = 10;
enum E { emator_1 = a } enum_var;

$g++ -c bug.cc
bug.cc:2:21: error: the value of ‘a’ is not usable in a constant expression
2 | enum E { emator_1 = a } enum_var;
  | ^
bug.cc:1:6: note: ‘long int a’ is not const
1 | long a = 10;
  |  ^
bug.cc:2:21: error: the value of ‘a’ is not usable in a constant expression
2 | enum E { emator_1 = a } enum_var;
  | ^
bug.cc:1:6: note: ‘long int a’ is not const
1 | long a = 10;
  |  ^
bug.cc:2:21: error: enumerator value for ‘emator_1’ is not an integer constant
2 | enum E { emator_1 = a } enum_var;
  |   

While in clang
$clang++ -c bug.cc
bug.cc:2:21: error: expression is not an integral constant expression
enum E { emator_1 = a } enum_var;
^
bug.cc:2:21: note: read of non-const variable 'a' is not allowed in a constant
expression
bug.cc:1:6: note: declared here
long a = 10;
 ^
1 error generated.

I have tested in almost all GCC versions, they all have this issue.

[Bug c++/95872] New: Duplicated warning message in "-Wlogical-op"

[haoxintu at gmail dot com]

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

Bug ID: 95872
   Summary: Duplicated warning message in "-Wlogical-op"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This code, bug.cc, GCC emits two duplicated warning messages about it.

$cat bug.cc
int a = 10;
decltype(( a or a ) ? 1:0) var = 0;


$g++ -c -Wlogical-op bug.cc
bug.cc:2:14: warning: logical 'or' of equal expressions [-Wlogical-op]

2 | decltype(( a or a ) ? 1:0) var = 0;

  |~~^~~~

bug.cc:2:14: warning: logical 'or' of equal expressions [-Wlogical-op]

All GCC-6 to GCC-trunk versions have this issue.

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #1)
> GCC does not yet vectorize stmts without loads (and explicitely rejects
> vector types somewhere).

But this particular case might be easy since we already vectorize from CTORs,
we likely just disregard the BB because it doesn't contain any datarefs:

  _1 = BIT_FIELD_REF ;
  _2 = BIT_FIELD_REF ;
  _3 = _1 + _2;
  _4 = BIT_FIELD_REF ;
  _5 = BIT_FIELD_REF ;
  _6 = _4 + _5;
  _9 = {_3, _6};

vectorization might turn this into

 _10 = {_1, _4 };
 _11 = {_2, _5 };
 _9 = _10 + _11;

and then forwprop CTOR "folding" will get rid of the
_10 and _11 CTORs (until the vectorizer handles BIT_FIELD_REFs
of existing vectors).

So kind-of "easy hack" - Martin, your branch might already do this
(not give up on <= 1 datarefs).

[Bug c++/95873] New: Duplicated warning message "'class' tag used in naming 'union a'"

[haoxintu at gmail dot com]

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

Bug ID: 95873
   Summary: Duplicated warning message "'class' tag used in naming
'union a'"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This code, bug.cc, GCC emits two duplicated warning messages.

$cat bug.cc
union a{};
auto var = new (typename :: a );

$g++ -c -fpermissive bug.cc
bug.cc:2:29: warning: 'class' tag used in naming 'union a' [-fpermissive]
2 | auto var = new (typename :: a );
  | ^
bug.cc:1:7: note: 'union a' was previously declared here
1 | union a{};
  |   ^
bug.cc:2:29: warning: 'class' tag used in naming 'union a' [-fpermissive]
2 | auto var = new (typename :: a );
  | ^
bug.cc:1:7: note: 'union a' was previously declared here
1 | union a{};
  |   ^

All GCC-6 to GCC-trunk versions have this issue.

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
OK, with some pending patch applied and 

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index ca6bedc9cc8..3d5de39383c 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3130,7 +3130,7 @@ vect_slp_analyze_bb_1 (bb_vec_info bb_vinfo, int n_stmts,
bool &fatal)
   return false;
 }

-  if (BB_VINFO_DATAREFS (bb_vinfo).length () < 2)
+  if (0 && BB_VINFO_DATAREFS (bb_vinfo).length () < 2)
 {
   if (dump_enabled_p ())
 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,

this only fails to vectorize due to cost considerations (considering to
code-generate as I wrote):

0x53b15a0 _1 + _2 1 times vector_stmt costs 12 in body
0x53b15a0  1 times vec_construct costs 8 in prologue
0x53b15a0  1 times vec_construct costs 8 in prologue
0x5412d10 _1 + _2 1 times scalar_stmt costs 12 in body
0x5412d10 _4 + _5 1 times scalar_stmt costs 12 in body

but with -fno-vect-cost-model it "works" as I guessed.  For division
we correctly do not vectorize.

[Bug target/95874] New: CLWB isn't supported on Icelake client

[hjl.tools at gmail dot com]

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

Bug ID: 95874
   Summary: CLWB isn't supported on Icelake client
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

CLWB isn't supported on Ice Lake client.  Only Tiger Lake supports it.

[Bug c++/95875] New: Misleading error message "invalid use of incomplete type"

[haoxintu at gmail dot com]

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

Bug ID: 95875
   Summary: Misleading error message "invalid use of incomplete
type"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

$cat bug.cc
class A: 
public 
A,
A,
A
{} g_class;

$g++ -c bug.cc
bug.cc:5:1: error: invalid use of incomplete type ‘class A’
5 | A
  | ^
bug.cc:1:7: note: forward declaration of ‘class A’
1 | class A:
  |   ^
bug.cc:5:1: error: invalid use of incomplete type ‘class A’
5 | A
  | ^
bug.cc:1:7: note: forward declaration of ‘class A’
1 | class A:
  |   ^
bug.cc:5:1: error: invalid use of incomplete type ‘class A’
5 | A
  | ^
bug.cc:1:7: note: forward declaration of ‘class A’
1 | class A:
  |   ^

While in clang
$clang++ -c bug.cc
bug.cc:3:1: error: base class has incomplete type
A,
^
bug.cc:1:7: note: definition of 'A' is not complete until the closing '}'
class A: 
  ^
1 error generated.

I doubt that how GCC deals with this case. I guess there might be two
situations:
1. GCC gives the wrong line number.
2. GCC just emits the duplicated messages.

I guess GCC might have the second issue. I have tested in almost all GCC
versions, and they all have this issue.

[Bug libstdc++/95851] [10/11 Regression] std::to_chars(p, p, c, 2) segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for 10.2

[Bug go/95876] New: Error in compiling gcc-11-20200621 with gcc-10 without -g

[570070308 at qq dot com]

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

Bug ID: 95876
   Summary: Error in compiling gcc-11-20200621 with gcc-10 without
-g
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: 570070308 at qq dot com
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 48781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48781&action=edit
fullscreenlog and a sh file

This is my host gcc version:
ig@ig-vmware71:~$ gcc-10 -v
Using built-in specs.
COLLECT_GCC=gcc-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.1.0-3ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--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-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --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=/build/gcc-10-JWjDxk/gcc-10-10.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-JWjDxk/gcc-10-10.1.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (Ubuntu 10.1.0-3ubuntu1)

The status:
Successfully building gcc-11-20200614 with gcc-10 by default.
Successfully building gcc-11-20200614 with gcc-10 without -g.
Successfully building gcc-11-20200621 with gcc-10 by default.
Failed building gcc-11-20200621 with gcc-10 without -g.


Part of the error log:
mv -f .deps/matmul_c8.Tpo .deps/matmul_c8.Plo
f="context.o"; if test ! -f $f; then f="./.libs/context.o"; fi;
x86_64-linux-gnu-objcopy -j .go_export $f context.s-gox.tmp; /bin/bash
../../../../gcc-11-20200621/libgo/mvifdiff.sh context.s-gox.tmp `echo
context.s-gox | sed -e 's/s-gox/gox/'`
echo timestamp > context.s-gox
f="crypto/cipher.o"; if test ! -f $f; then f="crypto/.libs/cipher.o"; fi;
x86_64-linux-gnu-objcopy -j .go_export $f crypto/cipher.s-gox.tmp; /bin/bash
../../../../gcc-11-20200621/libgo/mvifdiff.sh crypto/cipher.s-gox.tmp `echo
crypto/cipher.s-gox | sed -e 's/s-gox/gox/'`
echo timestamp > crypto/cipher.s-gox
f="crypto/sha512.o"; if test ! -f $f; then f="crypto/.libs/sha512.o"; fi;
x86_64-linux-gnu-objcopy -j .go_export $f crypto/sha512.s-gox.tmp; /bin/bash
../../../../gcc-11-20200621/libgo/mvifdiff.sh crypto/sha512.s-gox.tmp `echo
crypto/sha512.s-gox | sed -e 's/s-gox/gox/'`
during GIMPLE pass: vrp
[01m[K../../../gcc-11-20200621/libgo/go/golang.org/x/crypto/ed25519/internal/edwards25519/edwards25519.go:[m[K
In function ‘[01m[Kedwards25519.GeDoubleScalarMultVartime[m[K’:
[01m[K../../../gcc-11-20200621/libgo/go/golang.org/x/crypto/ed25519/internal/edwards25519/edwards25519.go:879:1:[m[K
[01;31m[Kinternal compiler error: [m[KSegmentation fault
  879 | func GeDoubleScalarMultVartime(r *ProjectiveGroupElement, a *[32]byte,
A *ExtendedGroupElement, b *[32]byte) {
  | [01;31m[K^[m[K
echo timestamp > crypto/sha512.s-gox
f="crypto/ed25519/internal/edwards25519.o"; if test ! -f $f; then
f="crypto/ed25519/internal/.libs/edwards25519.o"; fi; x86_64-linux-gnu-objcopy
-j .go_export $f crypto/ed25519/internal/edwards25519.s-gox.tmp; /bin/bash
../../../../gcc-11-20200621/libgo/mvifdiff.sh
crypto/ed25519/internal/edwards25519.s-gox.tmp `echo
crypto/ed25519/internal/edwards25519.s-gox | sed -e 's/s-gox/gox/'`
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [Makefile:2870:
golang.org/x/crypto/ed25519/internal/edwards25519.lo] Error 1
make[4]: *** Waiting for unfinished jobs

The log is generated by `script ../screen.log`. It seems that the colorful
warning generated by compiler turn to Garbage characters. But the log is too
long so I can't copy the log from the shell. I will upload the full log file. I
will upload the full log file with an attached archive (rar) because the log
file is 31.2Mb, and it is too large to upload. Sorry.

All the build is in the same environment, and the same configure:
../gcc-11-20200621(gcc-11-202

[Bug c++/78906] ICE with a member variable template whose type is a decltype of a member variable template of a class template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
GCC >= 7 fixed, closing.

[Bug c++/88752] [8 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||mpolacek at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED

--- Comment #13 from Marek Polacek  ---
Even GCC 8 was fixed, closing.

[Bug c++/95870] ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-24
 Ever confirmed|0   |1

[Bug c++/95870] ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed, don't see any existing PRs for this.

Going to bisect + reduce.

[Bug tree-optimization/95853] Failure to optimize add overflow pattern to __builtin_add_overflow

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #10 from Tamar Christina  ---
Hi Vlad,

Just curious if you had a chance to think about an approach to this that would
be acceptable.

[Bug c++/95820] ICE in splice_late_return_type, at cp/pt.c:29034

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Hit this when reducing something:

template class a b[]()->int

So it'd be nice to fix it to alleviate problems when reducing C++ code.

[Bug c++/95870] ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Looks like it started with r251433.

[Bug c++/95870] ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Reduced, but invalid:

template  class a {
public:
  a();
  int b = [] { enum E {}; };
};
class c : a {
  c();
};
template  a::a() = default;
c::c() {}

[Bug fortran/95877] New: gfortran.dg/pr95689.f90

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95877
   Summary: gfortran.dg/pr95689.f90
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:84323d9fa7526496d844f167f6353e0ec12279e8, r9-8693 

This same error occurs on both gcc 8 and 9.  Bad backport maybe?

commit 84323d9fa7526496d844f167f6353e0ec12279e8
Author: Harald Anlauf 
Date:   Sat Jun 20 16:09:45 2020 +0200

PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015

With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer.  We now check that we do not
exceed the enlarged buffer size.

gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.

(cherry picked from commit 62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6)


Executing on host:
/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-9-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-9-test/gcc/testsuite/gfortran.dg/pr95689.f90   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never-O  -fsecond-underscore -S -o pr95689.s   
(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-9-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-9-test/gcc/testsuite/gfortran.dg/pr95689.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -fsecond-underscore -S -o pr95689.s
f951: internal compiler error: Segmentation fault
0x1090cd5b crash_signal
/home/seurer/gcc/git/gcc-9-test/gcc/toplev.c:326
gfortran: internal compiler error: Segmentation fault signal terminated program
f951

Unfortunately the traceback in gdb isn't much help:

Program received signal SIGSEGV, Segmentation fault.
0x3930313233343534 in ?? ()
(gdb) where
#0  0x3930313233343534 in ?? ()
#1  0x3930313233343536 in ?? ()
Cannot access memory at address 0x3334353637383940

[Bug tree-optimization/95866] vectorized shift with scalar argument not correctly costed

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1633-gc78907d514d65483c7ddfb4cb1f5c57f23da73d9
Author: Richard Biener 
Date:   Wed Jun 24 15:49:00 2020 +0200

tree-optimization/95866 - avoid vectorizing uniform SLP subgraphs

This avoids vectorizing SLP subgraphs that just compute uniform
operations on all-same operands.  That fixes the less interesting
(but most embarrasing) part of the testcase in the PR.  On the
way it also fixed a missing matches[0] reset in the last
refactoring touching that place.

2020-06-24  Richard Biener  

PR tree-optimization/95866
* tree-vect-slp.c (vect_slp_tree_uniform_p): New.
(vect_build_slp_tree_2): Properly reset matches[0],
ignore uniform constants.

* gcc.target/i386/pr95866-1.c: New testcase.

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
Patch – without one recursively checks the same type.

--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -330,6 +330,11 @@ gfc_has_alloc_comps (tree type, tree decl)
return false;
 }

+  if (GFC_DESCRIPTOR_TYPE_P (type)
+  && (GFC_TYPE_ARRAY_AKIND (type) == GFC_ARRAY_POINTER
+ || GFC_TYPE_ARRAY_AKIND (type) == GFC_ARRAY_POINTER_CONT))
+return false;
+
   if (GFC_DESCRIPTOR_TYPE_P (type) || GFC_ARRAY_TYPE_P (type))
 type = gfc_get_element_type (type);

[Bug c++/95870] [8/9/10/11 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
   Keywords||ice-on-valid-code
Summary|ICE(segmentation fault) in  |[8/9/10/11 Regression] ICE
   |most_general_template(), in |(segmentation fault) in
   |gcc/cp/pt.c |most_general_template(), in
   ||gcc/cp/pt.c

--- Comment #4 from Marek Polacek  ---
Valid code that ICEs:

template  struct S {
  S();
  int b = []() -> int { enum E {}; return 1; }();
};
struct C : S {
  C();
};
template  S::S() = default;
C::C() {}

[Bug rtl-optimization/89310] Poor code generation returning float field from a struct

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Maybe you can make a define_insn_and_split for the lshrdi3 plus this?
Which will split to an insn fewer immediately.

If you split after reload you need many extra patterns to get the most
basic optimisations done for its result...  But (at least in this case)
you do not need a peephole at least ;-)

[Bug c++/95878] New: ICE when compiling code that mixes an empty class, [[no_unique_address]] and non-trivial default and copy constructors

[boris.staletic at gmail dot com]

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

Bug ID: 95878
   Summary: ICE when compiling code that mixes an empty class,
[[no_unique_address]] and non-trivial default and copy
constructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris.staletic at gmail dot com
  Target Milestone: ---

Hello,

first, apologies for a bad title. I was unsure how to make it more descriptive.

My repro case looks suspiciously like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432

However, the bug in 90432 has been fixed in 10.1 and 9.3. I've encountered a
similar code that still triggers an ICE. Just like 90432, gcc 8 works fine.
I've encountered a non-minimal version of this bug while working on the
nanorange library.

The minimal code that causes ICE:

struct istream_iterator {
istream_iterator() {}
istream_iterator(const istream_iterator&) {}
};

istream_iterator next(istream_iterator&& bound) {
return static_cast(bound);
}

struct copy_result {
[[no_unique_address]] istream_iterator in;
};

int main() {
copy_result result{next(istream_iterator{})};
}


during RTL pass: expand
: In function 'int main()':
:15:45: internal compiler error: in assign_temp, at function.c:982
   15 |  copy_result result{next(istream_iterator{})};
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler returned: 1

[Bug fortran/95877] [9 regression] ICE in test case gfortran.dg/pr95689.f90 after r9-8693

[anlauf at gcc dot gnu.org]

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #0)
> g:84323d9fa7526496d844f167f6353e0ec12279e8, r9-8693 
> 
> This same error occurs on both gcc 8 and 9.  Bad backport maybe?

I do not get this error on x86_64-pc-linux-gnu, but we've seen this
before.

The backport was for a sort of borderline technical regression.
The fix is most likely contained in related patches that did not
backport straighforwardly.

I'd rather revert the commit on 8/9.

[Bug c++/93711] [9/10/11 Regression] ICE: [[no_unique_address] when constructing via template helper

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||boris.staletic at gmail dot com

--- Comment #5 from Marek Polacek  ---
*** Bug 95878 has been marked as a duplicate of this bug. ***

[Bug c++/93711] [9/10/11 Regression] ICE: [[no_unique_address] when constructing via template helper

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Another test:

struct istream_iterator {
istream_iterator() {}
istream_iterator(const istream_iterator&) {}
};

istream_iterator next(istream_iterator&& bound) {
return static_cast(bound);
}

struct copy_result {
[[no_unique_address]] istream_iterator in;
};

int main() {
copy_result result{next(istream_iterator{})};
}

[Bug c++/95878] ICE when compiling code that mixes an empty class, [[no_unique_address]] and non-trivial default and copy constructors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
(In reply to Boris Staletic from comment #0)
> Hello,
> 
> first, apologies for a bad title. I was unsure how to make it more
> descriptive.

No worries, thanks for the bug report.

It's actually a dup, but the additional testcase might be useful.

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

[Bug fortran/95879] [10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

While not embedded :


$ cat y1.f90
module m
contains
   integer function f(x) bind(c)
  use iso_c_binding
  c_funloc(f) = x
   end
end


$ cat y2.f90
module m
contains
   integer function f(x)
  use iso_c_binding
  c_funloc(f) = x
   end
end


$ gfortran-11-20200621 -c y2.f90
y2.f90:5:15:

5 |   c_funloc(f) = x
  |   1
Error: Function result 'f' at (1) is invalid as X argument to C_FUNLOC

[Bug fortran/95879] New: [10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[gs...@t-online.de]

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

Bug ID: 95879
   Summary: [10/11 Regression] ICE in gfc_get_derived_type, at
fortran/trans-types.c:2729
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190630 and 20190728 :


$ cat z1.f90
module m
contains
   integer function f(x) bind(c)
  use iso_c_binding
   contains
  subroutine s
 c_funloc(f) = x
  end
   end
end


$ cat z2.f90
module m
contains
   integer function f(x)
  use iso_c_binding
   contains
  subroutine s
 c_funloc(f) = x
  end
   end
end


$ gfortran-10-20190630 -c z1.f90
$
$ gfortran-11-20200621 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbce57f crash_signal
../../gcc/toplev.c:328
0x6d07a5 gfc_resolve_formal_arglist(gfc_symbol*)
../../gcc/fortran/resolve.c:313
0x6ebde2 do_traverse_symtree
../../gcc/fortran/symbol.c:4162
0x6d0fc3 resolve_formal_arglists
../../gcc/fortran/resolve.c:563
0x6d0fc3 resolve_contained_functions
../../gcc/fortran/resolve.c:1129
0x6d0fc3 resolve_types
../../gcc/fortran/resolve.c:17164
0x6d11a0 resolve_types
../../gcc/fortran/resolve.c:17186
0x6d11a0 resolve_types
../../gcc/fortran/resolve.c:17186
0x6cc7ac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17290
0x6b46f2 gfc_parse_file()
../../gcc/fortran/parse.c:6448
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug c++/95820] [10/11 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|ICE in  |[10/11 Regression] ICE in
   |splice_late_return_type, at |splice_late_return_type, at
   |cp/pt.c:29034   |cp/pt.c:29034
   Target Milestone|--- |10.2

--- Comment #4 from Marek Polacek  ---
Started with r10-6571-ga6ee556c7659877bb59b719f11ca2153e86ded59

[Bug fortran/95880] New: [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030

[gs...@t-online.de]

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

Bug ID: 95880
   Summary: [9/10/11 Regression] ICE in gfc_add_type, at
fortran/symbol.c:2030
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r8, started between 20200517 and 20200524 :


$ cat z1.f90
module m
end
block data
   use m
   integer m
end block data


$ cat z5.f90
module m
   type t
   end type
end
block data
   use m
   type(t) m
end block data


$ gfortran-11-20200517 -c z1.f90
z1.f90:5:12:

5 |integer m
  |1
Error: Symbol 'm' at (1) cannot have a type


$ gfortran-11-20200621 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbce57f crash_signal
../../gcc/toplev.c:328
0x6f02bc gfc_add_type(gfc_symbol*, gfc_typespec*, locus*)
../../gcc/fortran/symbol.c:2030
0x63eeed build_sym
../../gcc/fortran/decl.c:1685
0x649969 variable_decl
../../gcc/fortran/decl.c:2793
0x649969 gfc_match_data_decl()
../../gcc/fortran/decl.c:6195
0x6ad323 match_word
../../gcc/fortran/parse.c:65
0x6ad323 decode_statement
../../gcc/fortran/parse.c:376
0x6aed6a next_free
../../gcc/fortran/parse.c:1280
0x6aed6a next_statement
../../gcc/fortran/parse.c:1512
0x6b03bb parse_spec
../../gcc/fortran/parse.c:3923
0x6b4e30 parse_block_data
../../gcc/fortran/parse.c:6026
0x6b4e30 gfc_parse_file()
../../gcc/fortran/parse.c:6413
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95881] New: [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175

[gs...@t-online.de]

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

Bug ID: 95881
   Summary: [9/10/11 Regression] ICE in resolve_symbol, at
fortran/resolve.c:15175
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r7, with a missing attribute :


$ cat z1.f90
program p
   type t
  real, allocatable :: a[:]
   end type
   class(t) :: x
   allocate (x%a[*])
end


$ cat z2.f90
subroutine s(x)
   type t
  real, allocatable :: a[:]
   end type
   block
  class(t) :: x
  allocate (x%a[*])
   end block
end


$ gfortran-6 -c z1.f90 -fcoarray=lib
z1.f90:5:16:

class(t) :: x
1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer


$ gfortran-11-20200621 -c z1.f90 -fcoarray=single
z1.f90:5:16:

5 |class(t) :: x
  |1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer


$ gfortran-11-20200621 -c z1.f90 -fcoarray=lib
f951: internal compiler error: Segmentation fault
0xbce57f crash_signal
../../gcc/toplev.c:328
0x6cda25 resolve_symbol
../../gcc/fortran/resolve.c:15175
0x6ebde2 do_traverse_symtree
../../gcc/fortran/symbol.c:4162
0x6d1094 resolve_types
../../gcc/fortran/resolve.c:17175
0x6cc7ac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17290
0x6b48ec resolve_all_program_units
../../gcc/fortran/parse.c:6246
0x6b48ec gfc_parse_file()
../../gcc/fortran/parse.c:6493
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95882] New: [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[gs...@t-online.de]

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

Bug ID: 95882
   Summary: [9/10/11 Regression] ICE in gfc_get_derived_type, at
fortran/trans-types.c:2729
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20200517 and 20200524 :


$ cat z1.f90
module m
   type t
  character(((0)/0)) :: c
   end type
end


$ gfortran-11-20200517 -c z1.f90
z1.f90:3:22:

3 |   character(((0)/0)) :: c
  |  1
Error: Division by zero at (1)


$ gfortran-11-20200621 -c z1.f90
f951: internal compiler error: in gfc_get_derived_type, at
fortran/trans-types.c:2729
0x784843 gfc_get_derived_type(gfc_symbol*, int)
../../gcc/fortran/trans-types.c:2729
0x784b68 gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc/fortran/trans-types.c:1166
0x784dbe gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2247
0x729616 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1769
0x72c888 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5302
0x6ebde2 do_traverse_symtree
../../gcc/fortran/symbol.c:4162
0x72d08b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5801
0x707ca4 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2238
0x6b4b01 translate_all_program_units
../../gcc/fortran/parse.c:6294
0x6b4b01 gfc_parse_file()
../../gcc/fortran/parse.c:6546
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95882] [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

Related, with different backtraces :


$ cat z2.f90
module m
   character(((0)/0)) :: c = '123456789'
end


$ cat z3.f90
subroutine s(c)
   character(((0)/0)) :: c
end


$ cat z4.f90
program p
   character(((0)/0)) :: c
   common /x/ c
end


$ cat z5.f90
program p
   character(((0)/0)) :: c = '123456789'
   common c
end